The Role of the Registry for Legacy Drivers

< BACK  NEXT >
[oR]

In recent history, it was common for hardware to remain dormant until software somehow magically became aware of its existence and began to stimulate it. The techniques used by drivers and the NT operating system fell into one of three categories:

  • A driver would maintain a list of potential hardware resources (i.e., port address, DMA channels, and interrupt levels) for each device that it might encounter. By probing each potential resource during DriverEntry, a driver would create an appropriate Device object (IoCreateDevice).

  • A driver would rely upon an installation program to specify (either by probing or by user specification) the resources and devices that the driver would manage. This list of devices and associated resources would then be conveniently stored in the system registry.

  • The NT operating system, as part of a preboot process, would probe for conventional devices and resources. For example, COM serial ports are routinely present at 0x3F8 or 0x2F8 (et. al.) and are therefore probed during the boot process. The discovery of devices was reported and maintained within the system Registry.

As system designers recognized the need for a more orderly hardware configuration process, new buses and protocols were specified that automatically reported the presence (or removal) of hardware. Generally, any bus type other than ISA supports some form of autodetection.

As an intermediate step to take advantage of autodetecting buses and hardware, earlier versions of NT augmented the preboot process to include autodetected hardware within the system Registry. Thus, an initializing driver (DriverEntry) would have the ability to see the list of autodetected hardware that was present during the boot process and create appropriate devices.

Regardless of which technique the OS or driver utilized, it was still imperative to force the loading of a driver manually. That is, appropriate entries within the system registry allowed a driver to load (either at system boot or later), which in turn would control discovered devices. Indeed, the examples given in previous chapters rely upon a manual installation of the driver. Because a driver would first load and then begin to control devices, the technique is sometimes referred to as driver-centric.

With the advent of Windows 95, and subsequently Windows 98 and Windows 2000, the model has been reversed. Devices that announce themselves, either during boot or by subsequent insertion (hot plug), force the loading of an appropriate registered driver. The new technique is said to be device-centric.

While the original Windows 95 driver model supported Plug and Play, it differed significantly from the NT driver model. Microsoft, recognizing the need for a compatible driver environment, extended the NT model to support Plug and Play and incorporated this technique in Windows 2000 and Windows 98. The new common model is designated the Windows Driver Model (WDM).

< BACK  NEXT >


The Windows 2000 Device Driver Book(c) A Guide for Programmers
The Windows 2000 Device Driver Book: A Guide for Programmers (2nd Edition)
ISBN: 0130204315
EAN: 2147483647
Year: 2000
Pages: 156

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net