Windows Driver Model

Source: Wikipedia, the free encyclopedia.

In

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

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

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

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

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

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

Windows NT Driver Model used before it, has been criticised by driver software developers,[18]
most significantly for the following:

  • Interactions with power management events and plug and play are difficult. This can lead to situations where Windows machines cannot enter or exit sleep modes correctly due to bugs in driver code.
  • I/O cancellation is difficult to get right.[19]
  • Complex boilerplate support code is required for every driver.
  • There is 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 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. .
  2. .
  3. .
  4. .
  5. .
  6. .
  7. .
  8. .
  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. .
  11. .
  12. .
  13. .
  14. .
  15. .
  16. .
  17. .
  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