基于PassThru的NDIS中间层驱动程序扩展

概要：开发一个NDIS驱动是一项相对复杂的工作，这一方面是由于核心驱动本身有更多的限制和要求，有更多的“游戏规则”要求开发者理解和掌握，NDIS 的复杂性把难度更是提高了，本文以PassThru为例，加上自己的理解，讲述了NDIS驱动的处理过程和在PassThru的基础上进行扩展的基本方法，本文并不是一个入门读物，所以没有提及任何核心驱动开发的相关知识，本文主要讲述的是NDIS中间层对数据包处理的流程。在阅读过程中，关于相关 API的用法，或其它信息，请参看DDK文档。

一  NDIS驱动程序分类.
    NDIS(Network Driver Interface Specification)是Windows网络驱动程序接口标准，NDIS驱动程序分为三类：
1. NDIS Miniport NIC Driver: 底层的微端口NIC驱动，这就是网络设备的物理的驱动程序了。
2. NDIS Protocol Driver: 高层的协议驱动，用来实现某个具体的协议栈，如TCP/IP协议栈，
   并向上导出TDI接口。
3. NDIS Intermediate Driver: 中间层驱动，位于Miniport Driver和Protocol Driver之间。

二  NDIS驱动结构简介.
              
    其中，最上层是一个NDIS Protocol Driver，它向上提供一个Transport Driver Interface(TDI)，向下通过NDIS接口与下面的NDIS中间层的上边界交互，NDIS中间层的下边界通过NDIS接口与下层的NDIS Miniport Driver交互。最后，由NDIS Miniport Driver利用NDIS接口与物理网络设备NetCard交互。NetCard是由不同的网卡设备产商提供的，而NDIS接口库是由Microsoft 开发好的，为什么NDIS Miniport Driver不是直接与物理网卡交互，而是通过NDIS接口与下物理网卡交互呢？(我想很多人都会和我当初一样，有这个疑问)。
    事实上，这是由于Windows系统为了提高可移植性，而设计出一个硬件抽象层(HAL)，硬件抽象层在内部处理不同的硬件之间的差异，并且暴露出一个统一的接口给核心驱动开发者。例如：在Intel构架的系统中，内存和外部设备的端口采用分别编址，如果要从某个外部设备的端口上读写数据的话，可能要通过专用指令IN/OUT读写，而在Alpha构架的系统上，采用的是统一编址的方式，所以对外部设备的IO端口进行读写的话还是通过访问内存的指令，HAL提供一组服务支持函数，如果要访问外部设备上的端口数据可以使用READ_PORT_UCHAR/WRITE_PORT_UCHAR等等，核心驱动开发者不用去考虑不同硬件构架的之间的差异。在NDIS Miniport Driver中，NetCard驱动的程序，正是这样通过NDIS接口提供的一组类似功能的函数，与物理的网络设备进行交互。其中，最上层是一个NDIS Protocol Driver，它向上提供一个Transport Driver Interface(TDI)，向下通过NDIS接口与下面的NDIS中间层的上边界交互，NDIS中间层的下边界通过NDIS接口与下层的NDIS Miniport Driver交互。最后，由NDIS Miniport Driver利用NDIS接口与物理网络设备NetCard交互。