Windows驱动开发环境入门指南

需积分: 3 130 浏览量更新于2024-07-31 收藏 179KB DOCX 举报

"Getting Started with Windows Driver Development Environment by Don Burn, Microsoft MVP" 在Windows驱动程序开发领域，调试和测试工具是确保设备驱动程序高质量的关键。本文由微软最有价值专家（MVP）Don Burn撰写，旨在为新手开发者提供Windows驱动开发环境的入门指南，同时也为经验丰富的开发者介绍了使用新工具的方法。 Windows驱动开发工具有助于开发者在早期阶段发现并修复问题，从而提高驱动程序的稳定性和性能。这些工具包含在Windows Driver Kit (WDK)中，WDK是开发、测试和部署Windows驱动程序的核心工具集。WDK提供了编译器、链接器以及其他必要的工具，用于构建和调试驱动程序代码。本文涵盖了适用于以下操作系统的调试和测试技术： - Windows Server 2008 R2 - Windows 7 - Windows Server 2008 - Windows Vista - Windows Server 2003 - Windows XP - Windows 2000 对于新手开发者，WDK介绍涵盖了如何设置开发环境，编写驱动程序的基本结构，以及如何使用调试器进行故障排除。Visual Studio集成开发环境（IDE）与WDK结合，提供了编写、构建和调试驱动程序的便捷平台。开发者可以利用Kernel Debugging（内核调试）来诊断驱动程序在操作系统内核层的错误，而User-Mode Debugger（用户模式调试器）则用于调试用户模式下的驱动组件。对于有经验的开发者，文章可能会更深入地探讨WDK中的新特性和工具，如Driver Verifier，这是一个强大的工具，能够自动检测驱动程序的常见问题和潜在的不稳定因素。此外，Performance Analysis of Drviers (PAD)工具可用于分析驱动程序的性能，帮助优化代码。除了这些调试工具，文章还可能涉及测试策略，包括使用Test Signatures来绕过签名要求，以便在开发过程中快速测试驱动程序，以及使用Windows Hardware Lab Kit (HLK)进行兼容性测试，确保驱动程序在各种硬件配置和操作系统版本上都能正常工作。文档的末尾通常会列出参考资料和进一步学习的资源，帮助读者深入研究特定主题。由于原始文档的链接不再可用，建议在Microsoft Developer Network (MSDN) 或更新的资源库中寻找最新的Windows驱动开发信息和WDK文档。 "Getting Started with Windows Driver Development Environment"是一个宝贵的资源，它为开发者提供了在Windows平台上构建高质量驱动程序所需的工具和知识，无论你是初学者还是经验丰富的专业人士。

Getting Started with the Windows Driver Development Environment - 10

May 17, 2010

Installing the Software

Before you install the WDK and the debugger, you must know several things:

� Not all tools in the WDK work if the directory path for the WDK or the path to

your driver code-base contains a space. Do not install the WDK at some location

such as “C:\Program Files\WDK”. If the path contains a space, you do not receive

a clean error message. Instead, the build of your driver might fail in mysterious

ways.

� At a minimum, load the full build environment from the WDK. By doing this, you

receive the tools that are required to build a driver, samples from which to start

your driver development, additional tools (many of which are discussed in this

paper), and the documentation. Although some developers use the

documentation on the Web, it is much easier to find what you are looking for

when you search only documentation that is related to the WDK.

� The WDK includes debugging tools for Windows, part of which is the debugger

that you need to debug your drivers.

� Although the WDK includes the Device Simulation Framework (DSF), you should

install DSF on test machines and not on development systems. The framework is

mainly for testing certain classes of USB drivers.

� The WDK provides the Windows Device Testing Framework (WDTF). Install WDTF

on the development system to provide a programming framework for creating

tests for your driver. In addition, installing it with the WDK includes a directory

that you can then move to the test system to install the framework and example

scripts for testing.

Development Environment

This section explores the development environment that is required to compile and

link Windows device drivers. The Build utility controls the actual process of compiling

and linking the driver. The remainder of this section provides an overview of the Build

utility and the input file for the tool. The end of the section looks at an approach to

running Build from the Visual Studio integrated development environment.

Build Utility

You use the Build utility to create a driver in the WDK. This utility invokes the correct

tools with the appropriate options to build your driver. It is a wrapper around the

Microsoft NMAKE utility, so it handles issues such as checking dependencies to

ensure that the correct files are rebuilt after a change.

If you have not worked with Build before, you might want to try to build one of the

samples from the WDK:

1. Copy the files under src\general\<sample> (where <sample> is the particular

sample’s name) to a test directory.

2. Click Start > Programs > Windows Driver Kits > WDK <version> >

Build Environments.

3. Choose one of the build environments. The build environment opens a command

window.

Getting Started with the Windows Driver Development Environment - 11

May 17, 2010

4. Change the directory to your test directory.

5. Type build to create the driver.

For most drivers, setting up the Build tool environment is simple:

1. Copy the standard makefile from a WDK sample project.

2. Create a sources file in the directory where your code resides.

Note that you should not change makefile. All commands are set up by the sources

file or makefile.inc, as discussed later in this section. The following is an extremely

simple sources file:

TARGETNAME=test

TARGETTYPE=DRIVER

SOURCES=test.c

This file sets three macros that instruct the Build utility to create a driver that is

named test.sys from the test.c source file.

Build Environments

Earlier in this paper we told you to choose one of the build environments. The current

WDK has build environments for the four targeted versions of Windows

(Windows XP, Windows Server 2003, Windows Vista and Windows Server 2008, and

Windows 7). Under each version are environments for checked and free builds and

for each CPU target that is supported for that version:

� The checked build creates a driver that has debugging enabled. Many of the

optimizations in the compiler are disabled, and conditional code for debugging is

included. While you work to get your driver functional, build your driver with the

checked build.

� The free build creates a production driver in which the code is optimized and

debug code is disabled. Use the production driver for performance testing and to

ship to customers. Do not mistakenly ship the checked build driver—your

customers deserve the best performing driver.

The Build utility names several files and directories that are based on the chosen

environment. These names include the Type_Version_Cpu construct, as shown in the

following table.

Type

“Fre” for the free build and “Chk” for the checked build.

Version

“wxp” for Windows XP, “wnet” for Windows Server 2003, “wlh” for Windows Vista

and Windows Server 2008, or “win7” for Windows 7 and Windows Server 2008 R2.

Cpu

“x86”, “amd64”, or “ia64”, depending on the processor.

As stated earlier, building and testing for the latest version of Windows provides

additional checks for your driver. Building for the earliest version of Windows that

you plan to support creates a binary of your driver that is compatible with all versions

of Windows from that version forward.

As an example of this, assume that you are developing a driver that must support

Windows XP, Windows Vista, and Windows 7, with Windows XP being your largest

current customer base. In this case, you should use the “Windows XP” build

environments for building your driver binary, so that you can create a single binary

that is compatible with Windows XP as well as Windows Vista and Windows 7. For

Getting Started with the Windows Driver Development Environment - 12

May 17, 2010

testing, you should not focus on Windows XP only just because that is your largest

customer base. Instead, you should also spend considerable time on Windows 7

because additional checks and validation points are incorporated into the latest

version of Windows.

Sources File

The example at the beginning of this section had a very simple sources file, but the

recommended file is more complex. The sources file has many macros and

environment variables, all of which are documented in the WDK. The following table

lists items for the sources file that is used in this paper.

C_DEFINES

Specifies switches to pass to the C compiler and the resource

compiler.

INCLUDES

Specifies directories in addition to the source directory to search for

Include files.

MSC_WARNING_LEVEL

Sets the warning level for the C compiler. The default is /W3.

Recommended is /W4 /Wp64 /WX. For details, see "Compile Time

Checking" later in this paper.

NTTARGETFILE0

Causes the inclusion in the build process of makefile.inc. Typically

used to support Windows Management Instrumentation (WMI).

SOURCES

Specifies the files to be compiled.

TARGETNAME

Specifies the name of the binary to be built. This name does not

include the file name extension.

TARGETLIBS

Specifies additional libraries and object files to link to the product.

TARGETPATH

Specifies the destination directory for all build products. In almost

every case, you should set TARGETPATH=obj.

TARGETTYPE

Specifies the type of product that is being built. Common values are

DRIVER (kernel-mode driver), PROGRAM (user-mode program), and

DRIVER_LIBRARY (kernel-mode library)

USER_C_FLAGS

Specifies switches to pass only to the C compiler.

For several capabilities that are discussed later in this paper, it is valuable to know

about the following construct in the sources file. Sources has conditional tests, such

as the following example:

!if !$(FREEBUILD)

...

!endif

This sample specifies that the actions between !if and !endif occur only in the

checked build of the driver.

Makefile.inc File

Makefile.inc provides additional information to the Build utility. This file lets you add

commands and dependencies to makefile, typically for preprocessing and

postprocessing of files that are related to the project. One common use in driver

development is to compile a Managed Object Format (MOF) file that is required for

WMI and produce an Include file that contains data structures for the driver.

剩余55页未读，继续阅读

sillyboard

粉丝: 0
资源: 1

Windows驱动开发环境入门指南

Getting Started with Windows VDI mobi

Getting Started with OpenCart Module Development

Getting Started with C++ Audio Programming for Game Development

Getting Started with Windows VDI epub

Getting Started with Windows VDI azw3

Getting started with Unity 2D Game Development(2nd) 无水印pdf

Getting Started with Semantic Segmentation using DL:Getting Started with Deep Learning Semantic Segmentation using your own image dataset-matlab开发

Getting Started With SIMATIC Manager_GettingStarted_simatic_siem

Getting Started with Bluetooth Low Energy_GettingStarted_ble_

Getting Started with Unity 5.X 2D Game Development epub

最新资源