Write Cross-Platform Software

Posted 7 Jan 2002 at 00:04 UTC by goingware Share This

Would you like to write more portable code? Do you wonder how the developers of AbiWord, Mozilla and the GIMP got their programs to run on both Linux and Windows, and even other operating systems? Would you like to develop and run your application on Linux but infect Windows and Mac OS users with the love of Free Software? Would you like your Linux software to run on PowerPC, ARM, S/390, Alpha and Sparc and not just x86?

I have written my first column of a planned series at a new cross-platform resource on the web: ByteSwap.net

The site is in its infancy, but I have great things planned for it. Besides future columns, I will have a database of links to pages and software to inform and enable cross-platform development.

I don't have the database software for this yet, but the hosting service (Hostway) provides MySQL. If you know some software that will work well for a dmoz or Yahoo-like index, let me know.

I invite others to write articles to publish on the site. Write me at editor@byteswap.net to discuss it.

I have been involved with porting and cross-platform development for some time. Among the ports I did was moving Spellswell from Working Software from the Mac OS to the BeOS. Also I helped ZooLib author Andy Green prepare the framework for open source release under the MIT License by writing a large application in it, and leading a beta test where other developers used it to write their own applications. And now that I have finally learned DocBook I am writing the programmer's manual for ZooLib - it hasn't been that well accepted yet, I think in large part because there is no documentation.

Alternative frameworks, posted 7 Jan 2002 at 12:07 UTC by LinuxNinja » (Journeyer)

Interesting article. On the subject of frameworks, wxWindows (wxwindows.org) is celebrating its 10th birthday early this year and definitely does not represent "least common denominator" as far as platform features go. It offers widgets which look native to the platform upon which it runs, and most importantly, is available under a very attractive license.

Codingstyle.com will be running an interview with many key developers of the wxWindows project, it should be up on January 9th.

Linux/Windows/MacOS... and... and..., posted 7 Jan 2002 at 14:19 UTC by matt » (Journeyer)

Why is it that cross-platform is often considered "runs on Linux and Windows", when a much simpler start to cross-platformability would be to get it running properly on other free operating systems, such as the *BSDs?

Writing portable software, posted 7 Jan 2002 at 19:36 UTC by neil » (Master)

Define ported.

Has either Mozilla or Gimp been ported to Windows, when neither follows the standards and practices of that OS's interfaces? For that matter, has Mozilla or Gimp even been correctly ported to a Unix desktop? Mozilla's UI is equally custom on any OS, and Gimp isn't a correct GNOME app.

To favor getting something compiling and running on many OSes is to tradeoff usability on all of those OSes. At most one environment's users will get something standard. Everyone else gets something weird and different. If you're Mozilla, you choose to make *everyone* put up with something different.

By that standard of ported, do I want to write portable apps? No way. I prefer to improve usability by adhering to standards.

Re: Writing Portable Software, posted 7 Jan 2002 at 20:15 UTC by goingware » (Master)

Although most people don't do it, it is possible to write an application framework that adheres to platform UI standards on multiple platforms.

For example, ZooLib places its menu bar at the top of the screen on Mac OS, like native Mac applications do, and at the top of the window for other OSes. On the Mac, it uses the Appearance Manager to render its widgets, and has renderers for each of the platforms it supports to give it a native look.

To some extent, keeping to platform UI standards may require some customization for each platform. This is certainly possible, and straightforward if it is managed well, but yes I understand many people don't do it.

Perhaps a problem is chauvinism on the part of the developers. I recall reading somewhere (it may have been here) that Gimp users on windows complained that all the tool palettes didn't follow the document window when the document moved into the foreground or background. The Gimp developers responded that the windows users should get a new window manager. But custom window managers are not available for Windows, or at least not easily so.

One can certainly trumpet the superiority of one's favorite OS but I feel the developer's duty is to serve the needs of his users. Maybe you don't want to provide an MDI interface, but there are other alternatives, such as activating all the tool palettes when the document is activated, and hiding them when it is deactivated.

The proof is in the eating..., posted 8 Jan 2002 at 02:09 UTC by GJF » (Apprentice)

Yes of course standards compliance is good. But let's consider two things:

  • usefulness is as key measure of software
  • standards are made to be changed

The Gimp is the application that convinced me that GNU/Linux could suceed on the desktop. It fills an essential market need - the need for a good/useful (GNU) bitmap graphics program. Sure it behaves a little strangely for a Windows app, but then so do lots of native Windows apps. On the other hand I personally prefer to have it work the same way independently of the operating system it runs on.

For a long time, Microsoft promoted MDI as a UI standard, but not any more. Similarly, emacs and vi are the standard text editors for *NIX - but as growing numbers of Windows users move to Linux - Windows style key bindings are beginning to emerge as standards for Linux text editors.

Excellent idea !!, posted 8 Jan 2002 at 13:00 UTC by freetype » (Master)

Congratulations for starting this series of articles. I believe that this is an excellent idea. Very unfortunately, many C/C++ developers are not aware of the importance of writing portable code, I would like to emphasize a few more points:

    It's not about the GUI !!:

    Operating systems today are extremely similar when you look under the hood. Yet, there are very few good, simple and efficient libraries to perform most low-level tasks we've learned to live with daily. I'm thinking about multi-threading, networking, DLL loading, database access, abstract data types, and a lot of other similar features..

    I'd like to point out a few remarkable achievements like the Apache Portable Runtime for C programmers, or the Boost project for C++. The Netscape Portable Runtime also comes to mind. Note that all of these are fairly recent compared to the C and C++ languages themselves and work reliably on a large number of platforms.

    Unfortunately, many developers think that portability is only useful when you want to code a GUI application that must run on mostly Windows and Unix. Hence, the massive list of 'portable frameworks' dedicated to managing "pretty windows", and which invariably finish by providing their own threading, data types, string management, etc.. ( WxWindows, Qt, ZooLib and a lot of other GUI libraries come to mind..)

    Of course, these "bonus features" are generally not compatible from one framework to another one, and you end up being locked by the set of features they want to provide and support on multiple platforms. I think we should really separate the GUI framework from the "runtime" when speaking about portability..

    The importance of build tools !!

    Aside from the program source code themselves, portability is also inherently limited by the build tools we use to assemble our code and data into programs on various platforms.

    Things like Makefiles are supposed to be simple to write, but that's only true when you use one compiler on one platform. Otherwise things get extremely messy very quickly. Of course, programs like Autoconf and Automake were born out of the need to build portable programs on various flavors of Unix. However, they're still pretty difficult to use on other platforms, including Windows, except if you want to limit yourself to gcc (and this is hardly a good idea when you want to write truly portable code). They also do not deal very well with things like multiple builds of the same sources (i.e. release, debug, optimised) which are simply a requirement for any serious software project.

    Generally, the only way to deal with these limitations is to use some additional magic (Perl scripts anyone ?) _above_ AutoConf, AutoMake and Make.. And we all know how easy and reliable these can be to write :-).

    I thus encourage and serious developer to try alternative build tools as soon as possible. There are a few well-crafted programs like Jam or Ant that deserve to kick Make's ass in many useful projects..

    All of them allow you to produce "build control" file that do not embbed compiler directives directly, and are thus portable among platforms and compilers. And now for some shameless plug:

    I myself use Jam and this allows me to compile my code with the following compilers:

      Visual C++, Borland C++, Intel C++, Watcom C++, LCC-Win32, Mingw GCC and Cygwin GCC on Windows. Nearly any C or C++ compiler on Unix. EMX/GCC, Visual Age C++ and Watcom on OS/2

    All of this is done from a single set of "Jamfiles" so there is no need to update compiler or platform specific control files each time I switch toolsets.. I did not test them myself, but the source code has been also compiled on VMS and BeOS systems since Jam is availabel for them too, and all of this was without modifying a line of my package.. Jam has still a few limitations, however the Boost project is working very hard to improve it so expect very good things about it in the near future :-)

    The importance of choice

    From the ability to build and run your code on multiple platforms with multiple compilers come the ability to choose the best tool for the task you need. For example, on Windows, I heavily use the free Borland C++ compiler suite during development since it provides impressive compilation speeds and a really, really nice Turbo Debugger that beat GDB and its front ends in nearly all aspects IMHO.

    Of course, important milestones are compiled through GCC and Visual C++.. This is a good opportunity to find subtle bugs because you'll never find two compilers on this planet which will generate the same set of warnings or errors in the case of buggy code. Also, GDB is the only debugger that will allow you to spot really subtle bugs when they happen.. I also often switch to Linux to be able to use "dmalloc" and "Electric Fence", which are not available on Windows otherwise.

    This freedom of choice is a great way to help you reduce your bug count drastically. That doesn't mean they'll be a thing of the past though, but your debugging time will be focused on really important topic, not "=" versus "==" typographic mistakes ;-)

Re: Excellent Idea !!, posted 9 Jan 2002 at 03:34 UTC by goingware » (Master)

freetype, thank you for your enthusiasm. I am very gratified by the response I have received so far.

Certainly cross-platform is not just about GUI, although that is what is usually thought about the most. A good example of a cross-platform library that has nothing to do with the user interface is the Adaptive Communication Environment, "An OO Network Programming Toolkit in C++".

I agree wholeheartedly that it would be a big improvement if the different frameworks shared common libraries. After he released ZooLib as open source, Andy Green contemplated working on a "cross-platform framework toolkit", that would provide common functions that any cross-platform framework would need. He approached at least one other framework author about this, but I think because both were very busy it didn't go anywhere.

There are some reasons each toolkit re-invents its own runtime. A big reason, for the C++ toolkits, is the inadequacy of the C++ standard library on some target platforms. Templates and exceptions have not been in the language for so many years, and the standard hasn't been set for that long at all, and it is a very complex standard that is difficult for compiler implementers to adhere to.

A difficulty with cross-platform work is that, while I say you don't need least common denominator behaviour in the finished product, you do have to suffer from least common denominator support for the language and libraries in the different development systems you use.

Evidence of this problem is the Mozilla C++ Portability Guide, which says, among other things, not to use C++ exceptions or templates. Doing this comes at a great cost of what you can do in C++, and the result is workarounds that involve writing one's own low-level libraries. I understand AbiWord also takes this approach. The benefit is that you are portable to more systems, especially to older systems that are not maintained well anymore.

One doesn't have to take that approach. An entirely different attitude is to require that the target platform have compliant compilers and libraries available, and then to make use of standard language features as you wish. It comes at the cost of limiting the platforms you can run on, but it potentially speeds development. It certainly makes the framework sourcebase smaller because you depend on libraries others have written.

A framework that takes this approach is Whisper, which runs on Mac OS and Windows. The author says "Like Raven Whisper is a modern framework that takes advantage of templates, multiple inheritance, STL, and exceptions."

I think that common runtime libraries for frameworks will come, but I don't think we're there yet. For example, ZooLib has its own thread classes, and the implementation provides an "almost preemptive" thread library for the classic Mac OS, which doesn't have preemptive threads. It runs a scheduler whenever you try to acquire a mutex. Boost provides a thread library, but there is no support for classic Mac OS yet, so for now it is not possible to use Boost threads in ZooLib.

I don't know much about the netscape runtime, but I guess they are able to make threads work on the Mac because Mozilla works on classic Mac OS.

wxWindows Interview Ready, posted 9 Jan 2002 at 12:31 UTC by LinuxNinja » (Journeyer)

As promised for January 9th, the codingstyle.com interview with several key developers of the wxWindows cross-platform framework is now ready for public consumption.

List of Cross-Platform Abstraction Libraries, posted 9 Jan 2002 at 13:15 UTC by shlomif » (Master)

I started composing a list of cross-platform abstraction libraries. It's pretty stable now.

You can find it here:


I'll appreciate any additions or corrections one can make to it.

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!

Share this page