Driver Developer's Toolbox, Part 1: The DDK
There are a lot of basic questions asked in the various driver development
forums that basically reduce to "how should I go about developing a driver?".
Every so often, I'll post a quick discussion of one of the tools I use every
day to do driver development. Try though they might, Microsoft doesn't exactly
hammer you over the head with information like this - a lot of this know-how
really just comes from doing the job.
At the risk of starting too basic, when you sit down to build a driver, the
first tool will need is the Windows Driver Development Kit (DDK). The DDK has
changed a lot over the years, but the last couple of releases have finally
started to settle down from a consistency standpoint. The current released DDK
is the Windows Server 2003 DDK, which represents build 3790 of the OS. It also
includes full development environments for Windows XP and Windows 2000. The
DDK is (almost) free from Microsoft - go to WHDC for more information on how to
get it.
Installation of the DDK takes forever. I'll never understand why these things
take sooooo long to uncompress and copy files, but perhaps I'm just a fundamentally
impatient person. Yep, that's it. :) At any rate, do yourself a favor and install
absolutely everything in the DDK. The whole mess - all of the build environments,
all of the tools, all of the samples, all of the docs. There are a couple of reasons
for this: first, you need to have the older build environments if you're planning on
releaseing drivers for the older platforms. The "wnet" build environment isn't always
backward-compatible with the "w2k" environment, so you need both. Unless, of course,
you are one of the lucky few that don't have to support older OSes. I'm jealous.
The other reason is that the sample code is by far the best documentation in the whole
kit. You might find yourself wondering about the semantics of a particular API in a
particular situation, and it really helps to be able to grep through all of the samples for
usage examples. I recently was in a situation where I needed to get a file handle back
from a file object, so I looked at all of the samples I could find for examples of
ObOpenObjectByPointer(). There were *none* in any of the files, prompting me to
redesign the driver to not need that API. I'm better off now, in that the overall architecture
wound up being much cleaner.
The DDK includes the latest authoritative documentation from Microsoft on how
to build drivers. It includes both "design guides" and reference material.
The design guides tend to read like technical documentation, so I'd still
recommend one of a few third-party driver development books. The reference
sections provide lots of detail about every public function provided for use by
driver writers. Most of this documentation (all?) is also available online at
OSR's website www.osronline.com, which
also has tons of other resources for driver writers. For those who didn't
know, OSR is the company that hosts the NTDEV and NTFSD mailing lists.
Wherever you get it from, I'd recommend becoming very familiar with the DDK
documentation.
Also included with the DDK is an entire build environment. All of the headers,
libraries, compiler tools, and support infrastructure needed to build your
driver are included. In particular, you don't need visual studio to compile
your drivers. In fact, using visual studio directly is not supported by
Microsoft for driver development. Mark Roddy (www.hollistech.com) has a script called
DDKBUILD that can be used to integrate the DDK with Visual Studio, but unless
you're really glued to its editor (and believe me, there are better ones), there's really no reason to use it.
Finally, don't miss the array of testing and troubleshooting tools present in
the DDK. There are so many of them, and some of them are so important to doing
the job correctly, that I'll post specifically about them another time.