Cross platform UNIX software development:

A Mac OS-X based case study.

Written by Paul Bourke
AUC conference, 2003

See also: Fractal Dimension Calculator


Within the scientific research community the installation of UNIX based computers is widespread, this is particularly so in the high performance computing arena. While there are many reasons for this, an important consideration is the sharing of software as source code with the knowledge that the code has a high chance of being compiled and run on a system from a different supplier. This is especially important for university institutions with heterogeneous UNIX systems or groups who may have one primary in-house computer platform but use a different system on a university cluster or on a high performance national facility. This paper will discuss some of the considerations when developing software solutions under Mac OS-X that are intended to also work on other UNIX based computers, a new possibility following the introduction of OS-X. The discussion will be based upon a particular example from a recent project by the author.


Software development is a major activity for many university departments, usually because they are addressing unique problems for which there are no existing solutions, commercial or otherwise. All of the requirements of any software project such as reliability, correctness, efficiency, and functionality are equally as important when writing university research software as they are for commercial software projects. However there are some unique features or at least a different emphasis for many research based software development projects.

Research based software projects often require a very fast proof-of-concept development phase. It may not even be known whether the algorithm being tried will even work. Many times the software may be written solely to test a theory. In either case if there is a reasonable risk of an unsuccessful result then that places limits on how much time can be invested in some aspects of the application. Traditionally this means that interface design and implementation are minimal and as a result one often ends up with the UNIX style command line interface.

After the proof-of-concept or prototyping stage it may be decided to further develop the software so that can be used on an ongoing basis by a number of people within a research group or, if the software is general enough, it may be applicable to multiple disciplines and a broader distribution. There are still differences between this sort of the development project and a commercial one, the main one is that often a high emphasis is placed upon the code being able to be run on a wide range of different hardware platforms. However there is usually a resource constraint for the project, generally there may be only one person doing the programming and there isn't sufficient motivation or expertise within that person to maintain separate code streams for multiple platforms.

These realities have been a major drawback for this type of research software development based upon MicroSoft Windows or the earlier Macintosh operating systems. Software developed within those environments invariably became very system dependent and therefore hard to port to any other operating system. The main reason for this was that developers were forced or encouraged, often by user expectations, to create applications that used and conformed to the graphical user interfaces and associated look-and-feel expectations which are fundamentally different between MicroSoft Windows, Classic Macintosh, and X-Windows. That is not to say that cross platform software development hasn't been possible, the reality though was that the effort required was more than an individual developer could reasonably deal with or it required a larger commitment of resources than most research software projects could justify.

By it's very nature, software being written by researchers often requires very long processing times, it is therefore important to be able to run applications on high performance hardware as well as on a large number of machines in a cluster say. This requires software that can be operated remotely (without a display) as well as automatically using a scripting language. This applies also to applications that may be performing fundamentally graphical tasks.

Considerations such as these are some of the main attractions of the use of UNIX based computer systems in research laboratories. While there may be different underlying hardware from different suppliers, there was a reasonable chance of compiling code between different implementations of UNIX and a very good chance if code was written with that in mind.

Case study: FDC (Fractal Dimension Calculator)

In 1990 a Macintosh application called FDC (Fractal Dimension Calculator) was developed that estimates the fractal dimension of an object represented in a PICT image using a technique called box counting. The analysis and interpretation of fractal dimension isn't always straightforward and, to be successful, any software that is used needs to give the user a clear feedback of the processing, at least until the user is familiar with the limitations and behavior of the various options. FDC was relatively innovative at the time as the only other solutions were not interactive and in many cases numerically dubious and unstable. As a result FDC had a very wide uptake, at least within the community that has an interest in such matters.

FDC followed to a large extent the Apple development guidelines and although it has been 12 years since it has been modified it still runs on all Macintosh hardware including the Classic environment under OS-X. With the inevitability of the Classic environment being phased out, many researchers using this software were increasingly enquiring about an alternative, for which there are still no preferred options.

While there were many requests for a MicroSoft Windows version, the largest number of requests were for Mac OS-X or Linux versions. It was decided to develop the new version of the software on a machine running OS-X, some of the key design criteria were as follows:

  • Ensure that it would compile on essentially any current UNIX X-Windows based system, in particular, it was necessary to support Linux (i386), OSF Tru64, and SGI IRIX.

  • Versions for all platforms should be compiled from just one copy of the code and that there would be no platform or operating system specific components in the code. For example, there would be no bits of code that were used for one platform and other bits for other platforms. This decision was partly based upon a desire to see whether this was possible but also due to time constraints given the reality that the testing phase would necessarily longer if there were different code segments for the different platforms.

  • The application should run as both an event driven application with a graphical user interface but also in a purely command line mode. The later has benefits for scripted operation (analyzing large collections of images) or for running on remote high performance systems that may not even have a graphical display.

  • While the application would have a graphical user interface, provide visual feedback on the processing and be event driven, a user on any platform would have the same general experience. Put another way, a user of the software on one platform would not notice any significant difference on another platform.

Of all the platforms the application was required to operate on the common denominators dictated that all graphical display/feedback would be based upon OpenGL in addition to the GLUT (OpenGL Utility Toolkit) library and all user interface items (dialog boxes, menus, buttons, etc) would be supported within the X-Windows environment. While there were a couple of options, the toolkit that satisfied the requirements of this project was the Forms library, initially an SGI based project but now perhaps the most widely supported X-Windows toolkit.


FDC is now in beta release and is already being used in research projects. It is freely downloadable and fully operational except for a feature required for more accurate estimates of fractal dimension. A version with this feature enabled is provided with payment of a modest fee. This is not an uncommon approach, it allows the software to be tested on the platform in question and to ensure it operates as the prospective user expects. The additional functionality missing in the free release is only required for serious users.

FDC has been successfully compiled (without modification) and tested on 7 different UNIX systems (Max OS-X, Linux on Pentium 4, Linux on SGI workstations, HPUX, OSF, IRIX, SunOS). The main aspect that is less than ideal is that the Mac OS-X Forms library file open dialog is somewhat ugly, at least different to most Mac OS-X users expectations. This is primarily because it was designed to look like a traditional X-Windows interface and a custom Mac OS-X version isn't yet available.

The similarity between platforms is very apparent and not terribly surprising given the small number of external libraries used. Screen captures for the four platforms that absolutely needed to be supported are shown in the figures.

Mac OS-X

Linux i386

OSF Tru64

SGI Irix

One of the core design criteria for FDC was that it could run in a traditional UNIX command line mode without any graphical support. In this mode all settings are provided as command line switches and all output is written to standard output or standard error. This has proved critical to some of the more demanding applications where large images are analysed with a sliding window approach in order to estimate variations of fractal dimension, something not initially conceived in the original design. In these cases the UNIX command line approach allows the analysis to be performed automatically as a background task (sometimes taking many days) and also for it to be distributed across large scale clusters for parallel computation.

A consideration for such projects if binary files are to be exchanged between machines is whether the underlying hardware is big or little endian, this is how the bytes are ordered when representing other than single characters, eg: short integers, integers, floating point values, etc. While one solution is to record the endian convention being used and another is to have different code for the different endian machines, the approach taken here is to develop code that is independent of the endian nature of the file. So for example, the code in FDC that reads a TGA file reads everything at a byte level and reconstitutes any higher level values appropriately.

While it was not initially intended to support MicroSoft Windows, because the external libraries are also available for that platform the code was very easily ported to Windows by a third party.


There are a number of considerations when deciding if or how to create portable software. It is difficult or at least a major development effort to create a fully Cocoa Mac OS-X application and also provide support for MicroSoft Windows and UNIX systems. This project has shown that if an X-Windows style interface is acceptable then cross platform development, even of graphically orientated software, is relatively straightforward.

Besides X-Windows, using OpenGL for 2D and 3D graphics has major cross platform benefits. Not only is OpenGL standard across the Macintosh range but it now much more common across the UNIX workstation market than it was even just a few years ago.

A further exploration is the use of Qt, a multiplatform application development platform supporting MicroSoft Windows, X-Windows, and Mac OS-X. Problems at the time of writing was that it wasn't supported for one of the key required UNIX platforms. There are also questions regarding the future licensing and pricing. It certainly offers a much richer and attractive environment than the Forms library.

There are still some frontiers, the main one is audio support, at the moment while there are some standard audio libraries they are not supported across a particularly wide range of UNIX platforms.


Using Box Counting Techniques for Measuring Shape of Colonies of Filamentous Micro-organisms
Jacques Soddell and Robert Seviour
Complexity International (1995) 2

The Box-Counting: Critical Study
M. Nezdal, O. Zmeskal, M. Buchnicek
Technical University of Brno, Faculty of Chemistry, Institute of Physical and Applied Chemistry, Purkynova 118, 612 00 Brno, Czech Republic

Viscosity of Venusian Lava Flows: Constraints from Fractal Dimension and Chemical Composition
W. A. Pike, H.M. Frey, A.E. Krull, E.B. Grosfils, M.S. Gilmore, L.A. Reinen, and S.J. Kozak
Lunar and Planetary Sciences, XX1X

Fractal Properties of the Thyrotropic Feedback Control Implications of a Nonlinear Model Compared with Empirical Data
J. W. Dietrich, A. Tesche, C. R. Pickardt and U. Mitzdorf
Cybernetics and Systems, 2002

Advances in the implementation of the box-counting method of fractal dimension estimation
K Foroutan-pour, P Dutilleul, DL Smith
Applied Mathematics and Computation Vol. 105 No. 2-3 NOV 1999

Forms library
T.C. Zhao and Mark Overmars

GLUT library
Mark Kilgard

Qt Development framework
Trolltech Inc