Windows Drivers

VxD is the device driver model used in 16-bit versions of Microsoft Windows. They have access to the memory of the kernel and all running processes, as well as raw access to the hardware. The name "VxD" is an abbreviation for "virtual xxx driver", where "xxx" is some class of hardware device. It derives from the fact that most drivers had filenames of the form vxxxd.386 in Windows 3.x. Some examples are: vjoyd.386 (joystick), vmm.386 (memory manager). VxDs usually have the filename extension .386 under Windows 3.x and .vxd under Windows 95. VxDs written for Windows 3.x can be used under Windows 95 but not vice versa.

Prior to the advent of Windows, DOS applications frequently communicated directly with various pieces of hardware, by responding to interrupts, reading and writing device memory etc. Each application expected to have exclusive and complete control over the hardware. Though Windows applications don't often communicate directly with hardware, it was the only way to write Windows drivers, and still is in the real and standard modes of Windows 3.x. Despite the fact that Windows switched from running in real mode to protected mode, direct hardware access and interrupt hooking could still be done because when Windows switched to running in protected mode it kept the single privilege level model used in real mode. This lasted all the way through Windows 9x. Windows/386 and onwards allowed multiple MS-DOS applications to execute simultaneously. This was done by executing each legacy application within its own virtual machine. To share arbitrary physical resources amongst these virtual machines, Microsoft introduced dynamically-loadable virtual device drivers. These drivers solved issues relating to conflicting usage of physical resources by intercepting calls to the hardware. Instead of a machine port representing an actual device, it would represent a "virtual" device, which could be managed by the operating system.


Windows Driver Model (WDM) — also known 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, as well as the Windows NT Driver Model.
WDM drivers are layered in a complex hierarchy and communicate with each other via I/O request packets (IRPs). The Microsoft Windows Driver Model defined a unified driver model for the Windows 98 and Windows 2000 lines 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 compatible (an application binary interface (ABI) describes the low-level interface between an application program and the operating system, between an application and its libraries, or between component parts of the application. An ABI differs from an application programming interface (API) in that an API defines the interface between source code and libraries, so that the same source code will compile on any system supporting that API, whereas an ABI allows compiled object code to function without changes on any system using a compatible ABI.) and source compatible (a computer that can run the same source code intended to be compiled and run on another computer is said to be source-compatible.) across Windows 98, Windows 98 Second Edition, Windows Me, Windows 2000, Windows XP, Windows Server 2003 and Windows Vista (for backwards compatibility) on x86-based computers. WDM is designed to be backward-compatible.WDM is generally not forward-compatible. WDM will most likely fail to load drivers written for a newer version. For example, the WDM in Windows XP will load drivers written for Windows 2000, but will not apply new WDM features that were introduced in Windows XP. The WDM in Windows 2000 will not load a driver written for Windows XP.

WDM drivers can be classified into the following types and sub-types:

Device function drivers

A 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). A function driver can service one or more devices.

* Class drivers: These are a type of function drivers and 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 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 also function drivers for 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.

Bus drivers

A bus driver services a bus controller, adapter, or bridge. 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. A bus driver can service more than one bus if there is more than one bus of the same type on the machine.

Filter drivers

Filter drivers are optional drivers that add value to or modify the behavior of a device and may be non-device drivers. A filter driver can also service one or more devices. Upper level filter drivers sit above the primary driver for the device (the function driver), while lower level filter drivers sit below the function driver and above the bus driver.

* Driver service: This is a type of kernel-level filter driver implemented as a Windows service that enables applications to work with devices.

The Windows Driver Model, while a significant improvement over the VxD and Windows NT driver model used before it, has been criticised by driver software developers [1], most significantly for the following:

* WDM has a very steep learning curve.
* Interactions with power management events and Plug-and-play are difficult. This leads to a variety of situations where Windows machines cannot 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.

Because of these issues, Microsoft has released a new framework to replace WDM, called the Windows Driver Foundation, which includes Kernel-Mode Driver Framework (KMDF) and User-Mode Driver Framework (UMDF). Windows Vista supports both WDM and the newer Windows Driver Foundation. KMDF is also available for download for Windows XP and even Windows 2000, while UMDF is available for Windows XP.


Windows Driver Foundation (WDF) is a set of Microsoft tools that aid in the creation of high-quality, reliable drivers for Windows 2000 and later versions of Windows.The primary tools that comprise WDF are the Kernel Mode Driver Framework (KMDF) and User Mode Driver Framework (UMDF). These tool kits provide a new, object-oriented, programming model for Windows driver development. The primary goal of of the Frameworks is "Conceptual Scalability", that is the characteristics of only requiring a driver developer to learn a few simple concepts to be able to write a simple driver, and to be able to incrementally learn more as more complex driver features are required. This differs markedly from the Windows Driver Model (WDM) that requires driver developers to be fully familiar with lots of complex technical details before writing even a simple driver.
Part of the key to achieving Conceptual Scalability is that KMDF and UMDF use an "opt-in" model. This model allows the developer to extend and override the default behavior of a canonical "good driver". This is in contrast to the older Windows Driver Model that depends on the driver writer to implement all aspects of the driver's behavior.

The Framework comes in two varieties:
* The Kernel-Mode Driver Framework, for writing standard kernel-mode device drivers.
* The User-Mode Driver Framework, for writing certain classes of driver that can run in user-mode.

These share the underlying programming model. However, the kernel-mode framework uses a flat C API while the user-mode framework is based on C++ and a light version of the COM.

WDF also includes a set of static verification tools for use by driver writers. These tools examine driver code for common errors and/or simulate the code of a driver in order to identify problems that are both difficult to detect and difficult to test for.