Chris Cant - Writing Windows WDM Device Drivers

Over the years, various hardware developments have seen the light of day, such as MCA, EISA, PCI, and SCSI buses, with Plug and Play capability. Not all these developments have won market support.

PC 99 still supports all these "legacy" peripherals, if they are present in the system.

PCs have a Basic I/O System (BIOS) in ROM that runs when the computer is first switched on. This ROM finds the relevant operating system and runs its boot loader to start DOS, Windows 98, Windows 2000, or whatever.

Most programs that are used nowadays run using Win32 (or at least Win16) functions. These routines do not allow direct access to I/O ports, etc. For example, when keyboard input is required, W98 or W2000 carries out the necessary operation. In the IBM-compatible environment, it interacts with the keyboard controller using techniques dating from time immemorial.

Less DOS applications are being run. In W98, NT, and W2000, these do not get direct access to the hardware. Instead, a Virtual Device Driver arbitrates access to these peripherals, allowing multiple DOS and Windows applications to run at the same time.

These two developments allow the Windows operating systems to move away from the original IBM-compatible specification. As long as the right keystroke messages get through to user programs, it does not matter where in hardware they come from. For old DOS programs that do try to access the actual hardware, virtual device drivers on faster new machines can emulate the required functionality.

The new wisdom is that the USB and IEEE 1394 (originally called FireWire) devices represent an easier way for users to connect assorted peripherals to the system, including standard system components such as a keyboard and a mouse. The idea is that any devices can be plugged in easily (even when the computer is on) and — within limits — daisy chained together. USB and IEEE 1394 devices cope with being plugged in anywhere. The Windows Plug and Play system sorts out any resource allocations on the fly.

Whether users will take to the new doctrine remains to be seen. Plugging a new USB device in will certainly be easier than dismantling a case, fiddling with jumpers, and inserting a card. The new Device Bay specification will allow easy insertion of cards within the chassis of the PC.

USB's 12Mbs is designed for slower-speed devices, such as keyboards, mice, joysticks, printers, modems, telephones, and monitors. IEEE 1394 runs faster, at 100 Mbs or more, and is more useful for devices such as scanners, storage units, and audio/visual kit, such as digital cameras.

New PCs aim to use less power and switch on more quickly, as well as supporting Plug and Play. Windows and new BIOS chips use the Advanced Configuration and Power Interface (ACPI) specification to help with these tasks.

ACPI-based hardware knows how to turn off or reduce power to some devices. Windows drivers can now help in this process by using the Power Management IRPs and routines, and the power management routines that are relevant for its device class. The aim of the OnNow initiative is that a PC may appear to be off, when in fact it is just "sleeping", waiting for a soft power on button to be pressed. As the operating system and drivers are already loaded into memory, it takes less time to start up the system. Devices simply need to be powered up for the user to get started. A remote control handset or incoming modem call may similarly be used to wake the system up.

Both Windows 98 and Windows 2000 can now take full use of the Plug and Play hardware facilities to allow easy device insertion and removal. Again, drivers need to help in this process, allocating and releasing resources only as instructed by the Plug and Play Manager.

PC 99 specifies that ACPI, OnNow, and Plug and Play must be supported.:

Microsoft can certify your hardware and software as PC 99 compatible. To do this, contact their Windows Hardware Quality Labs at http://www.microsoft.com/hwtest/ or e-mail to whqlinfo@microsoft.com. When your driver passes these tests, Microsoft gives you a digital signature catalog file that you should include in your driver's INF file.

The Windows DDK includes a simplified version of Microsoft's own tests on their Hardware Compatibility Tests (HCT) CDs. Check out your driver with these tests before submitting your driver for full testing.

This book does not cover Direct Memory Access (DMA) in detail. However, NT 3.51 and NT 4 driver writers will find that they must access the DMA system routines in a new way. All the same routines are there, you just have to call IoGetDmaAdapter first. This returns a pointer to a DMA_ADAPTER object. The DmaOperations field in there contains pointers to all the familiar routines. Call the DmaOperations PutDmaAdapter callback when you have finished with the DMA_ADAPTER object.

Table C.1 shows the corresponding old and new routines. Just to reiterate, there is no kernel routine directly called PutDmaAdapter . This routine is only available through the DMA_ADAPTER structure, e.g.,

(*DmaAdapter->DmaOperations->PutDmaAdapter)(DmaAdapter);

Table C.1 Old and new DMA routines