1 / 9

Porting XCTL from Borland C++ to Visual C++

Understand the porting process, resolve differences between Borland and Visual C++, efficiently compile code, resolve errors, and adapt UI elements and resource descriptions. Learn about architectural variances and address runtime behavior disparities.

bradfordc
Download Presentation

Porting XCTL from Borland C++ to Visual C++

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  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. 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

  4. XCLT Architecture: Windows API View • Classes for wrapping Windows API (Object Windows Library not used)

  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(RIGHT),TRUE); and GetBarEdge has side effect

  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. 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. 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. 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.

More Related