Graphics Driver writing
In the Windows operating system, the drawing of graphics is implemented by a three-layer structure. The uppermost layer is an application. The user draws the graphic graphics on the screen by calling the graphic API function. During the writing program, the user can ignore the display hardware. Differences, as long as the API calls agree, the same segment can produce the same effect on different hardware. The coordination between API functions and hardware actual operations is done by GDI32.dll located in the middle. The intermediate layer is generally referred to as a GDI layer, which is part of the Windows operating system. It provides a set of hardware-independent APIs and the application socket, defines a standard display driver interface, and is set to hardware Graphics Driver. Implement the graphics API by calling the drawing function of Graphics Driver. The Graphics Driver is located at the bottom of this three-layer structure, providing the final implementation for drawing operations, in order to make the GDI layer can successfully call Graphics Driver, make the required operation, there is a list of called functions between the two This list is generally referred to as DDI (Display Driver Interface). The basic operation of several must-have graphics is defined in DDI, so that a hardware works fine under Windows, the hardware driver must implement all functions in the DDI.
The relationship between the user program, GDI, and Graphics Driver is shown in the following figure:
As shown in the figure above, Graphics Driver is not only in the status of the caller, but also calls some of the service functions provided by GDI. Below we discuss details of the interaction between Graphics Driver and GDI.
The above has been clarified that Graphics Driver must complete all functions defined by DDI, and thus the process of writing Graphics Driver is the process of implementing DDI, as long as the DDI function table is implemented one by one. However, how do GDI layers call different manufacturers' display drivers? We know, if a program wants to call a function, just know the name of the function, return the value and the parameter table. In these three elements, the function name is actually a normally pointer to the function entry address, which can be replaced with a function pointer; so in special cases, as long as the entry pointer, parameter table and return value are defined, it can be Call a function.
The Windows GDI layer is to request the display driver to upload the various function pointers of the DDI to call the DDI function through these pointers. Note that the various function names of the display driver can be arbitrary, and the parameter table and return value definition must follow the DDI definition, otherwise the GDI layer cannot correctly call the DDI function correctly. - This is very natural. As your program uses a function that is inconsistent with the function declaration, it is inevitable.
So what way is the driver to upload the DDI function pointer? The answer is DRVENABLEDRIVER, which exists specifically for this function. GDI will explicitly call (point out the function name instead of using the function pointer) this function and pass an address table. DRVENABLEDRIVER is part of the display driver and the display driver must populate the address table in this function and return to the operation success mark. Thus all the entry addresses of all DDI functions are uploaded to Windows. In the future, GDI will be able to draw DRIVER normally, of course, the premise is that the uploaded address must be true and effective.
In summary, a Graphics Driver's writing process is a process of implementation of DDI, and we can complete a Graphics Driver as long as we write all DDI functions and upload DDI function addresses in DRVENABLEDRIVER. You can any naming our DDI functions under the premise of following the parameter table and the return value definition, even the class member function can be uploaded - this will lead to the problem of using GRAPHICS DRIVER using GPE. For other questions about Graphics Driver, see MSDN-> DDK-> Windows CE DDK-> Windows CE Driver Development-> Display Driver
For DDI definitions, see NT4.0 DDK Document-> Graphics Driver-> Design Guide-> Part 1: Graphics Drivers-> Chapter 3: Support DDI-> Graphics Driver Function Support
Ok, finally put forward a question: Why is Windows to clearly call the drvenableDriver instead of using a function pointer? I hope everyone thinks.
