Windows Driver Model

In computing, the Windows Driver Model (WDM) — also known (somewhat misleadingly) at one point as the Win32 Driver Model — is a framework for device drivers that was introduced with Windows 98 and Windows 2000 to replace VxD, which was used on older versions of Windows such as Windows 95 and Windows 3.1 and the Windows NT Driver Model.

Overview

WDM drivers are layered in a complex hierarchy and communicate with each other via I/O Request Packets (IRPs). The Windows Driver Model defined a unified driver model for the Windows 98 and Windows 2000 line by standardizing requirements and reducing the amount of code that needed to be written. WDM drivers will not run on operating systems earlier than Windows 98 or Windows 2000, such as Windows 95, Windows NT 4.0 and Windows 3.1. By conforming to WDM, drivers can be binary and source compatible across Windows 98, Windows 98 Second Edition, Windows 2000, Windows XP and Windows Server 2003 on x86-based computers. WDM is designed to be forward-compatible but not backward-compatible. That is, drivers will be compatible with the same or higher-numbered WDM versions. Such WDM drivers will not be able to take advantage of new operating system services, but they will still load and run. Newer drivers running in a lower-version environment will most likely fail while loading. For example, a WDM driver written for Windows 2000 will load and function under Windows XP, but cannot take advantage of any new WDM features that were introduced in Windows XP. A WDM driver written for Windows XP will not load under Windows 2000.

WDM exists in the intermediary layer of Windows 2000 kernel-mode drivers and was introduced to increase the functionality and ease of writing drivers for Windows. The WDM was mainly designed to be binary and source compatible between Windows 98 and Windows 2000. However, this may not always be desired and so specific drivers can be developed for either operating system. WDM consists of:

• Class drivers: these can be thought of as built-in framework drivers that miniport and other class drivers can be built on top of. The class drivers provide an interfaces between different levels of the WDM architecture. Common functionality between different classes of drivers can be written into the class driver and used by other class and miniport drivers. The lower edge of the class driver will have its interface exposed to the miniport driver, while the upper edge of top level class drivers is operating system specific. Class drivers can be dynamically loaded and unloaded at will. They can do class specific functions that are not hardware or bus-specific (with the exception of bus-type class drivers) and in fact sometimes only do class specific functions like enumeration).
• Miniport drivers: these are USB, Audio, SCSI and network adapters. They should usually be source and binary compatible between Windows 98 and Windows 2000 and are hardware specific but control access to the hardware through a specific bus class driver.
• Software bus drivers: Microsoft provides bus drivers for most common buses, such as PCI, PnPISA, SCSI, USB and FireWire. Each software vendor can create their own bus drivers if needed.
• OS Services: this layer is all the operating system functionality that has been abstracted away from the miniport driver.
• Virtual device drivers: Windows 98 and Windows Me only. Have been part of Windows since v3.0 and are used for legacy hardware.
• Windows NT 4.0 drivers: Windows 2000 and Windows XP and later only. Legacy drivers written for Windows NT 4.0.

In the layered architecture of Windows kernel-mode drivers, class/mini port drivers are functional drivers.

Problems

The Windows Driver Model, while a significant improvement over the VxD driver model used before it, has been heavily criticised by driver software developers[1]. Most significantly:

• WDM has a very steep learning curve.
• Interactions with power management events and Plug-and-play is difficult. This lead to a variety of situations where Windows machines could not go to sleep or wake up correctly due to bugs in driver code.
• I/O cancellation is almost impossible to get right.
• Thousands of lines of support code are required for every driver.
• No support for writing pure user-mode drivers.

There were also a number of concerns about the quality of documentation and samples that Microsoft provided.

Because of these issues, Microsoft has released a new framework to replace WDM, called the Windows Driver Foundation.

See also

• Windows Driver Foundation
• Kernel Mode Driver Framework
• User Mode Driver Framework

References

• Finnel, Lynn (2000). MCSE Exam 70-215, Microsoft Windows 2000 Server. Microsoft Press. ISBN 1-57231-903-8.

• Oney, Walter (2003). Programming the Windows Driver Model, Microsoft Press, ISBN 0-7356-1803-8.

External links

• Windows driver API basics - This article informs you about the basics behind soundcard drivers such as WDM, ASIO, MME, DirectX, etc.
• Channel 9 Video - Interview with the Device Management and Installation team at Microsoft, primarily covering Plug-and-play.