I'm talking about drivers, those pieces of software that sit between Windows and your hardware. Bad drivers--and it's easier to write a bad driver than a good one--can play havoc with your computer system in all sorts of unexpected ways.
Take, for example, the driver than connects your network card to the Windows OS. It may work just fine on its own. But another piece of software, far removed from the network interface, could still somehow mess up that network driver and bring your computer to a halt.
When that happens it's only natural to blame the operating system. "Damn Microsoft," we say, perhaps waving a fist at the computer.
Microsoft estimates that 15 percent of all "blue screen of death" (BSOD) Windows crashes are caused by faulty drivers. Yes, that leaves another 85 percent caused by other things. But Microsoft sees drivers as low-hanging fruit in its push to make Windows XP even less crash-prone than it already is.
At a Microsoft technology road show last week, I saw one of the ways the company hopes to make safer drivers. It's an automated test system designed to run the drivers through a much wider range of potential problems than human testers--still an important part of the process--could ever handle alone.
While not yet available, that testing software will eventually find its way, in one form or another, into Microsoft developer tools, allowing programmers to test their driver code as it's being written.
This is part of an overall Microsoft approach, to make its Visual Studio .Net better at finding and solving problems in the development process, before they find their way into finished projects and onto users' systems.
Microst already has a driver certification program in place. But too few hardware vendors take part in it. You'll notice this for yourself when you install a new piece of hardware on your XP machine and the OS warns you that the driver hasn't been tested.
Now, like everyone else, I always click "OK" and load the driver anyway. But I'd be much happier if the software had been through a Microsoft test process, and I didn't have to worry.
Of course, I never worry about drivers on my other computer, the Mac. And that computer hardly ever crashes. While it's true the Unix underpinnings of OS X are part of the reason for this, it's also true that even pre-OS X Macs were less crashy than their Windows cousins.
Why? Partly because of one of the chief differences between Apple and Microsoft: Apple is a monopoly. Sure, I know a court says Microsoft is one, too. But in this case, I'm talking about Apple having control over the operating system, many of the applications, all the hardware, and some of the peripherals, of which there aren't so many in the first place. This gives Apple such tight control of its platform that, in some ways, it's hard to believe it could ever crash at all (and it hardly ever does).
For Microsoft, creating a bomb-proof OS is much more difficult, simply because Microsoft doesn't control as much of the platform as Apple does.
Microsoft is hampered by its need to maintain backward compatibility with older applications and hardware. Even for new apps and add-ons, Microsoft can only send out descriptions and sample code of how everything should, in theory, work. But at the end of the day, Microsoft can't force third-party developers to write compatible code. Sure, it'd be in the best interest of those developers to do so. But the quality of their work still sometimes leaves a lot to be desired.
I know that none of this will make you feel any better when you're staring at a BSOD and some lost, unsaved work. XP may not crash as often or as severely as previous operating systems (remember Windows ME?), but it still occasionally falls over dead.
But when you shake your fist and curse the machine, try to remember it isn't all Microsoft's fault. The company is doing what it can to help hardware vendors write better drivers. Perversely, if it's successful, MS will have no one to blame for the occasional crash but itself.