Device drivers

We use them every time we touch our PC, but how do they work? Follow Frank Charlton's guide to find out.
Windows drivers

Your PC consists of two basic components: hardware and software. The hardware side is obvious, since it includes everything from the main processor up to any internal or external peripherals you may have connected, along with everything in-between.

On the software side, you can break this rough description down even further into three basic sub- categories: the Operating System itself, user applications and finally device drivers. In a nutshell, device drivers are the pipeline through which the software communicates with the hardware. Windows comes with thousands of drivers right out of the box, and each is designed to make it possible for you (via Windows) to work directly with a specific piece of hardware, whether it be a scanner, modem or something more esoteric like a fingerprint reader. Every piece of hardware connected to your PC requires a driver of its own, or it simply won't work.

How drivers work
So what is a device driver, and how does it work? Thankfully, you don't need to understand the hideous complexities which face programmers when they sit down to develop a new driver, but a good understanding of how they actually perform their tasks is a good thing - and this series is called How Windows Works, after all.

From a very simple perspective, a device driver is like any other application, albeit one with some very important differences. To begin with, a device driver doesn't use windows and icons to communicate with the user, but sits between the programs you use and the hardware itself. While a normal application won't crash the entire system if a bug in the code rears its ugly head, device drivers need to be cleanly written and tested to the point of destruction to function properly.

If a program you're using crashes, modern versions of Windows will generally isolate that program and terminate it, preventing it from bringing the entire OS down with it. Since device drivers communicate with the OS and hardware at such a fundamental level, a crash will usually halt the system completely - we've all seen the blue screen of death pop up for no apparent reason with Windows XP, and it's almost always a device driver at fault in these cases.

In many senses, a device driver is similar to the Dynamic Link Library or DLL files used by Windows and every program under the sun to store portions of regularly used code. When a device driver runs, it passes information to Windows on which hardware it's talking to and what it can do, which is called a driver object.

Driver communication
The driver object is a portion of memory allocated by Windows, which describes where the actual driver is loaded into memory plus contains information readable by Windows about the driver. The driver does this by filling in entries in what Windows calls the Function Dispatch Table, a database which indicates to Windows what each driver can do.

When you decide to print a document or connect to the Internet, Windows will examine the Function Dispatch Table to see which major function code will be able to fulfill the request. Once that's done, Windows will then pass the request on to the relevant device driver to perform, so your printer springs into life or your modem dials out.

So that's how a driver basically works, but of course it's considerably more complex than that in real terms. To begin with, you need to grasp something fundamental about how program code is executed on your PC, and why certain differences exist.

Kernel and user mode
In simple terms, when Windows executes a segment of program code, it does so in one of two ways. First is what's known as user mode - this is how standard applications are run. When you launch Internet Explorer or any other program, it runs in user mode and as such can only call and access system services provided by Windows. Programs running in user mode can't access the hardware directly - if they try, Windows terminates the program thread and warns you. A good example of this is if you try to use an older hard drive management tool under XP, at which point Windows will warn you that direct hardware access isn't allowed.

The other execution method is using what is known as kernel mode. This runs programs in isolated portions of protected memory, and is how the core of modern Windows itself runs. When something runs in kernel mode, it has direct access to system memory and the hardware itself. As you might expect from this, device drivers will almost always run in kernel mode.

While a driver is running, it does nothing but sit back and wait for requests from user programs, Windows itself and even other drivers on the system. These requests are sent to the driver from Windows using something called an IRP, or I/O Request Packet. This is a piece of information which contains one of the supported major function codes so that the driver knows what it has to do. So, for example, your printer driver knows that you've asked it to print a page rather than run a test cycle or change the cartridges.

Mission control
Once the driver has received and understood this packet, it can take one of three paths. If it understands the request and can immediately fulfill it, it will do so and confirm to Windows that the request is complete. If the driver cannot immediately grant the request - if your scanner is busy dealing with an image at the time, for example - it places the IRP into a queue and tells Windows that the request is pending. Finally, if a driver can't fulfill the request, it notifies Windows of the problem and Windows must then pass the request to a different driver to proceed.

That's essentially how a device driver does its job. As we all know too well, though, not everything is perfect in this world and drivers often fail to perform properly and will occasionally crash Windows quite dramatically - yet another reason why we frequently stress you should always check that you have the latest drivers for your hardware, as an updated version can solve lots of different problems.
Frank Charlton

XP driver management

Driver management under Windows XP is more complex and more flexible than under the 9x variants of Windows. For starters, there's the thorny issue of driver signing. Once you have your PC working in a stable manner, you can easily prevent other users from adding new drivers which haven't passed Microsoft's stringent certification tests. By default XP will warn you that a driver is unsigned, but will happily install it if the user provides permission. If you want to change this behaviour so that Windows XP simply refuses to install a device driver without a digital signature, it's simple to do.

Log in with Administrator privileges, right-click My Computer and select Properties. Switch to the Hardware tab, then click the Driver Signing button. Change the setting to 'Block - Never install unsigned driver software' and ensure that 'Make this action the system default' is checked.

If a new driver proves to be troublesome, XP can revert to the previous version. Open Device Manager and double- click the problematic driver, then switch to the Driver tab. Click 'Roll Back Driver' to return to the previous version.

Driver signing

If you have Windows 2000 or XP installed, you may or may not have come across the concept of signed drivers, depending on whether you've installed any hardware after you bought the PC or not. With older versions of Windows, you could quite happily install any old driver you liked to communicate with your hardware. While most of these would work as intended, many drivers were so full of bugs they could crash Windows on a frighteningly regular basis.

With the advent of Windows 2000, Microsoft introduced digital signatures attached to device drivers. When Windows 2000 or XP install a new device, they check to see if the driver has been digitally signed. If it has, it means the driver has undergone extensive testing for compatibility with that version of Windows, and that it hasn't been altered since. If no signature is present, Windows will warn you - in quite stern terms - about the possible dire consequences of installing unsigned and thus untested driver code.

You can, of course, proceed and install the driver anyway, providing you give Windows permission. Many drivers from smaller companies won't have passed Microsoft's certification for various reasons, but most will perform as well as if they had. Whether you opt to install unsigned drivers or not is purely a personal choice.
This article first appeared in PC Answers Issue 130 - March 2004