Das Mono-Projekt wirbelt schon seit längerer Zeit immer wieder Staub auf. Auch mit großen Ankündigungen wird nicht gespart. Seit etwa einem Jahr wartet die Weltöffentlichkeit nun bereits auf die lange ersehnte Version 1.0. Für uns Grund genug, uns ein wenig umzuhören, um zu sehen, wie es um das Mono-Projekt bestellt ist und wie es in Zukunft weitergehen wird.

Als Miguel de Icaza begonnen hat, das .NET Framework nachzubilden, haben sich viele Entwickler sicherlich gefragt, ob das Projekt ein Erfolg werden würde und ob es überhaupt möglich sei, eine komplette Microsoft-Umgebung so ohne Weiteres ansprechend nachzubilden. Ich habe mich damals selbst gefragt, warum sich Miguel das antut, da es ja für Unix-Systeme im Prinzip schon alle Programmiersprachen gibt, die man sich nur vorstellen kann. Gut eineinhalb Jahre später sehe ich die ganze Situation ein wenig anders und beginne langsam zu erkennen, welch gewaltiges Potenzial in Mono steckt und welche Möglichkeiten sich bieten. Zwar ist Mono noch weit davon entfernt, eine echte, absolut zuverlässige Alternative zu anderen Entwicklungsumgebungen zu sein, aber es gibt jede Menge gute Ansätze, die sicherlich für zukünftige Projekte genutzt werden können.

Wann gibt's endlich 1.0?
Die meisten Leute werden diesen Artikel vermutlich lesen, weil sie endlich wissen wollen, wann Mono in Version 1.0 zur Verfügung stehen wird. Genau das hat mich vor mehr als einem Jahr mein Verlag gefragt, als es darum ging, einen Zeitplan für ein Buch über Mono auszuarbeiten. Mittlerweile sind es nun schon zwei Bücher geworden, Mono ist immer noch nicht fertig und mehr als ein Jahr später stellt sich wieder die selbe Frage - die Antwort hat sich im Prinzip seit damals nicht verändert: Mono 1.0 wird im zweiten Quartal dieses Jahres endlich verfügbar sein (so zumindest will es die offizielle Roadmap). Das ist zumindest der aktuelle Stand der Dinge. Sollte mich jemand nach meiner persönlichen Meinung fragen, würde die Antwort etwas anders aussehen: Wahrscheinlich bald, aber sicherlich irgendwann.

Aktuelle Entwicklungen
Das Mono-Framework hat sich in den letzten Wochen und Monaten massiv und spürbar weiterentwickelt. Vor allem die Portierung auf verschiedenste Betriebssysteme scheint zügig voranzuschreiten. Vor wenigen Monaten war Mono im Prinzip nur auf Windows und Linux lauffähig. Mittlerweile läuft Mono bereits auf Windows, Max OS X und auf Linux (x86). In zukünftigen Versionen von Mono werden sowohl Solaris und andere Betriebssysteme unterstützt werden. Das klingt nicht gerade nach einer großen Weiterentwicklung - der Bytecode Interpreter ist allerdings bereits für Linux auf S/390 und PPC verfügbar, was auf eine rasche Portierung auf diese Systeme hoffen lässt.

Mit der Portierung auf weitere Betriebssysteme wird wohl auch die Akzeptanz von Mono weiter steigen, da es für Firmen immer attraktiver wird, Mono als Ersatz für Java einzuführen. Vor allem die Verfügbarkeit von Grafikbibliotheken wie Gtk# und Qt# spielt dabei noch eine wichtige Rolle, aber dazu später mehr.

JIT
Vor einigen Monaten hat ein Entwicklerteam um Dietmar Maurer einen neuen Just-In-Time-Compiler entwickelt, der leicht auf andere Betriebssysteme portiert werden kann und signifikant schneller läuft als das alte System. Der neue JIT ist ein wichtiger Bestandteil des Mono-Frameworks, da sich hier letztendlich entscheidet, wie performant Mono auf den einzelnen Systemen läuft. Durch die Optimierung des JIT hat man gegenüber Windows ordentlich aufgeholt und erreicht mittlerweile bereits recht gute Performancewerte.

Mono Basic
Basic ist vielen Programmierern wahrscheinlich bereits aus der Steinzeit der EDV bekannt. Den ersten Kontakt mit Basic hatte ich bereits vor zwölf Jahren (Freifach Informatik; 2. Klasse Gymnasium) - wenn ich mir heute modernen Basic-Code ansehe, fühle ich mich fast ein wenig in die nicht ganze so gute alte Zeit zurückversetzt. Die Sprache hat sich eigentlich nicht wirklich verändert. Auf Unix-Systemen war Basic bisher aus vielen Gründen kein Thema. Das Mono-Projekt versucht nun diese Lücke zu füllen und auch die Unix-Welt mit Basic zu beglücken. Die Arbeiten am Mono Basic-Compiler schreiten gut voran - sind aber noch nicht abgeschlossen, da einige wesentliche Elemente der Sprache noch fehlen. Mittlerweile ist es aber bereits möglich, mehr oder weniger brauchbare Programme zu übersetzen und lauffähigen Code zu erzeugen. Bis zum Erscheinen der Version 1.0 soll hier noch vieles bereinigt und vor allem weiterentwickelt werden.

mod_mono, ASP.NET und Co.
Microsoft hat .NET als universelles System konzipiert. Neben zahlreichen Sprachen wie C# und Co. hat auch ASP.NET seinen fixen Platz in der Microsoft-Welt. Da Webanwendungen sehr beliebt sind, gibt es zahlreiche Bestrebungen, Mono und Apache besser zu integrieren.

Mono schickt sich an, volle Unterstützung für ASP.NET bereitzustellen. Im Prinzip besteht ASP.NET aus zwei Komponenten: Web Forms (Web Applications Infrastructure) und Web Services (SOAP-basiertes RPC-System). Beide Module funktionieren bereits und es ist möglich, einfache Anwendungen zu betreiben. Klarerweise ist es noch nicht möglich, komplexere Programme zum Laufen zu bringen, aber auch Monos ASP.NET-Implementierung ist definitiv auf dem richtigen Weg.

Derzeit kann ASP.NET entweder mit mod_mono oder mit XSP (Light-Weight Webserver) verwendet werden. Sowohl mod_mono als auch XSP sind noch in einem frühen Beta-Stadium und sollten noch nicht im professionellen Umfeld eingesetzt werden.

Oberflächenprogrammierung
Die Gestaltung von grafischen Benutzeroberflächen ist in vielen Fällen ein zentraler Teil moderner Applikationsentwicklung. Ohne ansprechendes GUI ist eine Anwendung heute kaum mehr unter die Leute zu bringen. Im Endkundenbereich scheinen die Zeiten von textbasierten Ansätzen (aus meiner Sicht leider) vorbei zu sein. Microsofts .NET-Umgebung stellt eine Vielzahl von Klassen zur Verfügung, die es ermöglichen, grafische Benutzeroberflächen zu entwickeln. Leider sind die unter Windows verwendeten Klassen sehr tief im Windows-System selbst verankert. Das wirft ein gewisses Problem auf, da es nicht so einfach möglich ist, die Oberflächenbibliotheken nachzubilden.

Derzeit verfolgt das Mono-Team zwei sehr interessante Ansätze: Ein Projektteam versucht derzeit, die fehlenden Funktionalitäten des System.Windows.Forms Namespaces in Gtk# nachzubilden. Das ist nicht ganz einfach, da sich der Funktionsumfang von Gtk# und Windows.Forms doch ein wenig unterscheidet. Das Endergebnis wird daher nicht 100prozentig .NET-kompatibel sein.

Ein zweiter Ansatz macht sich die Ergebnisse des Wine-Projektes zunutze. Das Wine-Projekt versucht, die Win32-API eins zu eins nachzubilden. Durch den Umweg über die WineLib wird es daher möglich, die entsprechenden Funktionalitäten zu implementieren. Die Arbeiten an der Wine-basierten Lösung sind noch lange nicht abgeschlossen - die Fortschritte sind aber bereits mehr als gewaltig. Auf MonoWiki (www.nullenvoid.com/mono/wiki/index.php/WineSamples) kann man sich einige beeindruckende Beispiele ansehen, die sehr deutlich zeigen, dass das Mono-Projektteam gewaltige Anstrengungen unternimmt, um diese wohl entscheidende Hürde zu nehmen. Ohne eine gute Windows.Forms-Implementierung ist es wohl schwer, Firmen von Mono zu überzeugen.

Gtk# vs. Qt#
In der Oberflächengestaltung sind die GTK- und die Qt-Libraries ja bereits gute alte Bekannte, die sich großer Beliebtheit erfreuen. Beide Libraries sind mittlerweile auch für Mono verfügbar.

Die Implementierung von Bindegliedern zwischen Mono und externen Bibliotheken gestaltet sich relativ einfach, da das .NET Framework bereits Möglichkeiten vorsieht, die es gestatten, auf externen C/C++-Code (besser gesagt auf Shared Objekts respektive auf DLLs) zuzugreifen. Mit Hilfe von PInvoke kann man jede beliebige externe Funktion aufrufen und in Mono verfügbar machen. Genau diesen Weg haben die Entwickler von Gtk# und Qt# eingeschlagen. GTK# und Qt# sind nicht Bestandteil von Mono selbst - können aber sehr leicht nachinstalliert werden.

Gnome.NET
Miguel de Icaza ist nicht nur Begründer von Mono, sondern auch Begründer des Gnome-Projektes. Der Gnome Desktop erfreut sich großer Beliebtheit und ist de facto Teil jeder größeren Linux-Distribution. Es liegt daher nahe, eine Verknüpfung zwischen Mono und Gnome zu schaffen. Ziel ist es, die mächtigen Gnome-Bibliotheken für Mono verfügbar zu machen. Als Basis dient GTK, das bekanntlich ja auch das Rückgrad von Gnome bildet. Neben GTK# gibt es aber auch noch andere Module wie Gnome#, Glade#, Gconf#, Gda#, Gstreamer#, Rsvg# und DiaCancas#, die Mono bereits zur Verfügung stehen.

Mono and friends
Wenn man an Mono denkt, denkt man in erster Linie an einen C#-Compiler und an die große Anzahl von Windows-Klassen, die es nachzuprogrammieren gilt. Mittlerweile entwickelt sich das Projekt allerdings in eine Richtung, die ich selbst nicht für möglich gehalten habe. Das .NET Framework enthält im Prinzip ein Set von Klassen, das jede Programmiersprache für ihre Zwecke verwenden kann. Das ist ein grundlegendes Konzept, das zahlreiche Vorteile bringt.

Für Mono war lange Zeit nur ein C#-Compiler verfügbar. Mono Basic hat ebenfalls eine große Rolle gespielt, aber viel mehr hat man im Prinzip nicht erwartet. Mittlerweile haben sich allerdings Projekte entwickelt, die sich Unglaubliches zum Ziel gemacht haben.

IKVM.NET
IKVM.NET ist eine JVM für Mono und .NET, die die größtmögliche Interoperabilität zwischen Mono und Java ermöglichen soll. IKVM.NET selbst besteht aus mehreren Komponenten:

• ik.vm.net.dll: konvertiert Java-Bytecode in CIL; mappt System.Objekt auf java.lang.Object, mappt System.String auf java.lang.String und mappt System.Exception auf java.lang.Throwable
• Classpath.dll: Implementierung von GNU Classpath
• ik.vm.jni.dll: managt C++-Assembly, die das JNI-Interface anbindet
• ikvm.exe: vergleichbar mit java.exe
• ikvmc.exe: kompiliert Klassen zu .NET-Code
• netexp.exe: ein Tool zum Erzeugen von Stub Files

Ziel des Projektes ist es, die Migration von Java nach .NET/Mono zu erleichtern.

PHP goes Mono
PHP verfügt über eine Erweiterung, die es ermöglicht, auf Assemblies des .NET Frameworks zuzugreifen und via Mono einzubinden. Das hat den Vorteil, dass man auf jede Menge bestehenden Code, den es für PHP nicht gibt, zugreifen kann.

MonoLogo
Kann sich noch jeder an die schicke rosarote Schildkröte erinnern, die man zum Zeichnen verwenden konnte? In der Unterstufe war das mit Abstand meine liebste Programmiersprache - ich habe es allerdings nie geschafft, wirklich sinnvollen Code zu schreiben. Einige Freaks haben es aber fertiggebracht, ein Portrait eines früheren österreichischen Bundeskanzlers zu zeichnen, das mehr als authentisch war. Böse Zungen sagen, dass das auf markante Merkmale in der Mitte des Gesichtes zurückzuführen sei (www.aeiou.at/aeiou.encyclop.data.image.s/s600917a.jpg).

Anyway, mittlerweile wird an einem Logo-Compiler für Mono gearbeitet. Wie ernst man dieses Projekt nehmen kann, ist schwer zu sagen, da mir kein sinnvolles Projekt bekannt ist, das auf Logo basiert (von Sinowatz Portraits mal abgesehen).

Und was ist mit C?
C-Compiler erzeugen üblicherweise nativen C-Code, der nur auf der entsprechenden Zielplatform lauffähig ist. Mit lcc (www.cs.princeton.edu/software/lcc/) soll das anders werden. Dieser (leider nicht freie) Compiler erzeugt CIL-Code, der von der Laufzeitumgebung ausgeführt werden kann.

In den letzten Monaten sind auch immer wieder Rufe laut geworden, dem GCC ein CIL-Backend zu spendieren. Mittlerweile sind diese Wünsche aber noch nicht erhört worden. Gründe dafür dürften sicherlich die Komplexität dieses Unterfangens und vor allem der immense Arbeitsaufwand sein. Die Erweiterung des GCC hätte aber letztendlich den Vorteil, dass man gleich mehrere Programmiersprachen auf einmal an Mono angebunden hätte. Zwar bleibt abzuwarten, wie viele Leute wirklich Interesse haben, ihre Fortran-Programme in Form von CLI-Code verfügbar zu haben - im Sinne der Portierbarkeit von Binaries wäre das aber auf alle Fälle ein erheblicher Vorteil.

ComponentPascal und Co.
Eine Universität entwickelt derzeit einen Compiler für Component Pascal. Weitere Projekte beschäftigen sich mit Python, Oberon, Tachy, dotLisp, DeltaForth und ADA.

Datenschleuder
Datenbanken sind aus modernen Anwendungen nicht mehr wegzudenken. Um eine Datenbank mit Mono betreiben zu können, benötigt man eine Art Treiber, auch Data Provider genannt. Mit Hilfe von ADO.NET lassen sich Datenbanken relativ gut ansprechen und es wird möglich, Anwendungen halbwegs datenbankunabhängig zu gestalten. Das bringt bei größeren Anwendungen auf alle Fälle Vorteile.

Derzeit gibt es bereits Data Provider für die meisten üblicherweise verwendeten Datenbanken und Protokolle wie PostgreSQL, Oracle, DB2, ODBC, OLE DB, MySQL, Sybase, SQLite und für den Microsoft SQL Server. Leider sind einige Datenbanken wie SAP DB, Foxpro oder Firebird noch nicht mit Mono verwendbar. Es ist aber mit an Sicherheit grenzender Wahrscheinlichkeit davon auszugehen, dass dieses Manko bald behoben sein wird.

Größere Packages
Immer wenn es darum geht, größere Packages zu kompilieren, wird man sehr schnell sehen, dass man mit Batch-Files nicht sonderlich weit kommt. Auf Unix-Systemen verwendet man zur Optimierung des Build-Prozesses üblicherweise make. Viele Programme verlangen teilweise sogar explizit gmake und weigern sich, mit BSD make oder kommerziellen Varianten zusammenzuarbeiten. Makefiles haben eine lange Tradition - mit der Einführung von Java hat aber vor allem ein kleines Nebenprodukt für Aufsehen gesorgt: Die kleine fleißige Ameise namens Ant. Ant-Dateien basieren auf XML und sind daher von der Syntax her teilweise etwas besser handhabbar, als Makefiles es sind. Auch für Mono-Entwickler stellt sich die Frage nach dem optimalen Build-Tool und die Community hat daher einige Möglichkeiten ersonnen, die das Leben mit großen Mengen von Quellcode spürbar erleichtern können.

Ein Tool namens Nant beispielsweise lehnt sich sehr stark an Apache Ant an. Nant-Konfigurationsdateien basieren ebenfalls auf XML und haben de facto die gleiche Syntax wie Build-Dateien, die von Ant verstanden werden. Das macht das Tool sehr angenehm, weil man sich schnell zurechtfinden kann und es relativ leicht möglich ist, komplexere Build-Vorgänge zu modellieren.

Fazit
Das Mono-Projekt hat sich in den letzten Monaten prächtig entwickelt. Zwar gibt es noch immer keine Version 1.0, aber offenbar ist ein Ende der Fahnenstange in Sicht. Vor allem die Arbeiten am neuen VB-Compiler und an Windows-kompatiblen Forms schreiten unaufhaltsam voran. Viele kleine Projekte mit verschiedensten Zielen haben sich mittlerweile entwickelt und die Arbeit an ihnen geht in geordneten Bahnen vonstatten. Man kann den Entwicklern nur alles Gute wünschen und hoffen, dass das Projekt auch weiterhin ein voller Erfolg bleibt.
Ewald Geschwinde und Hans-Jürgen Schönig sind Autoren mehrerer Bücher zum Thema PostgreSQL und sind Betreiber der Cybertec Geschwinde & Schönig OEG (www.postgresql.at/), die sich mit PostgreSQL-Lösungen beschäftigt.