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.
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.
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.