Re: Cross-platform apps

[Michael L Torrie <torriem chem byu edu>]

On Wed, 2006-04-26 at 16:12 +0200, Cesc wrote:
> I agree on all the advice you are given here ...
> My experience is that it is not piece of cake, but it can be done.
> Test often and plan compatibility since the very beginning.
> Then, i would recommend you take a look at other projects which are
> cross-platform and you borrow from there ... for example, i am
> involved with MiniSIP (www.minisip.org), which is builds on linux,
> win32 and wince. The approach is to isolate OS dependent calls in
> compatibility layers (in minisips case, libmutil and libmnetutil), so
> you have a stable API which compiles the appropriate code depending on
> the platform.

Definitely doing your own this abstractions is very important.  This
doesn't always mean making lots of #ifdefs and #defines, or wrapper
functions either.  In many cases this means you've completely separated
your backend code from your frontend (the UI).  If you completely
modularized the backend to the point that OS-specific things can be
compartmentalized into their own modules which can be selected at
compile time, you will be much more successful.  I believe this is a
better approach than trying to limit yourself to the most common
denominator c library calls.  For example I have written one program
that uses asynchronous socket i/o.  Because of the design of the backend
code, I can move my state machine engine to threaded-i/o without a lot
of problem for platforms where that may be better (just an example
that's not necessarily relevant).

One thing I find that helps make the backend more portable is heavy use
of glib (the underlying utility library from gtk).  This can allow you
to do file i/o on a variety of OSes and file systems and not worry about
things like path separators.  For areas where glib doesn't cover
directly, like socket i/o, having an OS-specific module would be needed.

On the frontend, GTK does provide some portability and abstraction that
works well on Windows and Linux, but not so much on OS X yet.  For this
reason I have been using Qt a lot lately, since Qt 4.1 is now very
native on Windows and OS X.  But if your target is X11 and Win32, gtk
works very well.  However it is not always a good idea to tie your UI
(gtk) so closely to the backend that it would not be possible to change
out the GUI down the road and use something else (something native for
example, like, heaven forbid, win32).  Abiword chose this route.  The
backend code is shared between platforms but the UI is, to my knowledge,
specific to the OS.

I have written several programs recently in Qtk (and Qt) with the
intention to run them on several platforms and, having planned for this
from the beginning, have been quite successful.  For just a little bit
of effort up front (which turns out to be good practice anyway), you'll
find the transition from platform to platform to be relatively simple.
Makes me wonder why any application developer would ever intentionally
tie himself to one platform regardless of that platform's market share.


Michael

> Good luck!
>
> Cesc