1. Dragan Bojić University of Belgrade Porting XCTL from Borland C++ to Visual C++

2. Dragan Bojić, Porting XCTL from Borland C++ to Visual C++ 2 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)

3. Dragan Bojić, Porting XCTL from Borland C++ to Visual C++ 3 Understanding overall structure Windows carries out the request to destroy the application window Windows then sends a WM_DESTROY Message directly to The window function Message flow in a typical Windows application Windows kernel User selects “Exit” from application menu Application message queue Application WinMain function Message loop Window function Application window WM_DESTROY WM_QUIT After receiving WM_QUIT, Message loop and WinMain function terminate Phrases to search for in program code

4. Dragan Bojić, Porting XCTL from Borland C++ to Visual C++ 4 XCLT Architecture: Windows API View Classes for wrapping Windows API (Object Windows Library not used)

5. Dragan Bojić, Porting XCTL from Borland C++ to Visual C++ 5 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(RIG HT),TRUE); and GetBarEdge has side effect

6. Dragan Bojić, Porting XCTL from Borland C++ to Visual C++ 6 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

7. Dragan Bojić, Porting XCTL from Borland C++ to Visual C++ 7 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)

8. Dragan Bojić, Porting XCTL from Borland C++ to Visual C++ 8 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

9. Dragan Bojić, Porting XCTL from Borland C++ to Visual C++ 9 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.