Have you experienced the frustration of trying to load a driver for a specific piece of hardware? Perhaps you tried to use a driver with Windows 98 that was intended for use with Windows NT. Fortunately, in the very near future, this will no longer be a problem. In this article, we’ll introduce you to the WIN32 Driver Model and explain how it will allow you to use a common driver for Windows 98, and for future versions of Windows NT (Windows 2000).

What is the WIN32 Driver Model?
The WIN32 Driver Model refers to a set of standards that will allow any Windows operating system complying with these standards to use a common set of drivers. This model was first used in the OSR2 version of Windows 95.

To understand how the WIN32 Driver Model works, you must first know how a hook works. As you may be aware, 32-bit Windows operating systems don’t allow programs or device drivers to interface directly with the hardware. When an application needs to access a piece of hardware, it makes a call to that hardware. Windows intercepts this call by using a subroutine called a hook. Windows then makes the call to the hardware for the program and sends the desired information back to the program that made the original call. By using this hook, the program never directly accesses the hardware, thus allowing the Windows operating system to maintain full control over your system.

Before the advent of the WIN32 Driver Model, each device driver was responsible for interacting with a particular operating system, and for tying that operating system to the hardware the driver was responsible for. This meant that a device driver written for Windows 9x couldn’t be used with Windows NT.

However, a growing number of hardware types now support the WIN32 Driver Model. These hardware types include Universal Serial Bus (USB), the IEEE standard 1394, OnNow power management, DVD players, and Digital audio devices.

In some circumstances, it may also be possible to use a common network card driver with Windows NT and Windows 9x because the driver conforms to the NDIS standard, and not because it’s using the WIN32 Driver Model.

WDM architecture
The reason the WIN32 Driver Model works with multiple operating systems is its structure. Rather than writing one large monolithic device driver, Microsoft has taken a layered approach. This method breaks each device driver down to seven layers. Rather than having to tackle the entire task, each layer performs only a small portion of the task at hand. Each layer is written in a way that allows it to communicate with the layer above it and the layer below it.

Some of these layers are built into the operating system, while others are built into the driver itself. Since each layer is written in such a way as to communicate certain information with the layers surrounding it, it’s no problem to use the driver’s portion with a different operating system—as long as the operating system conforms to these standards.

Figure A shows the complete WIN32 Driver Model architecture. You can refer to this figure when reading the rest of the article.

Figure A
Each layer is written in a way that allows it to communicate with the layer above it and the layer below it.

Legacy Virtualization Drivers
One of the highest layers of the WIN32 Driver Model is the Legacy Virtualization Drivers layer. This layer is responsible for interfacing with legacy programs. Rather than actually controlling the hardware, it acts as a go between. For example, if a DOS-based program made a call to the joystick, this layer would intercept the call and interpret it in a way that Windows could understand.

Device Class Drivers
The Device Class Drivers is a module that’s responsible for communicating with the operating system and with a class specific component of the driver. Device class drivers contain class specific functions that aren’t specific to the bus or to the hardware.

Device and Bus Class
Mini-drivers
As we mentioned earlier, Windows 98 allows you to use mini-drivers with a variety of hardware types. Mini-drivers indirectly control the hardware through a specific bus class driver. These mini-drivers will actually work with Windows 98 and with Windows NT. One of the most interesting features of the mini-drivers is that they allow multiple class interfaces. This feature is essential for supporting hardware devices with multiple functions, such as video and sound combination cards.

Bus class drivers
Bus class drivers are the same as device class drivers, except that they communicate with the hardware and with the mini driver.

Operating system services
The operating system services layer handles all communication between the class driver, which is operating system specific, and the mini-driver layer. An example of an operating system service driver is the Ntkern.vxd file. Used in Windows 95 OSR2 and in Windows 98, this file makes the operating system appear to the mini-driver as if it were Windows NT. This functionality can be directly compared to Windows NT’s HAL (Hardware Abstraction Layer).

Conclusion
In this article, we’ve explained how the use of the WIN32 Driver Model allows a single driver to work on multiple operating systems. As we did, we’ve explored the various levels of the WIN32 Driver Model and how they interface with each other.

Talainia Posey learned to handle PCs the old fashioned way: by reading manuals and doing on-the-job troubleshooting. Her experience also includes installing networks for several small companies. When she’s not working on computers, Talainia loves to shop for toys and watch cartoons, or spend time with her cat, Beavis.

The authors and editors have taken care in preparation of the content contained herein, but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for any damages. Always have a verified backup before making any changes.