先安装WDK 7；驱动开发包 7；
包含 build环境，调试工具，设备仿真和测试相关；
路径；
DSF一时不知道是什么；
安装过程；
完成；
开始菜单出来两个一级菜单，调试工具，驱动开发包；
看一下构建环境，包含Checked和Free两种；有何区别？
"Checked build" 有 traces和asserts, "Free build" 没有；基本上这两者与我们传统的 "Debug" 和 "Release" 相对应；
chk表示Checked，fre表示Free。主要的区别在于，checked build有traces和asserts，而free build没有。
checked和free是怎么出现的呢？因为传统的用词一般是debug和retail（或者release）。
当Windows NT还处在开发阶段的时候，开发组的人还在用“debug”和“retail”。Debug和Retail的不同在于编译时的选项：
Compiler Optimization：开、关
Debug Traces：开、关
Assertions：开、关
Sanity checks：开、关
传统来说，Debug是“Optimization：关，Traces：开，Assertions：开”，Retail是“O：开，T：关，A：关”。后来，NT团队加入了Sanity checks的选项。本来，Sanity check在内部版本中有，在发布的时候会移除掉。
于是，NT的团队就有了“O：开，T：开，A：开，S：开”，“O：开，T：关，A：关，S：开”和“O：开，T：关，A：关，S：关”三种Build。
最后一种是传统的“retail” build。那么，前两种叫什么build呢？第一种Optimization是开着的，所以不是传统的“debug”，后一种Sanity check是开着的，所以不是传统的“retail”。
为了区别这些build的不同。讨论以后，NT团队决定用“checked”表示“O：开，T：开，A：开，S：开”，“Free”表示“O：开，T：关，A：关，S：开”。Checked是因为所以的check都打开了，Free是因为“check free”。
后来，随着NT 3.1项目进展，团队认识到：
他们其实根本就不会去测试“retail” build，
他们对free build进行了性能测试，结果发现它能够满足性能要求。
于是，团队把free build作为最终版本发布。
进到一个build环境命令提示符；输入 build 命令； 我的本意是看一下 build 命令的帮助；结果一行行提示自己出来，看上去不停地在运行某个程序；原来在安装的一级或二级目录下直接打build命令，会自动构建WDK本身自带的全部驱动程序例子；
先Ctrl-C终止；
做一个入门WDK驱动程序，代码如下；存为test.c；
#include <ntddk.h>#include <wdf.h>DRIVER_INITIALIZE DriverEntry;EVT_WDF_DRIVER_DEVICE_ADD KmdfHelloWorldEvtDeviceAdd;NTSTATUS DriverEntry(_In_ PDRIVER_OBJECTDriverObject, _In_ PUNICODE_STRING RegistryPath){// NTSTATUS variable to record success or failureNTSTATUS status = STATUS_SUCCESS;// Allocate the driver configuration objectWDF_DRIVER_CONFIG config;// Print "Hello World" for DriverEntryKdPrintEx(( DPFLTR_IHVDRIVER_ID, DPFLTR_INFO_LEVEL, "KmdfHelloWorld: DriverEntry\n" ));// Initialize the driver configuration object to register the// entry point for the EvtDeviceAdd callback, KmdfHelloWorldEvtDeviceAddWDF_DRIVER_CONFIG_INIT(&config, KmdfHelloWorldEvtDeviceAdd);// Finally, create the driver objectstatus = WdfDriverCreate(DriverObject, RegistryPath, WDF_NO_OBJECT_ATTRIBUTES, &config, WDF_NO_HANDLE);return status;}NTSTATUS KmdfHelloWorldEvtDeviceAdd(_In_ WDFDRIVER Driver, _Inout_ PWDFDEVICE_INIT DeviceInit){// We're not using the driver object,// so we need to mark it as unreferencedUNREFERENCED_PARAMETER(Driver);NTSTATUS status;// Allocate the device objectWDFDEVICE hDevice; // Print "Hello World"KdPrintEx(( DPFLTR_IHVDRIVER_ID, DPFLTR_INFO_LEVEL, "KmdfHelloWorld: KmdfHelloWorldEvtDeviceAdd\n" ));// Create the device objectstatus = WdfDeviceCreate(&DeviceInit, WDF_NO_OBJECT_ATTRIBUTES,&hDevice);return status;}
相关参考见此：/zh-cn/windows-hardware/drivers/gettingstarted/writing-a-very-small-kmdf--driver
有关WDK驱动程序构建的参考见
/zh-cn/windows-hardware/drivers/devtest/tools-for-building-drivers
/link?url=gofQddvm4cFhKAFxAD1iH0_YNCjokCmRwhWT5SEKaaWhbkQPew_4nTGZRiuBBX9bK8r98rY4F-FZuzSfC7o-SPME2VHxHqYizvD8EV7M7Ly&wd=&eqid=a98c2ec5000d4902000000065fef218a
从Checked Build 环境，切换到test.c所在目录，输入build test.c，看一下能否构建出一个test.sys的驱动程序；构建完成，Done；
没有出来.sys为后缀的驱动程序；还不是很清楚这概念，可能到某一版本后，MS的构建应用程序的build和构建驱动程序的build，可能是一个，只是通过不同的参数和环境，来构建出不同的程序类型；
看一下安装目录的下面目录，是一个wmi示例驱动程序；
adm64目录下都是源文件；构建一下此驱动示例，看能否生成.sys驱动；amd64架构的驱动程序，构建成功以后，出现在amd64目录下；如果是构建x86的驱动程序，则.sys出现在i386目录下；
构建wmisamp示例；完毕后显示 Done，wmisamp.sys，1 executable built；
看一下amd64目录下，出来一个.sys驱动程序；
