To alleviate problems created by unreliable device drivers, Microsoft has announced a set of long-term goals, as well as steps it is taking with the next Windows client OS (code-named Longhorn), to transform the way Windows interacts with device drivers. The Windows Driver Foundation (WDF) seeks to simplify the task of creating device drivers and to insulate the OS from the effects of unreliable ones.

Driver Architecture Limits Reliability

Like most OSs, Windows offers a set of interfaces that hardware developers can use to get new devices to work with the OS. In the case of Windows, the set of interfaces is known as the Windows Driver Model (WDM.) When measured by the vast number of Windows-compatible hardware vendors and devices on the market, Microsoft has been quite successful, but the success has come at a price—data collected from Microsoft’s error-reporting systems indicate that device driver faults are a leading cause of OS crashes (known informally as "blue screens"). There are several reasons for the lack of reliable device drivers.

Complex APIs. The device driver API exposed by Windows is complex and requires developers to include many lines of code, a bug in any of which can cause the system to crash. In addition, WDM exposes many important internal OS data structures directly to the device drivers; these data structures can be corrupted by the device driver and cause the OS to crash.

Microsoft mitigates these difficulties somewhat with a set of "miniports" built on top of WDM. Miniports provide common code required for an entire class of devices, such as network cards, leaving the device manufacturer free to write the code specific to its particular device, such as a 3COM 3C905X Ethernet card.

Although a laudable effort, miniports quickly became complex in their own right. As many as 10 distinct miniport interfaces evolved to meet the needs of a wide range of devices, from printers to digital cameras to SCSI devices. In addition, important OS capabilities such as Plug-and-Play and Advanced Power Management were often introduced after a given miniport architecture was first developed, leading to different APIs for each miniport. This wide variation in APIs has become particularly problematic with the increasing popularity of multifunction devices. A vendor producing a combination scanner, printer, and fax machine might have to deal with three or four different miniport models.

Tightly coupled to OS internals. Device drivers have direct access to many key internal data structures of Windows. Although such access gives driver developers a great deal of flexibility, it restricts Microsoft’s ability to change these internal structures without breaking the drivers that rely on them. Sometimes Microsoft decides that a particular change provides enough benefit to be worth breaking compatibility, such as when it moved from Windows NT to Windows 2000, but more often than not, it is forced to leave these data structures alone.

Forced into kernel mode. Most device driver developers find they must create drivers that run in kernel mode along with the OS itself, rather than in user mode, where applications run. Even if the device in question doesn’t require kernel-mode drivers, WDM often forces the driver to run in kernel mode. This limits system reliability because kernel-mode failures crash the machine, while user-mode failures typically do not.

Must be written in C. Windows, like many OSs, is largely written in C, and the APIs and data structures it exposes to device drivers are C-based. When compared with more modern languages, C offers little protection from common programmer errors that can lead to accidental data corruption.

Windows and Drivers: Toward a More Perfect Union

To alleviate some of these problems, Microsoft has announced a set of long-term goals for transforming the way Windows interacts with device drivers and the steps it is taking with Longhorn. The long-term goals include the following:

Consistency across devices. As multifunction devices proliferate, it is becoming increasingly important that Microsoft consolidate its device driver APIs and eliminate the need for many miniport models. Important OS features such as Plug-and-Play and Advanced Power Management need to be exposed to device drivers in a consistent fashion.

Isolate the OS. Isolating key OS data structures from drivers will have several benefits. First, it prevents drivers from accidentally corrupting the OS. Second, it allows Microsoft to modify OS data structures without breaking existing drivers.

Support user-mode drivers. Although many device drivers will continue to require access to kernel-mode capabilities, Microsoft would like as many drivers as possible to run in user mode. Devices such as portable media players, for example, simply copy files to and from the PC and have no need for access to low-level PC hardware and services such as interrupt requests.

Longhorn Offers First Step

As a first step toward these goals, Microsoft announced at the May 2004 Windows Hardware Engineering Conference (WinHEC) a new framework for building device drivers. Available in Longhorn, the WDF will be a new set of APIs for building device drivers. In its initial incarnation, WDF will be built on top of the existing WDM architecture, ensuring that current drivers will still run on Longhorn. In addition, Microsoft has said that WDF will be supported on Windows 2000 or later. Microsoft hopes that the majority of drivers will eventually be built using WDF, allowing the company to drop the current driver architecture altogether. Such a move, however, will not happen until after Longhorn.

WDF will take several important steps toward Microsoft’s ultimate goal. First, it will introduce a level of isolation between the OS and the drivers, insulating the OS from some types of accidental corruption and allowing the company to change the underlying data structures without breaking compatibility. Second, it will provide a common framework that unifies the existing set of APIs into a coherent whole. Finally, although in its initial release it will still be limited to the C programming language, Microsoft has indicated that WDF will at some point in the future support C and C++ for kernel-mode drivers and C, C++, and C# for user-mode.

Still a Work in Progress

Although Microsoft made a prerelease version of WDF available to WinHEC attendees, some details remain sketchy. First, although Microsoft has said that support for user-mode device drivers is scheduled to be included in Longhorn, the prerelease version of WDF provided at WinHEC offered no such support.

WinHEC white papers offering more details on WDF are available at www.microsoft.com/whdc/winhec/papers04.mspx.