Saturday, March 31, 2007

DDK build environment

Maybe I'm just spoiled by years of writing user-mode code in Visual Studio, but I'm less than impressed with the DDK build environment. This is it:

It's not very friendly about reporting errors, although it does at least have color-coding support- errors are red, warnings yellow, etc. But in general, the whole thing is just a huge wad of chewing gum and duct tape around nmake and shell scripts. Welcome to 1993! Spaces in your directory names? Ha! You'd better have your DDK installed on the root of your disk, or nothing's gonna work. Same goes for your project path. Want to reference non-DDK headers from C:\Program Files\Microsoft SDKs? Too bad- no matter how you escape it, quote it, or anything else, the spaces just get collapsed. Short of sym-linking the crap out of my drive, using 8.3 filenames (not necessarily stable across machines) or making copies of the entire SDK include tree, it's just not going to fly. This probably wasn't much of an issue before UMDF- kernel drivers have little business referencing user-mode headers outside the DDK. I'm comfortable enough in a command-line environment, but it seems like PowerShell + MSBuild would be a killer combo for this kind of thing, with the side-effect of being much more pluggable into VS for those of us who have left life in vi and the command-line behind us.

DDKBUILD is a nice compromise- it "feels" like a better integrated experience with Visual Studio (it'll do browse info, errors in the VS errors window, etc)... It's far from perfect though- limited support for UMDF, and all the smarts still live in the makefile. Wanna add a few new files in VS? They're just going in the bit bucket until you hack 'em into the makefile. Compile or link flag changes? Makefile. Want to see the text of warnings that are causing your build to fail? Gotta dig them out of a build logfile by hand- only errors are reported in VS (even though the default DDK build behavior is to fail on errors).

I'd probably be a lot less frustrated with this if the Optimus Sideshow driver project were going better. As it is, I'm having trouble getting a .NET UMDF driver up and running- strange stack corruption right after loading the framework. I'm hoping it's something dumb, or something related to the Martian build environment, but I just don't know yet...

No comments: