Hereby I announce the release of DDKBUILD.CMD 7.2. This release fixes one issue with errors not being properly extracted from the respective file. Consequently Visual Studio would not show the errors and you wouldn’t be able to double-click the item in the task list in order to jump to the code in question.
Apart from that, this release introduces one new configuration and aliases for existing ones, which make this version more compatible with the DDKBUILD script from Hollistech. The support goes even as far as understanding the XPBASE environment variable for the respective DDKs, which differs - or rather differed - in name from both OSR flavors before.
Continue reading ‘DDKBUILD.CMD 7.2 released (updated)’
… the guys from OSR have put up the fixed DDKBUILD versions now.
Consequently I have mirrored the DDKBUILD.BAT version 6.12 on the DDKWizard website.
// Oliver
Although the manual is still perfectly valid for version 1.2.0a of DDKWizard and covers also older versions, I took the time to completely revise it. This means that it contains some updated information, some additional information and some corrections.
If you are using DDKWizard or DDKBUILD.CMD you may want to have another look into it. As usual, the latest version can be found here.
// Oliver
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)
Continue reading ‘DDKBUILD.CMD 7.1 released’
I am pleased to announce the release of DDKBUILD.CMD 7.0 final. User input has helped a lot to define the feature set and refine the features once introduced. It has been almost two years since the first public beta, so you can expect a mature version and you get it.
Thanks for all the feedback and support. Thanks to OSR for hosting DDKBUILD, thanks to Mark Roddy who wrote the very first version of DDKBUILD.
Download here.
// Oliver
I just fixed a cosmetic glitch in DDKWizard. If you downloaded 1.2.0, there’s no need to download it again. No program logic has changed!
// Oliver
I am pleased to announce that version 1.2.0 of DDKWizard has just been released. You can download it as usual from here:
- Direct download
- Project website
So, what’s new in this version? Not much and more than ever, would be an appropriate answer. This version technically doesn’t have many new features, in fact the most prominent is the only one worth mentioning: support for Visual Studio 2008.
However, there is one huge change. As you may recall, the previous versions of DDKWizard, except for the project templates, have been released under the GPL version 2. From now on, the new version is being released under the zlib/libpng license, which is a lot more liberal. The GPL states, that I have to keep the sources available for five years after publishing. If someone really needs the old stuff, I can still offer it - however, it is perfectly okay for any GPL-project to incorporate a zlib/libpng-licensed product, this just doesn’t work the other way around. So I suggest that anyone, including those who want to use it under GPL, use the newer version.
// Oliver
PS: This should also put an end to worries that the GPL’d version of DDKWizard could pose a legal threat to companies using the wizard! Spread the word …!
Today, searching for references to DDKWizard, I found that several people have posted misleading information in response to others recommending DDKWizard. For the most part they are recommending to use the DDK/WDK build environment. Bravo. That’s just what DDKWizard does, except that DDKWizard makes it a breeze to create and configure such projects. The magic behind DDKWizard is not the Visual Studio compiler and linker, but one of the OSR DDKBUILD scripts. This makes projects created with DDKWizard as portable as any other DDK/WDK project but leaves the developer with the option to work on the project conveniently from within the Visual Studio IDE.
So no worries, using DDKWizard will not use the Visual Studio compiler and linker (something that Microsoft advises against, when developing drivers), but will instead use the DDK/WDK build environment.
Feedback and project template contributions are generally appreciated.
// Oliver
OSR just updated their DDKBUILD.BAT to version 6.11! If you use this version, I recommend to update.
As usual either at OSR Online or at the DDKWizard homepage.
// Oliver
Hey. For those among you, who have actually updated to RC2, here is a little fix, if you like manual patchwork. If you prefer the easy way, just download RC3 here. Apologies!
This fix is yet another issue that can be traced to the NT script interpreter. The problem is the wrong handling of string substitution with empty strings. In case of an empty string, the substitution string is wrongly considered to be the actual content to set. Of course with unpleasant consequences.
Anyway, if you like the manual fix, search for:
set PATH_EXTSHORT=%PATH_EXTSHORT:~0,4%
and replace it with
if not "" == "%PATH_EXTSHORT%" set PATH_EXTSHORT=%PATH_EXTSHORT:~0,4%
// Oliver
… had to update the DDKWizard 1.1.2 setup. It won’t matter for those who downloaded it before. The only difference is, that the version shown in the dialog that allows you to choose the options was changed to 1.1.2 now. Argh, missed that one …
// Oliver
It has been almost half a year since DDKWizard got updated last time. But now it’s time for an update. Some accumulated reports of glitches and issues - especially those that bugged me most in daily use - got me to update the wizard finally. It has been almost a year since the very first version of DDKWizard was released to the public and it seems that at least a part of the driver community actually adopts it as a convenient way to create driver (and other) projects inside Visual Studio.
Despite many small changes and fixes, this release changes one file name, the notorious CustomVars.vsprops to <ProjectName>.vsprops. Furthermore the manual has been updated and DLL and CUI projects can now also contain a message file (.mc), which was offered before, but didn’t work properly until this version.
I hope you enjoy this update. Let me know - here in the blog or via email.
- Direct download
- Project website
// Oliver
PS: Don’t forget to subscribe to the RSS feed, if you are interested in future update notifications. This feed is dedicated to DDKBUILD and DDKWizard.
This release fixes minor issues found to cause DDKBUILD.CMD to fail under certain conditions, especially when either the DDK/WDK or the project was located in a folder that contained spaces or that had long (folder/file) names without spaces.
One common example would be:
C:\Program Files\WINDDK
While most of this can be attributed to the setenv.bat script (part of the DDK/WDK), which is flawed, there should have been an easy workaround. It turned out the easiest way could be to use short (i.e. 8.3) file names. However, the NT script interpreter is flawed. Exactly the part which is supposed to convert long to short file/folder names fails with the extension. Example: when calling a sub or a script, the parameters get passed as %1 through %x (x being the number of the last parameter). If you use for /?, you can easily see that %~fs1 is supposed to remove the surrounding double quotes from the first parameter, expand it to a full path (including drive letter, folder path, file name and file extension) and return it as a short file name. However, it appears that exactly this part is flawed (looks like the return buffer is not properly zero-terminated), because the extension (if a long folder name part contained a dot) does not get cut off after four characters (including the dot). That means a long path such as 3790.1830 (well known from the Windows 2003 Server DDK) gets translated to 3790~1.1831830 instead of the expected 3790~1.183.
Continue reading ‘DDKBUILD release candidate 2 (update #1)’
Just found it out, although it’s not hard to find if you know where to look. If you put a line such as the following into your SOURCES file, you will be able to make use of the delay-load-feature that is provided by the Microsoft compilers (which includes the one in the DDK :wink:):
DELAYLOAD=advapi32.dll;user32.dll;shell32.dll
This means it is a list of DLLs separated by semi-colons. Very useful to make applications quit gracefully on systems for which they weren’t designed (e.g. NT-apps on 9x/ME).
// Oliver
She and a partner, Alexander Tereshkin, have published the source to BluePill, or rather a rewrite called New BluePill (NBP), since Rutkowska’s previous employer owns the rights to the original one:
http://www.bluepillproject.org
The source is a little flawed, at least the version I got. It requires three minor corrections, but I am not sure whether this is an intentional hurdle for script-kiddies or a difference between the in-lab source and the one being published. Anyway, it’s not hard at all to figure it out. The source won’t compile with the WNET DDK, though - and presumably won’t compile with even older DDKs either. This means you have to get the Vista WDK or the beta of the 2008 Server WDK. The problem for the WNET DDK seem to be the assembly parts in the source, so this may be possible to be fixed, however, I didn’t try. The executable is around 50 kiB big. Obviously compiles only for AMD64
Continue reading ‘Joanna Rutkowska gets serious ;)’
After a bug report which turned out to be a false alarm, I have only clarified some stuff in the help output and in the comments of the code. Furthermore one line of code saw some change, which doesn’t have any influence on the logics whatsoever. So it’s fully up to you to update to this version or not.
Find the downloads as usual on the DDKWizard homepage.
BTW: Don’t miss the RSS feed on the DDKWizard website. It is exclusively for DDKWizard and DDKBUILD (so no noise of my regular blog ;)).
// Oliver
Today I set up an RSS feed for DDKWizard and DDKBUILD under this URL. If you are interested in either of these tools, please feel free to subscribe and get automatic notifications about updates within your favorite feed reader.
// Oliver
The fixes in DDKWizard are minor except for one. This one requires manual fixing in old existing projects that have been created using DDKWizard. The problem is described in section 5.1 “Important change in version 1.1.1b”.
As for DDKBUILD there was a bug that prevented users from calling it from inside a long path containing spaces. This has been fixed.
Please fetch your copy here.
// Oliver
Sorry fellows, please bear with me. The last version of the DDKBUILD.CMD script misbehaves if you set a variable inside the pre/post-build scripts and expect that variable to propagate beyond the script’s execution. Thanks to my colleague Kristmundur here at FRISK the bug has been found and is now fixed in the beta 6a!
Please fetch a fresh copy here.
Note: This update is only critical to those who use the pre/post-build scripts and set variables using them.
// Oliver
Thanks to feedback from some users, several bugs could be fixed. The two worst were:
- Build scripts failed with relative pathes
- Return code of the script was wrong
Also I took the chance to implement some minor changes in how some variables are treated. The following list contains some of the changes I consider noteworthy:
Continue reading ‘DDKBUILD.CMD updated (v7.0 Beta 6)’