Device Drivers

Introduction

Device drivers are sets of procedures that are used to communicate with the hardware on the computer. The task performed by device drivers is in this respect similar to software interrupts. However, while each interrupt routine has a different calling strategy, all device drivers have a standard method of operation. This makes it possible to write programs that interface with arbitrary devices, either monitor, printer or disk drives.

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.

Built-in drivers

DOS has a number of built-in drivers to communicate with the console (keyboard+screen), printer, disk-drives, etc. The device drivers are given specific names.
Name of device Name of driver
Console CON:
Printer LPT1: LPT2: LPT3:
Serial Ports COM1: COM2: COM3: COM4:
Null device NUL:
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.

Usage of device drivers

When the programmer uses DOS interrupt calls, the relevant device drivers are automatically used. File commands can access just about any device but the more specific commands use particular devices. The screen output DOS commands explicity use the CON: device while the printer output DOS commands probably use the PRN: or LPT devices.

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.

Loading device drivers

Device drivers are loaded in memory in the order in which they are encountered in CONFIG.SYS. DOS maintains a linked list of these drivers, with new drivers being added to the head of the list. When a device driver is accessed, the list is searched from the head. The latest driver is found first and is subsequently used.

Structure of a Device Driver

Device Header
Strategy procedure
Interrupt procedure
Command processing

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.

Request Header

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.

Block and Character Devices

There are two types of devices that are supported by standard device driver commands - block and character devices. Character devices transfer only single characters of data while block devices can transfer whole blocks of data.

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.