When you develop systems software for Windows NT/2000, much of how you do your job is defined by the DDK. We here at OSR have always wondered how the DDK got built, and who decides what sample drivers are in it.

To find out more about the DDK, The NT Insider put questions to Jean Valentine, the Microsoft program manager responsible for both the DDK and the IFS kit. Jean has been the one who has helped motivate and organize many of the positive changes that we’ve seen in the DDK over the past couple of years. But we’ll let her tell you all about the DDK in her own words:

The NT Insider:  Let's start from the beginning: What's your job at Microsoft?

Jean Valentine:  I'm the Program Manager responsible for kernel mode development kits - the DDKs, IFS Kit, and HAL Kits.

NT Insider:  So you're the one who actually decides what manuals and code examples comprise the Win2K DDK? 

JeanVal:  Well, not exactly.  I work closely with the development, test, program management, developer support, and developer documentation teams to define the content of the DDK. With the sheer number of technologies, new hardware features, and operating system initiatives, there is no way I could keep up with the breadth and depth on my own.  The Win2K DDK was a joint effort from many teams.

NT Insider:  OK, but who actually builds it? Who defines the general look and feel?

JeanVal:  The DDK Core team, which I lead, provides the infrastructure. Everything from the set-up program to the build environment to distribution channels to the http://www.microsoft.com/ddk/ web site. We are responsible for defining the direction of the DDK.

NT Insider:  How do you decide to include a particular driver example on the kit? How do you decide what source code that the driver group has that shouldn't be in the kit?

JeanVal:  The major concern is that the code is well written and can provide high quality, relevant information that would be useful to the majority of developers writing drivers of that type. We realize that driver developers will cut-and-paste the driver sample code into their drivers and use this code as "documentation" for their development efforts. This is the basis of any decision to put sample code into the DDK.

NT Insider:  What's your goal for the DDK?

JeanVal:  Wow. That's an essay, not a short question. For the Win2K DDK we had a number of key goals. First, we incorporated the DDK builds into the Win2K daily builds and began using "live" driver samples. Many of the driver samples in the Win2K DDK are the actual drivers shipping the Win2K CD. This was a very different model from previous DDKs, which have contained templates, skeleton drivers, code snippets, but rarely included full drivers. The complete drivers quickly become very complex, so moving to this model was a significant change. The work was an incremental process, and a learning experience.

The goal was to provide the means for developers to begin with a working driver, and then be able to add their modifications. We wanted driver developers to be able to get an existing piece of hardware, build the driver from the DDK, and have it function. This would allow a developer to modify a working driver to better understand the impact of his changes and provide the ability to test the code we ship to verify the quality of the sample drivers - an important concern, when we expect developers would copy it into their drivers.

We quickly realized that although we now had drivers that built clean (getting to 0 errors and 0 warnings for the full DDK build was an experience in itself), we had no way to get them installed. So, we began work on getting an .inf for each driver sample. Almost at once, we had a problem. The DDK documentation on .inf files was sketchy, and an .inf file could not easily be debugged. When loaded, it might fail, but even if it loads, how do you tell if it's correct? So, the senior Plug-n-Play DDK writer took on the documentation and a developer on the DDK Core team began work on what became ChkINF. We brought the problem to the Plug-n-Play Development team, and they began work from the OS end. And this is only one of the issues we worked through.

NT Insider:  Cool! In other words, by actually trying the DDK components more or less from “our” perspective (that is, the perspective of non-Microsoft users) you actually found and filled many of the potholes before the final release of the DDK.

And what’s been happening with the DDK for Whistler? Have you-all continued to try to use the DDK internally?

JeanVal:  For Whistler, the foundation had been laid, and we began to build on it. Whistler driver development work has been "dogfooding" the DDK since February. The drivers that will ship on the Whistler operating system CD are being developed out of the DDK. There is now a Developer's edition for the Whistler Beta program. By the time Whistler releases, the DDK will have been in use for over a year.

NT Insider:  Suppose people need code examples that aren't presently in the DDK. Is there any way for them to request additional code samples?

JeanVal:  Often, this type of request comes through the DDK Developer Support team. When they get a number of calls from developers needing similar information, we begin looking at the issue. Do we need to provide documentation? Sample code? A tool to validate or test?

Currently, the feedback mechanism we get the most requests from is the Whistler Beta bug reporting tools and the Whistler Beta DDK newsgroups.

NT Insider:  You mentioned the DDK Developer Support team. How does your job relate to what those folks do? Are you in the same group? Do you work closely together?

JeanVal:  The Microsoft product teams and the support teams are separate divisions, but we have a close working relationship. The product team's current focus is Whistler, and future development. The PSS Developer Support Teams for the DDK focus on released operating systems. But, this crosses over in many places. In fact, the instructional driver samples shipped in the Win2K DDK were created by the Developer Support team engineers. These engineers also do supportability reviews on the DDK. They look for everything from driver sample bugs to missing documentation — anything where their experience leads them to believe that driver developers could have a problem.

NT Insider:  Many of the students in our Driver Seminars say that they find the DDK difficult to use as a tutorial or initial learning tool. We frequently say that the Kernel Mode Driver Design Guide, for example, is excellent...once you know how to write Win2K Drivers. What do you hear?

JeanVal:  Drivers are hard. Period. This is not an endeavor for a novice developer. Anyone writing a Win2K driver is expected to be able to write concurrent, re-entrant code, understand the Win2K architecture, and be able to do kernel debugging. And that's before we get to the hard stuff.

But, that said, I agree. The DDK is geared to an intermediate level user.  We’re working on a new “Guide to the DDK and Driver Development” overview type documentation, to help developers find information, but the initial content won’t appear in the DDK for a while yet.

NT Insider:  I also know that you've reintroduced printed versions of the DDK Documentation. Lots of folks I know (including us here at OSR) have been asking for these for a long time. What's the story behind finally getting hardcopies of these documents available?

JeanVal:  Well, that's an interesting one. I had been looking for a way to get the documentation printed, and having trouble finding the right people at Microsoft Press to pick up the project. Since there is such a small audience for this information, compared to, say, the Office developers book, I was not having much success. The expected sales for the book, combined with the size, made it cost prohibitive. Believe it or not, I was at WinHEC last year, and met someone from Press at the conference. I spoke to him about printing the DDK documentation, and asked him to spend part of his time talking to conference attendees about it. It convinced him. With key Windows backing, like Lou Perazzoli, we were able to push this through as a strategic investment for MS.

NT Insider:  Do you have any opinion as to whether driver development is getting easier or harder on NT? In other words, do you think the changes introduced with Win2K and WDM make driver writing more difficult or more straight-forward for folks?

JeanVal:  Overall, I think it is getting more complex. Adding Power Management, Plug-n-Play, and WMI is putting more requirements into the driver. Although WDM provides the basis for writing cross platform drivers, the minor behavior variations between platforms and versions brings its own set of complexities.

The class drivers or the port/mini-port models handle quite a bit this functionality, so I don't think that every driver is getting more complex.

NT Insider:  Any big changes coming up in Whistler/Blackcomb that will impact us driver writers?

JeanVal:  64-bit. Consumer OS built from Windows NT code base. Driver Verifier expansion. Ask me again in six months, after the new technologies are no longer under NDA, and I'll tell you more.

[The NT Insider is grateful to Jean Valentine for taking the time for this interview. Look for more interesting interviews in future issues of The NT Insider with other influential people in the driver development community.]