As more and more new DDI’s get added to the DDK, the urge to use them may become too great for even the strongest of us to ignore. In fact, the urge may become so great that one might want to abandon their pursuit of that Holy Grail known as binary compatibility and add some conditional compilation to their code based on the OS that they’re targeting. I mean, how long can you really hold out against using KeAcquireInterruptSpinLock? I know I’ve caved in…

DDK_TARGET_OS

If you’re being a good driver writer, and you haven’t been condemned to a life of supporting NT4, you’ve only been using the latest DDK’s to develop all of your drivers from Windows 2000 through Windows Server 2003. You’re so good that you even read the release notes of each DDK and you’re already aware of the DDK_TARGET_OS environment variable that is set to an appropriate value by the DDK build environment. In your copious free time I’m sure you’ve even already added something like this to your SOURCES files, just in case you ever needed it.

!if "$(DDK_TARGET_OS)" == "Win2K"

C_DEFINES = -DWIN2K=1 $(C_DEFINES)

!elif "$(DDK_TARGET_OS)" == "WinXP"

C_DEFINES = -DWINXP=1 $(C_DEFINES)

!elif "$(DDK_TARGET_OS)" == "WinNET"

C_DEFINES = -DWIN2003=1 $(C_DEFINES)

!endif

A work of art really. You might want to cut that out and put it on your office wall in case you ever need a source of inspiration. But I digress…The only thing to note in this code is that when the DDK_TARGET_OS variable was added to the DDK, Windows Server 2003 was still called .NET and so it’s defined as “WinNET” in the Windows 2003 build environment.

One nice thing about this approach is that it allows you to “conditionally build” your driver. For instance, to use the new security functions (WDMSEC.H) you’ll need to link your driver with WDMSEC.LIB when building under the Windows 2000 build environment. Using this method, you can easily accomplish this:

!if "$(DDK_TARGET_OS)" == "Win2K"

C_DEFINES = -DWIN2K=1 $(C_DEFINES)

TARGETLIBS=$(DDK_LIB_PATH)\wdmsec.lib

!endif

But we shouldn’t forget about the unfortunate souls still working with NT4, those that don’t need to do any “conditional building” and, of course, those that are still waiting for their P.O. to be approved for the free $15.00 XP DDK.

VER_PRODUCTBUILD 

Every DDK since the NT4 DDK has included a header file NTVERP.H that defines, amongst various other things, a constant named VER_PRODUCTBUILD. This aptly named constant is the build number of the OS that the DDK is designed for. As you’d imagine, the newer incarnations of the DDK have multiple versions of this header file for each OS that they support. All you need to do is include this header and, depending on which build environment you fire up, VER_PRODUCTBUILD will be set to the build number of the target OS.

Assuming that you know how to conditionally compile on a numeric constant (I know, it’s never safe to assume but in this case I really have to or I won’t be able to sleep at night) here’s a handy table of build numbers

NT 4.0                                      1381

Windows 2000                          2195

Windows XP                            2600

Windows Server 2003              3790

Now run along and compile until your heart’s content!