Windows Driver Build Methods and Tools

March 15, 2003
Mark Roddy

Copyright © 2003 by Mark Roddy. All rights reserved

In this article, I'll examine several available methods and tools for developing device drivers for the Windows family of operating systems. My goal is to provide information about what is available, where to obtain the tools, and what the advantages/disadvantages are for the various methodologies. I'm not going to look at third-party kernel-mode driver libraries.

The standard toolset for Windows NT device driver development is the Microsoft supplied Driver Development Kit, or DDK. The current DDK is a complete stand-alone development kit; no tools other than a text editor and a workstation running a suitable version of the Windows NT OS are required.

Starting with the XP release of the DDK, Microsoft packaged a complete set of compilation tools and header files required for driver development into the DDK. Prior DDKs required Visual Studio and (at least portions of,) the Platform SDK. It was never quite clear exactly which version of Visual Studio and which release of the Platform SDK were supposed to be used with which release of the DDK, and building products for multiple versions of NT on the same system was a bit of an uncontrolled headache. Packaging the compilation tools and complete header files with the DDK has resolved this particular configuration management nightmare. Much to Microsoft's credit, the new DDKs remain free of charge (other than shipping and handling,) despite the addition of the compilation tools.

The development environment provided with the DDK is quite frankly antiquated. It is a command line oriented set of tools, driven by a program called build,  that front-ends Microsoft's version of the venerable MAKE batch compilation utility, nmake. Most of us stopped developing software this way 10 or 15 years ago, shifting to various IDE style applications that provide a variety of software development tools above and beyond batch file compilation. So an obvious question is how can a developer or a development organization integrate modern software engineering tools with the 1980's style DDK build environment?

One obvious solution to the toolset problem is to use Microsoft's Visual Studio application to build Windows device drivers. There are other IDEs available, such as Codewright and even the venerable Emacs. As most developers already own Visual Studio, my focus here will be on using Visual Studio as a development tool. Some of the techniques mentioned here can be used with other IDEs and code editors, some are Visual Studio specific.

Which Visual Studio are we talking about? Microsoft recently released an entirely reworked version of Visual Studio, Visual Studio .Net. I'll focus in this article on the prior release, Visual Studio version 6. I could write another article entirely about why I am rather annoyed with Visual Studio .Net. I will refrain from doing so. Some of the techniques mentioned here are compatible with, or can be converted to be compatible with, Visual Studio .Net.

Issues and Considerations.

In evaluating a development tool there are some basic issues that should be considered. First, the final goal is the production of Windows NT kernel components, and those components should be produced without production generated defects. (I am attempting to distinguish defects caused by the compilation toolset here from the more ordinary defects caused by programmer error.) Optimally there should be no additional cost involved. Development tools should also minimize conversion costs, both to the tool and from the tool. Specifically, the toolset should not be so invasive to the development process that abandoning its use would be prohibitively expensive. This consideration rules out third party development kits. These kits have their place, but that place is outside of what this article is considering.

One of the major advantages to using Visual Studio as a development environment is its support for automated code browsing. The Microsoft code browser tool (BSCMAKE) generates 'bsc' files that allow Visual Studio to locate definitions and references of all variables and functions in a source code project, and generate useful information such as 'calls' and 'called-by' trees for functions. Also, for those of us who use C++ for kernel development, Visual Studio provides basic class hierarchy browsing independent of the use of the code browser tool.

Another major advantage to using Visual Studio is automated source code control. Visual Studio can be configured to support most commercial source code and configuration management tools, and, once configured, Visual Studio will automate the checkout/checkin process. It may also offer integration with other configuration management features such as version tree browsing and version differencing.

The Options.

1) Microsoft DDK + Code Editor of Your Choice.

The DDK toolset, as mentioned above, is the standard toolset for building drivers, and the only Microsoft-supported method. Its free (currently available on CD only, shipping and handling charges apply.) It includes, starting with the Windows XP DDK, all of the compilation tools required to build a driver. It does not however include all of the compilation tools provided with Microsoft's Visual Studio product. Notably missing from the DDK is the source code browser compiler, bscmake.exe.

The major drawback to the DDK toolset is that it is a command line oriented toolset, leaving one with a 1980's style programming environment. On the other hand, as the core executable, build.exe, is a front end to Microsoft's nmake batch compilation utility, the DDK toolset is suitable for large-scale (both in number of separate build targets and number of concurrent users,) software development projects. Microsoft's internal operating system development work uses essentially the same set of tools as provided with the DDK. The same cannot be said of IDE-style programming environments such as Visual Studio, which typically cannot scale well.

Using the DDK toolset involves invoking a 'checked' or 'free' shell window from the Windows Start menu. This shell window is invoked through a shell script tailored to the specific DDK toolset, that sets up various environment variables used by other DDK toolset utilities. All work is done from within the environment established by the shell windows. Note that the implication of this method requires that additional work has to be done by development teams that need batch build facilities, such as overnight build disciplines, as the DDK tools expect an interactive environment.

2) WdmWiz + Visual Studio

Walter Oney's Programming the Microsoft Windows Driver Model, now in its second edition, includes a custom application wizard named WdmWiz for building driver projects. A Visual Studio Wizard is a plugin component for produces a template for a specific type of Visual Studio software development project.. Typically, such a project includes code templates that generate a basic programming framework. The Wizard also sets up all project build settings to correctly build the source code into an executable object.

WdmWiz is a typical Visual Studio Wizard. On invocation the user steps through a series of 'Wizard Property Page' style dialog boxes, selecting various options. WdmWiz has eight such dialogs, allowing the user to select a variety of options that customize the exact type of code skeleton that will be generated. Included in the output, in addition to source code for the driver, are inf files and the sources and makefile files required to build the driver using the DDK tools.

WdmWiz supports the use of the Mr. Oney's Generic.Sys kernel library, but does not mandate it. Thus the wizard is suitable for building standard kernel mode drivers. This distinguishes it from the other two Driver Wizards that are available, from Compuware/Numega and Jungo, both of which require the use of their proprietary kernel driver libraries. It also makes it the only Driver Wizard under consideration in this article.

WdmWiz is currently XP-driver centric. That is, the default project settings are suitable for building XP-targeted rather than W2K or .Net targeted device drivers. This can be adjusted using the fixproj utility that is supplied with the software CD or as a service pack download. Fixproj currently supports four build settings:

1. W2k DDK with VC6 sp4

2. XP DDK with W2K target

3. XP DDK with XP target

4. .Net DDK with XP target

Note that only the first option has a Visual Studio version requirement, as the other three options will, while using the Visual Studio IDE, select the compilation toolset from the DDK rather than using the tools supplied with Visual Studio. This is an important point, as one of the major advantages of using the DDK (or ddkbuild, discussed below,) is that the DDK supplies the supported OS build tools. While WdmWiz is not a Microsoft supported driver development environment, a development organization can be reasonably confident that the output is fully compatible with the target OS platform.

WdmWiz requires a bit of manual setup for environment variables that locate things like the DDK. This setup is performed as part of the setup application for the book's sample drivers. If you modify the location of the DDK (or Visual Studio, or SoftIce if you use it,) you may have to manually fix up these settings.

Visual Studio must be launched using the obscure "/useenv" option to Visual Studio, and with the proper environment variables set. The setup program for the book software attempts to automate this as much as possible, adding an explorer hook for dsp projects that launches Visual Studio with the correct command line settings.

Note also that WdmWiz is not free. You have to buy Mr. Oney's book in order to use it. However the book cost is fairly minimal ($42.00 on amazon as this article was being written,) and the book is definitely worth having on your bookshelf or in your development team library.

Finally note that while WdmWiz generates the DDK-required Sources and Makefile files, that these files are not managed after initial project creation. This means that if you add a file to the Visual Studio project, you also have to manually edit the Sources file to reflect the change, if you intend to use the Sources file to build the driver.

3) SrcToDsp + Visual Studio

SrcToDsp takes an existing Sources file for a standard DDK driver project and generates a visual studio project file for the same driver project. This allows the same project to be built using either Visual Studio or the DDK. However, like WdmWiz and to a certain extent Ddkbuild, discussed below, SrcToDsp to does keep the Visual Studio or DDK project synchronized, so if you change one project, you have to remember to manually change the other project as well.

I debated including SrcToDsp in this article, for reasons that will soon become apparent. However in newsgroups and email lists this utility gets mentioned as a useful development tool, so it does get included here. The freely available version of SrcToDsp only supports NT4 and Win98 platforms. That makes it less than useful, in fact I'll go out on a limb here and call it useless at this point in time. The Compuware/Numega website does document the existence of a second utility, DspToDsp, that takes the output from SrcToDsp and generates an XP DDK compatible driver project. Unfortunately this second utility is only available with their commercial DriverStudio toolkit - at a list price of $2499, and this is not considered further here. Due to this limitation, I can't conscientiously recommend SrcToDsp as a development tool.

4) Ddkbuild + Visual Studio

Ddkbuild is a shell script I wrote to integrate Visual Studio External Makefile projects with the DDK compilation toolset. The basic idea behind ddkbuild is to use the DDK from within a Visual Studio project by exploiting the flexible options associate with an External Makefile project. The shell script essentially locates the appropriate ddk (based on command line options and environment variables,) runs the same shell script used to invoke the DDK command windows, but does so without creating the DDK shell windows. The current version of Ddkbuild supports all released NT DDKs from NT4 to the latest .Net DDK. It does not support any Windows98/Me DDKs. Ddkbuild also supports all versions of Visual Studio from VS5 through Visual Studio .Net.

(Note: As the author of Ddkbuild, I have an obvious bias towards using this method for integrating Visual Studio and the DDK. I do not however have any direct financial interest, as ddkbuild is freeware. Presumably I do get some goodwill benefit from supplying this tool, however as far as I can tell, that benefit does not pay the mortgage, feed the kids, the dogs, the cats, or even the wife.That said, rather than recuse myself,  I will attempt to provide an objective evaluation of this tool.)

Like WdmWiz and SrcToDsp, Ddkbuild does not automate an synchronization between Visual Studio projects and DDK Sources files. Unlike the other two options, Ddkbuild always uses the Sources file to build the driver. As an External Makefile project, the DDK build utility is the program that is invoked (rather than nmake,) to build the project. Also unlike WdmWiz and SrcToDsp, the developer must setup the project source components manually. The output from a Ddkbuild project, as it uses the DDK toolset, is supported by Microsoft. Also, the output from such a project should in fact be identical to the output from building the same project using the DDK shell window.

The obvious drawbacks to ddkbuild are that project management is always manual, and that unlike WdmWiz, there is no nifty source code template that generates a skeleton driver for you. [Editor's Note: Unless you count the DDK samples as "nifty", that is.]

Resource Directory.

Note: URL links go stale on a regular basis, so I apologize if one of these is broken by the time you try to follow it.

Option	URL	DDK's Supported	Vis. Studio Versions	DDK Build Option	Source Code Control Integration	Code Browsing	Price
DDK + Editor	Microsoft	All	N/A	Yes	No (editor might support)	No (editor might support)	Free (plus cost of editor.)
WdmWiz	Walter Oney Software	W2k or XP/Net - as XP projects.	VS6	Yes	Yes	Yes	~$42.00
SrcToDsp	Compuware	NT4/W98	VS5/VS6	Yes	Yes	Yes	Free
Ddkbuild	Hollistech	NT4/W2K/XP/.NET	VS6/.NET	Yes	Yes	Yes	Free

Other Resources

• Code Editors:

Emacs - free, and as an ex-emacs addict, I have a lingering fondness for it: Emacs can be integrated with ddkbuild, and if you work at it, can be configured as a rather nifty development environment. Etags however is a bit antiquated as a source code browser. Gnu Emacs is a free (copyleft) GNU tool: NTEMACS.

Codewright - commercial code editor, IDE, etc. Currently a Borland product. Lots of NT developers swear by it. I tried it once and didn't much care for it, but editors are personal preference items. Lots of people despise Visual Studio as a code editor too. Codewright claims to be able to do just about anything Visual Studio can do, and I believe them, so I suspect it can be configured for use with any of the tools mentioned above. Codewright.

Textpad - someone recently introduced me to this shareware replacement for the irritating notepad and it soon became standard on my workstation. It isn't a bad code editor either, and can probably be integrated with ddkbuild, although I haven't tried it. It has plugin support for a ctags-style code browser, but it cannot use the Microsoft bscmake tool. TEXTPAD.

There are very likely about a dozen or so wonderful code editors I haven't mentioned.

• Toolkits

There are two general purpose driver toolkits being sold commercially. (There are other specialized toolkits that are available as well, these are not mentioned here.) Both of these toolkits come with extensive Driver Wizards that integrate their toolkits with Visual Studio.

DriverStudio - Compuware/Numega's toolkit is descended from the former Vireo product, and comes in a package that includes the SoftIce debugger. (SoftIce appears, finally, to be available as a standalone product as well.) DriverStudio

KernelDriver - Jungo's KernelDriver toolkit is the other commercial offering in this field. An evaluation version is available as a download from the website.  KernelDriver.

 

About the author:

Mark Roddy is an independent consultant specializing in Windows NT kernel software development. Mark has been working exclusively in the NT kernel since 1994, with a focus on storage subsystems and highly reliable computer platforms. In addition to software development, he has been training developers since 1996, and currently works with Azius to provide Windows NT device driver training.