In computing, the Windows Driver Model (WDM) – also known 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, as well as the Windows NT Driver Model.

Overview

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, Windows Server 2003 and Windows Vista (for backwards compatibility) on x86-based computers[citation needed]. 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).[1]

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:[2]

Bus driver: For every bus on the mainboard there is a one bus driver, with the primary responsibility for the identification of all devices connected to that bus and responding to plug and play events. Microsoft will provide bus drivers as part of the operating system,[3] such as PCI, PnPISA, SCSI, USB and FireWire.

Function driver: this is the principal driver for a device and it provides the operational interface for a device by handling read and write operations. Function drivers are written by the device vendors, and for their interaction with the hardware they depend on a specific bus driver being present in the Windows operating system.[4]

Filter driver: This driver is optional, and can modify the behaviour of a device, such as input and output requests. These drivers can be implemented as lower-level and upper-level filter drivers.[5]

Object-oriented driver stack

Function drivers and bus drivers are often implemented as driver/minidriver pairs, which in practice is either a class or miniclass, or a port or miniport pair.[6]

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.[7]

Port drivers support general input/output (I/O) operations for a peripheral hardware interface. The core functionality of port drivers is mandated by the operating system, and Windows operating systems integrate a variety of port drivers. For example, the i8042prt.sys port driver for the 8042 microcontroller connects PS/2 keyboards to the mainboard peripheral bus. The miniport drivers, like the miniclass drivers, are supplied by the hardware vendors and support only device specific operations of peripheral hardware that is connected to a port on the mainboard.[8][9]

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 IoCallDrive(), 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.[10] 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.[11]

Device drivers for different Windows operating systems

The WDM framework was developed by Microsoft to simplify the communication between the operating system and drivers inside the kernel. In Windows operating systems, drivers are implemented as Dynamic Link Libraries .DLL or .SYS files. WDM compliant drivers must follow rules of design, initialisation, plug-and-play, power management and memory allocation. In practice WDM driver programmers reuse large pieces of code when building new object-oriented drivers. This means that drivers in the WDM stack may contain residual functionality, which is not documented in specifications.[12] Drivers that have passed the Microsoft quality test are digitally signed by Microsoft. The Microsoft Hardware Compatibility Tests and the Driver Development Kit include reliability and stress tests.[13]

A device driver that is not designed for a specific hardware component may allow another device to function. This is because the basic functionality of a hardware device class is similar. The functionality of the video card class, for example, allows the Microsoft Basic Display Adapter driver to work with a wide variety of video cards. However, installing the wrong driver for a device will mean that the full functionality of the device can not be used, and may result in poor performance and the destabilization of the Windows operating system. Hardware device vendors may release updated device drivers for particular Windows operating systems, to improve performance, add functionality or fix bugs. If a device is not working as expected the latest device drivers should be downloaded from the vendor website and installed.[14]

Device drivers are designed for particular Windows operating system versions, and device drivers for a previous version of Windows may not work correctly or at all with other versions. Because many device drivers run in kernel mode installing drivers for a previous operating system version may destabilise the Windows operating system. Migrating a computer to a higher version of a Windows operating system therefore requires that new device drivers are installed for all hardware components. Finding up to date device drivers and installing them for Windows 10 has introduced complications into the migration process.[15]

Common device driver compatibility issues include: a 32-bit device driver is required for a 32-bit Windows operating system, and a 64-bit device driver is required for a 64-bit Windows operating system. 64-bit device drivers must be signed by Microsoft, because they run in kernel mode and have unrestricted access to the computer hardware. For operating systems prior to Windows 10 Microsoft allowed vendors to sign their 64-bit drivers themselves, assuming vendors had undertaken compatibility tests. However, Windows 10 64-bit drivers now need to be signed by Microsoft. Therefore, device vendors have to submit their drivers to Microsoft for testing and approval. The driver installation package includes all files in the .inf directory, and all files in the package need to be installed, otherwise the installation of the device driver may fail. For operating system versions before Windows 10 not all files necessary for the driver installation were included in the package, as this requirement was not consistently enforced. Some device driver installers have a user interface GUI, often requiring user configuration input. The absence of a user interface does not mean that the installation of the device driver is not successful. Besides, Windows 10 device drivers are not allowed to include a user interface. The Network Driver Interface Specification (NDIS) 10.x is used for network devices by the Windows 10 operating system. Network device drivers for Windows XP use NDIS 5.x and may work with subsequent Windows operating systems, but for performance reasons network device drivers should implement NDIS 6.0 or higher.[16] Similarly, WDDM is the driver model for Windows Vista and up, which replaces XPDM used in graphics drivers.

Device Manager

The Device Manager is a Control Panel applet in Microsoft Windows operating systems. It allows users to view and control the hardware attached to the computer. It allows users to view and modify hardware device properties, and is also the primary tool to manage device drivers.[17]

Criticism

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,[18] most significantly for the following:

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 set of frameworks on top of WDM, called the Windows Driver Frameworks (WDF; formerly Windows Driver Foundation), which includes Kernel-Mode Driver Framework (KMDF) and User-Mode Driver Framework (UMDF). Windows Vista supports both pure WDM and the newer WDF. KMDF is also available for download for Windows XP and even Windows 2000, while UMDF is available for Windows XP and above.

See also

References

  1. ^ Marco Vieira; Joao Carlos Cunha, eds. (2013). Dependable Computing: 14th European Workshop, EWDC 2013, Coimbra, Portugal, May 15-16, 2013, Proceedings. Springer. p. 64. ISBN 9783642387890.
  2. ^ Marco Vieira; Joao Carlos Cunha, eds. (2013). Dependable Computing: 14th European Workshop, EWDC 2013, Coimbra, Portugal, May 15-16, 2013, Proceedings. Springer. p. 64. ISBN 9783642387890.
  3. ^ Marco Vieira; Joao Carlos Cunha, eds. (2013). Dependable Computing: 14th European Workshop, EWDC 2013, Coimbra, Portugal, May 15-16, 2013, Proceedings. Springer. p. 64. ISBN 9783642387890.
  4. ^ Marco Vieira; Joao Carlos Cunha, eds. (2013). Dependable Computing: 14th European Workshop, EWDC 2013, Coimbra, Portugal, May 15-16, 2013, Proceedings. Springer. p. 64. ISBN 9783642387890.
  5. ^ Marco Vieira; Joao Carlos Cunha, eds. (2013). Dependable Computing: 14th European Workshop, EWDC 2013, Coimbra, Portugal, May 15-16, 2013, Proceedings. Springer. p. 64. ISBN 9783642387890.
  6. ^ Bill Blunden (2009). The Rootkit Arsenal: Escape and Evasion. Jones & Bartlett Publishers. p. 460. ISBN 9781449661229.
  7. ^ Bill Blunden (2009). The Rootkit Arsenal: Escape and Evasion. Jones & Bartlett Publishers. p. 460. ISBN 9781449661229.
  8. ^ Bill Blunden (2009). The Rootkit Arsenal: Escape and Evasion. Jones & Bartlett Publishers. p. 460. ISBN 9781449661229.
  9. ^ "Introduction to the Windows Driver Foundation". Microsoft Developer Network. 2006-10-13. Retrieved 2010-12-06. The device class-specific driver models are typically structured as a port driver written by Microsoft paired with a miniport driver written by an independent hardware vendor. The port driver does much of the work required for the device class, and the miniport driver supports device-specific characteristics.
  10. ^ Bill Blunden (2009). The Rootkit Arsenal: Escape and Evasion. Jones & Bartlett Publishers. pp. 460–461. ISBN 9781449661229.
  11. ^ Dave Penkler; Manfred Reitenspiess; Francis Tam, eds. (2006). Service Availability: Third International Service Availability Symposium, ISAS 2006, Helsinki, Finland, May 15-16, 2006, Revised Selected Papers. Springer Science & Business Media. p. 124. ISBN 9783540687245.
  12. ^ Dave Penkler; Manfred Reitenspiess; Francis Tam, eds. (2006). Service Availability: Third International Service Availability Symposium, ISAS 2006, Helsinki, Finland, May 15-16, 2006, Revised Selected Papers. Springer Science & Business Media. p. 124. ISBN 9783540687245.
  13. ^ Dave Penkler; Manfred Reitenspiess; Francis Tam, eds. (2006). Service Availability: Third International Service Availability Symposium, ISAS 2006, Helsinki, Finland, May 15-16, 2006, Revised Selected Papers. Springer Science & Business Media. p. 132. ISBN 9783540687245.
  14. ^ Byron Wright; Leon Plesniarski (2016). Microsoft Specialist Guide to Microsoft Windows 10 (Exam 70-697, Configuring Windows Devices). Cengage Learning. p. 96. ISBN 9781285868578.
  15. ^ Byron Wright; Leon Plesniarski (2016). Microsoft Specialist Guide to Microsoft Windows 10 (Exam 70-697, Configuring Windows Devices). Cengage Learning. p. 96. ISBN 9781285868578.
  16. ^ Byron Wright; Leon Plesniarski (2016). Microsoft Specialist Guide to Microsoft Windows 10 (Exam 70-697, Configuring Windows Devices). Cengage Learning. p. 96. ISBN 9781285868578.
  17. ^ Byron Wright; Leon Plesniarski (2016). Microsoft Specialist Guide to Microsoft Windows 10 (Exam 70-697, Configuring Windows Devices). Cengage Learning. p. 96. ISBN 9781285868578.
  18. ^ Oney, Walter (May 6, 2003). "Introducing Windows Driver Framework". Windows Driver Developer's Digest. Vol. 1, no. 3. Archived from the original on 2016-01-25.
  19. ^ "I/O Completion/Cancellation Guidelines". MSDN. Microsoft. May 5, 2003. Retrieved 2018-02-08.

External links

Microsoft APIs and frameworks
Categories