In case you haven’t been paying attention to what’s been going on in preparation for the next version of Windows, back on 13 September Microsoft held the long-awaited “Build” developer conference. As promised the conference gave the general public its first glimpse of Windows 8, dubbed the “Windows Developer Preview.” For most folks who work in the world of Windows this was pretty big news.
What was even bigger news for those of us involved in writing Windows drivers was the introduction of the next version of the Windows Driver Kit (WDK). For the past many years, we’ve grown to expect a WDK that looks pretty much like the previous WDK. Maybe there are a few more driver models. Perhaps there are some more DDIs added to KMDF and UMDF. And we always expect the documentation to continue its slow progression from useable to useful.
However, if you were expecting “more of the same” for this release of the WDK you were in for a very, very, big – enormous – surprise. The new WDK is nothing like the old one. In fact, the new WDK incorporates the number one feature requested by the driver development community over the past ten years: The Windows 8 WDK has been changed to be fully integrated with Visual Studio.
No, I’m not kidding. Seriously. We’ve finally gotten full Visual Studio integration. And it’s not just simple “invoke a command procedure as an external build step” integration, either. What we got was actual, real, integration including choices for different driver starter projects, built-in PREfast, the ability to fire-up SDV to run (asynchronously, thank goodness) from within the VS IDE, and even integration with the kernel debugger. And, if that’s not enough, the Win8 WDK also includes support for automated deployment of your driver. If enabled, when you hit F5 your driver is rebuilt (if it’s out of date), copied to the test system you’ve previously indicated, installed on that test machine, and started. You can choose to automatically enable Driver Verifier if you want. You can even configure a set of tests to start automatically.
Perhaps that’s not enough to excite you. How about automatically signing your driver for you, if you choose? Yup, you can select from test signing or production signing. If you choose test signing you can optionally have a test certificate automatically generated for you, or you can choose an existing test cert. You can even choose a timestamp server to use during the signing process, without having to remember the URL (the paths to the Verisign and Globalsign time stamp servers are built in). And, yes… the WDK comes complete with all the necessary cross-certificates so you don’t have to go searching for them.
The Windows Driver Kit, which used to be called the Windows Driver Development Kit (DDK), has gone through only two significant changes in its almost 20 year history. The first versions of the DDK required developers to separately acquire and install the compiler and Platform SDK, and then install the driver kit. The DDK itself was assembled by hand. The few example drivers supplied rarely built without error, and when they did they rarely ran correctly. Installing the kit was a major PITA, a real trial in fact, as it required you to provide just exactly the correct versions of the VC++ and the PSDK and install them in precisely the correct order. This was true even when the “correct” versions of VC++ and the PSDK were no longer available from MSDN. So, woe unto the poor developer who didn’t save the proper CDs! In short, these early versions of the DDK seriously sucked, but we lived with them for many years. As driver developers, many of us felt like Microsoft didn’t much care about us or the tools they gave us to do our jobs.
The first major change to the DDK came with the introduction of Windows XP in 2001. Starting with this version of the DDK, the compiler, linker, headers, and libs were distributed as integral parts of the DDK. Many more sample drivers were provided, and these drivers all built without errors (though, not necessarily without warnings). While the samples were of varying quality, they mostly worked. It is hard to overstate how much having all the tools bundled into the DDK improved our lives as developers. Installing the DDK became simple; no longer an excruciatingly painful exercise in self-flagellation. It was an awesome step forward. Coincidentally or not, it was in this timeframe that many driver developers started to feel like Microsoft was listening to us, and trying to help meet our needs.
For the past several years, members of the driver development community have been asking for a more modern driver development environment. They didn’t want to build from the command line anymore. Because many devs work on both user-mode and kernel-mode code, they wanted to be able to use one tool, Visual Studio, for both their user-mode and kernel-mode development tasks.
And thus, ten years after the introduction of Windows XP, the second major change to the Windows Driver Kit has now come to light. Gone are our old friends the various build environment command prompt windows, build, sources, and dirs. In their place, we get Visual Studio with IntelliSense, class browsing, and all the features I mentioned earlier. You can see what the interface looks like in Figure 1.
While this is an epic, most excellent, and much appreciated change, all is not sweetness and light with the Win8 WDK. We’re not merely getting a new alternative for building drivers for Windows. The old tools are totally and completely gone. This means you will not find build.exe, makefile.new or setenv.cmd anywhere in the Win8 WDK kit. So, if you want to use the new WDK, you will migrate to the new environment whether you want to or not. Fortunately, the WDK provides a utility that’ll convert most (many? some?) projects from the old sources/dirs format to the new vcxproj format. We describe the conversion process in this issue (See Converting “Sources.” Based Projects to “.vcxproj”) . However, the point here is that Visual Studio integration isn’t optional. It’s the way things are, and the way things will be going forward.
There’s another detail that’s likely to cause many dev teams at least a little heartburn. This is the fact that, as shown in Figure 2, the new Win8 WDK does not support building drivers for Windows XP. Because most of us don’t have the option of not supporting XP, this means we’ll need to maintain parallel build environments with parallel project descriptions. Fortunately, once a project is developed, you typically don’t have to play with the project’s build description very much. But still, having to maintain two entirely separate project build environments, with two entirely different sets of project metadata, is just asking for trouble. Perhaps, if we ask nicely enough, we’ll be able to prevail upon the WDK team to support building drivers for Windows XP in the Win8 WDK.
And, of course, there are rough edges. Some of these are undoubtedly due to the early nature of this release. But some of them look like they’ll be with us into the eventual final release of the kit. I guess we can’t have everything we might wish for given to us all at once.
But, for a while at least, let’s not dwell on the negative. Let’s celebrate this epic change that so many of us have been requesting. Let’s praise the fact that they chose to do it right and not just toss in some command procedure that invokes the old build environment through a new front-end. And let’s recognize and admire the effort (and, to put it quite frankly, the balls) it’s taken to get the WDK from where it’s been for the last ten years to where it is today.
I, for one, am stoked about the changes. I hope you are too.
OSR Open Systems Resources, Inc.