1. WDF Component FunctionsWDF includes a suite of components that support the
development, deployment, and maintenance of both Kernel Mode and User
Mode Drivers. WDF components work with existing driver development tools
to address the entire driver cycle of the following:
Plan & Design:
Driver Model—The WDF driver model supports the creation of
object-oriented, event-driven drivers. By using WDF, driver writers can
focus on their device hardware, rather than on the operating system. WDF
drivers can be written for either kernel mode or user mode.
Frameworks and Windows Driver Kit (WDK)—WDF defines a single driver
model and includes frameworks for both Kernel Mode and User Mode Driver
development. The frameworks provide
the basic infrastructure to support the WDF model. They implement
common features, provide intelligent defaults, and manage most
interactions with the operating system.
Kernel Mode Driver Framework (KMDF) implements basic Kernel Mode Driver
support features that are required by Windows and are common to all
Kernel Mode Drivers.
User Mode Driver Framework (UMDF) provides functional support similar
to that in the KMDF, but enables drivers for some types of devices to
run in user mode instead of in kernel mode.
Tracing and Static Analysis Tools—Both the KMDF and the UMDF have
built-in verification code and support integrated tracing through Event
Tracing for Windows (ETW). The generated traces can help in debugging
drivers during development and in diagnosing problems in released
drivers. WDF drivers also work with the existing driver verifier. In
addition, compile-time driver verification tools, such as PREfast and
Static Driver Verifier (SDV), are also part of the WDF effort.
Qualify: Driver Signing—WDF drivers are signed in the same way as Windows Driver Model (WDM) drivers.
Driver Installation Tools—WDF drivers are installed by using INF files
and work with existing driver installation tools, including the Driver
Install Frameworks (DIFx) tools.
Versioning—WDF supports versioning so that a single driver binary can
run on any version of the operating system and use the same version of
the framework on which it was built and tested.
2. Design Goals for WDF
Writing a Windows driver is
not easy. The current Kernel Mode Driver development model Windows
Driver Model (WDM) is complex and has serious limitations.
WDM requires that drivers be
designed to manage interactions with the operating system, not just the
device hardware. A simple WDM driver has thousands of lines of code,
much of which implements common features that every driver must support.
WDM drivers must use device-driver interfaces (DDIs) that are exported
directly from the operating system kernel. These interfaces were
designed for performance, not for ease of use. In many cases, the DDIs
expose essential operating system data structures directly to the driver, thus increasing the chance that a driver error might crash or corrupt the system.
For some device types,
port/miniport models implement much of the WDM code. However, Windows
supports more than 10 such models and each is different. So the
knowledge gained from writing a miniport driver for one type of device
does not necessarily apply to writing a miniport driver for a different
type of device.
Unlike Kernel Mode Drivers, User Mode Drivers have no common infrastructure that is comparable to WDM.
The following are the primary design principles underlying the WDF model:
Separate the driver model from the core operating system components.
Provide a user mode option for some device types.
Implement common and default driver features so that driver developers can focus on their hardware.
Make drivers event driven and define the events at a detailed level so that driver tasks are straightforward.
Support Plug and Play and power management implementation for all drivers.
Support a consistent installation process for both User Mode and Kernel Mode Drivers.
integrated tools, including built-in tracing and verification support,
to help find and diagnose problems both during debugging and after
Enable a single driver binary to work with several versions of the framework and the operating system.
3. Device and Driver Support in WDF
lists the WDF support for various device classes and driver models in
Windows 7. From this table, we can get a feel for the wide range of
device types that Windows 7 supports. As we have mentioned earlier, this
book is primarily about creating custom device drivers. That is, ones
not normally supplied by Microsoft. Notice also the distribution of
device types across the two driver modes—that is, Kernel Mode Driver
Framework (KMDF) and User Mode Driver Framework (UMDF).
Table 1. WDF Device Support for Windows 7
|Device Class/Driver Model||KMDF||UMDF||SDV||PREfast|
|Keyboards and mouse devices||Yes||No||Yes||Yes|
|Other device (not listed here) that connect to a Protocol bus such as USB or IEEE 1394||No||Yes||No||Yes|
|Portable media players||No||Yes||No||Yes|
|Video capture devices||No||No||No||Yes|
4. WDF Driver Model
The WDF driver model defines an
object-oriented, event-driven environment in which driver code manages
device-specific features and a Microsoft-supplied framework calls the
driver to respond to events that affect operation of its device. The
driver model includes the following:
An object model that is implemented by both KMDF and UMDF.
A Plug and Play and power management implementation that both frameworks use.
I/O model in which the frameworks handle interactions with the
operating system and manage the flow of I/O, Plug and Play, and power
A versioning strategy that applies to both Kernel Mode and User Mode Drivers.
Consistent installation techniques for both Kernel Mode and User Mode Drivers.
This design has several important advantages:
implement common driver features and default behavior, thus making
vendor-written drivers smaller and faster to develop and debug.
Microsoft can change the operating system’s internal data structure without introducing driver incompatibilities.
developers and hardware vendors are better isolated from incremental
changes in each new version or update of the operating system.
framework can track the state of the driver, operating system, and
device, thus eliminating much of the complex logic often required in a
driver, particularly in respect to Plug and Play and power management.
The WDF model provides a
consistent but extensible driver development interface. Both frameworks
conform to conventions for naming, parameter types and usage, object
hierarchy, and default. Features that are required by or common to all
device types are part of each overall framework, so driver writers can
apply knowledge gained from writing a driver for one device type to
writing a driver for another device type.