Tested Platforms and Compilers
As was the case for the Windows XP DDK a complete set of tools is supplied with the Windows XP Service Pack 1 DDK for building drivers. Microsoft Visual C++ is no longer required to be installed to use the DDK.
Please use the included tools to build Windows 2000 or Windows XP device drivers. Do not use compilers, linkers or other build tools from other development products such as Visual Studio .NET to build Windows 2000 or Windows XP device drivers. This version of the Windows DDK does not support using a version of Microsoft Visual C++ other than the one supplied with the DDK. Attempts to use in incorrect version of Visual C++ will result in the following error message from the compiler:
error C1189: #error : Compiler version not supported by Windows DDK
Some Windows Millennium (Me) drivers may require Visual C++ version 6.0 to be installed for use regardless of the platform being used to build the drivers. Later versions of Visual C++ will not work in the Windows Me build environment.
The DDK toolset has not been fully tested for use other than driver development. The DDK toolset is not complete in respect to developing all types of applications.
The <BaseDir>\setenv64.bat has been merged into
a <BaseDir>\setenv.bat. All build environments are still supported with the <BaseDir>\setenv.bat but the
command line has been updated. The new command line is: SetEnv <Directory> [fre|chk]  [WXP|W2K].
Directory is the install location of the DDK, fre or chk are the build types and 64
is to select the building of the 64 bit platform. If the 64 option is used, fre or chk are required. WXP or W2K select the desired target platform.
Building Binary Compatible Drivers
Drivers should typically be built in the build environment of the earliest operating system that the drivers will support. Therefore, a driver that will need to run on Windows 2000 and Windows XP should typically be built within the Windows 2000 build environment.
Some drivers, however, may wish to use additional features that are available on the newer operating system, when they run on that operating system. Such drivers may do this by carefully utilizing functions such as IoIsWdmVersionAvailable() and MmGetSystemRoutineAddress(), or similar technology specific functions.
Extreme care and thorough testing will be required to determine if a driver built for a later operating system will work properly on an earlier operating system. This may not always be possible.
One problem that you may encounter when building a driver in the Windows XP Checked Build Environment, and running that driver on Windows 2000, concerns functions that are only exported by the Windows XP or Windows XP Service Pack 1 version of NTOSKRNL. If your driver calls one of these functions, it may crash or fail to load when run on any platform other than Windows XP or Windows XP Service Pack 1. The Free Build of your driver is not typically affected, as these newly exported functions typically resolve to intrinsics when optimizations are enabled in the Free Build. This problem may be avoided by defining the value USE_LIBCNTPR=1 in your driver's sources file.
Change In Definition of KeNumberProcessors
The kernel variable KeNumberProcessors indicates the number of active CPUs in the system on which a driver is running. The definition for this variable was changed in the Windows XP versions of ntddk.h and wdm.h from a pointer to a value. The Windows 2000 definition of this variable required that KeNumberProcessors be dereferenced (e.g. *KeNumberProcessors). As a result of the change in the defintion of this variable, drivers built in the Windows XP Service Pack 1 build environment need not (and in fact must not) dereference this variable (e.g. KeNumberProcessors).
Drivers that fail to use KeNumberProcessors correctly will get an "illegal indirection" error at compile time.
Note that regardless of the declaration used, drivers that properly reference KeNumberProcessors according to the environment in which they are built will work properly on both Windows 2000 and Windows XP. Therefore, a driver that properly references KeNumberProcessors and that is built in the Windows 2000 build environment, will get the proper value for this variable when the driver is run on either Windows 2000 or Windows XP Service Pack 1.
Windows 9x Development Platform
Using Windows 9x as a development platform for WDM drivers is not supported. Drivers that target Windows XP or Windows 2000, with or without Windows 9x as an additional target, should be developed on a machine running Windows XP or Windows 2000.
New Slist Implementation
Additional optimizations were added in Windows XP to the implementation of singly linked lists (Slists). The Windows 2000 implementation of Slists also remains on Windows XP Service Pack 1 to enable drivers built on Windows 2000 to run unchanged on Windows XP Service Pack 1. The functions affected are ExInterlockedPopEntrySList() and ExInterlockedPushEntrySList() as well as ExAllocateFromPagedLookasideList(),ExFreeToPagedLookasideList(),ExAllocateFromNPagedLookasideList(), and ExFreeToNPagedLookasideList().
The Windows XP Service Pack 1 implementation of these functions, by default, is not binary compatible with the implementation on Windows 2000. If your driver uses SLists and needs to run on Windows 2000, you should build your driver in the Windows 2000 build environment. Optionally, you can build your driver on Windows XP Service Pack 1 and use the Windows 2000 Slist implementation by defining the symbol _WIN2K_COMPAT_SLIST_USAGE at compile time, prior to including any other DDK header files.
Identifying Obsolete Functions In Your Driver
The Windows DDK has a very useful feature that driver developers can enable. When the environment variable DEPRECATE_DDK_FUNCTIONS is defined, the compiler will generate a warning message whenever particular obsolete functions or macros from ntddk.h are referenced. Such obsolete functions are clearly marked in the DDK documentation.
The compiler warning message shows both the line in your source file that invoked the obsolete function, and the line in ntddk.h where the function is declared. An example of an error message you'll get is:
\test\mydriver.c(1785) : error C4996: 'RtlExtendedIntegerMultiply' was declared deprecated
\winddk\WinXP\inc\ddk\wxp\ntddk.h(3106) : error see declaration of 'RtlExtendedntegerMultiply'
Each of the functions that have been declared deprecated in ntddk.h have comments that indicate what, if any, function or mechanism you should use instead of the obsolete function. You can find this same information in the DDK Documentation. Continuing the example above, if you look at line 3106 of ntddk.h you'll find the following declaration, instructing you to use native 64-bit math instead of RTL functions for this purpose:
DECLSPEC_DEPRECATED_DDK // Use native __int64 math
The goal of this feature is to help developers easily discover functions in their drivers that have been obsoleted. All the functions that have been declared deprecated in the DDK have been obsolete at least since Windows 2000. Only a subset of functions that are obsolete have been actually declared as deprecated. There may other obsolete functions, both in ntddk.h and in other header files that have not yet been declared deprecated. Please refer to the DDK documentation as the ultimate guide regarding which functions are obsolete and which are presently supported.
The Windows DDK, by default, will not use any pre-defined Include or Library paths (as specified by the %include% and %lib% environment variables). This is due to the stand alone nature of the DDK and to avoid possible conflicts with other installed source or compiler programs. Any drivers that need to alter the search path for include files should use the Includes= directive in the SOURCES file.