What’s a Multi-OS Platform and How to Deal with Such a Beast?

After 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.

Before talking about the platform which might become the most important Multi-OS platform in the future, let’s take a look at two other failed attempts at creating a Multi-OS platform. The first attempt was OPENSTEP, a platform which was available for Solaris, Windows, and in its incarnation as NextSTEP as its own OS, which was available on several hardware platforms. The reasons for the failure are quite numerous: OPENSTEP was too alien on a platform like Windows and it had its completely own look and feel, meaning it was too hard for a user of a native platform to get used to it. Not many applications existed for this platform and the company Next was too small to push it.

The second attempt was the AVA Desktop. After the introduction of the JAVA Desktop on Linux, Sun ported it to Solaris and was thinking loud about porting its components to Windows to achieve a similar working experience across several platforms, but this remained a wish, and these days Sun changed its business directions like socks, dropping this idea. However, maybe such discussion will appear again, when the Looking Glass project becomes more mature and will become a toolkit for a complete platform.

Now finally I want to introduce the most promising Multi-OS platform: KDE 4.0. What is so exiting about it? KDE4.0 is based on QT, which, as we’ve already seen, is suited for Multi-OS development. However, KDE 4.0 is much more. KDE consists of thousands of programs, many of them quite high quality, so if a user installs KDE 4.0 on his OS he has potential access to most of them. Technologies like Phonon help to develop Multi-OS applications, because all the access to multimedia codecs, which are different on every native platform, happens through the Phonon layer, so the application does not care if it is Quicktime on Mac, GStreamer on Linux, or DirectShow on Windows. Applications communicate with each other via DBUS. Applications itself are so called KParts, which can be combined into new ones. Copy/paste and drag/drop work across the platform. Look and feel can be configured to resemble the native platform, so a user can quickly get into it.

So what are the advantages and disadvantages to have a complete Multi-OS platform beside the native platform?


1. Compatibility across all OSes. Using the same office suite, the same instant messenger, the same groupware regardless of the operating system allows sharing all data without compatibility issues.

2. Painless switch between different OSes. Once the user understands the basic look and feel of the platform he can use the same programs, which might look a bit different, but are called the same (all the Windows users I met were not able to surf the Internet on a Mac, because they had no idea that Safari and Camino were web-browsers) and behave the same. Again compatibility is very important in the case of switching platforms, because all user data can be transfered, without any potential loss through convertion.

3. Since KDE 4.0 is open source and provides tons of applications, an average computer user does not have to buy expensive computer software for basic tasks; hence he can save money for software which really demands special functionality of the OS, which a cross-platform application cannot provide.

4. More programers who are using different OSes can write application software which is available for all desktop users.

5. Multi-OS platform can be ported to less widespread systems like Haiku, AmigaOS, MorphOS, and SkyOS giving the users of these platforms lots of software for their daily work.


1. While QT mimics quite good the look and feel of a native platform, it still can be recognized as alien, which is highly unwelcome especially by Mac users, who react very sensible to a different look and feel than Cocoa or Carbon. This is especially valid in times when Apple changes the look and feel of the platform (usually with a new MacOSX release) and QT still mimics the old version. But this consistency arguement is true, if only few applications have different appearance, but what if the majority of the applications has different appearance? Is it the common appearance then and the native applications start to look differently?

2. Multi-OS platform can offer only the least common denominator, so the applications cannot use special advantages of the particular OS. This is true, but we’re not talking about highly specialized software packages, which really demand some special functionality of the OS, but such applications like an office suite. I’m not saying that everybody should use KOffice, but several different office suits can be created based on Multi-OS, which serve every taste. So a demanding user can use a suite which is as powerful as Microsoft Office, while a less demanding user can use a suite which is as design oriented as iWorks. There is no reason why such applications cannot be cross-platform; they do not require any special capabilities from the OS. The last office suite which was really optimized for an OS, was Gobe Production suite and even that one was ported to Windows.

3. But what about integration with the native platform which was so important in previous cases? Well, the close integration with the native platform is not required, because we have a whole ecosystem with plenty of applications, so communication outside the platform is becoming a nice-to-have and not an absolutely necessity.


We see that it makes a lot of sense to have a Multi-OS platform besides the native platform. Sure, there are disadvantages, but in my opinion most of the people can live with the fact that some applications behave slightly different then the rest. Imagine what will happen if KDE4.0 becomes such a winner like Firefox; a lot of people will use plenty of open source software, first on Windows, but then they see that they can easily switch to any other platform. This will be the moment when finally Windows will face a serious competition on the desktop.

About the author:
Currently I’m located in Bracknell, UK and I work for a major EDA company. If you want to find out more about me and my interests, please read my blog at kloty.blogspot.com (only in German), where you will find my profile and some other interests beyond operating systems.

If you would like to see your thoughts or experiences with technology published, please consider writing an article for OSNews.


  1. 2007-02-19 6:32 pm
    • 2007-02-19 6:57 pm
      • 2007-02-19 7:04 pm
        • 2007-02-19 7:39 pm
          • 2007-02-19 7:55 pm
          • 2007-02-19 10:14 pm
          • 2007-02-20 7:28 am
          • 2007-02-19 7:58 pm
          • 2007-02-19 10:07 pm
          • 2007-02-19 10:24 pm
          • 2007-02-20 8:50 am
          • 2007-02-20 10:36 am
          • 2007-02-20 2:09 pm
          • 2007-02-19 9:12 pm
          • 2007-02-19 9:43 pm
          • 2007-02-19 11:50 pm
          • 2007-02-20 1:47 am
          • 2007-02-20 10:39 am
          • 2007-02-20 1:25 am
          • 2007-02-20 2:28 am
          • 2007-02-20 3:06 am
          • 2007-02-20 7:47 am
          • 2007-02-20 1:43 pm
          • 2007-02-20 10:42 am
  2. 2007-02-19 7:05 pm
    • 2007-02-19 7:19 pm
      • 2007-02-19 7:59 pm
        • 2007-02-19 9:06 pm
        • 2007-02-19 11:06 pm
      • 2007-02-19 10:08 pm
        • 2007-02-21 8:47 am
    • 2007-02-19 10:45 pm
      • 2007-02-20 1:05 pm
        • 2007-02-20 2:41 pm
          • 2007-02-20 8:24 pm
  3. 2007-02-19 7:06 pm
  4. 2007-02-19 7:23 pm
  5. 2007-02-19 7:50 pm
  6. 2007-02-19 7:56 pm
    • 2007-02-19 9:23 pm
      • 2007-02-19 10:34 pm
        • 2007-02-19 11:10 pm
        • 2007-02-20 12:32 am
          • 2007-02-20 7:39 am
          • 2007-02-20 10:29 am
          • 2007-02-21 10:57 am
          • 2007-02-21 11:41 am
          • 2007-02-20 9:41 pm
    • 2007-02-20 7:28 am
  7. 2007-02-19 8:22 pm
  8. 2007-02-19 8:49 pm
    • 2007-02-19 9:26 pm
      • 2007-02-19 10:24 pm
        • 2007-02-19 10:37 pm
        • 2007-02-20 12:58 pm
    • 2007-02-20 1:34 am
      • 2007-02-20 2:32 am
    • 2007-02-20 3:37 am
  9. 2007-02-19 9:19 pm
    • 2007-02-19 10:10 pm
      • 2007-02-20 12:38 am
    • 2007-02-19 10:20 pm
      • 2007-02-19 10:47 pm
        • 2007-02-20 12:07 am
          • 2007-02-20 10:18 am
      • 2007-02-20 12:34 am
    • 2007-02-19 10:41 pm
      • 2007-02-20 12:36 am
        • 2007-02-20 10:23 am
          • 2007-02-20 2:53 pm
          • 2007-02-20 4:46 pm
          • 2007-02-20 9:04 pm
          • 2007-02-20 10:51 pm
          • 2007-02-21 4:57 am
          • 2007-02-21 11:48 am
    • 2007-02-20 3:39 am
  10. 2007-02-19 10:44 pm