In computing, Windows Driver Model (WDM) 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. WDM drivers are layered in a complex hierarchy and communicate with each other via IO Request Packets (IRPs).

At a minimum, WDM drivers usually support the following:

• Power management
• Plug-and-play
• Windows Management Instrumentation

Introducing the Windows Driver Model

Windows Driver Model defined a unified driver model for the Microsoft Windows 98 and Windows 2000 operating systems by standardizing requirements and reducing the amount of code that needed to be written. Programmers who are already familiar with Windows NT 4.0 drivers will recognize most of the features of WDM drivers.

WDM drivers will not run on operating systems earlier than Windows 98 or Windows 2000, such as Windows 95 and Windows 3.1.

By conforming to WDM, drivers can be binary-compatible across Windows 98, Windows 98 Second Edition, and Windows 2000 on x86-based computers. However, subsequent operating systems will contain features not available in preceding versions. 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.ie: A WDM driver written for Windows XP will not load under Windows 2000.

WDM driver writers should carefully consider feature-set inclusions. For example, does the driver need to run on different platforms? Will the hardware be widely available, or is it highly specialized and limited in distribution?

Not all hardware meets the requirements of WDM. Video drivers do not support the WDM model and must be written separately, as do certain drivers utilizing VxDs under Windows 98 and some network drivers. Virtual hardware (emulation) and non-standard buses are not supported in a WDM class.

A multi-operating system driver is required to conform to the lowest WDM version of any operating system supported by the driver. For cross-operating system compatibility, WDM driver writers should thoroughly test drivers on all versions of Windows 98 and Windows 2000; operating system differences can produce slightly different driver behavior. Differences are most apparent between single-processor and multi-processor platforms.

Driver Entry Points

All NT drivers must have a basic set of standard routines in order to process IRP's. If a driver does not process IRP, the set of standard routines that can or must be implemented depends on whether the driver controls a physical device or is layered over such a device driver, as well as on the nature of the underlying physical device.

Every NT driver must have the following types of routines, defined by the NT I/O Manager :

• A DriverEntry routine
• One or more dispatch routines
• Zero or one StartIo routine

Installing Device Drivers

Early in the device driver development process, it is important to consider how an end user will install your driver and the hardware it serves. Microsoft Windows 2000 and Microsoft Windows 98 use a text file with the file extension INF to control most of the activities associated with installing drivers, which is a file that you provide. It either goes on a diskette or on a disc that you package with the hardware, or else Microsoft puts it on the Windows 2000 installation disc. In the INF file, you tell the operating system which file(s) to copy onto the end user's hard disk, which registry entries to add or modify, and so on. To generate the INF file, the Microsoft Windows Device Driver Kit® (DDK) provides a tool called GenINF.

GenINF

GenINF is a GUI-based tool that guides the user through the process of creating Windows® 2000 device driver information (INF) files.

The tool does not create fully valid INF files. However, the skeleton INF files it generates should help developers complete their device driver INF files. Users should review all INF files created by GenINF carefully and modify them as required. Users should expect to add additional INF directives, especially any directives that are device-class-specific or that contain device-class-specific information.

GenINF is located in the <DDKRoot>\Tools subdirectory. Because it is GUI-based, it can be executed from within the Windows 2000 User Interface, or from the Command Prompt. The GenINF program does not accept any command-line parameters.