The Windows Driver Model traces its roots several years back to an OS called Windows for Workgroups 3.10. At that time we were struggling with support for the myriad of different SCSI controllers, and I was gazing longingly at the assortment of miniports that the Windows NT team had created. It didn’t take long to realize that it would take less effort to re-create the necessary image loader and execution environment that the miniports expected than it would to rewrite and debug all of those miniports in some sort of VxD form.
Unfortunately Windows for Workgroups 3.10 ended up shipping without support for SCSI miniports, due mainly to peripheral issues such as solid ASPI (Advanced SCSI Programming Interface) compatibility. However, the groundwork to share the same executable driver images across the Windows and Windows NT operating systems was in place and would see the light of day in Windows 95, which could share both SCSI and NDIS miniport binaries with Windows NT.
The potential benefits of a shared driver model are significant. For driver developers interested in supporting both platforms, a shared driver model can cut the driver development and testing costs almost in half. For Microsoft, a shared model means easier migration from Windows 9x to Windows 2000 and future releases of this platform. And for the end user, a larger variety of more stable drivers would be available for both platform families.
The next logical step, then, was to create a driver model with the ability to share general purpose drivers across both platforms. But what form should it take? Three requirements were immediately obvious: it must be multiprocessor-capable, it must be processor-independent, and it must support Plug and Play (PnP). Fortunately, the Windows NT 4.0 driver model met the first two requirements, and it seemed clear that the next major release of Windows NT would support PnP as well. As a result, WDM can be considered a proper subset of what is now the Windows NT driver model.
The potential benefits of a shared driver model can be realized today for many classes of devices, and choosing the WDM driver model will continue to pay dividends in the future. For example, a correctly written WDM driver requires only a recompile before functioning in an NT 64-bit environment prototype.
WDM will continue to evolve as new platforms and device classes are supported. Future versions of Windows 9x and Windows 2000 will contain upwardly revised WDM execution environments. Fortunately, WDM is designed to be "backward compatible," meaning that WDM drivers written according to the Windows 2000 DDK and designed to work for the intended environment will continue to work in a subsequent WDM environments.
There is a lot to WDM, and in this book Walter does an excellent job in offering an in-depth tour of every aspect as well as the philosophy of the Windows Driver Model.
Forrest Foltz
Architect, Windows Development
Microsoft Corporation