What it isEdit
The Windows DDK comes on CD with a number of different options. Specifically, the DDK is capable of writing device drivers for a number of different platforms (Win9x, WinNT, WinServer), and is capable of targeting several different processors (IA-32, IA-64, and Itanium). Installing the necessary components for every platform on every processor can take up allot of harddisk space. In addition, the DDK comes with many examples of how to write everything from parallel port controllers to file system drivers, display drivers, and ethernet drivers. Installing all the examples can also take up a large amount of disk space.
See also: Obtaining the DDK
Checked and Free EnvironmentsEdit
The DDK comes with a number of different batch files, that will create a suitable driver programming environment. The different batch files will create an environment to program for a specific OS/Processor combination. Each different environment will set a number of global variables that the compiler and linker will read to make decisions about the code generation. Compiling a driver using the wrong environment will lead to a driver that may not be compatible with your system (and may destabilize your computer).
For each target platform, there are two environments available: checked and free. The Checked environment is essentially a debug environment, that will add additional debugging bloat to your compiled drivers, and will perform additional error checking and warnings. The Free environment, however, does not contain any debugging information, and should only be used to compile a fully-debugged device driver.
The DDK comes with the compiler: cl.exe, the linker: link.exe, and an assembler: ml.exe. When writing device drivers, it is recommended that you only use these particular files, and that you do not use any other versions of these programs that you may have on your computer (either from the SDK or Visual Studio). The DDK will also come with a number of header files. Some of the header files you may be familiar with, but some of them will contain function prototypes for kernel-mode libraries, that most programmers are unfamiliar with.
The DDK defines a number of different data structures for use in device drivers. However, because drivers operate at kernel mode, it is important to realize that many of the fields of these structures are for use only internally to the kernel, and your driver should not alter them. These data fields are known as "Opaque" members of the structure, and should be treated as if they were a "protected" or "private" member of a C++ class. Data fields that are not explicitly mentioned in this Wikibook should be considered suspect, and if there are any outstanding questions about the availability and use of a particular data field, consult MSDN or the DDK documentation.
Device drivers should always be thoroughly debugged before installing on a system. If a faulty device driver is installed in the system, it could compromise the kernel at boot, making the entire system unstable, if not completely unusable. Uninstalling a faulty driver can be difficult, especially if you need to perform a rescue boot operation on your computer. Device drivers should be written with care, and fully debugged before installing.