One of the most common questions that we get here at OSR is, "what do I need to get started writing drivers?" This article addresses that question by providing a minimal level of guidance to get you headed in the right direction.

Where Do You Start?
In order to start developing drivers for Windows, there are a few things that we need to discuss in detail:

• The Windows Driver Development Kit (DDK)
• A code editor
• A development machine
• A target machine
• A debugger
• A source control system

The Driver Development Kit
The Windows DDK is required for building drivers. You can either order the DDK via http://www.microsoft.com/whdc/devtools/ddk/orderddkcd.mspx (just pay shipping), or you can get it as part of a Microsoft Developers Network (MSDN) subscription. MSDN has four applicable subscription levels available to assist driver writers: Universal, Enterprise, Professional, or the minimum Operating Systems subscription. Each of these subscriptions gives you the latest DDK and checked and free versions of the Windows operating systems. Which MSDN subscription you pick depends upon what extra features you require. You can buy an MSDN subscription from a variety of resellers, including OSR.

The current versions of the DDK (XP and later) contain the header (".H") files and all the tools you need to compile and link your driver. Thank your lucky stars that this has now all been integrated into one kit. By the way, you always want to be building with the latest DDK available, since Microsoft tends to improve the associated tools with each release.

The other thing that the DDK gives you is sample code. While once pretty sad, the DDK samples have been cleaned up immeasurably and are great starting places for your driver.

A Code Editor
Let’s face it – Notepad and WordPad don’t cut it when it comes to code development. Whether you use CodeWright, SlickEdit, Visual Studio, or Emacs, you need an editor that understands code formatting. If it offers other features like the ability to build from within the environment; then that is another plus.

Here at OSR, we use Emacs, CodeWright, and Visual Studio, so pick your favorite. For those of you using Visual Studio you may want to check out the article If you Build it – Visual Studio and Build Revisited. This article talks about how to use the batch file ddkbuild.bat to perform builds with Visual Studio and Visual Studio .NET.

A Development Machine
When selecting a development machine, you need to be aware of what you are going to be using it for. Remember, you are going to be running the compiler, editor, debugger, source control, DDK help, and web browser simultaneously – and let’s not forget the operating system! These all take memory and processing power and none of us likes to wait. Personally, I recommend at least 768 MB of memory on your development machine, and as for processing power, the more the merrier. I have dual 1.5GHz Xeons which I am more than happy with. Your mileage may vary…

Oh and don’t forget your debugging connection. For kernel debugging on Windows, you either need a serial connection or an IEEE 1394 connection (only supported on Windows XP and Later OSes) on both your development and target machine.

A Target Machine
Now some people may say, "I can’t afford another machine", and will argue that they can use SoftICE and do everything on one machine. We completely disagree! No matter how good a driver developer you are, sooner or later you are going to either trash your disk or corrupt the registry and the system will not boot. Do you realize how much time you’ll spend restoring your system? Think about the changes you could lose. If you are getting paid $30 dollars an hour (good God, I hope not) and you lose 40 hours of development time because you are restoring your system, that $1200 will go a long way towards buying a second machine. Have you checked the prices on new PCs lately?

The driver-writer version of Murphy’s Law states; "Your customer will be running your software on a computer with more CPU’s than you have." This means you better be running at least a dual-processor. You can’t test your software solely on a uni-processor system and expect it to work automatically on a multi-processor.

Here at OSR, we highly recommend that your primary target machine be a dual-processor AMD-64 based system. Why? This allows for 32-bit and 64-bit testing, as well as single and dual processor testing.

By the way, no one likes a slow test machine. If you haven’t already read Just Checking - Revisited, then I suggest that you do. It will save testing time and will provide a way to save some of that precious processing power.

A Debugger
When it comes to picking a debugger there are really only 2 choices: Microsoft’s WinDBG (or kd.exe) and Compuware’s SoftICE. Which one you choose is a decision that falls somewhere between a personal preference and religion. They both have their pros and cons.

WinDBG users for many years have lived with the serial port as the only way of connecting the host to the target. But take note! As of Windows XP, this restriction was lifted so that a WinXP host (i.e. the one running the debugger) could connect to a target running WinXP or later over IEEE 1394. I’m thinking that 400 MBps for a transfer rate over 1394 is much better than 115200 Kbps over serial.

OSR is a WinDBG shop. You can find the latest versions of the WinDBG debugger and other debugging needs at http://www.microsoft.com/whdc/DevTools/Debugging/default.mspx.

A Source Control System
Some people just don’t appreciate the value of a good source control system. Copying your project into different directories and running WinDiff to determine what has changed is really not acceptable. It doesn’t matter which one you use as long as you use one that allows you to label base levels and easily keep track of changes. Some source control systems that you may want to check out are Visual Source Safe, RCS, and CVS to name a few.

Common Sense and Plenty of Stimulants
Let’s face it – writing a Windows driver is not the easiest thing to do. If you make a mistake in kernel mode it is usually fatal or soon will be. Having the right tools in-hand is a great first step to simplifying the development process and preventing critical errors from popping up while your software is in the hands of those that feed you. Of course, coffee, soda or your stimulant of choice will help too.

Writing a driver takes patience and attention to detail. Remember, how your driver behaves impacts the entire system. If your driver is awful, the entire system is awful.