Windows驱动开发一些基本概念.doc

Window驱动开发的一些基本概念 驱动对象，设备对象。DirverObject VS DeviceObject 网上一查，相关的资料一大堆，所有的资料都会说，一个驱动对象对应一个设备对象，一个设备对象对应一个驱动对象。这个说法过于笼统。首先来聊一聊驱动对象。 Windows内核编程借鉴了面向对象的思想，很多基本概念都是以对象Object的形式呈现。包括最重要的DRIVER_OBJECT和DEVICE_OBJECT。一个驱动程序，如果仅仅作为一个内核模块，实现特定的功能，不需要与上层应用程序通信，那么，它可以不要设备对象，不需要创建IoCreateDevice。实际上，设备对象存在的意义就在于，它可以接收内核消息，就像上层app中的窗口一样。如果你的程序运行于后台，那就不需要有窗口的存在。在内核里面，同样如此。 第二种情况，你可能并没有显式地IoCreateDevice，但你的派遣函数仍然可以收到来自某设备对象的irp。这种情况多见于过滤驱动。比如文件系统过滤等。绑定，就意味着被绑定设备对象的所有请求，都会优先发送到绑定的设备对象上。在某个驱动中，比如串口中，你绑定了某个串口，就是想实现对流经串口的数据的过滤，那么这个时候要注意了，你在你的派遣dispatch函数中，必须要做出决断，是允许数据通过，还是禁止通过，不做决断是不行的，不做决断意味着所有数据都被禁止。这也是为什么要编写派遣历程的原因。不过，判断设备对象是否是我们绑定的设备对象有点诡异，它直接是这样的:if(pDeviceObject == MyDeviceObject)。 驱动与应用交互的方式 三种。 METHORD_BUFFER //缓冲方式 METHORD_XX_DIRECT //直接方式 METHORD_NEITHER //都不是方式（有点别扭，没办法，英文原意就是这样） 我们自己编写应用程序与驱动交互时，可以选择上面三种任意一个，驱动收到控制码后，要对不同的I/O缓冲做不同的处理。三种方式分别对应的buffer获取方式： 对于输入缓冲区InputBuffer,如下表所示： METHORD_BUFFER Irp-AssociatedIrp.SystemBuffer METHORD_XX_DIRECT Irp-AssociatedIrp.SystemBuffer METHORD_NEITHER Irp-Parameters.DeviceIoControl.Type3InputBuffer 对于输出缓冲区OutputBuffer如下表所示： METHORD_BUFFER Irp-AssociatedIrp.SystemBuffer METHORD_XX_DIRECT Irp-MdlAddress METHORD_NEITHER Irp-UserBuffer 但如果不是自己编的应用程序，驱动还是要做出反应，那么可以利用寒江独钓一书50页上所说的： 实际使用中，InputBuffer的获取简单，不是systembuffer，就是type3inputbuffer。OutputBuffer稍微麻烦。不过实际上很少用到，用到的时候一般也是自定义的应用程序请求码。 文件过滤驱动sfilter 这个例子在wdk自带的src目录中有。看了一遍，有些心得，特此写出，以备忘记。码字真累啊。。。 该驱动目标是实现文件系统的实时监控。稍加改造，添加一些功能，能够实现禁止/允许用户对文件的读，写，打开，新建，重命名，文件重定向等。 过滤，形象地说，就是在固有的层面上再添加一层过滤网，让本来流经下面的东西先流到过滤网上，过滤网根据规则判断哪些需要过滤掉。就驱动来说，就是要attach，绑定。文件系统的绑定很麻烦，有两个过程，第一是绑定控制设备对象，第二是绑定文件系统卷设备。第一个过程主要是为了获得发送给文件系统控制设备的文件系统控制请求。IRP_MJ_FILE_SYSTEM_CONTROL。 LIST_ENTRY LIST_ENTRY是微软为内核开发者定义的一个双向链表指针。这个链表里面没有任何数据： typedef struct _LIST_ENTRY {? ?? ? struct _LIST_ENTRY *Flink; ? ?? ? struct _LIST_ENTRY *Blink; } LIST_ENTRY, *PLIST_ENTRY; 为了使用它，我们需要自己定义一个结构体类型，将LIST_ENTRY作为结构体的一个成员： typedef struct MyDataStructTag { ULONG data; LIST_ENTRY list; }MyDataStruct ,*PMyDataStruct; LIST_ENTRY的常见操作有：初始化、插入、弹出、