![]() |
![]() |
All Products | Support | Search | microsoft.com Home | |||||||||||||
![]() | |||||||||||||||
|
|
Windows DDK Release NotesContents: See Also: Driver Verifier
Included in this release of Windows 2000 is the Driver Verifier. This facility, built into Windows 2000, allows developers and users to perform extra testing and validation on a driver or set of drivers. A shortcut that opens the configuration utility for the Driver Verifier is included in the DDK. This shortcut can be found at: Programs\Development Kits\Windows 2000 DDK. Driver Verifier can be found at <DDKroot>\Tools\verifier.exe. All drivers must be tested using the Driver Verifier. If a driver behaves incorrectly, the Driver Verifier will crash the system immediately. In this way, the Driver Verifier prevents the driver bug from being masked by further processing. The result is a faster, easier debugging process. For more information on the Driver Verifier, please see the Driver Writer's Guide in the DDK documentation. Windows File Protection
Windows File Protection (WFP) protects system files. Windows 2000 will not allow protected system files to be overwritten by another file with the same name. However, the system will allow files that are not named the same as a protected file to be installed. Further information on WFP is available in wfp.htm, located on the root of the CD or the root of the DDK installation. Driver Signing
Microsoft now provides digital signatures for most publicly distributed drivers. Please see DDK Digital Signing for more information on this initiative. Installation Issues
Dirs Files If OPTIONAL_DIRS directives must be preserved, it is suggested that the \ntddk\bin\setenv.bat and/or the \ntddk\bin\setenv64.bat file be modified to prevent automatic dirs creation. Open the \ntddk\bin\setenv(64).bat and search for the second occurence of VCCheck and comment out the line. When the build window is opened, the automatic dirs creation will not occur and any changes made to the existing dirs file will be preserved. Icons Not Updated To allow the current icons to be seen, log in as the user who originally installed the previous version of the DDK. Right-click on the Start menu, and pick Explore. Double-click on Programs. The folder Development Kits should be seen. Rename this folder and close the Explorer window. The Start menu should now contain both the current DDK icons and the previous kit icons. Compiling and Linking
Tested Platforms and Compilers Compiler Notes
The version of ATL that ships with this Windows 2000 DDK is not the same as the Visual C++ version and should only be used for driver development. General purpose ATL source code is available with your normal Visual C++ installation. Build Error Messages During the initialization of BUILD, the following message might be displayed: invalid include statement: importlib(STDTYPE_TLB) To prevent this message from displaying in the future, edit the xxxx.odl file specified in the warning message. Use a text editor to open the file and search for "importlib." When found, add quotes around the name inside the parentheses. For example: importlib("STDTYPE_TLB") Then save your changes. Debugging
For more information on WinDBG and the KD debuggers included in the DDK, and on debugging, please see the debuggers.txt file in the directory where the debugger is installed. See also the information on debugging found in the Driver Writer's Guide in the DDK online Help. You can also find more information on debugging at http://www.microsoft.com/ddk/debugging/. WDM 1.0
Windows 98 defined a unified driver model for the Windows 98 and Windows 2000 operating systems by standardizing requirements and reducing the amount of code that needed to be written. Programmers who are already familiar with Windows NT 4.0 drivers will recognize most of the features of WDM drivers. However, the DDK documentation and samples should be studied in order to understand the subtleties of WDM. WDM drivers will not run on operating systems earlier than Windows 98 or Windows 2000. By conforming to WDM, drivers can be binary-compatible across Windows 98, Windows 98 Second Edition, and Windows 2000 on x86-based computers. However, subsequent operating systems will contain features not available in preceding versions. WDM is designed to be forward-compatible but not backward-compatible. That is, drivers will be compatible with the same or higher-numbered WDM versions. Such WDM drivers will not be able to take advantage of new operating system services, but they will still load and run. Newer drivers running in an earlier-version environment will most likely fail while loading. WDM driver writers should carefully consider feature-set inclusions. For example, does the driver need to run on different platforms? Will the hardware be widely available, or is it highly specialized and thus limited in distribution? Additionally, not all hardware meets the requirements of WDM. Video drivers do not support the WDM model and must be written separately, as do certain drivers utilizing VxDs under Windows 98 and some network drivers. Virtual hardware (emulation) and nonstandard buses are not supported in a WDM class. A multi-operating system driver is required to conform to the earliest WDM version of any operating system supported by the driver. For cross-operating system compatibility, thoroughly test drivers on all versions of Windows 98 and Windows 2000, because operating system differences can produce slightly different driver behavior. Differences are most apparent between single-processor and multiprocessor platforms. WDM Audio Drivers
This Windows 2000 DDK should be used for all WDM audio driver development. As of this release, this DDK supports both the Windows 2000 and Windows 98 Second Edition platforms. The sample code shown here will work interchangeably on either operating system with the INF files provided. Please rebuild your driver with this DDK to take advantage of recent changes and fixes. This DDK does not support nor do we recommend the development of WDM drivers for the original Windows 98 release. We have added a WDM driver sample which supports the AC97 architecture. It uses the WavePCI miniport, and should work with any AC97 codec connected to an Intel motherboard with integrated AC97 controller, such as the Intel 810 Chipset. Sample Issues
WDM NDIS Drivers New IDE Driver Stack Signed Sample Installation Windows 9x WDM Symbol Generation IME Warnings Under the Japanese System Locale cht\chajei\..\ime.rc(37) : warning RC4093: unescaped newline in character constant in inactive code cht\phon\..\ime.rc(37) : warning RC4093: unescaped newline in character constant in inactive code cht\quick\..\ime.rc(37) : warning RC4093: unescaped newline in character constant in inactive code These warnings appear in both the free and checked builds. These warnings do not cause any problems in the resulting drivers. Plotter Sample Will Not Compile Under Some System Locales Change the code on line 640 from Buf[Size++] = (BYTE)((bData & Mask) ? '?' : '?'); to this: Buf[Size++] = (BYTE)((bData & Mask) ? 0xDB : 0xB0); WDM Video Capture Drivers ICreateDevEnum *pCreateDevEnumTmp; CoCreateInstance(CLSID_SystemDeviceEnum, NULL, CLSCTX_INPROC_SERVER, IID_ICreateDevEnum, (void**)&pCreateDevEnumTmp); IEnumMoniker *pEmTmp = 0; if(pCreateDevEnumTmp) { pCreateDevEnumTmp->CreateClassEnumerator( CLSID_VideoInputDeviceCategory, &pEmTmp, 0); } ... // Release both pCreateDevEnumTmp and pEmTmp after the graph Scanners and Cameras KAnalyze DvdTs Toaster Change: This will be fixed in the next release of the DDK. KeWaitForSingleObject Affected samples: Windows 2000 Fixing the bug required a minor change in the behavior of IoGetRelatedDeviceObject. Unfortunately, the change impacts a small number of drivers (primarily file system filter drivers) that called IoGetRelatedDeviceObject directly or indirectly and relied on the incorrect behavior. When called on a file object that represents the underlying storage device, IoGetRelatedDeviceObject now always returns the highest-level device object in the storage device stack. To obtain the highest-level device object in the file system driver stack, drivers must call IoGetRelatedDeviceObject on a file object that represents the file system's driver stack, and the file system must currently be mounted. (Otherwise, the storage device stack is traversed instead of the file system stack.) To ensure that the file system is mounted on the storage device, the driver must have specified an appropriate access mask, such as FILE_READ_DATA or FILE_WRITE_ATTRIBUTES, when opening the file. Specifying FILE_READ_ATTRIBUTES does not cause the file system to be mounted. This requirement also applies to drivers that call IoGetDeviceObjectPointer. Such drivers should pass the appropriate access mask value in that routine's DesiredAccess parameter. Drivers that call IoAttachDevice are also affected by this change. IoAttachDevice opens the file with FILE_READ_ATTRIBUTES and then calls IoGetRelatedDeviceObject. This does not cause a file system to be mounted. Thus a successful call to IoAttachDevice returns the device object of the storage driver, not that of the file system driver. Updated Windows NT 4.0 Samples Some VDD Samples Require 16-bit Build Tools VDD Sample is a Legacy Driver WmiCli Sample Requires MFC to be Installed Tool Issues
Grapher SCSIINF GenINF The tool does not create fully valid INF files. However, the skeleton INF files it generates should help developers complete their device driver INF files. Users should review all INF files created by GenINF carefully and modify them as required. Users should expect to add additional INF directives, especially any directives are that are device-class-specific or that contain device-class-specific information. GenINF is located in the <DDKRoot>\Tools subdirectory. Because it is GUI-based, it can be executed from within the Windows 2000 User Interface or from the Command Prompt. GenINF takes no arguments. Please check the GenINF release notes for details on usage and limitations. ChkINF ChkINF is located in the <DDKRoot>\Tools\Chkinf subdirectory and should be executed from the Command Prompt. Because ChkINF is a Perl script, in order to use the tool, you will need to obtain a Perl interpreter. ChkINF requires a Perl interpreter that is Version 5.003_07 or later. ChkINF should work with any version of Perl 5.0 or later, but has not been tested with any versions before 5.003_07. Please check the ChkINF release notes in <DDKRoot>\Tools\Chkinf\Chkinf.htm for details on usage and limitations. Windows 2000 DDK Build Environment Changes
The Windows 2000 DDK includes an environment for building drivers that closely matches the internal build environment used to build Windows 2000 drivers at Microsoft. This environment comes in two types: free and checked. The free environment is similar to the Microsoft Visual Studio® concept of retail builds, which are optimized for release. The checked environment has no optimization and often has extra tests in the code to catch errors. All drivers should first be written and tested in the checked environment, and then retested in the free environment after they seem to be complete. The Build tool (Build.exe), which is part of both environments, acts as a front end to a standard compilation tool such as Nmake. Build and the makefiles included in the DDK are customized for creating Windows 2000 drivers. Most drivers do not need to specify their own custom makefile, because a simple makefile that includes the makefile.def in the DDK will suffice. However, to properly set up driver code to compile using Build, you must create a sources file that specifies values for the environment variables that drive Build's actions. The DDK documents how to create this file plus the related dirs file. In past versions of Microsoft DDKs, the objects compiled through the build process often ended up in arbitrary locations. The location was defined by the environment variable TARGETPATH. Usually, the location was set to either $(BASEDIR)\lib\<platform>\Free|Checked or to Obj\<platform>, where <platform> could be either I386 or Alpha. The former is confusing to inexperienced users. The latter allowed the user's checked files to be overwritten by the free ones, and vice versa. Previously, the common TARGETPATH setting was TARGETPATH=$(BASEDIR)\lib, which is now explicitly disallowed by the code in makefile.def. The version of Build included in the Windows 2000 DDK still uses TARGETPATH to place objects created by Build. If TARGETPATH is set to point to a particular directory, the objects created will be placed in that directory. The default for TARGETPATH is OBJ, which is treated by Build as a special token. If TARGETPATH is set to OBJ, the objects will be placed in Obj$(BUILD_ALT_DIR)\<platform>. If the environment variable BUILD_ALT_DIR is undefined, the default is Obj\<platform>. In the Windows 2000 DDK, the free environment sets BUILD_ALT_DIR to FRE, and the checked environment sets the variable to CHK. The result is that free build objects are placed in Objfre\<platform> and checked builds are placed in Objchk\<platform>. This allows both a free and checked version to co-exist and be built from the same source. Use the variable $(O) [capital O, not zero] as an easy way to refer to this directory in sources files. BUILD_ALT_DIR is also appended to the build logs created by the build -e command. In the DDK environments, this causes the names of the log files to change as follows.
The DDK environment also emulates this same behavior for the libraries included in the DDK. Instead of a single Lib\<platform> directory containing only the free versions of the libraries, there are now two directories: Libfre and Libchk. This allows the DDK to include both the free and checked versions of the libraries. The DDK environment is created using a batch file, Setenv.bat, which sets the variables CRT_LIB_PATH, DDK_LIB_DEST, DDK_LIB_PATH, SDK_LIB_DEST, and SDK_LIB_PATH correctly for the free or checked environment. The variable TARGETPATHLIB allows you to specify a different location than TARGETPATH for .lib and .exp files created for DLLs. When you are building a DLL, you create the DLL itself. You also create an import library that other images can use to reference functions exported by your DLL. Setting TARGETPATH independently from TARGETPATHLIB allows the binary to be kept in the current directory, while the .lib and .exp files can be shared with other components. TARGETPATHLIB has no effect on binaries that are not DLLs. The location of header files has also been changed in the current DDK. Most headers remain in the $(BASEDIR)\inc directory. However, the DDK-specific headers are now in $(BASEDIR)\inc\ddk, and the WDM-specific headers are now in $(BASEDIR)\inc\ddk\wdm. You may need to adjust INCLUDES directives in sources files. The following environment variables included in sources files in the past are now disallowed:
These are unneeded, so please remove them from your sources file. Last Updated: Tuesday, March 20, 2001 |