Porting DDHAL from the Desktop (Windows CE 5.0)
This topic and its subtopics discuss what is necessary to convert a DDHAL implementation for a Windows-based desktop platform into a DDHAL implementation for a Windows-CE based platform. While the conversion to a device driver that is not derived from the DirectDraw Graphics Primitive Engine (DDGPE) is not specifically discussed, the topics referenced here will still be of use to developers who decided to ignore DDGPE.
Before you start porting any DDHAL display driver from a desktop implementation, you should already have a working DDGPE-based driver. To create a driver that you can modify with the code in your Desktop DDHAL, follow the steps outlined in DirectDraw Display Driver Creation.
32-Bit vs. 16-Bit
Windows CE is a purely 32-bit environment. This means that its DirectDraw implementation is not compatible with the 16-bit mechanism offered by the desktop implementation of DDHAL. Any callbacks that were implemented in 16 bits must be converted to 32 bits when moving to the Windows CE implementation of DDHAL.
Initialization of the DDHAL
The process of initialization of the DDHAL has changed slightly from the desktop specification. Unlike the DriverInit entry point in the desktop implementation, the main initialization point for the Windows CE–based DDHAL is HALInit.
- HalInit
The display driver exports HALInit. It is implemented in the DDGPE interface so you can simply export it from your driver. - buildDDHALInfo
HALInit calls buildDDHALInfo with the appropriate parameters.
You should be able to convert your 32-bit buildDDHALInfo, or buildDDHALInfo32, function. When transferring this function from your Desktop DDHAL implementation, keep in mind that the parameter list has changed slightly. The following code sample shows the buildDDHALInfo function prototype.
EXTERN_C BOOL buildDDHALInfo (
LPDDHALINFO lpddhi,
DWORD modeidx
);
Because there is no longer a DDHAL driver data structure associated with the device driver, your buildDDHALInfo function should be modified to use the DDHALINFO structure passed into it by HALInit. Also, your driver is now responsible for allocation of the callback structures. DDGPE expects all callback and capabilities data structures to be implemented as global variables. For more information, see the sample code or DDHAL Callbacks and Capabilities.
You will need to extend your buildDDHALInfo function to set up several global variables required by the DDGPE model. For examples and descriptions of these global variables, consult the sample code and Required Variables.
DDHAL Callbacks
Because your DDHAL implementation no longer supports buildDDHALInfo16, you can ignore all of your old 16-bit callbacks. If your implementation requires any of the 16-bit callbacks in order to operate properly, you will have to rewrite them and include them in your buildDDHALInfo function and callback structures.
You should be able to move your 32-bit callbacks into the DDGPE implementation by copying the source code and ensuring that the callback structures are initialized properly to identify your callbacks instead of the sample or stub callbacks that already exist.
You might need to make minor modifications when dealing with surfaces and memory allocation in your driver.
Surface and Memory Management
You need to decide what mechanism you will use for memory management. Ensure that your DirectDraw surfaces are tracked and disposed of properly and that video memory management in your DDHAL and in your DDGPE implementation are able to interact with each other to track memory usage. Initially, consider using functions that already exist in your DDGPE implementation to perform all your video memory and surface management driver-wide.
Send Feedback on this topic to the authors