Porting Windows Applications to OS/2: Problems and Solutions

By Jeff English

Porting Windows application source code to native OS/2 code is doable! The process of analyzing, porting, compiling, and testing the code, as well as exploiting the OS/2 environment, may seem like an overwhelming task. That's why I wrote this article - to dispel the fears, to show that it can be done, and to discuss how One UP Corporation's porting tools can help.

Before discussing what is involved, it must be understood that there is no magic header file that will port your code automatically. While there are many similarities between Windows and OS/2, there are many more conceptual and architectural differences that make such a header file improbable.

The development of applications that can run on multiple platforms can be done, with a limited number of possibilities. Cross-platform API libraries and application frameworks (such as XVT and zApp) that enable you to develop for multiple platforms are really only useful for new development, and you become dependent upon the vendor for updates and support of other platforms.

Given that you already have a Windows application that must be ported, another option is the Mirrors tool kit. The Mirrors tool kit provides a layer that implements the Windows functionality either internally or via multiple calls to OS/2. While the Mirrors tool kit was designed as a tactical solution for quickly migrating an application to OS/2, it is not intended as a long-term strategic solution.

The only other solution is to port your existing Windows application to native OS/2 code. Doing so not only allows you to convert to a true 32-bit application, but allows you to exploit the 32-bit memory management, pre-emptive multitasking, and multithreading capabilities of OS/2. The result is an application that is faster and better integrated than any of the other possible approaches. Getting there, however, is not necessarily an easy task.

The Porting Process

Porting existing code is a much more difficult process than writing a new application from scratch. Unless you wrote the code being ported - which usually isn't the case - you can't tell whether the code that you are modifying is correct until the entire application has been ported and compiled. There is not the immediate feedback of windows being created, manipulated, and drawn upon that is available when a new application is developed.

The process of porting Windows applications to OS/2 can best be described as a non-linear process. The methodology and techniques applied to the porting process have a greater impact when several passes are made on the code. Each pass, or phase, attacks more complex problems than the previous pass.

Figure 1 illustrates the recommended flow of porting activity, where each block represents a separate pass on the source code. During the analysis phase, and all the way through the platform-specific phase, specific items and characteristics of the application are identified to better tailor the porting activity.

<insert>

Figure 1. Recommended Flow of Porting Activity

Analysis

During the analysis phase, the entire application's source code is scanned for Windows keywords. This analysis provides a quantified look at the code, and gives the necessary information to size, staff appropriately, and schedule the porting activity.

A detailed analysis involves classifying all of the functions, messages, typedefs, and symbols into various categories of difficulty, from easiest to hardest. The easiest ones are those that have a one-to-one correlation in OS/2; the hardest ones are those that have no equivalent definition in OS/2 (e.g., DDEML).

There are approximately 4,700 points of difference between Windows and OS/2. A point of difference is defined to be a function, message, typedef, or symbol that is defined in one of the Windows header files, and must be converted when used in OS/2. The difficulty of each item is classified in one of six categories, as shown in Figure 2.

<insert>

Figure 2. Six Conversion Categories

During this phase, the code is also scanned for items that may cause difficulty in porting from 16-bit to 32-bit code. For example, structures that contain "int" data types and send output to a file should be changed to a "short" data type if file compatibility is a concern.

Code Replacement

The code-replacement phase uses automated tools to quickly convert all category 010 and most category 020 items. The automated replacement of these items eliminates the very time-consuming process of manually changing each and every one of these items. As shown later, about 74 percent of all keywords that are identified for porting are in category 020 or less.

Another very time-consuming process is the conversion of resource files (e.g., dialogs and menus). The amount of time and difficulty will depend upon the number of dialogs and other resource types that must be converted. During this phase, the resource files should be automatically converted to OS/2 resource files.

API Macros / Functions

Many Windows functions are classified as categories 020 or 030, and they occur several hundred times in the source code. If any of these functions performs an immediate action (e.g., GlobalAlloc) and doesn't rely on the state of other parameters or objects (e.g., SelectObject), it may be desirable to simply implement many such functions internally. This provides the immediate benefit of not having to modify every occurrence and to duplicate multiple OS/2 function calls. It also provides the longer-term benefit of making it easier to debug and modify the changes.

Code-Assist Replacement

Many changes that are identified as category 030 or 040 are similar in nature throughout a specific application. In many cases, the change that is made for one occurrence of a keyword can be applied to several other occurrences of the same keyword. A tool that provides the capability to note the way in which a change is made to one item, and can replay the same sequence to another occurrence of the same item, is useful at this point. Other types of changes can be made easier by having a tool that can provide a list of selections, information about required parameters, or templates for the ported code.

Unsupported Features

There will most likely be some features of the Windows environment that are not directly supported in OS/2. These category 050 items must be resolved by the programmer, by either removing the functionality altogether, or implementing an alternate strategy to perform a similar function.

Platform-Specific Features

The addition of features specific to OS/2 usually occurs after the application is ported and running. It is not recommended to attempt to add multithreading or Workplace Shell capabilities while the code is partially ported and in an unstable state. However, when an area for adding these capabilities has been identified, you may want to tag certain portions of the code as it is being ported. During this later stage of the port, you can add OS/2-specific features to make it a more marketable or a more tightly integrated product. You should try to add platform-specific code in a separate module or DLL.

Factors Affecting the Porting Process

Many factors affect the difficulty of porting code from Windows to OS/2. They include: the complexity of the code; "cleanliness" of the code; how much and to what extent the Windows environment was exploited; the use of third-party libraries; the abstractness of the design; the tools being used; and the experience level of the programmers doing the port.

Most Windows applications have evolved over several years, and have been worked on by programmers with various levels of experience. The result is usually an application with many blocks of code that have similar functionality but use a completely different set of API calls. While programming standards may be in place now, the standards most likely have changed over the years, and the strictness to which programmers stick to those standards, is questionable at times.

Many Windows applications also get away with using memory and object handles after they have been released. This will cause a problem when the code is ported to the protected-memory environment of OS/2. A good guide for helping to identify such a problem is to run your application using the debug version of Windows.

The use of third-party libraries in an application makes it extremely difficult to port your application to OS/2 or any other platform. The future portability of the application depends upon the owner of the library providing a version for each platform.

If there is one item that I would recommend when designing an application, it would be to try to use abstract design techniques. Whenever a system level, third-party library, or operating system-dependent function is required, it should be given a functional name and placed into either a separate source file or library. For example, instead of calling GlobalAlloc every time that memory is allocated, create a function called AllocateMemory. This will centralize the porting activity to the single function, and will enable the main logic of the application to remain mostly intact during the porting process.

Ultimately, the success and amount of time it takes to complete a Windows-to-OS/2 port comes down to the experience level of the programmers and the tools used in porting the code. Ideally, you would want programmers who have a wide range of experience in both Windows and OS/2. Given that there are a limited number of programmers with this kind of experience, it is better to have a programmer with more experience in OS/2 than in Windows.

Porting Tools

Tools that assist the programmer in modifying the code and suggesting possible changes can speed up the porting process. The proper tools can, to some extent, reduce the need for experts on both the Windows and OS/2 platforms.

The Source Migration And Reporting Tool (SMART), developed by One UP Corporation, has been used to analyze several large Windows applications. In addition to reporting the number of points of difference (hits), the tool also reports the relative difficulty of porting an application. Obviously, category 020 items require more effort than category 010; category 030, more effort than category 020; and so on. The average of all the data collected leads to a general observation about the distribution of the category of items, and where the effort must be spent in porting an application.

Figure 3 shows a graph of the frequency of occurrence of each category of items found, and the distribution of the effort involved in porting each category. The accompanying data for the graph is shown in Figure 4. For example, 26.5 percent of all hits are category 020 items, but this amounts to only 17.7 percent of the effort.

<insert>

Figure 3. Occurrence of Each Category and the Porting Effort Involved

<insert>

Figure 4. Occurrence of Each Category and the Porting Effort Involved

All category 010 items and most category 020 items can be ported with an intelligent global search-and-replace utility. While this resolves 73.3 percent of all items to be ported, it would only complete 17.7 percent of the required work effort. For the remaining 82.3 percent of the work effort, a set of tools is needed to identify the items to port, recommend the appropriate OS/2 code to replace the Windows code, and allow you to hyperlink among all occurrences of an item.

SMART can be used to migrate source code by inserting templates, code samples, prototypes, and comments whenever a Windows point of difference is encountered. Using a hyperlink editor, such as SourceLink, a programmer makes multiple passes on the source code, first attacking the category 020 items, then category 030 items, and so on. In the very near future, SMART will have added intelligence to perform the code-assist replacement functionality of the porting process.

In addition to porting source code, SMART also includes a utility for converting Windows resource files to OS/2 resource files in native format, and for converting Windows icons and cursors to OS/2 icons and cursors. OS/2 currently recognizes many of the Windows bitmap formats. However, if you have a bitmap that is not recognized by OS/2, there are several bitmap conversion utilities available, including the OS/2 Multimedia Image Converter.

Windows-to-OS/2 Implementation Issues

As mentioned earlier, there are approximately 4,700 points of difference between Windows and OS/2, and this number doesn't even cover the changes required for conversion from 16-bit to 32-bit code, or the use of third-party libraries. It is not appropriate to list all of these items here. However, there are a number of functional areas, found in most applications, that cause the most amount of difficulty and effort in the porting process. While many of these functional areas have what appear to be simple solutions, they can actually require either a lot of rework or redesign to integrate properly into the ported code. Here are some of these functional areas:

Resource files must be converted from Windows to OS/2 format.
Dialog units in Windows are calculated based on the font used in the dialog, while dialog units in OS/2 are calculated based on the default system proportional font.
Font names and selections must be converted to those available in OS/2.
Menus for dialogs must be defined at run-time, not in the resource file.
Icons, cursors, and bitmaps must be converted to an OS/2-recognized format.
Multiple Document Interface (MDI) must be implemented in the application.
The frame window, frame-control windows, and client windows are all separate windows in OS/2. Subclassing must be performed in OS/2 to monitor and process non-client window activity.
Windows brushes and pens must be converted to area- and line-bundle attributes. Different OS/2 functions are used for drawing filled and non-filled objects, as well for as drawing a nominal-width line versus a wide line.
APIs for drawing an arc, chord, pie, etc. require several function calls in OS/2.
The OS/2 coordinate system has lower-left origin, versus Windows' upper-left origin. All coordinate calculations for positioning windows and drawing must be converted to be relative to the lower-left corner. If window positions are to remain relative to the upper-left corner when a parent window is resized, code must be added to reposition child windows.
The CS_CLASSDC class style is not supported in OS/2.
Regions are bottom-right-exclusive in Windows, but top-right-exclusive in OS/2.
The bits for monochrome bitmaps in OS/2 are reverse from those of Windows.
Windows metafiles must be converted to OS/2 metafiles. Metafile enumeration is not directly supported in OS/2.
Applications have less direct control over printing properties in OS/2. Applications should use the job properties dialog to allow users to modify the printing characteristics.
Support of tab stops in a listbox is not available in OS/2. Columns are supported in OS/2 by using the container class.
Cursors are not registered with a window class in OS/2. Setting the pointer in OS/2 is performed during the WM_CONTROLPTR or WM_MOUSEMOVE message.
Background brushes are not registered with a window class in OS/2. A background-fill color can be set by setting a presentation parameter for the window.
Control activity messages are received in a WM_CONTROL message instead of the WM_COMMAND message.
Processes must explicitly gain access to shared memory, and all processes having access to shared memory must free it before the memory is freed. This differs from Windows, where the shared memory is freed when the creator of the memory frees it.
Memory and window classes allocated and registered by a DLL are not available to other processes. In Windows, the ownership of window classes and memory objects is based on the code-segment that registered the class or allocated the memory. In OS/2, all resources, classes, and memory objects are owned by the process that allocated or registered them.
OLE is not supported in OS/2.
There is not a color or print common dialog in OS/2. The options available for the font and file common dialog differ from Windows.

Simplify and Expedite Porting with SMART

Porting of source code from Windows to OS/2 is not an easy process. There are always architectural components of the Windows environment that are used by an application and require a programmer to decide the direction of the implementation in OS/2.

Designing an application with portability in mind means abstracting the design to the point that system-dependent and third-party library functions are kept separate from the integral logic of the application. Simplifying and expediting the porting process is possible, and in fact being done today, with tools like SMART.