Color is a glorious thing—most of the time. When you see red roses or green acres or purple sage, life is good. But when the blue screen of death pops up on your computer, the air rapidly takes on the same hue as you contemplate the work you just lost. (Tsk - didn't Mom tell you not to use language like that!) Aargh! And, chances are, if you wade through the esoteric error dump, you'll find that the BSOD was caused by a funky device driver.

The driver model we've known and cursed for years was born before many of the devices for which it's used were a gleam in a designer's eye. It predates the last several versions of Windows. And it is, Microsoft admits, totally inadequate for today's systems. It's too complex, and offers too many opportunities for errors.

Stu Farnham, director, Windows device experience group core, heads the team that is working on a new driver model. Well, actually, he's working on one of the models. In the driver world, there are graphics drivers, and everything else.

Farnham's in charge of everything else.

His group is working to simplify the platform and make it more robust, so third party drivers won't send Windows into hysterics. “Writing drivers is difficult, expensive and risky,” he said. “I view this as a Microsoft problem, not a third party problem. We have to provide a better platform.”

To understand the issues, we have to step back and look at the existing Windows Driver Model (WDM). Device-specific drivers (storage, for example, or networking) consist of two pieces: a port driver, typically written by Microsoft, that handles the generic functions for the device class, and a miniport driver written by the device vendor that handles the specifics.

As more device types have hit the market, more pieces have been tacked on, until now the crazy-quilt supports more than ten miniport models.

Because the WDM is low-level, a lot of coding is required for basic functions. Microsoft says that supporting Plug and Play and power management takes at least 2,000 lines of tricky code, writing to a complex device driver interface (DDI). And, says Farnham, a lot of what's provided to developers is code that has to be cut and pasted from boilerplates, so “Microsoft's bugs are being propagated through the community.”

Therefore, one of the first things Microsoft has done in the new Windows Driver Foundation (WDF) is encapsulate boilerplate code in libraries. No more cut and paste. Just a call to a library that can be fixed, if necessary, with no impact on the millions of lines of code that depend on it, except that bugs will go away.

WDF also contains the beginning of an isolation model that will protect the operating system from misbehaving drivers. Today, device drivers usually run in kernel mode, an artifact of the early days when Microsoft didn't believe that third parties would write drivers. A burp in a driver can mean the infamous BSOD.

Another artifact, designed to give systems folks heartburn, is a total lack of versioning in DDIs. To add to the pain, DDIs are exported directly from the operating system kernel, and may expose essential OS data. They also effectively prevent changes to the structure of that data.

The WDF manipulates data structures on the device's behalf. It will contain two frameworks: one for kernel mode drivers, and one for user mode drivers.

The kernel mode framework is not part of the operating system kernel, though. Instead, it is a separate library that supports versioning and side-by-side usage. It is designed to run under driver isolation, where drivers run in a protected environment and can't crash the operating system if they go toes-up.

The user mode framework is a subset of the kernel mode, and will be used for devices like digital cameras and cell phones.

Both frameworks will be supported under Longhorn, but the kernel mode can also be used for drivers for Windows 2000 and higher. In fact, at the Windows Hardware Engineering Conference (WinHEC) this spring, Microsoft's Jim Allchin urged developers to begin writing to the model now to help increase Windows' security and stability.

“I can imagine that most drivers will take advantage of the kernel/user split. A trend I'm seeing is that more and more IHVs are looking to people less familiar with systems programming to write their drivers. Application developers are not familiar with the subtleties,” Farnham noted. “[User mode drivers] will be cheaper to produce. You can use normal tools, they're faster to develop, and (when testing) you can just restart the application, not crash and reboot.”

To get started with WDF, sign up for the beta program here. For white papers and further documentation, visit: http://www.microsoft.com/whdc/driver/wdf/default.mspx.