As mentioned in this month’s ‘Developing Trends’ we’re at an interesting crossroads as far as PC software development goes, with radically different processor architectures on the horizon and mainstream 64-bit development just around the corner. At the same time, Apple’s Macintosh platform has recently gained something of a popularity boost thanks to the release of Tiger (OS X 10.4) and the Mac Mini. If you want a quick synopsis, Tiger delivers much of the Longhorn promise here, now, and it works. ’Nuff said…

The bottom line is that things have never looked so tempting for developers keen to get into cross-platform development. If you don’t like the idea of being tied down to the Windows platform, then don’t be! Not only is there Mac OS X, but also Linux, and the prospect of developing software for hand-held devices such as smart phones, Palms, and so on.

Choosing a development language
When thinking about cross-platform programming, your choice of development language becomes a critical issue. If you’re thinking of porting twenty thousand lines of Object Pascal code (Delphi) across to the Mac, for example, you could have problems unless you go with something like the Free Pascal compiler. Similar considerations apply to C# where you’ll need the Mono project to help you out in a similar situation. The good news is that if you’ve never dipped a toe into the waters of Delphi or C#, but have stuck with plain old-fashioned Win32 C++ development, then you might actually be better off where cross-platform portability is concerned.

f the reasons for this is because of the all-pervasive nature of C++. Years ago, when C++ was making its first tentative steps out of Bell Labs, C++ compilers were very often written as a ‘front-end’ to an existing C compiler. In other words, the C++ front-end took the C++ source code and converted it into equivalent source which could be compiled by a plain-vanilla C compiler. It made sense to do things this way because virtually every significant platform already had a C compiler, and it eliminated the need to write a code generator and optimiser. The C++ front-end only had to worry about things at the source code level.

Nowadays, similar arguments apply to C++ itself. Whether you’re talking about Windows, the Mac, Linux, or whatever, there’s almost always a multitude of C++ compilers available, and some of them are often free. From this perspective C++ makes the ideal portable development language. In fact, you should think of it as the common language of the cross-platform world.

Why go cross-platform?
There are more reasons for going cross-platform than simply boredom with Windows! Some of these considerations are unashamedly financial. It’s often been said that it’s better to be a small fish in a small sea than a big fish in a large sea. In fact, if the sea is small enough, you might actually find that you’ve been promoted to a medium-sized fish, relatively speaking!

To put this in concrete terms, take the issue of shareware. You might be a small one-man programming outfit creating shareware utilities for Windows. After some years of hard graft, you’ve realised that the Windows software marketplace is over-saturated and that it’s very difficult to make your product stand out from the crowd. You don’t have the time or the energy to go back to square one, but porting your existing code to (for example) the Mac is tempting, not least because there’s no similar utility currently available for that platform. You’ve also noticed that Mac users tend to be an enthusiastic bunch, and that once some new application hits the scene, word gets around very quickly. OK, you’re probably not going to end up with Bill Gates’ bank balance, but I hope you get my drift …

So let’s assume that you’ve got lots of existing C++ code, written specifically for the barefoot Win32 API. Even as it stands, you might have some success in getting your application to work with WINE. Wine is an open source, portable class library (written in C++, natch) which implements many of the most common Win32 API routines, mapping these calls down on to the equivalent native calls. Wine actually loads a standard Windows executable and provides a Win32 compatible execution environment for it. From the program’s perspective, it’s just running under Windows as normal.

The downside of this approach is that, a) your application might make unusual Win32 calls that aren’t implemented in WINE, and b) because of the way in which WINE directly runs the Windows executable, it should be clear that WINE only runs on x86 platforms. There is no emulation of the processor instruction set in the way that you’d get with something like VirtualPC for the Mac, an x86 emulator which lets you run Windows XP on the PowerPC.

Nevertheless, WINE implements a surprisingly large subset of the Win32 API and is getting better all the time.

The accompanying screenshot on the left shows Internet Explorer and PowerPoint running on a Linux host. (You might wonder why anyone would seriously want to run Internet Explorer under a Linux platform, but let’s not get drawn into that argument).

C++ portability toolkits: what’s available?
If WINE isn’t your particular tipple, take a look at some of the other C++ portability toolkits that are available – there should be one there to suit your needs. One of the most admired is Qt, a C++ class library developed by the Norwegian company Trolltech, found here. Qt is a very full-featured library and allows applications to run natively on Windows, Mac OS X and X11 (including assorted flavours of Linux and UNIX). Qt has become so popular that it’s been used by Adobe to port parts of their Photoshop Album to other platforms, and was used by Skype to port their telephony software to other platforms.

If you know much about Linux at all, you’ll know that the KDE Linux desktop (which is loosely equivalent to Windows Explorer, but is also responsible for the visual look and feel of the system) has actually been written in C++ using Qt as the underlying foundation.

This raises the interesting possibility of porting KDE to OS X. It turns out that this has already been done, at least to some extent: see here.

Of course, there’s no such thing as a free lunch: the Qt class library isn’t cheap. The exact price depends on what package you go for and the number of platforms you want to support, but a typical configuration might be ¤3,430 for a duo-platform Enterprise licence; that’s around £2,300 in real money. Arguably, Qt represents a very cost-effective approach to cross-platform development and you only have to browse the list of impressive screenshots at the Trolltech website to see what can be achieved. However, it’s still a lot of dosh for a small developer to stump up.

Another approach is wxWidgets, a respected open source library that you’ll find here. Borland watchers will know that the Scott’s Valley company had a brief fling with wxWidgets which ended acrimoniously. This didn’t come as any great surprise to the folks at Trolltech who had been previously spurned by the same capricious lover.

wxWidgets has actually been around for 12 years according to the website. It was originally called wxWindows, but Microsoft didn’t like that. (One wonders how long it’ll be before we have to refer to those rectangular panes of glass in our homes by some other name – ‘widgets’, perhaps?) Anyway, like Qt, wxWidgets is a C++ class library with a very impressive pedigree. Unlike Qt, it’s completely free. wxWidgets runs on various flavours of Windows, going all the way back to that primordial slime otherwise knows as Windows 3.1. It also runs on Linux, UNIX (via Motif) and, of course, Mac OS X. The website also states that an OS/2 port is in progress – I’m not entirely sure why!

A wide range of different compilers are supported including (on the Windows side) assorted versions of Visual C++ going all the way back to version 1.5 which – if memory serves – was a 16-bit development system.

You can also compile wxWidgets programs with Borland C++ Builder, Borland C++, OpenWatcom, CodeWarrior and others. Next month, we’ll be using wxWidgets as the focus of our cross-platform development experimentation, and hopefully I’ll have settled on a specific compiler by then! One other thing that should be mentioned is wxDesigner. This is a very tasty-looking graphical application for laying out wxWidgets forms in a RAD-like manner. You can find wxDesigner at the author’s home page. This is actually a commercial application and will cost you from ¤29 (around £20 in real money) for the student licence, up to ¤129 (£88) for a single user licence, rising in price depending on your situation. I think this is a very reasonable price and certainly makes life a lot easier when designing wxWidgets forms. More on all this next time.

There’s actually another visual designer utility for wxWidgets called wxWorkshop. This is free software complete with source code. However, wxWorkshop appears to be defunct, or at least on life support, because according to SourceForge nothing much has happened for the past three years. From where I’m sitting, wxDesigner looks like the better bet for most people’s purposes.