什么是驱动程序？为术语“驱动程序”给出单一的准确定义比较困难。

就最基本的意义而言，驱动程序是一个软件组件，可让操作系统和设备彼此通信。

例如，假设应用程序需要从设备中读取某些数据。

应用程序会调用由操作系统实现的函数，操作系统会调用由驱动程序实现的函数。

驱动程序（由设计和制造该设备的同一公司编写）了解如何与设备硬件通信以获取数据。

当驱动程序从设备获取数据后，它会将数据返回到操作系统，操作系统将数据返回至应用程序。

扩大定义到目前为止，我们的说明采用以下几种方式进行简单化：∙并非所有驱动程序都必须由设计该设备的公司编写。

在多种情形下，设备根据已发布的硬件标准来设计。

这表示驱动程序可以由Microsoft 编写，设备设计者无须提供驱动程序。

∙并非所有驱动程序都直接与设备通信。

对于给定的I/O 请求（如从设备读取数据），通常有一些驱动程序（在堆栈中进行分层）参与该请求。

可视化堆栈的传统方式是将第一个参与对象放在顶部，将最后一个参与对象放在底部，如此图所示。

堆栈中的某些驱动程序可能通过将请求从一种格式转换至另一种格式来参与。

这些驱动程序不会与设备直接通信；它们只操纵请求并将请求传递至堆栈下方的驱动程序。

堆栈中直接与设备通信的一个驱动程序称为“函数驱动程序”；执行辅助处理的驱动程序称为“筛选器驱动程序”。

某些筛选器驱动程序遵守并记录有关I/O 请求的信息，但不会主动参与这些请求。

例如，某些筛选器驱动程序充当验证程序以确保堆栈中的其他驱动程序正确处理I/O 请求。

我们可以扩大“驱动程序”的定义，方法是表示驱动程序为遵守或参与操作系统与设备之间通信的任一软件组件。

软件驱动程序我们的扩大定义相当准确，但仍不完整，原因是某些驱动程序与任何硬件设备根本不关联。

例如，假设你需要编写可以访问核心操作系统数据结构的工具，这些结构仅可以由内核模式下运行的代码进行访问。

可以通过将工具拆分成两个组件来执行该操作。

第一个组件在用户模式下运行且提供用户界面。

第二个组件在内核模式下运行且可以访问核心操作系统数据。

在用户模式下运行的组件称为应用程序，在内核模式下运行的组件称为“软件驱动程序”。

软件驱动程序与硬件设备不关联。

有关处理器模式的详细信息，请参阅用户模式和内核模式。

此图说明了与内核模式软件驱动程序通信的用户模式应用程序。

其他说明软件驱动程序始终在内核模式下运行。

编写软件驱动程序的主要原因是获取对仅在内核模式下可用的受保护数据的访问权限。

但是设备驱动程序不会始终需要访问内核模式数据和资源。

因此某些设备驱动程序在用户模式下运行。

有一系列的驱动程序我们尚未提及，“总线驱动程序”。

若要了解总线驱动程序，你需要了解设备节点和设备树。

有关设备树、设备节点以及总线驱动程序的信息，请参阅设备节点和设备堆栈。

到目前为止，我们的说明过度简化了“函数驱动程序”的定义。

我们表示设备的函数驱动程序为堆栈中直接与设备通信的一个驱动程序。

对于直接连接到外围组件互连(PCI) 总线的设备而言，以上为真。

PCI 设备的函数驱动程序获取映射到设备上端口和内存资源的地址。

函数驱动程序通过写入这些地址直接与设备通信。

但是在多种情形下，设备未直接连接到PCI 总线。

相反设备连接到的主机总线适配器连接到PCI 总线。

例如，USB toaster 连接到主机总线适配器（称为USB 主控制器），该适配器连接到PCI 总线。

USB toaster 具有函数驱动程序，USB 主控制器也具有函数驱动程序。

toaster 的函数驱动程序与toaster 间接通信，方法是将请求发送至USB 主控制器的函数驱动程序。

然后，USB 主控制器的函数驱动程序与USB 主控制器硬件直接通信，该硬件与toaster 通信。

是否需要编写驱动程序？0（共1）对本文的评价是有帮助 - 评价此主题Microsoft Windows 包含适用于许多设备类型的内置驱动程序。

如果有适用于你的设备类型的内置驱动程序，则不必自行编写驱动程序。

你的设备可以使用内置的驱动程序。

适用于USB 设备的内置驱动程序如果你的设备属于由USB 设备工作组(DWG) 定义的设备类，则可能已经存在适用于该设备的Windows USB 类驱动程序。

有关详细信息，请参阅支持的USB 设备类的驱动程序。

适用于其他设备的内置驱动程序目前，Microsoft 为以下其他类型的设备提供内置驱动程序：选择驱动程序模型4（共6）对本文的评价是有帮助 - 评价此主题Microsoft Windows 提供了多种驱动程序模型，你可以使用这些模型编写驱动程序。

最佳驱动程序模型的选择策略取决于你计划编写的驱动程序类型。

下文介绍了这些选项：∙设备函数驱动程序∙设备筛选器驱动程序∙软件驱动程序∙文件系统筛选器驱动程序∙文件系统驱动程序有关各种类型驱动程序之间差异的介绍，请参阅什么是驱动程序？和设备节点和设备堆栈。

以下部分说明了如何为每种类型的驱动程序选择模型。

为设备函数驱动程序选择驱动程序模型当你设计一个硬件设备时，首先要考虑的事项之一就是你是否需要编写函数驱动程序。

提出下列问题：是否可以完全避免编写驱动程序？如果必须编写函数驱动程序，则最好使用哪个驱动程序模型？若要回答这些问题，请确定设备的何处可以容纳设备和驱动程序技术中介绍的技术列表。

参阅该特定技术的文档，以确定是否需要编写函数驱动程序以及了解哪些驱动程序模型可供设备使用。

某些个别技术具有微型驱动程序模型。

在微型驱动程序模型中，设备驱动程序由两个部分组成：一个部分处理常规任务，另一部分处理设备特定的任务。

通常，Microsoft 编写通用部分，设备制造商编写设备特定的部分。

设备特定的部分具有多种名称，其中大部分名称都共享前缀“微型”。

以下是微型驱动程序模型中使用的一些名称：∙显示器微型端口驱动程序∙音频微型端口驱动程序∙电池微型类驱动程序∙蓝牙协议驱动程序∙HID 微型驱动程序∙WIA 微型驱动程序∙NDIS 微型端口驱动程序∙存储器微型端口驱动程序∙流微型驱动程序有关微型驱动程序模型的概述，请参阅微型驱动程序和驱动程序对。

并非设备和驱动程序技术中列出的每项技术都有专用的微型驱动程序模型。

特定技术的文档可能会建议你使用内核模式驱动程序框架(KMDF)；其他技术的文档可能会建议你使用用户模式驱动程序框架(UMDF)。

关键点是你应从研究特定设备技术的文档开始。

如果你的设备技术具有微型驱动程序模型，则必须使用微型驱动程序模型。

否则就遵循技术特定的文档中有关是使用UMDF、KMDF 还是Windows 驱动程序模型(WDM) 的建议。

为设备筛选器驱动程序选择驱动程序模型一些驱动程序频繁参与单个I/O 请求（如从设备读取数据）。

驱动程序在堆栈中进行分层，并且可视化堆栈的常规方法是将第一个驱动程序放在顶部，将最后一个驱动程序放在底部。

堆栈具有一个函数驱动程序并且还可以具有筛选器驱动程序。

有关函数驱动程序和筛选器驱动程序的介绍，请参阅什么是驱动程序？和设备节点和设备堆栈。

如果你准备为设备编写筛选器驱动程序，则确定设备的何处可以容纳设备和驱动程序技术中介绍的技术列表。

查看特定设备技术的文档是否有关于选择筛选器驱动程序模型的任何指南。

如果设备技术的文档未提供此指南，则首先考虑使用UMDF 作为驱动程序模型。

如果筛选器驱动程序需要访问的数据结构无法通过UMDF 获取，则考虑使用KMDF 作为驱动程序模型。

在极端少见的情形中，驱动程序需要访问的数据结构无法通过KMDF 获取，则使用WDM 作为驱动程序模型。

为软件驱动程序选择驱动程序模型未与设备关联的驱动程序称为“软件驱动程序”。

有关软件驱动程序的介绍，请参阅什么是驱动程序？主题。

软件驱动程序很有用，原因是这些驱动程序可以在内核模式下运行，这样为其提供了受保护操作系统数据的访问权限。

有关处理器模式的信息，请参阅用户模式和内核模式。

有关软件驱动程序，你的两个选项为KMDF 和旧的Windows NT 驱动程序模型。

使用KMDF 和旧的Windows NT 模型，你可以在编写驱动程序时无须考虑即插即用(PnP) 和电源管理。

你可以改为专心于驱动程序的首要任务上。

使用KMDF，你不必考虑PnP 和电源，因为框架会为你处理PnP 和电源。

使用旧的Windows NT 模型，你不必考虑PnP 和电源，原因是旧的驱动程序在与PnP 和电源管理完全无关的环境中运行。

我们的建议是使用KMDF，尤其是当你已熟悉KMDF 时。

如果你希望驱动程序与PnP 和电源管理完全无关，则使用旧的Windows NT 模型。

如果你需要编写注意到电源转换或PnP 事件的软件，则不能使用旧的Windows NT 模型；必须使用KMDF。

注意在极少情形中，你需要编写注意到PnP 或电源事件的软件驱动程序，并且驱动程序需要访问无法通过KMDF 获取的数据，则必须使用WDM。

为文件系统筛选器驱动程序选择驱动程序模型有关为文件系统筛选器驱动程序选择模型的帮助，请参阅“文件系统微过滤驱动程序”和文件系统筛选器驱动程序。

为文件系统驱动程序选择驱动程序模型有关为文件系统驱动程序选择模型的帮助，请参阅文件系统微过滤驱动程序。

相关主题内核模式驱动程序框架用户模式驱动程序框架Windows 兼容硬件开发板此主题尚未评级 - 评价此主题Windows 兼容硬件开发板（比如Intel Sharks Cove）使你能够为硬件组件开发软件和驱动程序，这些组件通常将合并到手机、平板电脑和其他高度集成或嵌入的系统中。

开发板Summer 2014：新的Microsoft 计划将使硬件工程师使用专为特定SoC 环境设计的经济高效的开发板更轻松地开发和验证Windows 驱动程序。

硬件工程师过去在为SoC 平台创建Windows 驱动程序方面一直面临许多挑战。

与具有PCI 插槽和USB 端口的电脑不同，类似平板电脑和贝壳机的SoC 系统使用低功率内部总线，缺少标准连接器、即插即用支持和发现机制。

通常，这些设备受安全启动的保护，而且无法用于开发或测试第三方驱动程序。

这将很快得到改变。

硬件工程师将能够购买现成的开发板，专门用于特定的SoC 环境。

Intel Sharks Cove 板将在2014 年下半年上市的一种板是Intel Sharks Cove 硬件开发板。

Intel Sharks Cove 板将支持设备的驱动程序开发，这些设备使用各种接口，包括：∙GPIO∙I2C∙I2S∙UART∙SDIO∙USB即将提供：关于Intel Sharks Cove 板的其他信息。

获取硬件开发板即将提供：关于如何获取Windows 兼容硬件开发板的信息。

如果你有兴趣了解更多信息，并希望获得有关硬件开发板可用性的通知，请向HardwareDevBoard@发送电子邮件。