Windows 95/98

Windows Support Menu


Windows 9X Devices

Win98 Device Drivers

Win32 Driver Model Architecture

The Microsoft Win32® Driver Model is an effort to allow developers to write a single hardware device driver that is compatible with both of Microsoft’s operating systems for Intel platforms, Windows 9x and Windows NT. First introduced in Windows 95 OEM Service Release 2.1, WDM defines a device driver architecture that provides a common set of I/O services understood by both Windows NT and Windows 98.

Currently, WDM support in Windows 98 only extends to the Simply Interactive PC (SIPC) framework which includes new Plug and Play device support for USB, IEEE 1394 (FireWire) and power management adhering to the On-Now initiative. Device drivers for display adapters and network adapters that conform to the WDM are not being provided for Windows 98.

Cross platform compatibility is the result of Win32 Driver Model’s (WDM) layered architecture. Each layer or class isolates portions of the services required of a device driver and allows hardware vendors to contain all of the hardware specific functionality into a single file.

Prior to WDM, device drivers included hooks for a particular operation system in addition to the elements necessary to interact with a specific piece of hardware. This non-layer approach prevented device drivers from being supported across multiple operating systems. Removing operating system links from the driver files that directly interact with the hardware is precisely the way WDM allow a single device drivers to be used in Windows 98 and Windows NT.

WDM Driver Model

WDM is based on the concept of driver classes. Driver classes serve as layers of abstraction that give Windows devices drivers the ability to be used in both Microsoft Windows NT and Windows 98. There are five layers to the WDM.

  • Class Drivers
  • Bus Class Drivers
  • Minidrivers
  • OS Services
  • Virtualization Drivers

Class Drivers

Class drivers provide interfaces between different layers of the WDM architecture. The lower layer of the class drivers communicates with the class-specific interface exposed by a minidriver. The upper edge of top-level class drivers is OS-specific. Class drivers also have the following capabilities:

  • Class specific functions, not hardware or bus-specific
  • Dynamically loaded and unloaded
  • Contain only class-specific functions such as enumeration
  • Exposed a single class-specific interface to multiple client layers

An example of a class driver is Hindclass.sys. This is the generic layer for input devices such as joysticks, mice and keyboards.

Bus Class Drivers

Bus Class Drivers are a subset of Class drivers. Bus Class drivers perform the same function as Class drivers but facilitate the communication between the hardware and device specific mini-drivers.

An example of a bus class driver is Usbd.sys, the generic USB class driver.


Minidrivers are already implemented in Microsoft Windows 95 in the classes of SCSI and network adapters. With Windows 98, the concept of minidrivers has been widened to include support for Universal Serial Bus, Digital Audio, DVD player, still imaging, video capture and IEEE 1394 (more commonly known as Fire Wire). Minidrivers provided the following services:

  • Indirectly control hardware through a specific bus class driver.
  • Source and binary compatible across the Microsoft Windows platforms which allows the minidriver to be used in NT as well as Windows 98.
  • Can be dynamically loaded and unloaded.
  • Contain only hardware specific functionality.
  • Can expose multiple class interfaces. This functionality is very important in respect to multi-function (or composite cards) such as devices that provide audio and video.

An example of a minidriver is Hidusb.sys. This is the minidriver HID class device designed for the Universal Serial Bus.

Operating System Services

The OS services layer is always specific to the operating system. It is this layer that abstracts all of the operating system specific functionality from the minidriver layers beneath it. It handles the communications between the OS specific class drivers and the platform independent minidriver.

An example of an Operating System Driver is Ntkern.vxd.


The implementation of WDM in Windows 98 is achieved by adding a new layer to the existing device driver architecture. In Microsoft NT, device driver access is handled by calls to Kernel Services. In Windows 98, Ntkern.vxd provides a similar environment. Ntkern.vxd allows the Windows 98 architecture to appear, to the minidriver, to be the same as the NT architecture. This abstraction is what allows IHVs to develop one driver for both operating systems.

Simply put, Ntkern.vxd provides an NT-like environment in Windows 98 so common device drivers can be sues in both operation systems.

Note: The file Ntkern.vxd is contained within the Vmm32.vxd.

Virtualization Drivers

Virtualization drivers have been a part of Microsoft Windows since the release of Windows 3.0. They are the familiar Vxd files in Microsoft Windows 95 and the 386 files in earlier versions of Microsoft Windows. Virtualization drivers under WDM have some very specific functions. They virutalize the interfaces to legacy hardware and send class-specific commands to the appropriate device. That is to say, an MS-DOS game running under Microsoft Windows would go through the virtualization driver in order to work with USB-based joystick. Virtualization drivers do not drive hardware directly. Instead they act as go-betweens so that legacy software and/or hardware can work correctly under the new architecture.

It is important to note that not all Vxds have changed to work with the WDM. Some Vxds retain the same functionality as before.

An example of this would be Joyhid.vxd, the mapping layer between Vjoyd.vxd and Hidclass.sys.

WDM Support Issues

WDM is the base line architecture in Windows 98. When troubleshooting a WDM issue, follow the steps listed under the bus class of the device. That is to say, if a customer is having problems with a WDM USB driver, follow the standard troubleshooting steps for USB.