[Previous] [Next]
Foreword
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
Page 5
ABC Amber CHM Converter Trial version, http://www.processtext.com/abcchm.html
