WDM: Introduction to Windows Driver ModelUpdated: May 22, 2002 
 On This Page
To allow driver developers to write device drivers that are source-code compatible across all Microsoft� Windows� operating systems, the Windows Driver Model (WDM) was introduced. Kernel-mode drivers that follow WDM rules are called WDM drivers. All WDM drivers must:
Although the Windows DDK emphasizes development of WDM drivers for kernel mode, information pertinent to kernel-mode drivers that do not follow WDM rules is also provided in the DDK. This allows you to maintain existing non-WDM drivers and to write new drivers that interface with these existing drivers. When to Write a WDM Driver. All new driver stacks should consist of WDM drivers. Cross-Platform Support. Types of WDM DriversThere are three kinds of WDM drivers:
In this context, a bus is any device to which other physical, logical, or virtual devices are attached; a bus includes traditional buses such as SCSI and PCI, as well as parallel ports, serial ports, and i8042 ports. It is important for driver writers to understand the different kinds of WDM drivers and to know which kind of driver they are writing. For example, whether or not a driver handles each Plug and Play IRP and how to handle such IRPs depends on what kind of driver is being written (bus driver, function driver, or filter driver). The following figure shows the relationship between the bus driver, function driver, and filter drivers for a device.
Possible Driver LayersEach device typically has a bus driver for the parent I/O bus, a function driver for the device, and zero or more filter drivers for the device. A driver design that requires many filter drivers does not yield optimal performance. The drivers in the previous figure are the following:
The following describe the general types of drivers in detail. Bus DriversA bus driver services a bus controller, adapter, or bridge. Microsoft provides bus drivers for most common buses, such as PCI, SCSI, and USB. Other bus drivers can be provided by IHVs or OEMs. Bus drivers are required drivers; there is one bus driver for each type of bus on a machine. A bus driver can service more than one bus if there is more than one bus of the same type on the machine. The primary responsibilities of a bus driver are to:
During enumeration, a bus driver identifies the devices on its bus and creates device objects for them. The method a bus driver uses to identify connected devices depends on the particular bus. A bus driver performs certain operations on behalf of the devices on its bus, including accessing device registers to physically change the power state of a device. For example, when the device goes to sleep, the bus driver sets device registers to put the device in the proper device power state. Note, however, that a bus driver does not handle read and write requests for the devices on its bus. Read and write requests to a device are handled by the device's function driver. Only if the device is being used in raw mode does the parent bus driver handle reads and writes for the device. A bus driver acts as the function driver for its controller, adapter, or bridge, and therefore manages device power policy for these components. A bus driver can be implemented as a driver/minidriver pair, the way a SCSI port/miniport driver pair drives a SCSI host bus adapter (HBA). In such driver pairs, the minidriver is linked to the second driver, which is a DLL. Function DriversA function driver is the main driver for a device. A function driver is typically written by the device vendor and is required (unless the device is being used in raw mode). The PnP Manager loads at most one function driver for a device. A function driver can service one or more devices. A function driver provides the operational interface for its device. Typically the function driver handles reads and writes to the device and manages device power policy. The function driver for a device can be implemented as a driver/minidriver pair, such as a port/miniport driver pair or a class/miniclass driver pair. In such driver pairs, the minidriver is linked to the second driver, which is a DLL. If a device is being driven in raw mode, it has no function driver and no upper or lower-level filter drivers. All raw-mode I/O is done by the bus driver and optional bus filter drivers. Filter DriversFilter drivers are optional drivers that add value to or modify the behavior of a device. A filter driver can service one or more devices. Bus Filter Drivers. Bus filter drivers typically add value to a bus and are supplied by Microsoft or a system OEM. Bus filter drivers are optional. There can be any number of bus filter drivers for a bus. A bus filter driver could, for example, implement proprietary enhancements to standard bus hardware. For devices described by an ACPI BIOS, the Power Manager inserts a Microsoft-supplied ACPI filter (bus filter driver) above the bus driver for each such device. The ACPI filter carries out device power policy and powers on and off devices. The ACPI filter is transparent to other drivers and is not present on non-ACPI machines. Lower-Level Filter Drivers. Lower-level filter drivers typically modify the behavior of device hardware. They are typically supplied by IHVs and are optional. There can be any number of lower-level filter drivers for a device. A lower-level device filter driver monitors and/or modifies I/O requests to a particular device. Typically, such filters redefine hardware behavior to match expected specifications. A lower-level class filter driver monitors and/or modifies I/O requests for a class of devices. For example, a lower-level class filter driver for mouse devices could provide acceleration, performing a nonlinear conversion of mouse movement data. Upper-Level Filter Drivers. Upper-level filter drivers typically provide added-value features for a device. Such drivers are usually provided by IHVs and are optional. There can be any number of upper-level filter drivers for a device. An upper-level device filter driver adds value for a particular device. For example, an upper-level device filter driver for a keyboard could enforce additional security checks. An upper-level class filter driver adds value for all devices of a particular class. WDM VersionsAlthough Windows�XP, Windows�2000, Windows�98, and Windows�Me all support WDM, incremental changes to WDM have resulted in later-released operating systems supporting additional WDM features that earlier releases do not support. Later versions of WDM generally support all the features available in earlier versions of WDM; that is, each new version of WDM is a superset of the previous WDM version. When possible, a cross-system driver should conform to the lowest WDM version on any operating system. A cross-system WDM driver should use the IoIsWdmVersionAvailable routine to determine which version of WDM is supported by the system on which it is running. The reference page for IoIsWdmVersionAvailable provides a list of WDM version numbers. The simplest way to ensure cross-system compatibility is to write a driver that uses only those features supported by the lowest version of WDM. However, this is not always possible. In some situations, drivers require additional code to take advantage of features available in later versions of WDM or to compensate for differences between Windows operating systems. WDM Differences in Driver Support Routines. The DDK reference page for each driver support routine indicates if the routine is restricted to specific versions of WDM, or if its behavior is different on different operating system versions. Before using any driver support routine in a cross-system driver, be sure to understand any version-specific restrictions or behaviors. WDM Differences in Plug and PlayThe Plug and Play feature IRP_MN_SURPRISE_REMOVAL is supported only in Windows�2000 and later versions of the operating system (WDM version 1.10 and later). In addition, the following features work differently on Windows�98/Me from Windows�2000 and later versions of the operating system:
WDM Differences in Power Management. The following power management features differ in operation on Windows�98/Me and Windows�2000 and later versions of the operating system:
WDM Differences in Kernel-Mode Driver Operation. Kernel-mode WDM drivers for Windows�98/Me must follow certain guidelines for using floating-point operations, MMX, 3DNOW!, or Intel's SSE extensions. Windows�98/Me provides a fixed number of worker threads that might not be adequate for some drivers. For more information about this and other Windows�98/Me-specific WDM issues, see "Cross-Platform Issues for WDM Drivers" in the current Windows�DDK. |
