Rich Burridge's Blog

Open Source portability.

Recently I've been trying to get various open source applications running on Solaris on x86 machines. These were mostly GNOME applications, but some of them were dependant upon underlying libraries that come from the Linux world. I've been having some trouble with some of these software distributions because the author(s) have only ever been concerned with GNOME and Linux.

I'm old enough to remember a time (15-20 years ago) when SunOS (the predecessor to Solaris) was the preferred Unix development environment and porting to other flavours of Unix was secondary. Linux is the main "Unix" development environment now. Fair enough, but developers should still think about what it would take to get their software working on other operating systems like Mac OSX, Windows and Solaris. It's not hard to abstract the differences out. It would give you the benefit of having a much larger potential user base too.

Differences come in two types here. Operating system calls and library API calls I group together. Then the second type is graphics calls. Let's talk about the system calls and library API's first.

Some people prefer huge #ifdef/#endif sections in their code to capture these O/S specific differences. My favorite approach is for your configure (or build) script to determine the type of platform you are running on, then compile a single different file depending upon that O/S type. That file would contain the O/S specific calls in a single place, each call in a separate routine with a common abstract name. The other files in the software distribution call these abstract routines and the build picks up and compiles the specific O/S file containing these routines and just does the right thing. It's clean, easy to understand and if your application has to be ported to several additional platforms at the same time, this can be done by multiple developers efficiently and in parallel without stepping on each others toes.

Handling graphics calls I believe should be done in a similar manner. Too many times I've seen an application written with just one graphical toolkit in mind. And with these graphics calls being done in all the source code files. Experience has shown me that a graphics toolkit has a life expectantcy of 5-8 years (some less than that). Then something better comes along. Or you need to port to another platform which doesn't support the original toolkit. Porting to another toolkit is then a nightmare.

I've been writing open source code for about 19 years now. Open source graphical code for about 16 years. The approach I've taken is to abstract all the graphics calls out into a single file that's specific to a particular toolkit. This contains routines with names like "draw_frame", "make_button". The routines in that single file then contain implementations of the required functionality using that toolkit API. Porting to another graphical toolkit is a simple case of creating another file with those abstract names in, and providing calls to the new toolkit within. Plus a little glue in your configure (or build) script to make sure that the correct one is compiled depending upon the platform you are running on.

Using this approach, I'm still able to use today a calcalator program that was originally written in 1987. It's seen numerous toolkits (SunView, X11, NeWS, XView, Motif, MGR, Gtk+ and even a curses version) and it's worked on numerous UNIX systems (plus a version that runs in an embedded system).

Comments

• like they say...
  Don't like what you see, do it yourself.
  That's the "open source spirit" as advocated by the open source community.

  No need to go asking them to port the application to Solaris (or even to make porting possible), they most likely won't do it.
  They're not interested (open source is mainly about scratching your own itch after all, and that itch is mainly limited to your own computing environment).
  As an aside, Solaris is part of the group of Evil Software from Big Companies. As such it should be destroyed together with Windows, or such is the attitude of your typical Linux evangelist.

  Posted by: jwenting on April 28, 2004 at 11:16 PM

• ... and are you one of them?
  You are reffering to an attitude that is not representative of many open source projects, so be careful when you mention "open source spirit". Indeed, there are projects with the cowboy attitude of "Linux or nothing" but there are also many more projects, sponsored by companies, organized by foundations, or managed by individuals, with multi-platform development approaches.

  Posted by: sngraca on April 29, 2004 at 07:12 AM

• Separation of graphical interface and model
  I agree with a view of multi-platform software development and the techniques you mention are helpful to accomplish it. As far as the graphical calls are concerned, the architectural decision of viewing the GUI as a separate module, communicating with a kernel through a protocol, might be of benefit to further encapsulate operating system dependencies. The kernel would be built for several platforms. There could be more freedom in the implementation of the front end(s), using the native SDKs of the platform. So the kernel functionality could eventually be invoked for example though a CLI, a Swing application or a web browser.

  Posted by: sngraca on April 29, 2004 at 07:24 AM

• like they say...
  Nice troll...

  Posted by: lee_ on April 29, 2004 at 07:31 AM

• Not really the standard.
  You make this one example seem to be the standard situation for the group name open source. The correct subject of your log would have been "Gnome applications portability".

  As a counter example a project that is much larger then the Gnome project *is* portable across a wide range of unixes. The KDE project compiles and runs correctly on many processor types as well as various *nix variants out of the box.

  There are even pre-packaged binaries available for solaris;
  http://www.kde.org/info/3.2.2.php#binary

  I hope you will see that stating issues that are as easy to debunk as this does not only make you look bad; but your employer and the whole open source community as well. Please take the time to research this kind of stuff a _little_ further before you pass judgement.

  Posted by: zander on April 29, 2004 at 07:44 AM

• Not really the standard.
  I think you are missing my point. You mention KDE.
  Let's use that as an example. Say there is an
  application that's written to work with KDE and you
  now want to port it to Windows using the native
  Windows graphics toolkit. If the KDE graphics
  toolkit calls are dispersed all over the application
  source code files, then this porting job is much
  harder than if the calls are abstracted out so that a
  new win32.c file can be added to the distribution
  containing the needed Windows graphics calls.

  I'm suggesting a portability beyond where the
  existing graphics toolkits already work (I've got
  KDE on my Solaris box at work right now - it
  works fine). I'm proposing an approach that will
  allow you to port to totally different platforms using
  their native graphical API's.

  Not everybody wants to do that. Some development
  teams just want their application to work with
  GNOME, or KDE or Windows. That's fine. I'm
  hoping I'll reach others that are looking at the bigger picture.

  I've been doing "open source" long enough to
  realize that there are software distributions that
  do the right thing. Others, whether they be
  GNOME, KDE or whatever do not.
  

  Posted by: richburridge on April 30, 2004 at 04:52 PM

This work is licensed under a Creative Commons License.