How hard is it to write cross-platform software?

• Not that hard
• It depends
• Very hard

I would have picked ‘Not that hard’ two years ago when I started this project. However, that quickly skipped over ‘It depends’ and went straight to ‘Very hard’.

These days everything is hard.

Each project has a start and numerous decisions to be made. Knowing I wanted to build distributed software that runs on more than one machine and on Linux and Windows, I thought I basically had three choices:

• C++
• Java
• Scripting language, Perl or Python

And this is where the hard part comes in. You start to realize that these days there are many options available and it is quite a challenge to make good decisions up front. It takes a lot of effort to explore all your options.

It is not as simple as choosing C++ or Java or a scripting language, or even a mix of the three. Each language / platform has their pros and cons that can make or break your schedule. This one choice can quickly balloon into many choices, and each decision affects many aspects of the software.

The basic design for BixData called for an agent for each machine, a central server component and some user interface. Each of these components has to communicate with each other and integration has to be as simple as possible. The software needs to run on Linux and Windows. It has to be stable with a small footprint and very little system impact.

This is where my blog post got out of hand; initially I wanted to go into detail about the choices for inter application communication, user interface and data exchange. But I won’t underestimate the fact that most programmers are painfully aware of all the issues.

So instead I decided to list my reasons for how I think cross platform development could be easier.

 

Writing cross-platform software would have been much easier if…

• C++ had better memory management and a better standard library

You can’t possibly write a useful application without using XML, HTTP or some form of graphics format such as jpeg or png. Scripting languages have already had these features for a long time.

There are a few useful libraries that provide XML, HTTP, etc. but if you want them to actually work on Linux and Windows (not just pretend makefiles), the list gets short very fast.

I was also surprised at how unnecessarily complicated and bloated some of these libraries are. And its quite a challenge to get some of the libraries to compile and run inside the same applications.

If you are wondering what the short list is for extending the functionality of C++, after many hours of testing and use, try

• libxml, http://xmlsoft.org/
• libcurl, http://curl.haxx.se/
• OpenSSL, http://www.openssl.org/
• Boost, http://www.boost.org/
• GD Graphics Library, http://www.boutell.com/gd/

 

 Writing cross-platform software would have been much easier if…

• Java JFC/Swing was more elegant, less bloated and ran faster

It took me some time at IBM to realize the benefits of programming in Java. You can really develop stable production quality large scale applications that are also much easier to maintain than C++ and less error prone during runtime. Java is quite a bit slower than C++, but better and faster hardware can make up for that at a relatively low cost compared to development time and effort. Better hardware can not make up for bug ridden C++ code.

Java also does not truly run on all platforms. Yes there is a Java runtime for Linux and Windows, but the Linux version for example is not as stable as the Sun version. Also about 2 years ago, the Mac OS X version of Java runtime was far behind the Linux version.

The deal breaker though is writing an interface in Java. I think that interfaces written in JFC/Swing are unresponsive and unattractive. Java would have had much better adoption if its user interface library was as attractive and responsive as the Windows 2000 user interface or KDE interface. Also, unlike scripting languages, Java does not have good hooks into user interface libraries.

 

Writing cross-platform software would have been much easier if…

• the Mono project was more mature and a viable choice

C# and the .NET system library (or framework) has all the features that a large scale application requires, provides a similar stable coding infrastructure as Java, and has a user interface that is responsive and attractive. But it only runs on Windows.

I’m still intrigued as to how long the Mono project is going to last. The breadth of functionality that is in the .NET framework will be very hard to replicate in Mono. Much harder than say Wine was to Win32 API. If the Mono project was more mature and feature complete, it would be a very viable choice.

 

Writing cross-platform software would have been much easier if…

• Scripting languages could be compiled into binaries

Scripting languages such as Perl and Python have system libraries that are very feature complete, offer some platform independency and have hooks into viable user interface libraries such as GTK and wxWindows (wxWindgets).

Although scripting languages don’t scale very well to implement large scale server applications, this is not as big a deficiency as the fact that you can not compile scripting languages. When you distribute your application you have to consider whether you want to open source your code, or just have it open, and whether you want that code to be in such a format that it could easily be modified or corrupted. If a binary is corrupted it simply won’t run, but with hundreds of script files the risk of your application corrupting data or exhibiting weird behavior is much higher.

 

Cross-platform development is hard

I tried to highlight some of the issues regarding the initial direction to take when starting a cross-platform project.

There are many other issues that range from development tools and code editors, to platform specific differences in important areas such as threading and memory management.

We will go into more detail in future posts on these topics.