2023年3月18日发(作者：检察官公主)用程序和操作系统本身是分开的： 操作系统代码运行在特权处 理器模式 （也称核心态） 并有权访问系统数据和硬件； ， 应用程序运行在非特权处理器模式 （也 称用户态） 。当用户态程序调用系统服务时，处理器捕获该调用，然后把调用的线程切换到核
x0c心态。当系统服务完成后，操作系统将线程描述表切换回用户态，允许调用者继续进行。 为防止用户应用程序访问或更改重要的操作系统数据，Windows NT 使用两种处理器访 问模式，用户态和核心态。用户应用程序代码在用户态下运行，OS 代码（如系统服务和驱动 程序）在核心态下运行。核心态是处理器的一种执行模式，它允许访问所有的系统内存和所陆小果
有的 CPU 指令。Windows 2000 操作系统中有两种基本的驱动程序：用户模式驱动程序和内核 模式驱动程序。USB 设备驱动程序使用内核模式，按照内核模式的分层结构，驱动程序分为 高层驱动、中间层驱动、底层驱动 3 个部分。底层的主机控制驱动程序直接作用于硬件，中 间层驱动处理包括总线类虾虎鱼
驱动和根集线器驱动，负责总线列举、电源管理等在内的 USB 事务 以及在根集线器相连的下游设备的初始化等任务。这些驱动程序的特权级别高于应用程序软 件。这样，处理器就为操作系统的设计者提供了一个必要的基础，保证了应用程序的不当行 为不会破坏系统的稳定性。 Windows NT 融合了分层操作系统和客户服务器或称为内核 OS 的特点。对性能影响很大 的 OS 组件在核心态下运行。在核心态下，组件可以和硬件交互，也可以在组件之间交互，并 且不会引起描述表切换和模式转换。例赵孟頫楷书
如，内存管理器、高速缓存管理器、对象及安全管理 器、网络协议、文件系统、所有线程和进程管理，都运行在核心态。当然，所有这些组件都 应该受到保护， 以避免被有错误代码的应用程序侵扰， 而应用程序不能直接访问 OS 特权部分 的代码和数据（尽管它们可以快速调用其它的内核服务） 。这种保护是使 Windows NT 成为既 坚固又稳定的应用程序服务器的原因之一。 WDM 驱动程序有一个主要的初始化入口点，即一个称为 DriverEntry 的例程；它有一个 标准的函数原型，当 WDM 驱动程序被装入时，内核调用 DriverEntry 例程。所有对各种 IRP 的处理例程都在此入口函数中做出定义。 大多数的 WDM 设备对象，都是在即插即用管理器调用 AddDevice 例程入口点被创建的。 插入新设备后，当系统找到由安装信息所指示的驱动程序时，这个例程调用在此之后，一系 列的即插即用 IRP 被发送到驱动程序，设备驱动程序可进行相应的功能处理。 3 USB 设备驱动程序的实现 USB 系统主要由
主控制器 （Host Controller） USB Hub 和 USB 外设 、 （Peripherals Node） 组成系统拓扑结构。在应用程序可以与一个 USB 设备通信之前，主机需要知道设备支持哪些 传输类型和终端，主机也必须分配一个地址给设备，主机通过一个被称为枚举的信息交换来 完成这些工作。枚举过程：集线器的一个任务就是检测设备的连接与断开，每个集线器都有 一个中断流程来通知主机报告这些事情。在儿童快板
系统启动的时候，主机查询它的根集线器来了解 有哪些设备已经连接上了，包括其他集线器和连接到这些集线器的设备。在启动后，主机持 续周期性地查询了解是否有设备连接或断开。 一旦发现一个新设备， 主机发送一系列的请求给这个设备的集线器， 使这个集线器在主 机和这个设备之间建立一个通信渠道。然后主机试图枚举这个设备，枚举是使得主机的设备 驱动程序能与这个设备通信的最基本的信息交换。这个过程由如下动作组成：分配一个地址 给设备，从设备读取描述数据，分配和载入一个设备驱动程序以及从接收到的数据中选择一 个配置。然后设备就被配置完毕，并且准备好使用它的配置中支持的任何终端来传输数据。 主机的枚举是通过给终端 0 发送包含标准 USB 请求的控制传输。所有的 USB 设备必须 支持控制传输、标准 USB 请求和终端 0。对一个成功的枚举来说，设备必须对每一个请求响 应并返回请求的信息。从用户的角度看，枚举应该是不可见和自动的，除了一些情况下如申 明发现一个新设备和是否成功配置这个新设备的窗口，有时在第一次使用时，用户需要提供 一个右 INF 文件和设备驱动程序的磁盘。 在一个 USB 的外设中， 外设的程序代码包含了主机将请求的信息， 并且程序代码必须能
x0c识别和响应这些信息的请求。在 Windows 不需要编写枚举的程序，因为 Windows 自动处理枚 举过程。Windows 将查找一个被称为 INF 文件的特殊文本文件，这个文件会告诉 Windows 哪 个驱动程序适合这个设梦到黑蛇
备。 4 USB 驱动实例 开发 WDM 驱动程序有两种方法， 一种利用微软提供的 98DDK 和 2000DDK 驱动程序开发包， 另外一种是专用驱动程序开发工具，如 Compuware Numega 公司的 Driverstudio， KRF，Tech 公司的 WinDriver。后者给出驱动程序的框架，并对 DDK 中操作进行封装，因此减少了开发 时问，提高了效率。DriverWorks 其实是对 DDK 函数进行了类的封装。因此用 C++语言开发 WDM，相对来说更加方便。笔者是自主开发 USB IP 核，例子中主要测试批传输的读入写出。 用 Driverworks 生成的驱动程序框架主要包含两个类，本设备驱动程序名为 Usbtran， 所以这两个类分别为 Usbtran 和 UsbtranDevice
。为了使读者对 Driverworks 生成的驱动程 序框架有更加清楚的了解，结合驱动程序原理和 DDK 的做法，先对其做一个剖析。 SPec 类继承 Kdriver， 在所有的驱动程序中， 都有一个初始化的函数入口 DriverEntry， 该函数完成驱动程序处理例程的登记，如读写、退出等。所有驱动程序的这一工作几乎雷同， 因此 DriverWorks 将其封装成一个类--Kdriver， 当然其中有设备的添加和管道的初始化。 本 驱动程序有三个管道，其中控制端点 0 无须初始化，因为它总能使用。Bulk 管道的初始化如 下： m_lize(m_Lower,0x81,64); m_Endpoint1OUT. Initialize(m_Lower,0x1,64); UsbtranDevice 类继承 KpnpDevice，而 KpnpDevice 是从 Kdevice 继承而来。Kdevice 主要是以设备为对象，对设备栈进行管理以及 Irp 经过该设备栈时进行一些相应的动作。而 UsbtranDevice 是在 KDevice 的基础上， 处理一些来自于 Pnp 管理器的消息以及 IO 管理器的 消息等。其主要处理的消息如下： virtual NTSTATUS OnStartDevice(KIrp I); virtual NTSTATUS O跑步的作用
nStopDevice(KIrp I); virtual NTSTATUS OnRemoveDevice(KIrp I); virtual NTSTATUS DefaultPnp(KIrp I); virtual NTSTATUS DefaultPower(KIrp I); virtual NTSTATUS OnDevicePowerUp(KIrp I); virtual NTSTATUS OnDeviceSleep(KIrp I); 每一个消息函数，Driverworks 都已经做好了框架，如果需要特别的处理，编程者 可以在其中加入代码。 UsbtranDevice 有几个特别的成员函数： KUsbLowerDevice m_Lower; KUsbInterface m_Interface; KUsbPipe m_Endpoint1In; KUsbPipe m_Endpoint1Out; 在本例的框架都由 driverstudio 自动添加，需要改动的 bulk 的读写部分的代码如下 t << "Entering SampleDevice::SerialRead, " << I << EOL; NTSTATUS status = STATUS_SUCCESS; PUCHAR pBuffer = (PUCHAR) edReadDest();//取得返回数据 BUFF 的指针 ULONG dwTotalSize = ze(CURRENT); // Requested read size char buff[512];
x0cint n =512, j = (n % 26); for (int i=0; i
