Graphics Driver 的编写
在Windows操作系统中，图形的绘制由一个三层结构来实现，最上层是应用程序，用户通过调用图形API函数在屏幕上绘制千变万化的图形，在编写程序的过程中，用户完全可以忽略显示硬件之间的区别，只要按照API的调用约定，就能使同一段程序在不同的硬件上产生同样的效果。而API函数与硬件实际操作之间的协调则是由位于中层的GDI32.dll来完成。中间层一般被称为GDI层，是Windows操作系统的一部分，它向上提供一套硬件无关的API与应用程序套接，向下定义一个标准的显示驱动程序接口，与硬件Graphics Driver套接。通过调用Graphics Driver的绘图函数，实现图形API。而Graphics Driver位于这个三层结构的最底层，为绘图操作提供最终的实现，为了使得GDI层能够成功的调用Graphics Driver，使之执行所需的操作，二者之间存在一个被调用函数的列表，这个列表一般被称为DDI(Display Driver Interface)。在DDI中定义了若干必须的图形基本操作，要使得一个硬件在Windows下工作正常，硬件驱动程序必须实现DDI中的所有函数。
用户程序、GDI、Graphics Driver之间的关系如下图所示：
如上图所示，Graphics Driver不仅处于被调用者的地位，同时还可以向上调用一些GDI提供的服务函数。下面我们详细讨论Graphics Driver与GDI之间交互的细节问题。
上面已经阐明，Graphics Driver必须完成DDI定义的所有函数，因而，编写Graphics Driver的过程就是实现DDI的过程，只要对照DDI函数表一一实现即可。然而，GDI层究竟如何调用不同厂商的显示驱动程序呢？我们知道，一段程序要想调用一个函数，只要知道该函数的名称、返回值与参数表。在这三个要素中，函数名称事实上是指向函数入口地址的常指针，它可以用函数指针来替代；这样在特殊情况下，只要拥有函数的入口指针，参数表和返回值定义，就可以调用一个函数。
Windows GDI层正是要求显示驱动程序将实现DDI的各个函数指针上传，从而通过这些指针来调用DDI函数。注意，显示驱动程序的各个函数名称可以任意，而参数表和返回值定义必须遵循DDI定义，否则GDI层不可能正确调用DDI函数。——这一点是很自然的。正如你的程序使用与函数声明不一致的参数调用一个函数，失败在所难免。
那么，驱动程序通过什么途径将DDI函数指针上传呢？答案是DrvEnableDriver，这个函数是专门为此功能而存在的。GDI在初始化时会明确调用（指出函数名称而不是使用函数指针）这个函数，并传递一个地址表。DrvEnableDriver是显示驱动程序的一部分，显示驱动程序必须在这个函数中填充地址表，并返回操作成功标志。这样所有DDI函数的入口地址均上传至Windows。以后，GDI将可以正常的调用Driver绘制图形，当然，前提是上传的地址必须是真实有效的。
总之，一个Graphics Driver的编写过程就是一个对DDI的实现过程，我们只要编写出所有DDI函数，并且在DrvEnableDriver中将DDI函数地址上传，就可以完成一个Graphics Driver。可以在遵循参数表和返回值定义的前提下，任意命名我们的DDI函数，甚至可以将类成员函数上传——这就引出使用GPE编写Graphics Driver的问题。
关于Graphics Driver的其他问题，请参见MSDN->DDK->Windows CE DDK->Windows CE Driver Development->Display driver
关于DDI定义，请参见NT4.0 DDK Document->Graphics Driver->Design Guide->Part 1 : Graphics Drivers->Chapter 3 : Support DDI->Graphics Driver Function Support
好了，最后提出一个问题：为什么Windows要明确调用DrvEnableDriver而不是使用函数指针呢？希望大家思考。
