posted by Anton Klotz on Mon 19th Feb 2007 17:52 UTC
IconAfter MacOSX and Linux start to become viable alternatives to Windows on the desktop, more and more applications are developed to be cross- platform; all potential users can run them on their platform of choice. In the following article I will discuss different ways of creating a cross-platform application and their (dis)advantages for the user.

The author's native language is not English, so please forgive any grammar and/or spelling mistakes

First I will explain my definition of a multi-OS platform. A platform is an environment which an application is using to communicate and interact with the system and with the user. GUI, IO, and multimedia libraries are a part of a platform. Kernel API is a part of a platform. Applications, which are running on the same platform, have mostly the same look and feel and share the same global settings, which the user can adjust in the common preferences, and are able to communicate with each other. Quite often the applications offer interfaces so the user can write scripts, which are connecting these interfaces into a new application (think AppleScript or AREXX on Amiga). UI techniques like copy/paste and drag/drop are working across the applications; not only for unformatted text, but also for complex objects. From the programmers' view a platform offers a consistent environment with one main programming language (usually the language which has been used for the creation of the shared libraries) and several supported languages with bindings.

About 10 years ago it was fair enough to make the equation that an operating system is a platform. MacOS, Windows, AmigaOS, BeOS, Atari TOS; all these operating systems offered their own unique platforms, their own environments. UNIX was a bit different though; while the combination of POSIX-compliant kernel, X11, and Motif was a very common platform, other variants were also possible. Nowadays an operating system can have several platforms: MacOSX has Classic, Carbon, and Cocoa; Linux has KDE, GNOME, and GnuStep (among lots of others); and Windows has .NET and MFC. They all can be considered as native, but a lot of effort has been done to enable interoperability between the platforms running on the same operating system. One example can be the standardization efforts from Freedesktop.org to enable interoperability between KDE and GNOME.

Now let's talk about Multi-OS. Usually if an application is supposed to run on several operation systems you call it multi-platform. This term is applicable to the above equation 'one OS = one platform'. However, since we want to talk about platforms running on multiple OSes, multi-platform platform sounds a bit silly; instead I prefer the term 'Multi-OS'.

Let's talk about Multi-OS application first. So a Multi-OS application still has to interact with the system and the user, but the difference is, that it must be adaptable to several environments (native platforms), so there must be a kind of translator between the application calls and the current environment. In case of Mozilla and Firefox it is the XUL-Toolkit, in case of OpenOffice.org it is VCL. These toolkits are mini-platforms. The question is how well do they coexist with the native platforms. The answer is: not very well. When the application is launched, the whole mini-platform must be launched as well, which takes time and resources. The communication with the rest of the system can only be good if a lot of integration works has been done. The situation might become even worse if several multi-platforms have to communicate with each other; this happens only through the native platform, so only the least smallest denominator is understood by all three participants. Since the mini-platform is highly optimized for one particular application, it is quite hard to take this platform as foundation for other applications, XUL is used for Sunbird and Thunderbird, VCL is foundation for some OpenOffice.org forks.

Other toolkits are more flexible, so a variety of Multi-OS applications can be written using them. Exmaples of this are wxWidgets and QT (and to some extent GTK, which is available on different OSes. However, it is really optimized only for UNIX/X11). Applications, which have been written based on these toolkits, share the look and feel of the native platform (more or less), but still they are not communicating between each other or the native platform, so their integration is suboptimal.

A different approach is to use a virtual machine. A VM is also a kind of translator, but the difference is that it tries to provide as many own libraries as possible, while not relying on the libraries provided by the native platform. This way, a large variety of different applications can be created, which are all running in a VM. Two main examples are the JAVA platform and Mono.

The problem with this approach is that these applications feel even more alien on a native platform, despite the fact that with the introduction of SWT and Java Swing versions the look and feel of Java programs resembles that of the native platform. However, the weak point is still that communication between different programs inside and outside of the VM is not sufficient and there is no easy way to use parts of JAVA program for interaction with a different application. There is no language like Visual Basic or AppleScript which glues parts of different JAVA-programs together (maybe Groovy can become such a language).

Another point is that there are simply not enough JAVA-programs where such combinations would make sense. A platform is only viable if it has a large ecosystem, which means that a lot of applications have been developed for this particular platform - only then all communication worries about drag/drop, copy/paste, and connections of different application parts are justified.

So now finally we are coming to the Multi-OS platforms. Multi-OS platforms might also have the same weaknesses as a VM has, but the difference is that there is so much software available for this platform, so interaction with the native platform might not be perfect, because most of the required tasks can be done using the applications written for this platform.

Let's take a look at one of such platforms. A few days ago IBM announced Lotus Expeditor, based on the Eclipse Rich Clients platform. Lotus Expeditor runs on Linux, MacOSX and Windows. From the technical point of view it uses JAVA with SWT, but the ecosystem includes groupware Lotus Notes, instant messaging software Lotus Sametime and office software Productivity Tools. All the applications inside this platform are nicely integrated, interconnected and extendable with third-party plug-ins. Interaction with the native platform is not important in this case, as this is a platform for an office worker; most of the tasks he requires for his business are already there.

Table of contents
  1. "Multi-Os platform, 1/2"
  2. "Multi-Os platform, 2/2"
e p (5)    78 Comment(s)

Technology White Papers

See More