Porting MFC GUI to XWindow
by Juan Ramón Acosta
March 20th, 1996
In today's competitive software industry supporting multiple platforms is more than simply having an application on several platforms. The application must contain the whiz-bang functions our customers are demanding, and it must also have the sophisticated GUI they expect. Like it or not, Microsoft Windows 3.x is the leading desktop operating system. With Windows 95 selling one million copies a week, it will soon be the leading desktop operating system. In the UNIX world, CDE (common desktop environment) has given UNIX developers a new level of standardized ‘look and feel’ and consistency for application developers to build on.
Microsoft created Visual C++ and the Microsoft Foundation Class (MFC) library to ease implementation of applications that will run on either of its leading operating systems: Microsoft Windows 95 or Microsoft Windows NT. MFC is a C++ application framework supported by the four major Windows C++ compiler vendors: Microsoft, Borland, Symantec and Powersoft-Watcom.
Almost all new Windows 95 applications have the same general look. If closely viewed, there will always be differences in menu items, tools on the toolbar, fields in the status bar, and the contents of the document windows. In addition to the documented requirements an application is expected to contain the following components:
- A dragable, dockable, customizable toolbar
- Tooltips for most UI items (toolbar items and dialog buttons), including one-line description in status bar
- Multiple documents and views using MDI and splitter windows
- Status bars with multiple fields appropriate to our application.
Now let's take a look at how these requirements and features map to UNIX. The gap between a Windows 95 logo-compliant application and an application created on UNIX using X/Motif toolkits has widened. While the GUI ‘look and feel’ between Motif and Windows 95 is similar (e.g. right down to the mouse button to use to select a menu) the richness of the GUI in Windows 95 MFC applications tends to exceed standard Motif applications. Also, it is necessary to have separate source-code streams when using Win32/MFC on Windows and X/Motif on UNIX. The cost of maintaining separate source-code and the project itself is prohibitive . What could be done is, to use add-on applications such as development environments or libraries for one or both platforms. There are two basic add-on library choices: libraries with proprietary APIs and those with ported APIs. Proprietary APIs are APIs created by a single company that are layered on top of Win32 and Motif, e.g., XVT or Intersolv Views++, or emulated on the various platforms using low-level APIs e.g., Visix Galaxy or Neuron Data.
None of the proprietary APIs allows to create Windows 95 logo-compliant applications from a single source code stream, since they do not support OLE and the most common controls. Ported APIs are APIs that are defacto standards on one platform, but are available on the other platform e.g., Bristol Technology Wind/U (Win32 API on UNIX), UNO Software WM_MOTIF (Win16 and Win32 on UNIX) and Datafocus NuT Cracker (X and Motif on Windows). We can not create a Windows 95 logo-compliant application using NuT Cracker or WM_MOTIF, since X/Motif does not support common controls, most common dialogs and OLE. Thus, using the Win32 API and MFC, one can create a Windows 95 logo-compliant application with no add-on software required. The same source-code can be used to create a native X/Motif with very rich functionality that includes OLE and common controls if it decides to use an enabiling technology like Bristol Technology products. Since Wind/U 3.1, it has been included full support for Microsoft’s object technology, OLE, support for MFC library 4.1, Rich Edit Control, support for new versions of IBM’s AIX 4.1 and HP-UX 10 operating systems. Among the OLE 2.0 features supported by Wind/U are: Object Linking and embedding, Component Object Model (COM) Visual Editing, OLE Automation, OLE Custom Controls (OCX) and OLE Drag-and-Drop.
While choosing a good cross-platform framework is not a complete solution, it is the majority of the solution. The developer must also write portable code and test the application on every platform. Here are some guidelines for writing portable code:
Let the APIs and Framework do most of the work. Win32 and MFC have thousands of entry points.
Never Assume:
- Byte ordering
- Structure of the stack, heap, memory
- Internal structure layout
- Single-tasking operating system
- Case or format of a string or filename
- Undocumented functions are safe to use
Do Use:
- Typedefs - safer than native types
- Sizeof - never assume size
- Ifdefs - to isolate platform dependencies
- MFC!
- Safe subset of C++
Today there are a wide variety of companies using Bristol Technology’s Wind/U (MFC on UNIX). Many of these companies are familiar names, like Pure Software, Mercury Interactive, Informix and Sybase. Others like Cadence Design Systems and Powersoft have very complex applications and are leaders in their market segments. All of these companies have found that they can support multiple platforms with sophisticated GUI applications for their demanding customers with the Win32 API on UNIX.
|
