There is also a Printer Friendly version of this page.

Being an OS/2 user these days is a bit tough. The general perception is that OS/2 is largely a dead operating system kept on life support by a few die-hard zealots. Of course we know that to be false as it is still a widely used operating system with millions of users worldwide, particularly in Europe, India and Asia. One of the side effects of its perception is that we have a fairly limited choice for many genres of modern, up to date software, especially in the arena of application development tools. This is so even in this day of explosive growth on the Open Source movement, as most of the work done there is for Linux and Windows or even MacOS with little regard towards OS/2.

Into this breach, jumps wxWindows. So what is it? wxWindows is simply the most full-featured, all-encompassing, cross platform, C++, GUI framework available today, either commercially or via the Open Source community. We've all seen a steady parade of these toolkits over the years, each one touting themselves as the latest and greatest and most feature rich and so on. They all seem to lack either a key feature, support for what seems like basic widgets like toolbars, statusbars, tree controls, etc. or only cover two or three desktop environments and/or compilers. Some apply to only Windows and Gtk on Linux, others for Windows and MAC and maybe OS/2, and yet others, like the venerable IOCL from IBM, Windows, Motif, and OS/2, but none seem to cover the whole list.

wxWindows has production quality libraries for Windows and Gtk. However, the MacOS port is nearly a production level release. wxMotif goes in fits and starts and then into hibernation. At times it is in a usable state and at times not. No one is currently actively working on Motif. Even Win16 is supported (although it has been some time since it was last tested.) There has been talk of a wxQT, but so far that's all it has been, talk. Most important to the OS/2 community, however, is that I am nearing a usable release of wxOS2.

A real value that separates wxWindows from most of the GUI toolkits out there is its support for just about every compiler environment known. If you have a compiler, chances are wxWindows supports it. I have developed the wxOS2 port using the old IBM workhorse, VisualAge for C++ V3.0, Fixpack 8. However, the library also builds under EMX and Watcom C++, but no one is actively testing those environments.

With all that said, there is one aspect with wxWindows that truly separates itself from toolkits like V and Fox, and that is: it implements everything as fully native widgets. The primary goal of wxWindows is build applications from a single source, compile them to the target platform, and the resultant application runs with the native look and feel of that platform. Windows apps look like a Windows app is supposed to look. The same application built under OS/2 looks like an OS/2 application and so on. Most other toolkits, particularly Java, give you a window that attempts to look the same across all supported platforms. This is not so with wxWindows.

There is a new development within the wxWindows community that breaks with that tradition, however. wxUniversal is a framework that draws its own widgets rather than relying on the native OS' widgets. It was designed to make porting to new environments much quicker, as writing a full port is a massive undertaking (I'm in my third year on wxOS2.) The first such port using it is wxX11, a more generic X11 kit for Unix, than ports like Gtk or Motif.

What exactly does wxWindows do? How is it put together?

The actual design of wxWindows borrowed heavily from Microsoft's MFC. At the base of everything is the wxObject class. This class encapsulates the data associated with a GUI widget or graphics object and provides for customized overloads of basic memory management functions. Another basic class is the wxClassInfo class, which allows for the dynamic creation of classes. At any given time, a derived class can determine its inheritance tree, whether or not it is a class of a particular type, via a simple, IsKindOf query using this class.

The main application class is the wxApp class. This class encapsulates the typical "main" procedure that is so familiar to OS/2 "C" developers. It creates all the basic components for a GUI app, such as an anchor block for OS/2, the message queue, provides for an application entry point, registers custom user classes, and then starts the message pump. In addition to that, it initializes a vast array of wxWindow global objects and widgets. Placing an IMPLEMENT_APP macro at the top of your main application module typically starts your application.

The wxWindow class is the basis for all windows, including all the frames, dialogs, controls and other GUI widgets. Most of the methods here are virtual, allowing for each derived class to implement basic window management functions their own way.

While it would be possible to give every widget in wxWindows its own custom window procedure, it would quickly become chaotic to try and communicate properly with all the GUI elements in a complex application this way. Thus we have the wxEvent class and all its derivatives. This class forms the basis of the event handling system. Classes can choose to handle certain events or allow them to be passed on. Classes choose the events they want to process by a series of Message Map macros both in the class headers and atop the implementation file for the class. These macros and many others have a "DECLARE" in the header, and an "IMPLEMENT" in the .cpp file.

The wxDC class and all its derivatives handle drawing to windows. This class is used to display text in client windows, draw lines, shapes, display bitmaps and many other graphics objects. wxWindows supports a full array of graphic image formats from TIFF, to GIF, to JPEG to BMP and others that may be unfamiliar to OS/2 developers like PCX, PNG, PNM, XPM, and XBM. Even the Amiga IFF format is supported.

The library takes a very conservative tactic with the use of C++. It does not use templates or ANSI stl as those are notoriously non-portable and in the case of many of the older compilers (like VisualAge 3.0), not even available. Instead the wxWindows team has implemented a vast array of template-like, and stl-like container classes via an extensive set of macros and special classes. In order to fully support Unicode, the library uses its own string and char classes, wxString and wxChar, and an associated set of macros like wxT that you will see in front of many strings in the source.

The library is divided into general code and port specific code. In the common area are wxWidgetBase classes like wxWindowBase. These are abstract base classes designed to document the public interface of the class. Some of the non-OS specific class methods are implemented at this level, but the bulk of the actual classes are implemented in the port-specific directories. This eliminates a lot of the conditional compilation code one sees in many other cross-platform toolkits. However, the port-specific code, especially for windows, is loaded with all sorts if #ifdefs to support the vast array of compilers. The wxUniversal and X11 ports have also added a lot of conditional compilation into the source. You should not have to concern yourself with much of this, unless you are a library maintainer.

You can also build DLLs or shared libraries under Windows, MacOS, OS/2 and Gtk. While most of the Windows compilers use a variant of EXPORT and IMPORT to build DLL's dynamically, wxOS2 with VisualAge still uses the module definition file approach.

Python is supported as well, although no one has bothered with an OS/2 binding yet.

The documentation takes the form of a class reference. It is pretty good for what it is, but it is a technical reference, not a how to. There are really no books on the library at all, and only a few rather lame efforts at a user's guides or FAQs on the web site.

The building of wxOS2 faced a lot of challenges for an OS/2 "gray beard" like myself. Often I had to do things in a very "OS/2-unlike" fashion. GUI toolkits are designed to be very generic and this required me to do things a bit differently than a typical OS/2 programmer would. One has to stay within the class framework and general style of the library yet still make things work, natively.

Four areas made coding wxOS2 particularly difficult. The first is that OS/2 carries separate handles for the Frame window and its client. Most messages are meant for the client but sometime you have to deal with the frame, itself. The wxFrame class was not really designed to work that way, it expects a single handle to deal with everything, so that was quite an exercise.

The next area that has created a massive amount of pain and suffering is that OS/2's coordinate system is backwards from every other GUI in wxWindows. Everything but OS/2 uses the TOP left as (0,0), not the bottom left. This factor had to be accounted for in all the window positioning and sizing code and in the wxDC classes for drawing as well. I was, however, able to isolate the code dealing with this pretty well.

Another area of major difficulty with OS/2 was in drawing and image processing using wxDC. OS/2 is the only GUI that segments a Device Context into a hardware driver communication layer and a software drawing layer. In OS/2 GPI the Device context is a hardware abstraction, usually associated with a display device or a printer. Drawing occurs to a Presentation Space and you associate a PS with a DC for things to actually happen. For all the other wx ports the concept of a Device Context is really both wrapped into one. The challenge was melding OS/2's GPI into wxWindows concept of what a DC is. Windows style bitmaps are up-side down in OS/2 as well.

And the final area that makes writing a GUI port so difficult is that OS/2 is becoming an outdated and relatively primitive GUI (long in the tooth like me.) It lacks a lot of the more complex native widgets that Windows, MacOS X and Gtk have. It has no Windows-like status bar, no native toolbar, no native tool tips, no native tree controls, splitter windows, gauges, progress bars, and so on. That means all these missing widgets had to be coded from scratch. However, with a toolkit like wxWindows, many of the latest and greatest GUI widgets are now available for use in OS/2 applications!

So what is the state of wxOS2 today and when can we see it?

What is left to do involves finishing some of the standard dialogs wxWindows ships with. Some of these are native to OS/2, some are already coded in the generic path of wxWindows. Many default widgets are available in wxWindows as generic code designed for GUIs that do not have them natively. Some of this generic code is unusable in OS/2, however, but a lot of it is. I still need to implement some of the more exotic controls like tree and list controls with full drag and drop, a notebook control and deal with printing. Also, while many of the features work, some are real kludges on my part and could use cleaning up by someone more familiar with these areas.

So what is the real target for wxWindows, what is its direction, and who would find it useful?

There are really four classes of toolkit users out there, from my perspective.

First, there is the large, mainstream business community and the major software houses that support that group. In terms of lines of code, this is still where most of the software written in the world today is created. These are the companies that still use large mainframes or minicomputers, or giant PC clusters, and run mission-critical system software to back financial applications like ATM reconciliation's, smart card and credit card processing, telephony and utility switches, and line-of-business software like corporate accounting, shipping and receiving, inventory control, human resources management, data warehousing, reservations, and so on. All these systems have interface requirements for systems management, basic data entry, and table maintenance. The interfaces are fairly simple and straightforward.

Another group is the vertical application development. This software is usually custom built to address a specific business need for a particular company or industry. These are applications like a genetic sequencing simulation app, a market analysis or risk management app for a grain or commodity merchant, or a shop floor data collection system for a chemical plant. The user interfaces here can be simple to complex.

Then there is the mass market, general use software. This is the office suite, an AutoCAD variant, the photo processing application, home accounting, and game software and such. This software is designed for broad base use by a wide range of people to carry out general purpose business chores and for entertainment. User interfaces can be very intricate and involved in this area.

The last area is the hobbyist and academians. These are developers who do things for fun or for purely educational purposes.

So where is wxWindows most applicable? Well it can obviously be used in all four areas, though it is best suited for the last two.

For the first group and much of the second group, wxWindows is overkill. You get a lot of excess baggage and the library is one, take it or leave it, blob. Much smaller, more limited toolkits like V and Fox would be better targets (but Fox doesn't support OS/2.) Add to that, these tend to be mission critical type applications and are the realm of commercial software vendors or large internal development teams, whose requirements center on stability, support, and maintainability, and not on exotic feature sets. They just need the basics, but those basics have to as solid as the backend, mission-critical components they are front-ending.

Unfortunately wxWindows greatest strengths are also its greatest weaknesses. First off, it is Open Source. This library has four or five core developers, dozens of contributors and an army of patch submitters. As such, it gets loads of support, ideas and great technical content, but as most Open Source projects tend to be, they all have different ideas, do not like adhering to standards, and the core group, afraid of driving off contributors, almost never say no to anything. In other words, it is not managed in a way mission critical software is managed. It tends to be bloated with seldom used features ala Microsoft Office and Windows itself, which of course means it is somewhat buggy, as it is virtually impossible for the core group to regression test anywhere close to 100% of such a huge thing after every significant change. Then you have the problem that while there are many dedicated people on the project, they are beholden to no one but themselves, no one is paying them a dime. That all combines to make it a risky venture to bet a hundred million or billion dollar enterprise on.

WxWindows is a very traditional, Open Source tool, and thus has all the benefits of that (the best being that it is free) but with all the warts generally associated with major Open Source efforts.

However wxWindows is great for the last two areas, so long as you don't mind using Open Source tools for your next great commercial, boxed software title. In fact, if you have an application that requires a very extensive GUI interface and/or it needs to ship on Windows, Mac and Linux, and don't mind the baggage, can live with a steep learning curve, then wxWindows may be about your ONLY choice, warts and all!

I have several months of work left, and then plan to move on to my next big project.

The Call for Help

The next step for wxWindows for me, is to fork the GPL components and revamp wxWindows to better target the first two software groups. I intend to break it apart into several components, each building on the one below. A rock solid, mission-critical caliber, core GUI kernel and then solid building blocks on top of that, with feature sets added via add on libraries or dll's. I also intend to manage that project much more like a for-profit, commercial project, rather than the typical Open Source methodology of moderated chaos.