Plattformunabhängig programmieren

[creed steiger]

Zitat von Hisoka:

Aus meinen Erfahrungen ist auch Lazarus und die LCL nicht brauchbar. Die Performance der erstellten Anwendungen ist katastrophal. Sie ist teilweise so schlimm, das Anwendungen unter leichtgewichtigen Windowmanagern absolut nicht laufen. Also es ruckelt bis zur Unkenntlichkeit.(zumindest unter GTK2)

Würde also im Endeffekt eher C++ und Qt/wxWidgets nehmen.

Was spricht gegen LCL/Qt?
Davon abgesehen wäre unter "leichtgewichtigen" Systemen eher fpGUI oder MSEgui die beste Wahl anstatt GTK2.

[Hisoka]

Zitat von creed steiger:

Was spricht gegen LCL/Qt?
Davon abgesehen wäre unter "leichtgewichtigen" Systemen eher fpGUI oder MSEgui die beste Wahl anstatt GTK2.

fpGUI und MSEgui integrieren sich mal gar nicht ins Betriebssystem. Mag vielleicht einigen egal sein, aber nicht jedem. Der Punkt ist aber, eine Neuentwicklung der Anwendung mit Python und PyGTK hatte mehr Funktionen und lief deutlich besser als die Pascal/LCL variante. Also da wurde das ganze einfach schlecht umgesetzt, denn die LCL zeichnet zu viele Sachen selbst, was dazu führt das eine große Menge an Ressourcen verschwendet werden. Wobei das GTK1 Interface nicht so schlimm ist, dafür ist es aber hässlich wie die Nacht.


Die Qt Variante könnte ganz brauchbar sein, hab mich mit der aber nicht so sehr beschäftigt, denn wenn ich mit Qt arbeite kann ich auch gleich was ordentliches nehmen und QtCreator wählen und damit die Anwendung erstellen. Die IDE ist wenigstens ausgereift, stabil und bei der direkten Qt Nutzung bekommt man eben noch mehr als nur eine Interface Bibliothek. Damit ist gemeint das die LCL die Möglichkeiten welche Qt bietet nicht nutzt.

[Unwissender]

Hallo fkerber,

was ist eigentlich der Ausgangspunkt der Debatte gewesen? Ich glaube Du sagtest, dass Du jetzt gelesen hast, das irgendwer sagt: "Java ist doof!" (ok, etwas vereinfacht ausgedrückt ).

Aber mal ganz ehrlich, hast Du das nicht schon mal gelesen? Seit ich mit Java arbeite habe ich das schon häufiger gelesen, trotzdem verdienen meine Kollegen und ich (und viele andere auch) ganz gut mit Java Programmierung ihr Geld und hey, unsere Kunden sind (meistens) ganz zufrieden. Wie in jedem Unternehmen gilt das nicht immer, aber noch kein Kunde hat sich wegen der Programmiersprache beschwert.

Ich meine das übrigens ernst und finde es wichtig für die Debatte. Den Kunden oder Deinem Geldgeber ist es in der Regel egal welche Programmiersprache Du verwendest. Für die bleibt letztlich eine Anforderung die sie erfüllt sehen wollen und die Frage was es kostet. Natürlich gibt es auch Leute die Dir vorschlagen nimm doch Technik X oder die nach einer Java-Anwendung fragen, die Folgendes kann, es ist jedoch nicht deren Aufgabe sich über die technische Umsetzung sorgen zu machen. Ist eine Java-Anwendung nötig, weil die eine eigen QS-Abteilung haben, die nur Java kann, den Quellcode mitkaufen und der eben dort geprüft wird, dann ist das Anforderung und wird mit Kosten berechnet. Wollen die nur Plattformunabhängigkeit (für eine definierte Auswahl von Systemen) bleibt es dem Auftragnehmer überlassen ob der für Linux in C, MacOS in Objective-C und Windows in Java programmiert/ programmieren lässt oder nicht.

Was jetzt also die (ewige?) Debatte um Java angeht, ob es gut oder schlecht ist, so gilt hier das gleiche wie für andere Sprachen auch, die Antwortet lautet: depends. Z.B. kann C++ super sein, wenn Du eine IDE für Windows schreibst (was nicht heißt das andere Sprachen nicht auch super dafür sein können!). Schreibst Du aber einen Linux-Kernel, ist es ungeignet (siehe Post).
Auch Java ist nicht die eierlegende Wollmichsau. Möchtest Du einen Treiber programmieren, ist eine abstrakte Ausführungsschicht so ziemlich das Ungeeignetste, was einem einfallen könnte, das gilt somit auch für .NET Sprachen/ die CLI oder Interpreter. Das versteht sich von selbst. Auch gibt es die ewig gleichen Gerüchte, dass Java besonders langsam ist (gilt schon sehr lange nicht mehr) oder dass die Entwicklung mit der Sprache X (gerne wird hier C# benannt) 30% schneller ist oder so.

Das ist alles so pauschal wie falsch. Es kommt immer darauf an, was Du machen möchtest. Einen ganz wichtigen Punkt hast Du ja schon benannt, Java ist schon fast überall installiert. Das darf (und sollte) man nicht unterschätzen. Natürlich kann man jetzt auf MyBlaster, Conficker oder I-Love-You verweisen, die waren auch weit verbreitet, aber irgendwie doch nur unter Windows (was für die weite Verbreitung von Windows spricht und nicht gegen das OS!). Bei den Dingen, die wie Java oder FireFox, eher freiwillig verbreitet werden, spricht aber eine gewisse Alleinstellung und/oder Qualität für das Produkt. Java gibt es jetzt auch schon ein paar Jahre und bis heute finden sich viele Firmen, die freiwillig auf die Sprache setzen oder die Laufzeitumgebung auf ihren Systemen installieren, trotz der "vielen Nachteile" über die man so gerne liest. Man kann also davon ausgehen, dass es auch Vorteile geben muss oder vielleicht nicht alles stimmt was Leute gerne so behaupten.

Wie schon erwähnt, auch Java hat bestimmte Einsatzzwecke, für die es sich besser eignet und solche, für die es ungeeignet ist. Am Stärksten wiegt immer die Abstraktionsstufe, die Java mitbringt. Java gut für solche Anwendungen, die eine hohe Abstraktionsebene benutzen (und das sind viele Fachanwendungen). Hier möchte man nicht eine bestimmte CPU direkt ansprechen, einen Scheduler selbst steuern oder Treiber bereitstellen, sondern schnell und effizient eine komplexe Problematik (in der fachlichen Domäne) umsetzen.
Hier wird man eher schauen welche Frameworks bereits zur Verfügung stehen und da ist Java einfach sehr gut aufgestellt. SourceForge z.B. hat immer noch deutlich mehr Java-Projekte als irgendwas anderes, JasperReports und Birt sind sehr gute Report-Generatoren, mit JSF gibt es eine gute Mölgichkeit komponentenbasiert Webanwendung (HTML nicht Applets!) zur Verfügung zu stellen, mit der JPA gibt es freie O/R Mapper. Ist so nicht ganz korrekt, denn Java oder die JSRs definieren mit JSF oder JPA erstmal nur Schnittstellen, die eigentliche Bereitstellung erfolgt über Implementierungen (von denen es dann wieder gute Referenzimplementierungen und Alternativen gibt, z.B. EclipseLink und Hibernate als JPA Implementierung).

Wichtig ist aber, dass man für alle bekannten Datenbanksysteme einen jdbc-Treiber findet, der über so einen O/R-Mapper sehr einfache Zugriffe aus Java-Objekten auf die DB erlaubt. Noch viel wichtiger, auch ein Transaktionmonitor ist über Spring oder einen JEE Container gleich mit bei und hier steckt der wahre Mehrwert! Natürlich hat .net bestimmt ähnliche Technologien, aber vergleicht man das z.B. mit C, so fehlt dort dieser "quasi Standard". Ihn selbst zu schreiben und eine gute Qualität sicherzustellen ist mit einem Aufwand von mehreren Personen-Jahren zu beziffern (die Zeit und Erfahrung ist sicher auch bei Java nötig gewesen, aber schon investiert wurden).

Ich möchte hier nur die Domäne von Java rausstellen, die liegt (imho) schon länger nicht mehr auf "plattformunabhängigkeit". Nimm einfach die bekannteste Konkurrenz, C# oder .net. Natürlich kann man jetzt sagen, dass .net Plattformunabhängig ist, aber stimmt das so? Kann ich in VisualStudio mit der neusten .net Version arbeiten (die neueste Version bietet sicher einen Mehrwert gegenüber anderen Versionen, sonst lässt MS die nicht entwickeln und VS ist eine wirklich gute IDE!) und das Produkt dann einfach unter Linux verwenden? Ich glaube nicht. Warum also hat MS so eine CLI geschaffen, wo doch plattformunabhängigkeit hier (offensichtlich) nicht im Fokus stand oder steht (nicht durch MS selbst)? Wenn man sich hier die Unterschiede zwischen .net und Win32 anschaut, dann liegen sie darin, dass C# stärker abstrahiert. Man hat viele mächtige Frameworks wie LINQ und eine relativ hohe Abstraktionsebene. Der Code ist managed und somit gelten ähnliche Vor- und Nachteile wie für Java. Das zeigt aber einfach, dass diese Form von Programmierung/Entwicklung an Bedeutung gewonnen hat. C wird es wie C++ auch weiterhin geben und die Domänen die sie bedienen werden auch weiterhin vorhanden sein, aber es gibt auch viele Anwendungen höherer Abstraktion.

Ich würde Dir deswegen raten Dich nicht von Kommentaren irritieren zu lassen, die sagen, dass Java doof ist oder keine Treiberprogrammierung beherrscht. Klar, stimmt, wenn Du in die HW-nahe Programmierung eintauchen willst solltest Du nicht unbedingt mit C# oder Java anfangen, für die Anwendungsentwicklung ist es aber keine schlechte Sprache.
Auch solltest Du Dich nicht vom Feature-Wahn verfolgen lassen. Natürlich kannst Du in .NET verschiedene Sprachen kombinieren, sowie auch Java das kann (da gibt es eine Schnittstelle für und ich glaube z.B: Ruby oder Scala kann man darüber mit anderen Java-Klassen zusammen verwenden).

Bleibt noch die Sache mit dem GUI. Das ist (und das liegt in der Natur der Sache) ein Problem der Plattformunabhängigkeit. Hier muss man in Java 3 Möglichkeiten unterscheiden, alle mit ihren Vor- und Nachteilen:

1. AWT - Die "älteste" Fenstertechnik in Java. Hier wurde einfach der kleinste gemeinsame Nenner aller Plattformen genommen und in eine Java API gesteckt. Alle Elemente (Fenster, Button, ...) die es überall gibt werden nativ erzeugt. Ein AWT Fenster sieht unter Mac so aus, wie jedes andere auch, unter Windows sind es Windows-Fenster usw. Allerdings ist die Gemeinsamkeit eher klein, schon bei der Anzeige von Bäumen muss AWT passen.
2. Swing - Die Beschwerden über die viel zu vielen Dinge die AWT fehlten führten zu Swing. Um alle Komponenten darstellen zu können, wird bei Swing einfach ein viel kleinerer, gemeinsamer Nenner verwendet, die Zeichenfunktionen. Das führt dazu, dass Java-Anwendungen, die mit Swing erstellt werden, überall gleich aussehen (leider nicht immer schön). Ein Button wird hier einfach mit Grundoperationen gezeichnet, genauso ein Baum oder andere Komponenten. Das können alle Plattformen, aber schnell ist dann auch anders (daran hat man viel gearbeitet und mittlerweile ist die Leistung der Systeme und die Optimierung der Java Umgebung schon ganz ok!).
3. SWT - Bei SWT wurde eine Sammlung von unterstützten Komponenten festgelegt. Diese finden sich alle nativ unter Windows. Vereinfacht kann man hier eine Mischung aus AWT und Swing unterstellen, alle Komponenten, die nativ angeboten werden, werden vom OS aus erzeugt. Alles was eine bestimmte Plattform nicht direkt bietet, wird emuliert. Hier wird gerne darauf verwiesen, dass Windows SWT Anwendungen etwas schneller laufen als die unter Linux oder MacOS, aber ich glaube nicht, dass man hier im relevanten Bereich landet.

Dass die GUI Entwicklung mit Java besonders aufwendig ausfällt liegt hauptsächlich daran, dass es keine gute IDE mit kostenlosem GUI-Designer gibt. NetBeans fühlt sich immer etwas träge an, Ecipse bietet keinen integrierten GUI Editor. Eclipse selbst ist nutzt SWT (und zeigt eindrucksvoll wie wenig eine Java Anwendung schleicht oder sich von anderen Anwendungen unterscheidet). Man kann das Eclipse-Framework auch direkt verwenden um eigene SWT Anwendungen zu erzeugen. Auch finden sich kommerzielle Designer, die man sicher auch testen kann.
Ich selbst kann hier keine Empfehlung aussprechen, da ich aktuell nur Webentwicklung betreibe und dort bestimmt der Webdesigner schon das Layout mit seinen Tools, ich muss da nur die Logik einfügen. In Unternehmen wirst Du hier sicherlich keine Probleme haben ein paar hundert Euro für eine IDE oder eben so eine Erweiterung zu bekommen, ein Visual Studio (ohne Express) oder eine Delphi IDE werden ja auch bezahlt. Hier kommen wieder nur einfache Kosten-Nutzen-Rechnungen zu tragen (eine IDE kostet ein paar hunder Euro, Du kannst aber viiiel schneller arbeiten und nach wenigen PT amortisiert sich die Investion, der Rest interessiert keinen ).


Also nochmal zusammenfassend:

• Java ist mehr als plattformunabhängkeit
• Java ist gut für Fachanwendungen, schlecht für systemnahe Programmierung
• Java ist verbreitet und es gibt viele Frameworks (was die Entwicklung komplexer Fachanwendungen erleichtert)
• Java Anwendungen sind (wie z.B. Eclipse) nicht "langsame, graue Dinosaurier, denen man das Java schon ansieht"
• Java Applets sind nicht Java und sollten verboten werden! (da gibt es wirklich immer Ärger, aber das ist ein anderes Thema)
• Gutes GUI Design kostet bei Java

[Phoenix]

Zitat von Unwissender:

Wichtig ist aber, dass man für alle bekannten Datenbanksysteme einen jdbc-Treiber findet, der über so einen O/R-Mapper sehr einfache Zugriffe aus Java-Objekten auf die DB erlaubt. Noch viel wichtiger, auch ein Transaktionmonitor ist über Spring oder einen JEE Container gleich mit bei und hier steckt der wahre Mehrwert! Natürlich hat .net bestimmt ähnliche Technologien

Ein paar Schlagworte: Spring.NET, NHibernate, nDepend.

Nicht nur ähnliche. Zum Teil sogar die gleichen.

Zitat von Unwissender:

Ich möchte hier nur die Domäne von Java rausstellen, die liegt (imho) schon länger nicht mehr auf "plattformunabhängigkeit". Nimm einfach die bekannteste Konkurrenz, C# oder .net. Natürlich kann man jetzt sagen, dass .net Plattformunabhängig ist, aber stimmt das so? Kann ich in VisualStudio mit der neusten .net Version arbeiten (die neueste Version bietet sicher einen Mehrwert gegenüber anderen Versionen, sonst lässt MS die nicht entwickeln und VS ist eine wirklich gute IDE!) und das Produkt dann einfach unter Linux verwenden? Ich glaube nicht.

Glauben heisst nicht wissen. Ich sage Dir: Ja. Geht. Mache ich tagtäglich und funktioniert einwandfrei.

[rollstuhlfahrer]

Dann würde ich noch Python in den Raum werfen. Mein Informatiklehrer hat demletzt gesagt, dass Python die nächsten Jahre flächendeckend in der Rheinland-Pfälzer Sekundarstufe II als Konsolen/GUI-Anwendungsentwicklung eingeführt wird (anstelle von Delphi). Leider braucht man für Python sowas wie eine Runtime-Bibliothek. Unter Linux wird man schon fast dazu genötigt, diese zu installieren, wenn man bestimmte Anwendungen haben will, unter Windows dürfte es ein leichtes sein, diese mitzuliefern und im Anwendungsverzeichnis gleich mitzuinstallieren.

Ein weiterer Versuch wäre Erlang. Falls es jemand kennt: ejabberd (Jabber-Server) ist mit Erlang geschrieben, zur Verbreitung lässt sich allerdings nichts sagen.


Zu .net und Mono: Meine Musik-Lade-Software lief unter Linux mit Mono zusammen prima. Der Grund, warum sie nicht mehr läuft, ist im Betriebsystem zu suchen und die Software gehört einfach neu kompiliert. Dann würde sie auch wieder laufen. Leider ist mir das unter Linux viel zu kompliziert.

Bernhard

ADD: Und wenns nur Konsole sein soll, ist PHP auch einen Blick wert.

[Mithrandir]

@Feuervogel:
Der einzige Nachteil wäre vielleicht, dass WPF-Anwendungen nicht von Mono unterstützt werden...

[Phoenix]

Nicht unbedingt.
Silverlight ist am kommen, und SL-Anwendungen kann man auch auf dem Desktop laufen lassen (out-of-browser applications). Und mit Moonlight gibt es die Mono-Version von Silverlight auch auf allen Plattformen - auch mit out-of-browser support.

[BUG]

Wenn Java als Sprache nicht gefällt, gibt es auch einige andere interessante Sprachen (z.B. Scala, Gosu) die auf der JVM laufen und Java-kompatibel sind.

[fkerber]

Hi,

erstmal wow für die Vielzahl und die Länge der Antworten, danke.


@Phoenix:
Danke für die Ausführungen, jetzt bin ich schlauer.


@Unwissender:
Ich habe diese Aussage zum Anlass genommen, um mal "über den Tellerrand" zu schauen.
Natürlich renne ich jetzt nicht los und suche was anderes, nur weil jemand gesagt hat "Java ist doof" - und mir sind die Vorteile von Java ja ebenfalls geläufig und ich weiß sie zu schätzen. Allerdings hat mich gerade die GUI-Entwicklung beim letzten Projekt nahezu in den Wahnsinn getrieben und mich viel Zeit gekostet, damit es wenigstens ansatzweise manierlich aussah - und trotzdem war es hässlich. Dazu kommen dann auch so Sachen, dass bspw. unter Mac die Tastenkombis zum Kopieren, Einfügen etc nicht wie gewohnt mit Apfel+C/V funktionieren sondern nur mit Strg+C/V - das ist für Otto-Normal-Nutzer ungewohnt und vllt. sogar unhandlebar, weil er nicht auf die Idee kommt etc. Auch die Integration ins Fenster-Schließen-Konzept von Mac geht von Haus aus nicht wie sie soll, sondern erfordert ein extra Eingreifen etc. - halt so viele Kleinigkeiten.

Daher will ich einfach mal schauen, was es da sonst so gibt. Da ich privat gänzlich unter Mac unterwegs bin (von VMs abgesehen) sind schon alleine wegen der Verbreitung von Windows Lösungen für mich interessant, die ich sowohl für mich programmieren kann, aber vllt. auch irgendwo "unters Volk" bringen kann (und dann sollte Volk nicht auf Mac-User beschränkt sein).
Dank Android werde ich Java so oder so nicht so schnell den Rücken kehren, aber ich denke, es schadet nichts, auch mal was anderes anzutesten.


@Rollstuhlfahrer
Das mit Python ist auch durchaus interessant.
Wie im Eingangspost erwähnt habe ich auch schon einiges mit Python gemacht und die Sprache und Ihre Funktionalitäten finde ich auch recht sympathisch. Allerdings waren das bislang reine Entwicklung für Multi-Touch-fähige Eingabegeräte mit einer speziellen Bibliothek, die sowohl das Tracking übernimmt, wie auch sämtliche grafische Elemente zur Verfügung stellt (--> www.libavg.de ). Ist ne nette Sache, aber eben nicht für normale Alltagsprogramme sondern quasi nur solche Programme, deren GUI komplett durch Grafiken bzw. zumindest grafische Elemente dargestellt wird (und nein, ein normaler Button ist kein grafisches Element in dem Sinne, den ich meine ).

Also mal schauen, was es da gibt, um normale GUIs zu produzieren.
Gibt es "prominente" Programme, die mit normaler GUI in Python geschrieben sind?


@BUG:
Doch doch, Java als Sprache gefällt (zumindest mir) - meine Aufgaben konnte ich damit bisher gut umsetzen, solange sie keine GUI hatten


Liebe Grüße,
Frederic

[JamesTKirk]

QuickAndDirty hat zwar schon Free Pascal und Lazarus angesprochen, ich möchte da jedoch noch etwas ausholen.

Erstmal Free Pascal ist ein Open Source Object Pascal Compiler und für unterschiedliche Plattformen (x86, x86_64, ARM, Sparc, Power PC) und Betriebssysteme (u.a. Windows, Windows CE, Linux, Mac OS X, BSD, Solaris, DOS, OS/2) verfügbar. Der Compiler kompiliert die Anwendungen nativ für die jeweilige Zielplatform, ist also dann an den CPU Typ und das Betriebssystem gebunden (im Gegensatz zu Java, manchen .NET Programmen und den Scriptsprachen).

Aber auch wenn die Anwendung binär an ein bestimmtes Betriebssystem gebunden ist, so bietet Free Pascal eine plattformunabhängige RTL (so Sachen wie Writeln, TList, etc) und die Möglichkeit Code nur für bestimmte Plattformen zu kompilieren (wie es in Delphi ja auch möglich ist). Auch das Einbinden von anderen Bibliotheken (DLL, SO, Dynlib), welche eine flache C API bereitstellen, ist relativ einfach möglich (das berühmte "external 'Foo' name 'Bar'"). In der Entwicklungsversion des Compilers kannst du sogar Objective-C Klassen anbinden (hierzu wurde von der Mac Community eine eigene Spracherweiterung namens Objective Pascal entwickelt).

Das Kompilieren von verschiedenen Betriebssystemen nach Windows und Windows CE ist im großen und ganzen ohne weitere Verrenkungen möglich (dank internem Linker und zumindest für x86 und x86_64 auch internem Assembler). Um von Windows nach Linux zu kompilieren benötigt man schon passende Binutils (vor allem Linker) und die Bibliotheken des Zielsystems (z. B. libc, libpthreads, libgtk, etc.). Letzteres kann auch mal ein Problem sein, wenn du ein auf z. B. einem ArchLinux kompiliertes Programm (mit solchen Abhängigkeiten) auf einem Ubuntu laufen lassen möchtest, da ersters andere (meist neuere) Bibliotheken verwendet (Linux ist da etwas unverzeilicher als Windows). Hier hilft dann nur auf dem Zielsystem neu kompilieren. Das Cross Kompilieren nach Mac OS X ist dann (sowohl von Windows, als auch von Linux) ein noch größerer Terz (ähnliche Problematik wie unter Linux, nur noch etwas kopfzerbrechender).

Kompilierst du allerdings auf der jeweiligen Zielplatform (Windows CE und iPhone mal ausgenommen), hast du mit den Bibliotheken kaum Probleme.

Free Pascal alleine bietet allerdings keine GUI (von FreeVision, einem Klon von TurboVision für die Textmode IDE mal abgesehen). Du kannst natürlich auf die verschiedenen GUI Toolkits zugreifen (WinAPI, GTK(2), Qt, Carbon, Cocoa), musst allerdings für jedes Toolkit ne Extrawurscht machen (bei GTK und Qt etwas weniger, da diese auch auf anderen Plattformen als Linux laufen).
Möchtest du jedoch plattformunabhängig mit GUI arbeiten, so sind drei bekanntere Varianten möglich:

• LCL
• fpGUI
• MSEgui

Ersteres wird von der Delphi ähnlichen IDE Lazarus zur Verfügung gestellt und lässt sich ähnlich zur VCL verwenden. Die Entwickler streben danach LCL-Anwendungen auf dem jeweiligen System so nativ wie möglich aussehen zu lassen. Für die Plattformunabhängigkeit wurde eine Abstraktionsschicht, das sogenannte Widgetset eingeführt und erlaubt es dir zu bestimmen, ob eine kompilierte Anwendung nun die WinAPI oder Qt (als Beispiele) verwendet. Du kannst so zum Beispiel auch Qt Anwendungen für Windows entwickeln (nicht alle Kombinationen machen allerdings Sinn, wie Cocoa auf Windows CE). Diese Abstraktionsschicht bringt allerdings auch Performanceeinbußen mit sich. Ich persönlich empfinde diese jedoch nicht als so gravierend wie von Hisoka beschrieben. Hier empfehle ich dir (falls näheres Interesse besteht) einfach mal die IDE herunterzuladen und zu schauen, ob dir die Performance ausreicht (wobei du hier eventuell warten solltest, da sich zur Zeit ein neues Release in Vorbereitung befindet - das "aktuelle" ist bereits über ein Jahr alt und dementsprechend viel hat sich seitdem geändert).

Im Gegensatz zur LCL sind fpGUI und MSEgui komplette Neuentwicklungen. Beide haben den selben Look der Anwendung unter allen unterstützten Plattformen zum Ziel. Zu MSEgui kann ich jedoch nicht viel sagen, da ich mich noch nicht damit auseinandergesetzt habe. fpGUI ist jedoch näherungsweise ähnlich zur LCL/VCL und unterstützt zur Zeit Windows und Linux (bzw. allgemeiner: X-Server basierte Systeme). Mac OS X Unterstützung sowie Unterstützung für Open GL und Linux Framebuffer als Backend sind in Entwicklung bzw. Planung. Während mseGUI eine komplette eigene IDE (MSEide) mitbringt, bietet dir fpGUI nur einen Formulardesigner an. Der eigentliche Code wird in der IDE deiner Wahl (MSEide, Lazarus, Free Pascal IDE) entwickelt.

Ich persönlich bin sehr zufrieden mit Free Pascal und Lazarus (fpGUI teste ich hin und wieder aus). Die "Cross Compile" Funktionalität setze ich vorwiegend ein, um Anwendungen für Windows CE zu entwickeln (Hauptentwicklung/-test unter Win32, Details korrigieren dann unter WinCE). Die Variante Linux => Windows verwende ich seltener. Ich habe jedoch einiges an Code, den ich unter Linux und Windows verwende und weiterentwickle, wobei kaum IFDEFs vorhanden sind.

Ich hoffe dies hat dir einen kleinen Einblick gegeben.

Edit: Link zu fpGUI korrigiert.

Gruß,
Sven