WDM drivers are layered in a stack and communicate with each other via
I/O request packets (IRPs). The Microsoft Windows Driver Model unified driver models for the Windows 9x and Windows NT product 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 (before the OSR2 update that sideloads the WDM model), Windows NT 4.0 and Windows 3.1. By conforming to WDM, drivers can be
binary compatible and
source-compatible across Windows 98, Windows 98 Second Edition,
Windows Me, Windows 2000,
Windows XP and
Windows Server 2003 on
x86-based computers. WDM drivers are designed to be
forward-compatible so that a WDM driver can run on a version of Windows newer than what the driver was initially written for, but doing that would mean that the driver cannot take advantage of any new features introduced with the new version. WDM is generally not
backward-compatible, that is, a WDM driver is not guaranteed to run on any older version of Windows. For example,
Windows XP can use a driver written for
Windows 2000 but will not make use of any of the new WDM features that were introduced in Windows XP. However, a driver written for Windows XP may or may not load on 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. Although WDM was mainly designed to be binary and source compatible between
Windows 98 and Windows 2000, this may not always be desired and so specific drivers can be developed for either operating system.
Device kernel-mode drivers With the Windows Drivers Model (WDM) for devices Microsoft implements an approach to
kernel mode drivers that is unique to
Windows operating systems. WDM implements a layered architecture for
device drivers, and every device of a computer is served by a stack of drivers. However, every driver in that stack can chain isolate hardware-independent features from the driver above and beneath it. So drivers in the stack do not need to interact directly with one another. WDM defines architecture and device procedures for a range of devices, such as display and the
network card, known as
Network Driver Interface Specification (NDIS). In the NDIS architecture the layered network drivers include lower-level drivers that manage the hardware and upper-level drivers that implement network data transport, such as the
Transmission Control Protocol (TCP). While WDM defines three types of device drivers, not all driver stacks for a given device contain all types of device drivers. The three WDM device driver types are: Bus drivers for devices attached to a bus are implemented as class drivers and are hardware-agnostic. They will support the operations of a certain type of device. Windows operating systems include a number of class drivers, such as the kbdclass.sys driver for keyboards. Miniclass drivers on the other hand are supplied by the vendor of a device, and only support device specific operations, for a particular device of a given class. Each driver that processes an I/O request for a device has a corresponding object, which is loaded into
main memory. A device object is created by the Windows operating system from the associated device class. Device objects contain structures of type DEVICE_OBJECT, which store pointers to their driver. At run time these pointers are used to locate a driver's dispatch routine and member functions. In the WDM driver stack, the filter driver device object, known as the upper filter, will receive an
I/O request packet (IRP) for a device from the I/O manager. If the upper filter driver can not serve the request, it will locate the object of the driver one step down in the driver stack. The IRP is passed down the driver stack by calling the function IoCallDriver(), and processed by the function driver device object, also known as functional device object. The function driver device object in turn may pass the IRP to the lower filter, another filter device object. Then the IRP may be passed down to the bus driver, which operates as the physical device object. The bus driver object is at the bottom of the driver stack, and interacts with the
hardware abstraction layer, which is part of the
Windows operating system kernel and allows Windows operating systems to run on a variety of
processors, different
memory management unit architectures, and a variety of computer systems with different I/O bus architectures. The execution of an IRP is finished when any of the driver objects in the stack returns the request back to the I/O manager, with the result and a status flag. == Device drivers for different Windows operating systems ==