A Brief History of Device Drivers

The earliest PCs ran on an Intel processor chip that provided addressability for 640 KB of real memory so called because the memory was really there in the form of memory chips that the processor addressed directly by means of a 20-bit physical address. The processor itself offered just one mode of operation, the so-called real mode, wherein the processor combined information from two 16-bit registers to form a 20-bit memory address for every instruction that referenced memory. The computer architecture included the concept of expansion slots that brave users could populate with cards purchased separately from the computer itself. The cards themselves usually came with instructions about how to set DIP switches (later, jumpers between pins) in order to make slight changes in I/O configuration. You had to keep a map of all the I/O and interrupt assignments for your PC in order to do this correctly. MS-DOS incorporated a scheme based on the CONFIG.SYS file whereby the operating system could load real-mode device drivers for original equipment and for add-on cards. Inevitably, these drivers were programmed in assembly language and relied to a greater or lesser extent on the INT instruction to talk to the BIOS and to system services within MS-DOS itself. End users perforce learned how to invoke applications via commands. Application programmers perforce learned how to program the video display, keyboard, and mouse directly because neither MS-DOS nor the system BIOS did so adequately.

Later on, IBM introduced the AT class of personal computers based on the Intel 80286 processor. The 286 processor added a protected mode of operation wherein programs could address up to 16 MB of main and extended memory using a 24-bit segment address (specified indirectly via a segment selector in a 16-bit segment register) and a 16-bit offset. MS-DOS itself remained a real-mode operating system, so several software vendors built DOS extender products to allow programmers to migrate their real-mode applications to protected mode and gain access to all the memory that was becoming available on the market. Since MS-DOS was still in charge of the computer, driver technology didn t advance at this point.

The watershed change in PC technology occurred in my view, anyway when Intel released the 80386 processor chip. The 386 allowed programs to access up to 4 GB of virtual memory addressed indirectly via page tables, and it allowed programs to easily use 32-bit quantities for arithmetic and addressing. There was a flurry of activity in the software tools market as compiler vendors and DOS extender companies raced to capture the ever-growing volume of large applications hungry for memory and processor speed. Device drivers were still 16-bit real-mode programs written in assembly language and installed via CONFIG.SYS, and end users still needed to manually configure cards.

Subsequent advances in processor chips have been mainly in the area of performance and capacity. As I write this chapter, computers operating faster than 1 GHz with 50-GB hard drives and 512 MB (or more) of memory are commonplace and easily affordable by large segments of the population.

In parallel with the evolution of the platform, another evolution was occurring with operating system technology. Most people, even including programmers of system software, prefer graphics-based ways of interacting with computers to character-based ways. Microsoft was late to the graphical operating system party Apple beat them with the first Macintosh but has come to dominate it with the Windows family of operating systems. In the beginning, Windows was just a graphical shell for real-mode MS-DOS. Over time, a collection of Windows drivers for common hardware, including the display, keyboard, and mouse, came into existence. These drivers were executable files with a .DRV extension, and they were written primarily in assembly language.

With the advent of the AT class of computer, Microsoft added a protected-mode version of Windows. Microsoft ported the real-mode .DRV drivers to protected mode as well. Hardware other than the standard Windows devices (the display, keyboard, and mouse) continued to be handled by real-mode MS-DOS drivers.

Finally, some time after PCs with 386 processors became widely available, Microsoft released Windows 3.0, whose enhanced mode of operation took full advantage of the virtual memory capabilities. Even so, it was still true that every new piece of hardware needed a real-mode driver. But now there was a big problem. To support multitasking of MS-DOS applications (a requirement for end user acceptance of Windows), Microsoft had built a virtual-machine operating system. Each MS-DOS application ran in its own virtual machine, as did the Windows graphical environment. But all those MS-DOS applications were trying to talk directly to hardware by issuing IN and OUT instructions, reading and writing device memory, and handling interrupts from the hardware. Furthermore, two or more applications sharing processor time could be issuing conflicting instructions to the hardware. They would certainly conflict over use of the display, keyboard, and mouse, of course.

To allow multiple applications to share physical hardware, Microsoft introduced the concept of a virtual device driver, whose broad purpose is to virtualize a hardware device. Such drivers were generically called VxDs because most of them had filenames fitting the pattern VxD.386, where x indicated the type of device they managed. Using this concept, Windows 3.0 created the appearance of virtual machines outfitted with separate instances of many hardware devices. But the devices themselves continued, in most cases, to be driven by real-mode MS-DOS drivers. A VxD s role was to mediate application access to hardware by first intercepting the application s attempts to touch the hardware and briefly switching the processor to a sort of real mode called virtual 8086 mode to run the MS-DOS driver.

Not to put too fine a face on it, mode switching to run real-mode drivers was a hack whose only virtue was that it allowed for a reasonably smooth growth in the hardware platform and operating system. Windows 3.0 had many bugs whose root cause was that very feature of the architecture. Microsoft s answer was to be OS/2, which it was developing in harmony (using a twentieth-century definition of harmony, that is) with IBM.

Microsoft s version of OS/2 became Windows NT, whose first public release was in the early 1990s, shortly after Windows 3.1. Microsoft built Windows NT from the ground up with the intention of making it a durable and secure platform on which to run Windows. Drivers for Windows NT used a brand-new kernel-mode technology that shared practically nothing with the other two driver technologies then in vogue. Windows NT drivers used the C programming language almost exclusively so that they could be recompiled for new CPU architectures without requiring any source changes.

Another thing happened along about the Windows 3.0 time frame that has an important ramification for us today. Windows 3.0 formally divided the software world into user-mode and kernel-mode programs. User-mode programs include all the applications and games that people buy computers to run, but they are not to be trusted to deal robustly (or even honestly) with hardware or with other programs. Kernel-mode programs include the operating system itself and all the device drivers that people like you and me write. Kernel-mode programs are fully trusted and can touch any system resource they please. Although Windows 3.0 segregated programs by their mode of operation, no version of Windows (not even Windows Me) has actually put memory protection in place to yield a secure system. Security is the province of Windows NT and its successors, which do forbid user-mode programs from seeing or changing the resources managed by the kernel.

Computing power didn t really advance to the point where an average PC could run Windows NT well until quite recently. Microsoft therefore had to keep the Windows product line alive. Windows 3.0 grew into 3.1, 3.11, and 95. Starting with Windows 95, if you wanted to write a device driver, you would write something called a VxD that was really just a 32-bit protected-mode driver. Also starting with Windows 95, end users could throw away their I/O maps because the new Plug and Play feature of the operating system identified and configured hardware somewhat automatically. As a hardware maker, though, you might have had to write a real-mode driver to keep happy those of your customers who weren t upgrading from Windows 3.1. Meanwhile, Windows NT grew into 3.5, 4.0. You would have needed a third driver to support these systems, and not much of your programming knowledge would have been portable between projects.

Enough was enough. Microsoft designed a new technology for device drivers, the Windows Driver Model (WDM), and put it into Windows 98 and Windows Me, the successors to Windows 95. They also put this technology into Windows 2000 and Windows XP, the successors to Windows NT 4.0. By the time of Windows Me, MS-DOS was present only by courtesy and there was finally no need for a hardware maker to worry about real-mode device drivers. Because WDM was, at least by original intention, practically the same on all platforms, it became possible to write just one driver.

To summarize, we stand today in the shadow of the original PC architecture and of the first versions of MS-DOS. End users still occasionally have to open the skin of their PCs to install expansion cards, but we use a different and more powerful bus nowadays than we did originally. Plug and Play and the Peripheral Component Interconnect (PCI) bus have largely removed the need for end users to keep track of I/O, memory, and interrupt request usage. There is still a BIOS in place, but its job nowadays is mostly to boot the system and to inform the real operating system (Windows XP or Windows Me) about configuration details discovered along the way. And WDM drivers still have the file extension .SYS, just as the first real-mode drivers did.