
Click above to get retro games delivered to your door ever month!
X-Hacker.org- Peter Norton Programmer's Guide - Norton Guide
[<<Previous Entry] [^^Up^^] [Next Entry>>] [Menu] [About The Guide]
There are two kinds of device drivers: those for character devices, which,
like the keyboard, printer, and communications port, work with a serial
stream of characters, and those for block devices, which, like a disk
drive, read and write blocks of data identified by some form of block
address. Character devices are identified by their own names (similar to
the names LPT1 and COM1). Block devices are identified by a drive letter
that DOS assigns (D:, E:, F:, and so on).
In a program, you generally treat character devices like files. A
character device can be opened using its name and then read from or
written to. On the other hand, your program sees block devices as if they
were disk drives. This is the point of using installable device drivers--
the usual DOS interrupt 21H function for files and disks let you access
any device as long as the device driver conforms to DOS's format.
DOS maintains a chained list of device drivers in which each device driver
contains the address of the next device driver in the list. The chain
starts in the heart of the DOS kernel, beginning with the NUL device. When
you use an interrupt 21H function to identify a character device, DOS
searches the list of device driver names before it searches disk
directories.
Every installable device driver consists of three main structural
elements; a device header, a strategy routine, and an interrupt routine.
The device header is a data structure that contains a device attribute
word as well as the addresses of the strategy and interrupt routines. DOS
communicates with a device driver through a data structure called a
request header. DOS uses the request header to pass I/O function numbers
and buffer addresses to the device driver. The device driver uses the same
data structure to return status and error codes to DOS.
To initiate an I/O request, DOS builds a request header, calls the device
driver's strategy routine to pass it the request header's address, and
then calls the driver's interrupt routine. The interrupt routine examines
the request header, initiates the data transfer to or from the hardware
device, waits for the completion of the data transfer, and updates the
request header with a status code before it returns to DOS.
--------------------------------------------------------------------------
NOTE:
It may seem curious that DOS actually makes two separate calls to a
device driver for each input/output request. This somewhat redundant
design is actually similar to that used in device drivers in
multitasking operating systems like UNIX (after which the DOS design is
modeled) and OS/2.
In a multitasking system, the two-part design makes good sense because
it allows I/O operations to take place in parallel with other system
functions. The strategy routine starts the I/O operation and then
returns control to the operating system, which can perform other tasks
without waiting for the hardware device to transfer data. When the data
transfer is complete, the interrupt routine gains control and cleanly
terminates the operation.
--------------------------------------------------------------------------
Writing a device driver is similar to writing the I/O service programs
that are at the heart of DOS and at the heart of the computer's built-in
ROM BIOS. It is among the most sophisticated and intricate programming
that you can do.
Online resources provided by: http://www.X-Hacker.org --- NG 2 HTML conversion by Dave Pearson