Схемы, платы, компоненты

Читайте! Late-Breaking News for the Microsoft® Windows® Server 2003 Driver Development Kit (DDK) Installation Issues DDK Directory Structure The structure of the DDK directories has significantly changed from the structure used in Windows 2000. This change results from the Windows DDK's inclusion of all the tools, headers, and libraries necessary to build drivers, and also to allow support for multiple build environments. Drivers should continue to reference ntddk.h or wdm.h by specifying "#include ". The build environment automatically sets the appropriate include and library file paths. Drivers may find that some header files have been moved from their technology specific directories (such as \network\inc) to a higher-level DDK directory (such as \inc\wxp). Moving these files to the higher-level include path makes it unnecessary to specify the specific include path for these files. Removal of Windows 9x Content The documentation for Windows 95, Windows 98 and Windows Me driver development is included in this DDK, but the build environments for Windows 95, Windows 98 and Windows Me are no longer supported, and are not available on the Windows Server 2003 DDK. If you need the Windows 9x build environments and their related tools, refer to the Windows XP Service Pack 1 DDK. Dirs Files The method of generating Dirs files has changed. The Dirs are now created by the DDK setup program during the installation of the kit. If the Dirs need to be recreated after installation of the kit, a command line utility (MakeDirs) is supplied in the \bin\x86 directory. The uninstall program also updates the Dirs if a Basic Uninstall is selected. The DDK Build Environment Use This DDK For... Use the Windows Server 2003 build environments in this DDK to build drivers that use new features or functionality available only in Windows Server 2003. Use the Windows XP build environments in this DDK to build drivers that do not use new functionality as described above, and are targeted for either Windows XP or both Windows XP and Windows Server 2003. The Windows XP build environment in this kit contains minor updates to the DDK shipped with Windows XP gold. Use the Windows 2000 build environments in this DDK to build drivers that are designed to run on Windows 2000 only, or Windows 2000 and later operating systems. The Windows 2000 build environment in this kit includes an update of headers and libraries for Windows 2000 Service Pack 3. Changes to Support Conditional Compilation Based on Build Environment The environment variable DDK_TARGET_OS has been introduced to allow conditional testing in the 'sources' file to determine if a driver is being built in the Windows 2000, Windows XP, or Windows Server 2003 build environments. This variable is set to "Win2K", "WinXP", or "WinNET" respectively. For details, look up "DDK_TARGET_OS" in the index of the DDK documentation. Call Usage Verifier The Windows Server 2003 DDK contains Call Usage Verifier. This new feature provides enhanced bug detection and debugging support for driver writers. It can be used in conjunction with Driver Verifier or used separately. For details, look up "Call Usage Verifier" in the index of the DDK documentation. Building DDK Samples (See also Sample Issues) All samples that are supplied with this DDK build without any errors or warnings in the Windows Server 2003 build environments and function properly on Windows Server 2003. Some of the samples may use new features or functionality present for the first time in Windows Server 2003. These samples will not build properly in the Windows XP or Windows 2000 build environments. In addition, some samples use features or functionality first present in Windows XP. These samples will not build properly in the Windows 2000 Build environments. If you build the entire kit, samples that are not supported in the active build environment will not be built because of one (or more) of the following: Changes to the driver's SOURCES Changes to one of the driver's MAKEFILEs Changes to a DIRS file The result is that the correct set of drivers is always built when a command window is started for a given build environment, and the build -cZ command is issued from the DDK's base directory. When a command window is started for a given build environment, a user may manually cd to the directory of a driver that uses features or functionality that are not supported in that environment. If the user attempts to build such a driver in an unsupported environment, and the driver was blocked from building via a DIRS file, the build command fails with a variety of errors and/or warnings. This is the expected behavior. Expected Warnings Building Samples Under Windows XP and Windows 2000 Environments Some samples in the Windows Server 2003 DDK are not supported on Windows XP and/or Windows 2000. These samples now generate a warning when they are built in a non-supported build environment. The warning (which will appear in the build warning log) is in the format: BUILDMSG: Warning : The sample "" is not valid for the current OS target Extensible Firmware Interface (EFI) Developers who would like to build 64 bit EFI executable images for the Intel® Itanium™ Processor Family may use the 64 bit DDK build environments for compiling and linking images. This includes EFI compliant System Firmware, EFI applications and Option ROMs. EFI drivers and applications will only run in the pre-boot EFI firmware environment before Windows XP or Windows Server 2003 is loaded. At this time only the 64 bit compiler and linker have been tested with the EFI Sample Implementation releases and the Toolkit. For further information on EFI specifications and sample source code go to http://developer.i …el.com/technology/EFI. Changes to the Windows 2000 Build Environment Additional headers have been added to more completely match the headers shipped for the Win XP environment. This was necessary to allow some of the samples to compile when built in the Win 2K build environment. When creating the Windows 2000 build environment using the Start Menu icon, the environment variable BUILD_OPTIONS is set in order to exclude many samples from default compilation under this environment. This has a couple of effects and limitations, which apply only to the Win 2K environment. Build -cZ from the root of the DDK now results in a clean build with no errors or warnings. When doing the above, not all samples are built. This does not prevent cd'ing into an arbitrary sample directory and attempting to build it. When doing so, samples that do not work correctly in the Windows 2000 build environment will still produce errors and/or warnings. PREfast Static Analysis Tool Introducing PREfast In response to developer requests for more diagnostic tools, we are very pleased to be able to include in the Windows DDK a new tool to help driver developers detect errors in their C/C++ driver code. This tool is PREfast. As a static analysis tool, PREfast can identify critical defects such as buffer overruns and report those problems during the development phase, before your driver ships. PREfast can be run within any of the standard DDK build environments, using your existing build structure. For more information on using PREfast, please refer to the documentation and command line reference provided under the "Windows DDK->Help->Prefast" PREfast Usage Notes The goal of PREfast is to examine a C/C++ program carefully and identify potential problems in the code. As a result, after careful examination of all the warnings that PREfast produces for a driver, you will likely determine that some of those warnings are not problems. This is how PREfast works, and is to be expected. Users can automatically filter some of the more "picky" PREfast errorts by using one of the included filters when viewing PREfast errors. The "winpft" filter is particularly useful for this purpose. This can be done by selecting the filter manually from the PREfast viewer (by clicking the "Filter" button), or by starting the PREfast viewer with the following command: C:\> prefast /filterpreset=winpft view Test your code with PREfast within any of the DDK's 32-bit build environments. Use of PREfast within any of the 64-bit build environments is not supported at this time. PREfast Warning 314 on IoSetCompletionRoutine When building a driver with PREfast, you will notice that each invocation of the macro IoSetCompletionRoutine results in PREfast reporting a warning 314, with the followng text: "Incorrect order of operations: bitwise-or has higher precedence than the conditional-expression operator." This warning, which is expected and may be safely ignored, is automatically supressed by using the "winpft" filter described in the previous section. Building The Sample Driver With PREfast The samples in the Windows DDK have all been tested with PREfast, and build with no PREfast warnings when using the "winpft" filter, described previously. Compiling and Linking Tested Platforms and Compilers The DDK ships a complete set of tools for building drivers. These tools have been upgraded from those released with the Windows XP DDK. As in the Windows XP DDK, Microsoft Visual C++ is no longer required to be installed. Use the included tools for all Windows 2000, Windows XP, and Windows Server 2003 drivers. This version of the Windows DDK does not support building drivers using a version of Microsoft Visual C++ other than the one supplied with the DDK. Some Windows Millennium (Me) drivers (such as DirectX drivers for that platform) 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. This toolset has not been fully tested for use other than driver development. Development work on this toolset is not complete. Buffer Overflow Checking and DriverEntry The Windows Server 2003 DDK enables the /Gs compiler option for both free and checked drivers built in the Windows Server 2003 build environment. This compiler option implements stack buffer overflow checking. To support this feature, the Windows Server 2003 build environment set the driver entry point to GsDriverEntry. GsDriverEntry performs some brief initialization, and then calls the driver's DriverEntry entry point. Experience with using this switch at Microsoft has shown that the /Gs option adds very little overhead to a kernel module and while at the same time helping to counter a potential security risk. Buffer overflow checking can be turned off by setting the environment variable BUFFER_OVERFLOW_CHECKS to zero in the Windows Server 2003 build environment. Updated Setenv.bat The \setenv64.bat has been merged into a \setenv.bat. Windows XP and Windows Server 2003 build environments are supported with the \setenv.bat but the command line has been updated. For details, look up "setenv.bat" in the index of the DDK documentation. Changes To Build Log File Names The names of the log files created by the build utility have been changed to support the multiple build environment functionality included in the kit. For details, look up "specifying the location of created files" in the index of the DDK documentation. Building Binary Compatible Drivers Drivers typically should be built in the build environment of the earliest operating system that the drivers support. Therefore, a driver that needs to run on Windows 2000 and Windows XP should be built in the Windows 2000 build environment. Some drivers, however, may want 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 using functions such as IoIsWdmVersionAvailable() and MmGetSystemRoutineAddress(), or similar technology specific functions. Thorough testing is required to determine if a driver built for a later operating system works properly on an earlier operating system. This may not always be possible. 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 has been 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 definition of this variable, drivers built in the Windows XP build environment must not dereference this variable (for example, KeNumberProcessors). Drivers that fail to use KeNumberProcessors correctly get an "illegal indirection" error at compile time. Regardless of the declaration used, drivers that properly reference KeNumberProcessors according to the environment in which they are built work properly on Windows 2000, Windows XP, and Windows Server 2003. Therefore, a driver that properly references KeNumberProcessors and that is built in the Windows 2000 build environment gets the proper value for this variable when the driver is run on any of the three platforms (Windows 2000, Windows XP, and Windows Server 2003). Windows 9x Development Platform Using Windows 9x as a development platform for WDM or Windows XP drivers is not supported. Drivers that target Windows XP, with or without Windows 9x as an additional target, should be developed on a machine running Windows XP. New Slist Implementation Additional optimizations have been added to the Windows XP and later implementations of singly linked lists (Slists). The Windows 2000 implementation of Slists also remains in the DDK to enable drivers built on Windows 2000 to run unchanged on Windows XP and later systems. The functions affected are ExInterlockedPopEntrySList() and ExInterlockedPushEntrySList() as well as ExAllocateFromPagedLookasideList(), ExFreeToPagedLookasideList(), ExAllocateFromNPagedLookasideList(), and ExFreeToNPagedLookasideList(). The Windows XP and laterimplementation 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 in another build environment and use the Windows 2000 Slist implementation by defining the symbol _WIN2K_COMPAT_SLIST_USAGE at compile time, before including any other DDK header files. Identifying Obsolete Functions In Your Driver The Windows Server 2003 and Windows XP build environments of the Windows DDK have a very useful feature that driver developers can enable. When the environment variable DEPRECATE_DDK_FUNCTIONS is defined, the compiler generates a warning message whenever particular obsolete functions or macros from ntddk.h are referenced. These 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 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 NTSYSAPI LARGE_INTEGER NTAPI RtlExtendedIntegerMultiply LARGE_INTEGER Multiplicand, LONG Multiplier ); 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 be other obsolete functions, both in ntddk.h and in other header files that have not yet been declared deprecated. Refer to the DDK documentation as the ultimate guide regarding which functions are obsolete and which are presently supported. Predefined Paths 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. FusionManifestValidator Note: For the Windows Server 2003 DDK, not all files may compile correctly on a Windows 2000 machine using this tool. This will be fixed for future releases. WDM Audio Drivers This Windows® Server 2003 DDK should be used for all WDM audio driver development. Please rebuild your driver with this DDK to take advantage of recent changes and fixes. As of this release, this DDK supports Windows 98 Second Edition, Windows Me, Windows 2000, Windows XP, and Windows Server 2003. This DDK does not support nor do we recommend the development of WDM audio drivers for the original Windows 98 release. The code samples that are listed below will work interchangeably on the supported operating systems with the INF files that are provided with the samples: ac97 - A sample audio driver that runs on an Intel motherboard with an integrated AC97 controller. This sample shows how to write a WDM audio adapter driver that implements WavePci support for a PCI add-in card with scatter/gather DMA capabilities. Included with this sample driver are additional subdirectories containing sample code that works in conjunction with the driver. The subdirectories are named as follows: cpl - This sample shows how to write a control panel application. It requires that both the proppage sample DLL and the ac97 sample driver be installed. driver - This is the sample audio driver for the AC97 controller. INFViewer - This subdirectory contains an HTML version of the driver's INF file with hot-linked references to INF sections and keyword definitions in order to facilitate easy exploration. proppage - This sample shows how to write a property-page DLL that gets loaded by the device manager when a user elects to display the properties of your device. In addition to displaying the default property sheets, the device manager also displays the property sheet that is defined in the sample. This sample DLL requires that the ac97 sample driver be installed. ddksynth - Kernel-mode DLS synthesizer. This sample can be adapted for a MIDI output device as well. dmusuart - MPU-401 miniport driver for processing DirectMusic and MIDI input and output streams. This is the source code for the built-in DMusUART miniport driver in portcls.sys. Hardware vendors can adapt this sample to write their own custom miniport drivers. fmsynth - FM-synth miniport driver for MIDI. This sample driver provides an interface to a device that implements OPL3-style synthesis. This is the source code for the built-in FMSynth miniport driver in portcls.sys. Hardware vendors can adapt this sample to write their own custom miniport drivers. gf