Monday, October 13, 2008

Adventures in Cross Platform Development

I've been trying to find a solid way to do cross platform development for a while (with the prerequisite of it being capable of fairly high performance). With an interest in a single solid solution to the underlying framework.

The high performance requirement eliminates a few options off the bat including the vast majority of scripting languages and Java. Even the nicer scripting languages aren't going to give the performance of a bare metal system.

Bare metal systems would be the ideal solution for the types of code I'd like to be able to run, but the idea of writing an encapsulation system / re implementing everything from threads on up in the C/C++ stack makes that a horrifying proposition at best. Not to mention interfacing with each of the disparate screen drawing systems.

That being said, I've got three 'real' options to work with at least one of which is kinda of a weird one. Lets start with the oldest first.



Wx is a pretty solid system for a large variety of systems, unfortunately building it in Windows is not quite so trivial. The most obvious path for building the system is to open the (ancient) visual studio project files and use 'batch build'. This works (mostly) if you run it like 5 or 6 times, but that's not a terribly good way to go. Pile on top of the the fact that there is no clear way to make wxWidgets work in a 64bit system and you have somewhat of a problem. I had some remarkable success converting the 32bit apps to 64bit and the simply building them in visual studio. However this generates a pile of 'size_t' to 'long' conversions that indicate a possible loss of data. Not something I want to have to work with hanging over my head.



QT on the other hand has a significantly larger amount of polish than WxWidgets (at least with the release of QT4). It also introduces some new features to the system that are nice to have, like a fully functioning signal system without the need for a secondary framework like sigC++. However its open source version does not come with any form of useful interaction with visual studio and takes quite a bit of effort to get up and running as such. That work is nowhere near as trying and frustrating as WxWidgets however, as while the documentation on it is sparse it's not nearly as bad as WxWidgets. I've noticed a few pitfalls in the way it works on my development system (mostly connected to getting programs to link) that I'll be documenting in a separate post.

These pitfalls aside, the latest versions of QT can be built anywhere. You won't get an form of 'integration' with visual studio from a project generation perspective but compiling against the MSVC compiler and intelli-sense work just fine if the system is configured properly. It will also happily compile x86 and x86-64 versions (they will both be huge). A bridge to cross however is solving the visual studio development to unix build tool problem, and will require some further investigation.



The last and most controversial is the 'Mono' project. This system allows you to transport C# or VB 8 code from a Windows environment to a Unix / Mac environment. It also provides a number of extensions to these languages for use in Unix (it's not clear whether these extensions can be used in Windows). The goal of the system being two fold, first introducing write once run everywhere code and secondly lowering the barrier of entry for Windows programmers moving to the Unix/Mac world. It also gives a consistent set of available functions (mostly due to it's own dependencies) that ensure you have a fairly robust minimum operating environment. However I'm concerned about attempting to integrate something like the nvidia CUDA libraries into this system. There's currently no first or third party integration with the original .NET framework, let alone the Mono modified environment. This and a few other issues (some fairly pointed out by PeterB of Ars fame) make the enviroment not as attractive for me.

Coupled with this is a general stigma in my work environment of anything seen to be supporting windows in any way shape or form. I'd have to balance anything I wanted to do against the amount of fighting it would take to convince people to even install the latest and greatest invasion of the MS mentallity onto their systems. On top of that the Novell / MS joint patent protection surrounding it would probobly deter a large number of people who are hard core FOSS users.

That being said Mono appears to be gaining some rather signifigant moment and coupled with many of the technologies the .NET framework makes available should be a fantastic development environment for many domains. That being said, I suspect for HPC code it's not going to turn out to be the most appropriate system use.

The Blue Pill:
Of the three, Mono appears to be the least painful way to write software cross platform software and it probobly has the most technical merits in the 'write once use everywhere' bin. It would be interesting to see the Power Shell get ported to that system as well as it would give you a quick and dirty template to work on more indepth C# code with. It also has the posibility of introducing IronPython and IronRuby support increasing the pool of available developers signifigantly.

The Red Pill:
That being said, the local stygma and general controversies surrounding it make it unattractive in a University setting such as mine. The truly practical runner up to that on an ease of use side is QT4 (as of this writing 4.4.3). It has a few odd restrictions and the generally question of how do you use the build system hanging over it but overall it's a solid system. It's been trial by fired on a number of occasions and actually forms the basis of the latest version of KDE(4.x), which is a pretty slick Linux Desktop environment. Having wasted a good two days of my life trying to get 'something' to happen in WxWidgets only to find that they unsupported 64bit build seemed to behave better (or at least build more reliably) than the 32bit version has made me vote that that particular framework can go die in a fire. Leaving me only with QT4 as a practical solution for the particular projects I'm looking to work on in the near future.

Some of the reference articles that inspired this post:

http://tom.paschenda.org/blog/?p=28

http://www.telldus.se/qt/tutorial.pdf (sorry for the PDF link but it is helpful if your interested in QT)

Had any luck developing anything cross platform, or random input, post a comment!

0 comments: