90 likes | 286 Views
Porting XCTL from Borland C++ to Visual C++. Dragan Boji ć University of Belgrade. The porting process. Understanding overall structure and locating standard windows API elements in code Message handlers Callback functions Entry and exit dll procedures Resolving differences:
E N D
Porting XCTL from Borland C++ to Visual C++ Dragan Bojić University of Belgrade
The porting process • Understanding overall structure and locating standard windows API elements in code • Message handlers • Callback functions • Entry and exit dll procedures • Resolving differences: • Between 16bit and 32bit Windows • Between Borland C++ and Visual C++ • Efficient method: compile, then resolve compile time errors • Resolving differences in resources (description of UI elements) • Resolving runtime errors (result of differences in compiler calling conventions, behavior of library functions, etc)
Understanding overall structure • Message flow in a typical Windows application Windows kernel Application window Windows carries out the request to destroy the application window Windows then sends a WM_DESTROY Message directly to The window function User selects “Exit” from application menu Application WM_DESTROY Window function WM_QUIT WinMain function Application message queue Message loop WM_QUIT Phrases to search for in program code After receiving WM_QUIT, Message loop and WinMain function terminate
XCLT Architecture: Windows API View • Classes for wrapping Windows API (Object Windows Library not used)
Resolving Win16-Win32 differences • Different dll entry and exit: • 16 bit: int FAR PASCAL LibMain(HINSTANCE hInstance,WORD,WORD wHeapSize,LPSTR){...} int CALLBACK WEP(int bSystemExit){...} • 32 bit: BOOL DllEntryPoint(HANDLE hModule,DWORD dwFunction,LPVOID){ switch (dwFunction){ case DLL_PROCESS_ATTACH:... case DLL_PROCESS_DETACH:... }.... • Different actual param evaluation order for some callback macros (WINAPI, CALLBACK functions). Risky scenario: e.g. SetScrollRange(BarHandle,SB_CTL,GetBarEgde(LEFT),GetBarEgde(RIGHT),TRUE); and GetBarEdge has side effect
Resolving Borland-Microsoft C++ differences • Categories of differences: • Preprocessor definitions: e.g. Standard library MAXDIR to _MAX_DIR • Declaration modifiers: e.g. _export to __declspec(dllexport) • Names of library functions (in some cases even .h file containg the function is different): e.g. fnsplit to _splitpath Completely different functions for computing elapsed time • Syntax differences: e.g. BC++ label: } is ok, VC++ label: ; } • Different warning levels: e.g. VC++ „trunctation from double to float“ for: float f = 1.0; // to eliminate warning, add f to the end of constant
Resolving resource differences • Resources: descriptions of user interface elements (dialogs, parts of dialogs: controls, menus,...) • Replacing Borland Custom Controls with standard ones • Borland dialogs and controls „subclassed“ standard ones (they have specific message handling procedures to alter appearance (respond to paint message) or some behavior. • Changing resource description: CONTROL "Belichtungsregelung", -1, "BorShade", BSS_RGROUP | BSS_CAPTION | BSS_CENTER | WS_CHILD | WS_VISIBLE, 119, 93, 101, 50 to GROUPBOX "Belichtungsregelung", -1, 119, 93, 101, 50 • Changing code: eliminating BWCCRegister function call (initialization of borland controls)
Resolving run time behavior differences • Address calculation in msim.dll code: 16bit model with segment: address, and 32bit model with flat address • Data sizes (16b-32b): unions risky • Elapsed time calculation
Unresolved issues • Use of inline assembly and direct access to hardware ports, for controlling devices • Could work on Windows 95, but not on newer windows. Their device driver model is much more complex.