When to Write WDM Class Drivers

This article explores answers to a commonly asked question about whether the best approach for supporting a particular device under the Microsoft Windows 2000, Windows XP, Windows 98, and Windows Me operating systems is to write an additional WDM solution or to use the Microsoft-supplied Windows Driver Model (WDM) drivers supplemented with device-specific minidrivers.

For mainstream devices, Microsoft is providing a complete solution; but where is the dividing line beyond which you must develop an additional WDM solution? To help answer this question, this article briefly examines the features and capabilities of the Microsoft-supplied driver solutions to establish how these solutions apply for various kinds of devices. This article concludes with a list of issues to consider in planning new driver support under Windows operating systems.

The information in this article applies specifically for Windows 98/ME and Windows 2000. For complete information, see "WDM Drivers in Windows Millenium Documentation" (for Windows 9x), and see "Windows Driver Model" (for Windows 2000/Windows XP) in the Windows DDK.

On This Page

	Overview of WDM Mainstream Classes
	Choosing Driver Solutions

Overview of WDM Mainstream Classes

WDM Stream Class

The Microsoft WDM Stream class has abstracted a way to transport high-bandwidth, time-stamped, latency-sensitive data streams between kernel-mode components or between kernel-mode drivers and user-mode components. Power management and Plug and Play support is provided. The WDM Stream class also simplifies driver development by handling multiprocessor and reentrancy issues.

WDM Stream class services are purposefully not specific to any type of data or any bus type; property sets provide a method to support specific devices. Its generic quality makes the Stream class suitable for a broad range of device applications. Minidrivers supplied by IHVs or ISVs add globally unique identifiers (GUIDs) and define specific property sets to create new device-specific or data-specific implementations of the Stream class. Although extreme care must be taken, data-specific filter drivers can be written for hardware to manipulate the data in some way.

Through CSA, the Stream class works well with Microsoft DirectShow (formerly known as ActiveMovie) in that it shares media types, has similar streaming states (Stop, Pause, Run), and shares the same concept of pins and connections. This synergy makes user-mode DirectShow filters an extremely powerful and relatively safe method for manipulating data from a kernel-mode Stream class driver. Through CSA, identical streaming capabilities are supported between kernel-mode components.

Although mainstream implementations of streaming include video capture, TV viewing, VBI data codec support, and DVD movie playback, the Stream class can also be used to support other device types. An example is high-volume capture of instrumentation data, where time-stamping and data manipulation are important features. The ease with which DirectShow can use this data is an important consideration in deciding to use the Stream class to support a specific device.

For detailed information about the Stream class, see Stream Class Driver and Minidriver Design Notes and Reference, Windows Driver Model Connection and Streaming Architecture Design Guide and Reference, Stream Class Video Capture Minidriver Design Notes and Reference, and Audio Device Minidriver Design Notes and Reference, which are Help files provided in the Windows 98 DDK.

Human Interface Device (HID) Class

The Microsoft HID class driver has abstracted the description and manipulation of device controls. Any device with controls can benefit from the HID architecture, although this class driver is most commonly associated with keyboards, mice, and gaming devices (with monitors, power devices, and audio controls on speakers shortly on the horizon). For example, consumer-control devices such as remote controls and front panels are likely candidates for support using the HID class driver. Power management and Plug and Play support is provided. Current implementations of HID devices are for the USB, but HID support under WDM is not bus-specific. Development opportunities exist for IHVs and ISVs to supply HID class minidrivers that support legacy input devices using HID emulation or that support HID devices using legacy ports or IEEE 1394. Vendors can also add value to HID devices by creating user-mode filter drivers.

For detailed reference information about the HID class, see the Human Interface Devices Help file in the Windows 98 DDK. Information about USB HID is also available on the USB Implementers Forum web site at http://www.usb.org .

Port Class

The Microsoft Port class provides support for PCI and ISA/DMA audio devices.

Existing Port drivers include Wave I/O using cyclic DMA, Wave I/O using scatter/gather, Topology (MixerLine support), and MIDI. The Port class is the recommended technology for supporting audio devices, except in a few cases where only minor audio support is needed to supplement a Stream class driver. A vendor can use the Port class to provide support for a specific audio device by writing one or more miniport drivers.

The Port class, like the Stream class, participates in CSA and has the same streaming capabilities and the same synergy with DirectShow. It also simplifies driver development by handling multiprocessor and reentrancy issues. The Port class is distinguished from the Stream class in the following ways:

For detailed information, see WDM Streaming Miniport Driver Model Specification, which is a document in the Windows 98 DDK.

Still Image Architecture

The Microsoft Still Image architecture (STI) does not constitute a class, but rather an infrastructure that focuses on incorporation of support for still image devices such as scanners and still image cameras into the Windows 98 and Windows 2000 operating systems. Vendor-supplied, user-mode minidrivers implement device-specific device driver interface (DDI) functionality, including test, status, and data I/O capabilities. These minidrivers inform the DDI of the devices capabilities and use standard interfaces to communicate with a specific kernel-mode device driver. STI currently provides support for SCSI, serial, parallel, and USB devices, but the architecture is extensible, so IrDA, IEEE 1394, or MFP devices can be easily incorporated. If a device does not conform to the standard Microsoft kernel-mode drivers for a specific bus, the vendor must supply its own kernel-mode driver. Current bus-specific issues for STI are:

For detailed information about STI, see Architecture and Interfaces for Scanners and Digital Still Cameras Design Notes and Reference, which is a Help file in the Windows 98 DDK.

Modems

Controllerless modem support begins with the vendor implementing a Serial.sys solution for Windows NT 4.0. To leverage this development work for Windows 2000 and Windows 98, Microsoft developed Ccport.vxd, which can be used to map Serial.sys to a VCOMM port. However, because Windows NT 4.0 does not have Plug and Play capabilities, the Serial.sys driver must be enhanced to support Plug and Play. A single binary can be developed that programmatically determines which operating system it is running on and then exposes the additional features used by Windows 2000 or Windows 98. In this way, a single driver can be developed and pass compatibility testing for use on all three operating systems.

An implementation of an audio minidriver to expose pulse-code modulation (PCM) audio off the controllerless modem can be added. Additional implementations are still under discussion, and will be described in this article when details are available.

USB and IEEE 1394

The USB and IEEE 1394 drivers provided under Windows 98 and Windows 2000 are bus-independent, so they will support USB or IEEE 1394 adapters or bridges on any other type of bus. Plug and Play support is provided. Both interfaces use I/O request packets (IRPs) to communicate with their respective bus drivers.

For detailed information about the USB driver interface, see Universal Serial Bus, which is one of the Help file documents in the Windows 98 DDK. This Help file should be used in conjunction with WDM USB Driver Interface.

For information about the IEEE 1394 bus interface, see IEEE 1394 Bus Driver Design Notes and Reference, which is one of the Help files in the Windows 98 DDK.

Top of page

Choosing Driver Solutions

This section summarizes the key design issues to consider in establishing plans for WDM-based support for Windows 98 and Windows 2000. Your answers to the following questions should point you in the right direction for driver planning. You must still investigate the capabilities of specific WDM class drivers to complete your planning decisions.

Does your device need to ship before retail versions of Windows 98 or Windows 2000 ship?

If Yes, write a Windows 95 or Windows NT 4.0 solution, then write a WDM solution for Windows 98 and Windows 2000. Ensure that your driver installation routines will accommodate a smooth upgrade for users who upgrade to the new operating system.

If No, continue to the next question.

Does your device have wide enough distribution to justify writing a WDM layered-architecture solution? (For example, at the WDM Device Driver Conference, someone questioned how to support an electron microscope, which is an example of a device with very limited distribution.)

If Yes, continue to the next question.

If No, write a monolithic driver solution using Windows 98 or Windows 2000 services such as CSA that supply the needed functionality.

Do the capabilities of the Microsoft-supplied WDM class driver satisfy all your device requirements?

If Yes, write an appropriate minidriver, miniport, or filter

If No, it might be for one of several reasons:

Top of page