Device drivers are not like normal programs since they cannot be run from the DOS command line. Instead they must be loaded in the CONFIG.SYS file at boot-up time using a device command.
Device drivers are, for all intents and purposes, a collection of routines in memory. Consider what happens when a file is opened from a high-level language. First the relevant sub-service of the DOS interrupt 21h is called to open the file. This then sends a sequence of commands to the relevant device driver. The device driver opens the file, and communicates with it using BIOS commands to access the disk. Thus the data requests get filtered from the program to DOS to the device driver to BIOS, which ultimately uses hardware commands to communicate directly with the hardware.
|Name of device||Name of driver|
|Printer||LPT1: LPT2: LPT3:|
|Serial Ports||COM1: COM2: COM3: COM4:|
|Disk drive A||A:|
|Disk drive B:||B:|
|Disk drive C:||C:|
The console device gets input from the keyboard and sends output to the screen. The printer drivers send output only to the printer; the number of the printer port is specified in after LPT. The NULL device simply ignores all output to it and generates no input.
Since the use and installation of device drivers is so obscure, a little experiment may help to show their presence. A standard device driver called ANSI.SYS is shipped with most versions of DOS. This driver is a replacement for the standard console driver. It allows the user of DOS to move the cursor, clear the screen, and set colours (among other uses) using standard output commands. With this driver installed, multi-colour DOS prompts can be generated just by setting the PROMPT command appropriately. Particular sequences of characters sent to the screen will be intercepted by the driver and interpreted to change the display characteristics. If the driver were not installed, these sequences will be printed on the screen.
The device header is a formatted table of information that the OS needs to set up and link in the device driver properly. The strategy and interrupt procedures are called by the OS. The rest of the driver is composed of routines that can be called within the driver.
The device driver is not simply called to perform a particular task. Instead, a device Request Header is formed in memory. This is a fixed-format table of information specifying what the device driver is expected to do.
The address of the request header is then passed as a parameter, in the ES:BX register pair, to the strategy procedure. The strategy procedure stores this address within the body of the device driver and returns control to the OS.
The OS then calls the interrupt procedure without any parameters. The interrupt procedure is expected to retrieve the address of the request header from where the strategy procedure had saved it. The request header specifies what is to be done and the interrupt procedure will carry out this task.
The reason for this delayed two-step process is that it allows for future expansion into multi-tasking environments with process scheduling and prioritizing.
For each type of device there is a set of commands that the driver must support. These commands are specified in the request header by DOS.
Typical device driver commands include:
In total there are 25 commands that need to be supported by a driver to achieve total transparency to the OS.