When I think about all the places SWT runs and the things we do to make it work, it blows my mind.
Windows flavours include Windows 98, CE, NT, 2000, ME, XP and soon Vista. The win32 API has two identical calls for everything, one for ANSI and one for Unicode. Windows 98 and ME support only ANSI, while CE supports only Unicode. Windows NT, 2000, XP and Vista support both. This means no single API is available on all Windows platforms. C programs are supposed to compile for one or the other. Instead, we build one set of jars and native libraries for both and call the right API on the fly. It's ugly, but it works.
GTK is version hell. We run all the way back to 2.0.6. Lots of new API has been added since then so we look them up dynamically because Linux won't load a shared library with unsatisfied references. Somehow, when an operating system API isn't there, we run alternate code or fail gracefully. Whew!
Mozilla is it's own nightmare. Until recently, rather than using the Mozilla that you had installed on your machine, Mozilla.org expected you to ship a copy of Mozilla statically linked to your application. Somehow we don't do this, find the installed Mozilla and use it. We work with Mozilla versions as old as 1.2 all the way up to 1.8, which was the latest at the time this article was written. The Linux C++ binary format changed somewhere along the way, breaking us. We detect the right version dynamically and load the one of two identical libraries, compiled differently. Wow.
Advanced graphics on Linux uses the cairo graphics library but this doesn't ship with the current Linux distributions, so we compile and ship our own, just in case. On the fly, we detect whether you already have cairo installed and use that one. Otherwise, we use the one we compiled. It's magic.
The Macintosh comes with two complete and separate native toolkits, carbon and cocoa. We use carbon, the C based API. However, new features in the operating system are very often only available in cocoa. Cocoa is Objective C, not C. Safari, the Mac browser, is written in cocoa. So we call it, leading to wild clipping problems and all sorts of amazing interop issues that we work around. Did I mention that Macintosh controls didn't clip against each other until a few years ago so we had to roll our own sibling and parent clipping code?
AWT is a free threaded widget toolkit that comes with it's own event loop. On Windows, we hook into the event queue and cross post keystrokes. On Motif and GTK, life is easier, we implement the XEmbed protocol, which is a bunch of low level X windows calls. On the Mac, after being broken for ages, we got help from Apple. The Mac operating system has no concept of multiple event loops. Somehow, Apple found a way to make it work. The icing on the cake is that AWT is implemented in cocoa, not carbon.
On the Java side, we need 1.2 VM's or greater and run on J2SE and J2ME. If you recompile the native libraries, we'll run on 1.1.8.