Filter drivers let you modify the behavior of standard system drivers. A WDM filter driver is inserted into the device stack when the device stack is built. Figure 19.2 shows the different types of filter driver. This book does not cover filter drivers.
Figure 19.2 WDM filter drivers
Filter drivers can also be written to work in Windows NT 4 and NT 3.51. However, WDM device stacks are not available in these older operating systems. Instead, the
NT Layering
Windows NT 4, NT 3.51, and 2000 use layers of NT style drivers. This is not the layering of Plug and Play devices seen in most of this book. Instead, each driver must be loaded in the correct order and use any existing drivers.
As an example, Figure 19.3 shows the layering of the parallel port drivers. The parport driver is loaded first. parport arbitrates access to the parallel port hardware. The parallel and parvdm drivers are then loaded. When these drivers want to access the parallel port hardware, they must ask parport for access rights. Once access rights have been obtained, they can talk to the parallel port electronics directly.
New parallel port drivers should use the same technique to get access to the hardware[47]. The DDK recommends that you grab access to the port on a per-IRP basis. For most applications, I recommend taking control of the port for the duration of a larger transaction (e.g., while a handle is open to your device).
Figure 19.3 Parallel port layering
The parport driver creates a named kernel device object for each parallel port it finds. These device objects have kernel names starting with DeviceParallelPort0. Use
The parport driver supports several Internal IOCTLs. IOCTL_INTERNAL_GET_PARALLEL_PORT_INFO returns information about the parallel port (the base register address and port allocation routines). When the information is safely stored away, a similar (but undocumented) IOCTL_INTERNAL_RELEASE_PARALLEL_PORT_INFO call is made to release the information.
Two port allocation routines are available.
When you install a driver that uses the parport driver, you must make sure that your driver loads after parport has started. Do this by including a DependOnService string value in your driver's registry entry that is set to parport.
Microsoft may be introducing a new WDM architecture for these parallel port drivers. A parallel port bus driver would replace parport. It would enumerate the ports available on the 'bus'. This is particularly important, as several IEEE 1284.3 printers may be daisy-chained on a single parallel port connection. The header file parallel.h in the W2000 DDK srckernelinc directory gives a hint of how the new interface will work.
Conclusion
Writing a client driver to access standard buses has been made much easier with the provision of several important system drivers. In addition, you can write minidrivers to interface these standard drivers to your own specialized hardware.
Let's now start looking at the standard system drivers by considering the Universal System Bus.
Chapter 20
The Universal Serial Bus
This chapter introduces the Universal Serial Bus (USB) by giving an overview of the technology, its low-level structure, and its device framework. The next chapter looks at how to write Windows device drivers using the USB Device Interface (USBDI). This chapter takes a brief look at the available classes of USB device that have common characteristics. The subsequent chapters look in detail at one of these classes for Human Input Devices (HID)[49].
The Universal Serial Bus (USB) is the recommended way to connect new low-speed or medium-speed external devices to PCs. It is simple for users to plug in a new USB device or remove one, even if the PC is switched on. The system configures itself automatically to accommodate the new device, prompting for the necessary driver.
The USB Specification defines all the basic physical, electrical, and logical characteristics of all USB systems. The Windows system drivers define the closely related USB Driver Interface (USBDI) for use by USB client device drivers. This chapter and the next look at both these USB models.
The USB specifications are available from the USB website at www.usb.org/developers/ in PDF format. I recommend that you also get the USB Compatibility Test software, usbcomp.exe. This includes the
Membership of USB Implementers forum costs $2500 per year including a free vendor ID. Alternatively, vendor IDs can be purchased separately for $200.
Device Classes
Some USB devices just exhibit basic USB features. However, USB goes on to specify several classes of devices, with common behavior and protocols. This makes it easier to write generic device drivers.
Table 20.1 shows the main USB device classes. The USB website has the full specifications for each class. The hub device class is specified in the standard USB Specification. I shall show later how the class constant (in the Interface descriptor) is sometimes used to identify the correct drivers for the device.
Table 20.1 Main USB device classes
| Device class | Example device | Class constant |
|---|---|---|
| Audio | Speakers | USB_DEVICE_CLASS_AUDIO |
| Communication | Modem | USB_DEVICE_CLASS_COMMUNICATIONS |
| Human Input Device (HID) | Keyboard, Mouse | USB_DEVICE_CLASS_HUMAN_INTERFACE |
