Click above to get retro games delivered to your door ever month!

  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.