The DDK is scheduled for retirement.

Yup, that’s what I said.  Looking forward to Longhorn, the DDK will be discontinued.

In its place will rise an entirely new, and much more powerful, entity.  This new kit is currently referred to as the Longhorn Development Kit (LDK).  Before we go any further, it’s important to realize that everything in this article is entirely speculative. While we’ve been diligent at ensuring what appears in this article is correct as of press time, work on the LDK is presently ongoing.  As a result, things can, and probably will, change drastically between now and any product release.  Now that the lawyers are happy, we can continue.

The LDK will be different from the DDK in the same way that a Porsche is different from a Volkswagen.  Sure, they’re similar beasts and their each capable of getting you to the market, but there’s no way that they’re even in the same class.

Key to the LDK vision is an integrated platform that combines what today are the DDK and the Hardware Compatibility Tests (HCT).  This integrated platform will make it easier to build drivers and test them for correctness in one step.  It will also seek to integrate feedback from real user crash scenarios via OCA.

In addition, the LDK is scheduled to include a host of tools aimed at helping developers identify code and design errors as early as possible in the development cycle.  The goal of these tools is to create a series of overlapping “zones of coverage.”  Because each type of tool is most efficient at catching (and diagnosing) a particular type of error, the way to get the most comprehensive test coverage (with the easiest to decipher error diagnosis) is to utilize a set of tools that combine to form a complete test spectrum.

You can see the “overlapping zones of coverage” concept starting to emerge in the tools provided with the Windows Server 2003 DDK.  For example:

• Errors such as potentially bad code paths or invalid conditional statements are most easily caught at compile time.  Prefast, a code scanning tool developed by Microsoft Research, can be used to catch these errors.  Prefast is publicly available for the first time in the Windows Server 2003 DDK.

• Errors such as doing both interlocked and non-interlocked insertions on the same list head, or acquiring the same spin lock with KeAcquireSpinLock and KeAcquireInStackQueuedSpinLock, are most easily caught by including special diagnostic code in the driver executable during testing.  Call Usage Verifier (CUV) is provided to catch and warn the developer about precisely these errors.

• Properly interpreting and validating user data buffer descriptions, especially on IOCTLs, is a common driver problem.  Errors in user data buffer interpretation are best found by a tool that can synthesize and send a broad spectrum of valid and invalid requests to a driver.  This helps exercise the driver’s logic.  A tool that does this is Device Path Exerciser (DC2).

• Accidental pool corruption, by writing past the end of an allocation or by writing to a pool block that has already been freed, is best detected by the operating system itself.  Driver Verifier’s “special pool” mode finds and diagnoses such errors.

I’m sure you could cite other examples. In addition, I’m sure you could imagine how additional tools might fit into this equation.

While the most recent versions of the DDK have all the tools described above, they are all separate.  They require a developer to discover each tool and make a conscious effort to use that tool to test their driver.  Part of the goal of the LDK is to make this a more integrated processes, so that utilizing driver test tools is no more difficult than the build process is today.

There’s a lot more exciting stuff scheduled for the LDK.  We can only hope to talk about part of it here.  As time goes by, even more information about features and capabilities will emerge.  As these details are released, The NT Insider will keep you updated.