DDKBUILD.CMD 7.1 released

One issue was reported by Vladimir Zinin in the article about DDKBUILD on OSR Online already back in October 2007. However, since I hadn’t actually built any x64 code with the newer 6001.* WDK, and since Vladimir had mentioned that he used the WNETAMD64 configuration I had basically discarded his comment as a mixup of the wrong WDK/DDK with the respective configuration. Sorry about that, Vladimir. Your comment was right, although the configuration you used was obviously WLHNETX64.

Anyway, the fix proved not to be as easy as anticipated. The problem is, that the WDK team at Microsoft changed the setenv.bat in a way that breaks compatibility between the Vista WDK (6000) and the Windows 2008 Server WDK (6001.18000). Instead of adding the flag x64 for x64 builds, the flag AMD64 was replaced by x64. This makes it a bit tricky. I solved it by introducing a detection of the string “Windows Server Longhorn” inside setenv.bat. Since this file has to be in the ./bin folder inside the base directory of the used WDK, this should be pretty safe. Also, since it has been released now as “Windows 2008 Server” it is unlikely to change back to “Windows Server Longhorn” (at least I hope this!). This brings me to a little rant. The WDK team could easily ignore the base directory parameter and detect it from the location of setenv.bat … but well 😉 … (rant over)

So that’s it about the fix. However, there was actually the improvement of an existing feature, although the implementation is surely borderline to an actual new feature.

The improvement was in the auto-detection feature of DDKBUILD. I had implemented this earlier because many people “forget” to set up the build environment properly when using DDKBUILD. I mean, let’s face it: even if you use it on a daily basis, you sometimes forget your proper setup on a new system. The required setup is largely the setting of the environment variables for the base directories of the DDKs and WDKs: NT4BASE, W2KBASE, WXPBASE, WNETBASE, WLHBASE. I prefer having the script warn me that I haven’t set any of those variables but still do its job if possible, over having it bail out with a nasty error message.

Now how does the auto-detection feature work? Starting with this version of DDKBUILD.CMD the script will check in the registry whether it can find any needed DDK or WDK in reverse order. “Needed” means that if you say that you want a WNET* configuration the script will check for the known WNET DDKs and so on. “Reverse order” means that in auto-detection mode it will always try to find the newest DDK or WDK first! So if you have the 6000 and 6001.18000 WDKs installed on your system in parallel and you don’t set the WLHBASE environment variable explicitly, the auto-detection will pick the 6001.18000 WDK first and fall through for any earlier versions. Auto-detection honors the WOW64 registry node.

If there was no match in the registry, the script will try to brute-force detect the path by looking in any of four directories. The combination is as follows:

• %SystemDrive%\WINDDK\<build>
• %SystemDrive%\DDK\<build>
• %ProgramFiles%\WINDDK\<build>
• %ProgramFiles%\DDK\<build>

… in this order and for every build number of the respective DDK/WDK.

The detection from the registry keys of the installers is the actual improvement. Before it was only using brute-force detection.

Download the latest version here.

// Oliver