Um Windows-Software unter Linux zu benutzen, gibt es zwei völlig unterschiedliche Ansätze: Emulatoren, die den Anwendungen ganze Computer virtuell vorspiegeln, zum Beispiel VMWare, und Projekte wie Wine, die zwischen die Applikation und Linux eine Kompatibilitätsschicht (Application Layer) setzen, die die Windows-Systemaufrufe für Linux übersetzt. Doch den Schwerpunkt auf die Programm-Migration von Windows nach Linux setzen bedeutet nicht, dass es das Problem anders herum nicht gäbe: Viele Linux-Benutzer, die beruflich mit Windows arbeiten müssen, ärgern sich darüber, dass ihnen die Flexibilität der Kommandozeile nicht zur Verfügung steht. Andere möchten lieb gewonnene X-Client-Programme auch unter Windows benutzen, stellen aber fest, dass kommerzielle X-Server für Microsoft-Betriebssysteme oft sehr viel Geld kosten und dass die kostenlosen nicht leistungsfähig genug sind.

Warum nicht andersrum?
Bereits im Jahre 1995 begann Steve Chamberlain, Entwickler bei Cygnus, an einer Lösung des Problems zu arbeiten. Sie sah eine Bibliothek als Zwischenschicht zwischen dem jeweiligen Unix-Programm und Windows vor, also einen Application Layer. Steve gab dieser Bibliothek den Namen Cygwin, zusammengesetzt aus Cygnus und Windows. Weitere Entwickler trugen zum Projekt bei. Als Red Hat Cygnus im Jahre 1999 kaufte, entschied man sich, Cygwin kontinuierlich weiterzuentwickeln.

Bei der Cygwin-Bibliothek handelt es sich somit um das Gegenstück zu Wine: Sie übersetzt die Systemaufrufe (System Calls) der Unix-Programme in für Windows verständliche Befehle. Auf diese Art und Weise merken weder die Unix-Programme, dass sie genau genommen mit Windows kommunizieren,
noch Windows, dass es Programme aus der Unix-Welt ausführt.

Das Ergebnis kann sich sehen lassen: Cygwin ist mittlerweile zu einer komplexen, gut funktionierenden Bibliothek herangereift, mit der sich die verschiedensten Unix-Tools unter Windows einsetzen lassen: »bash«, »ls« und »dd« gehören zu den eher unspektakulären Beispielen; mittlerweile kann man sogar XFree86 und den Gnome-Desktop mit Hilfe von Cygwin unter Microsoft-Betriebssystemen ab Windows 95 (nur nicht mit Windows CE) betreiben.

Die Installation des Pakets ist alles andere als schwierig. Mittels Setup ein leichtes Spiel.Als Antworten auf die Fragen können die Standardwerte übernommen werden, doch bleibt es dem Benutzer überlassen, Einstellungen zum Zielverzeichnis oder zu dem einzusetzenden Proxyserver individuell vorzunehmen.
Bei der Paketauswahl empfiehlt es sich, sorgfältig eine eigene Auswahl zu treffen - der Standard-Installationsumfang fällt eher spartanisch aus.

Bei der Wahl des Servers, von dem die zu installierenden Cygwin-Pakete heruntergeladen werden sollen, führt wegen der unterschiedlichen Erreichbarkeit letztlich nur Ausprobieren zum Ziel. Mit Hilfe des Setups lassen sich später auch bislang nicht ausgewählte Programmpakete nachträglich einspielen
sowie bereits installierte aktualisieren.

Bourne again unter Windows
Vorausgesetzt, dass Sie den Haken vor »Add to Start Menu« nicht entfernen, steht nach erfolgreicher Cygwin-Installation unter dem Start-Menüpunkt »Programme | Cygwin« der Eintrag »Cygwin Bash Shell«. Ein einfacher Klick darauf genügt, um ein DOS-Fenster zu öffnen, in dem sogleich eine Bash startet.
Hier stehen Ihnen nun alle Unix-Tools zur Verfügung, die Sie während der Installation ausgewählt haben.

Dazu gehören unter anderen auch »gcc« und »g++«. Es handelt sich aber um für Cygwin modifizierte Versionen der originalen GNU-Compiler. Programmierer, die sich über die Aussicht freuen, unter Windows für Linux entwickeln zu können, seien gewarnt: Als Crosscompiler taugt der Cygwin-»gcc« leider nicht. Er produziert ausschließlich Cygwin-kompatible Programme, die sich nativ unter Windows nur ausführen lassen, wenn die Bibliothek »cygwin1.dll« im Bibliotheken-Pfad von Windows steht.

Wenn ein unter Linux erstelltes Programm keine speziellen Bibliotheken verwendet, erweist sich die Portierung nach Windows als Kinderspiel: Oft reicht es schon, den Quellcode mit dem Cygwin-»gcc« neu zu kompilieren und beim Installieren die »cygwin1.dll« in das systemweite Bibliotheken-Verzeichnis
von Windows zu kopieren.

X für ein W
Bei der Portierung von XFree86 auf Windows handelt es sich zweifelsohne um einen der größten Erfolge des Cygwin-Projekts. Cygwin/XFree86 macht es theoretisch möglich, von kleinen Programmen wie »xclock« über Window-Manager à la »fvwm« bis hin zu ganzen Desktopumgebungen wie KDE alle mögliche
Unix/Linux-Software mit der Cygwin-DLL zu betreiben. Das kommt nicht nur allen entgegen, die ihren Windows-Arbeitsplatzrechnern das Aussehen des heimischen Linux-Desktops verpassen wollen, sondern auch jenen, die schnell mal ein X-Client-Programm auf einem entfernten Unix-Rechner starten und auf dem Windows-Desktop anzeigen lassen wollen: »ssh« mit X11-Forwarding macht dies, eine entsprechend
schnelle Internetverbindung vorausgesetzt, möglich. Die Installation von Cygwin/XFree86 entpuppt sich dabei als genauso einfach wie die von Cygwin selbst: Sollten Sie das Gespann bei der Erstinstallation nicht ausgewählt haben, starten Sie »setup.exe« erneut, geben die gleichen Daten ein wie zuvor und selektieren bei der Paketauswahl den Eintrag »XFree | XFree86-base«. Unter demselben Menüpunkt finden sich auch andere vorkompilierte Programme für Cygwin/XFree86, zum Beispiel »fvwm« und Window Maker. Das Cygwin-unterstützte X11 läuft sehr stabil und könnte somit eine echte, frei verfügbare Alternative für alle Anwender sein, die auf der Suche nach X-Servern für Windows bislang auf teure kommerzielle Implementationen von X11 zurückgreifen.

Doch so schön die Cygwin-Welt auf den ersten Blick auch aussieht, die Sache hat einen Haken: Um Windows-Unzulänglichkeiten zu umgehen, gelangte Programmcode in die Cygwin-Bibliothek, der Modifikationen am Sourcecode der Linux-Programme notwendig macht. Größtenteils betrifft das die Limits für Datei- und Speichergrößen.

Damit eine etwas komplexere Unix-Software unter Cygwin läuft, verlangt dies folglich aktive Entwicklungsleistung, die nicht jedes Open-Source-Projekt aufbringen kann oder will.
Während die erforderlichen Anpassungen sich bei kleineren Projekten noch im Rahmen halten, überlassen große wie KDE und Gnome diese Aufgabe (besonders mit Blick auf sich häufig ändernde Programmierschnittstellen) anderen Entwicklern oder gar Teams.