Wer Windows-Anwendungen unter Linux zum Laufen bringen will, kommt an Wine nicht vorbei. Wir untersuchen die freie und die kommerziellen Wine-Varianten auf ihre Praxistauglichkeit.
Die Geschichte von Wine begannt 1993 mit einem kleinen Tool, das bei Sun Microsystems entwickelt worden war. Es sollte ermöglichen, unter Solaris auf SPARC Windows-Applikationen “out of the box” – also ohne Portierung – nutzen konnten. Bereits wenige Monate später wurden erste Versuche unternommen, dieses Werkzeug auch unter BSD und Linux zum Einsatz zu bringen – sozusagen die Geburtsstunde dessen, was heute unter dem Projektnamen Wine allgemein bekannt ist. Diese Bezeichnung ist ein Akronym und steht in bester GNU-Tradition für die Umschreibung “Wine is not an Emulator”.
Tatsächlich handelt es sich bei Wine [1] nicht um einen Emulator im klassischen Sinn. Das Tool bildet weder eine fremde CPU nach, noch emuliert es im engeren Sinne ein Betriebssystem. Wine legt sich vielmehr als Übersetzungsschicht zwischen Linux und die auszuführende Windows-Anwendung. Es fängt alle Windows-API-Aufrufe der Anwendung ab und versucht sie in deren Unix- und X11-Äquivalente zu übersetzen. Im technischen Sinn besteht Wine aus einem Loader, der Windows-Anwendungen lädt und startet, sowie einer Suite von Bibliotheken, welche die Übersetzung beziehungsweise Nachbildung der Windows-API-Calls übernimmt.
Die Rolle von Wine als Quasi-Dolmetscher zwischen Windows-Anwendungen und Linux macht klar, wo die potentiellen Probleme von Wine liegen: Übersetzungen können nur so gut sein, wie die Kenntnisse des Übersetzers von Sprache und Kultur der beiden beteiligten Parteien. Dass Microsoft ungern Interna der Funktionsweise seiner Betriebssysteme und Anwendungen preisgibt, ist hinlänglich bekannt. Aber auch andere Software-Hersteller lassen sich ungern in die Karten schauen und fühlen sich oft auch nicht gemüßigt, ihre Produkte nach Linux zu portieren.
Symptomatisch dafür ist Adobe mit dem Acrobat Professional, weswegen wir auch diese Software zu Testzwecken heranziehen. Als Testmaschine dient ein HP-Laptop, der über einen mit 1,7 GHz getakteten Pentium-4-Prozessor und 256 MByte Hauptspeicher verfügt. Als Betriebssystem dient Suse Linux 9.0 Professional.
Wine installieren
Alle gängigen Distributionen bringen Wine bereits im Lieferumfang mit. Meist wird das Paket jedoch bei der Standardinstallation ausgelassen. Um festzustellen, ob Wine auf Ihrem System bereits läuft, dient bei RPM-basierten Distributionen folgender Aufruf auf der Kommandozeile:
rpm -qa | grep -i wine
Wurde Wine bereits eingerichtet, erhalten Sie eine Rückmeldung wie beispielsweise wine-20040505-1 (Suse 9.0) oder wine-20040813-7 (Suse 9.2). Wie sich leicht erkennen lässt, dient hier das Release-Datum als Versionsnummer.
Es empfiehlt sich im Zweifelsfall, eine eventuell vorhandene ältere Version durch eine des aktuellen Jahrgangs (2005) zu ersetzen. Das lässt sich relativ schnell erledigen und bietet den Vorteil, dass man damit im Regelfall eine automatische und meist hinreichende (Vor-)Konfiguration erhält. Allerdings sollte man dazu die alte Version deinstallieren, da anderenfalls Probleme auftreten können. (siehe Kasten “Wine entsorgen”)
Wine entsorgen
Versuche zur Parallel- oder gar Mehrfach-Installation verschiedener Wine-Versionen sollte man tunlichst unterlassen. Auch bei der Installation einer neueren Release schadet es im Zweifelsfall nicht, die vorher installierte Wine-Spielart zu entsorgen.
Zunächst einmal gilt es zu klären, welche Version eigentlich installiert ist:
<B># rpm -qa | grep -i wine<B> wine-20040505-1
Als Antwort liefert das System die entsprechende Versionsbezeichnung – die Sie dann direkt in den Entsorgungsauftrag übernehmen. Im obigen Beispiel lautet dieser also rpm -e wine-20040505-1. Anschliessend sind die von Wine für jeden Account angelegten Verzeichnisse zu löschen:
# rm -rf /root/.wine # rm -rf /home/user/.wine […]
Nun sollten sämtliche relevanten Altlasten definitiv Geschichte sein. Der Weg für ein Wine-Upgrade ist damit frei. Gegebenenfalls deinstallieren Sie auf diesem Weg auch eine nicht mehr sauber funktionierende Wine-Installation.
Die eigentliche Installation läuft ebenso einfach wie unspektakulär ab. Zunächst besorgen Sie sich das aktuelle Paket (derzeit rund zwölf Megabyte gross) beim WineHQ [2]. Sie installieren es als root zum Beispiel für Suse 9.0 mit dem Befehl:
<B>#rpm -ivh wine-20050111-SuSELinux90.i586.rpm<B> Preparing… ########################################### [100%] 1:wine… ############################################## [100%]
Damit haben Sie Wine auch bereits auf fertig installiert, bei den aktuellen Versionen ist es auch vorkonfiguriert. Um die Konfiguration einzusehen und zu modifizieren, benutzen Sie das Tool winecfg. Dort können Sie auch einsehen und verändern, welche virtuellen “Laufwerksbuchstaben” welchen Devices zugeordnet sind.
Windows-Anwendungen installieren
Nun können Sie direkt mit der Installation der ersten Windows-Applikationen beginnen. Für unseren Test haben wir dazu eine recht weit verbreitete, aber offiziell nicht von Wine unterstützen Applikation ausgesucht: Adobe Acrobat 5.
Als Installationsquelle dient eine entsprechende Applikations-CD. Das CD-ROM-Laufwerk trägt in unserer Testkonfiguration das Alias “Z:”, sodass wir die Installation mit folgendem Aufruf starten:
wine 'Z:\media\cdrom\Acrobat 5\Setup.exe'
Hier müssen Sie Laufwerks- und Pfadangaben gemäß den Konventionen aus der Windows-Welt machen. Schließen Sie zudem den Programmpfad stets in Hochkommas (‘) oder Anführungszeichen (“) ein. Anderenfalls würde die Linux-Shell versuchen darin enthaltene Leerstellen und den darauf folgenden Text interpretieren.
Die Installation des Adobe Acrobat (Abbildung 1) dauert in unserem Beispiel rund 15 Minuten – wohlgemerkt: für eine einzige Applikation. Allerdings lohnt das Warten. Nach Abschluss der Programmeinrichtung belohnt der Aufruf
wine 'C:\Program Files\Adobe\Acrobat.exe'
mit einer funktionierenden Instanz des Adobe Acrobat, wie Sie Abbildung 2 entnehmen können.
Allerdings verlaufen nicht alle Programminstallationen derart problemfrei. Eine typische Stolperstelle tritt beispielsweise bei dem Versuch auf, das (ebenfalls nicht offiziell unterstützte) NetObjects Fusion – egal in welcher Version – einzurichten. Abbildung 3 zeigt das für zahlreiche Windows-Anwendungen typische Fehlerbild. Die Fehlermeldung führt etwas in die Irre: Die fehlende Schriftart ist keineswegs der Grund für das Problem. Die Anwendung lässt sich ohne installierten Internet Explorer schlicht nicht betreiben.
Alternative Crossover Office
Wer ernsthaft daran interessiert ist, Wine in einer produktiven Umgebung einzusetzen, sollte indes einen Blick auf das Paket Crossover Office von CodeWeavers [2] werfen. Es handelt sich dabei um ein kommerzielles Wine-Produkt, für das je nach Ausführung Lizenzgebühren zwischen 39,95 (Standard-Version) und 69 US-Dollar (Multi-User-fähige Professional-Variante) anfallen. Dafür erhält man neben einer grafischen Bedienoberfläche auch ein deutlich benutzerfreundlicheres Handling. Allerdings räumt auch Crossover Office die generellen Probleme des WINE nicht vom Tische (siehe Kasten “Wine is not an emulator”). Crossover Office Standard stellt also im Wesentlichen eine “Verpackung” dar, die es einfacher machen soll, mit Wine umzugehen.
Zumindest ein technisches Details jedoch hat Crossover Office dem puren Wine voraus: Der unter dem Original leidige Windows-Reboot wird hier zu einer Trivialität – auf diesen Punkt werden wir später noch zurückkommen. Vorerst einmal muss jedoch auch Crossover eine Acrobat-Installation über sich ergehen lassen, um seine Qualitäten in der Praxis unter Beweis zu stellen. Zum Test nutzen wir das von Codeweavers angebotene Demo-Paket, das sich für Testzwecke einen Monat lang uneingeschränkt nutzen lässt. Allerdings setzt der Download eine Registrierung voraus.
Die Installation erfolgt in einer auf den ersten Blick ungewöhnlichen, jeodch zweckmäßigen Weise über ein vorgeschaltetes Shell-Script:
install-crossover-standard-demo-4.1.sh
Die Installation verläuft problemlos, das Ergebnis ist eigentlich selbsterklärend (Abbildung 4). Die vorgeschlagene Konfiguration kann man in aller Regel schlicht übernehmen. Als Resultat der Anstrengungen wartet das Tool mit seinem Hauptfenster auf (Abbildung 5).
Einziger Kritikpunkt: Um späteren Konflikten aus dem Weg zu gehen, muss man die von Windows üblicherweise eingesetzten Schriftarten nachrüsten. Unter dem Reiter Fonts im Hauptfenster ist alles soweit vorbereitet, dass sich auch dieses Problem durch einen Download der fraglichen Schriftarten schnell aus der Welt schaffen lässt.
Wir beginnen auch hier unsere Versuchsreihe wieder mit Adobe Acrobat Professional 5.0. Dazu gilt es im Reiter Add/Remove auf Install zu klicken. Im daraufhin erscheinenden Fenster wählen wir Unsupported Software und lokalisieren dann noch die Installationsquelle (meist /media/cdrom).
Einmal installierte Anwendungen startet man entweder über den Reiter Menus im Crossover-Hauptfenster, oder ruft Sie auf dem klassischen Weg über die Kommandozeile auf:
~/cxoffice/bin/acrobat
Wenig Sinn macht es übrigens, eine bestimmte Windows-Version als Umgebung vorauszuwählen: In der Default-Einstellung laufen die Windows-Programme meist reibungsloser. Windows-Applikationen, die explizit Windows NT 4 bzw. NT 5 (Windows 2000) als Betriebssystem einfordern, lassen sich unter Wine meist nicht oder zumindest nicht reibungslos ausführen. Dies beweist auch ein Versuch mit Adobe Acrobat 6: Schon der (Windows-) Installer stürzt sofort ab.
Im Gegensatz zu Wine bietet Crossover Office übrigens eine einfache Möglichkeit zum “Reboot” von “Windows”. Dazu geben Sie an der Kommandozeile folgendes ein:
./cxoffice/bin/cxreboot
Einen Screenshot der resultierenden Meldung finden Sie in Abbildung 6. Ein Schelm, wer Schlechtes dabei denkt …
Fazit
Wine ist ein sehr ambitionierter Versuch, Windows-Applikationen nativ auf Unix ablaufen zu lassen. Im Sinn eines absoluten Minimalismus beschränkt sich Wine dabei auf Übersetzungsdienste zwischen der Betriebssystem und der Anwendung. Für dieses Konzept spricht der geringe Aufwand sowohl auf der Soft- wie auch der Hardwareseite.
Mit CrossOver als Aufsatz können auch Linux-Anwender ohne große Hintergrundkenntnisse das Tool problemlos einsetzen. Vor dem Erwerb von Crossover Office sollte man allerdings die Lauffähigkeit der zum Einsatz angepeilten Windows-Anwendungen unbedingt anhand der Crossover-Trial-Version verifizieren. Verweigert eine benötigte Anwendung durchaus die Benutzung unter Wine beziehungsweise Crossover, dann bleibt meist nur das Ausweichen auf eine Virtuelle Maschine wie VMware (siehe Seite 32) oder Qemu (Seite 40).
Wine is not an emulator
Ein echter Emulator stellt, anders als Wine, einen mehr oder minder komplett abgeschotteten Bereich zur Verfügung, innerhalb dessen er einen kompletten Rechner simuliert. Selbst das Betriebssystem dieser “box in the box” muss separat installiert werden – mit allem, was dazu gehört. Nach diesem Prinzip lässt sich jede Applikation installieren und nutzen, die für das Betriebssystem der Virtuellen Maschine geschrieben wurde. Zu den gravierendsten Nachteile dieser Methode zählen der Performance-Verlust aufgrund des hohen Simulations-Overheads sowie hohe Lizenzkosten: Die virtuelle Maschine benötigt ein komplettes Betriebssystem.
Wine realisiert eine auf der Hand liegende Alternative: Statt das gesamte Betriebssystem zu simulieren, beschränkt es sich darauf, den Windows-Applikationen eine entsprechende Umgebung vorzugaukeln. Daher auch der von Wine intern verwendete Name “fake windows”:
# ls -a /home/user/.wine dosdevices fake_windows […]
Die Datenstruktur innerhalb der Wine-Verzeichnisse ist der unter einem “echten” Windows nachgebildet. Allerdings fällt das Faksimile alles andere als vollständig aus. Genau hier liegt die Schwachstelle des Konzepts: Anwendungen, die auf sehr spezifische Windows-Elemente zurückgreifen, laufen hier nicht selten vor eine (virtuelle) Wand.
Spielen mit Cedega
Wer Windows-Spiele unter Linux betreiben will, braucht Cedega von Transgaming [4]. Dabei handelt es sich um eine Version des API-Emulators Wine, den die Programmierer um die Funktionen der Multimediabibliothek DirectX erweitert haben. Tatsächlich laufen unter Cedega selbst aktuelle und grafikintensive Windows-Spiele wie Half Life 2 oder Far Cry.
Solche Leistung ist aber nicht umsonst zu haben: Für drei Monate Cedega-Nutzung verlangt der deutsche Distributor ixsoft knapp 13 Euro – es handelt sich um ein zeitabhängiges Subskriptionsmodell.
Wer nur einmal einen Blick auf Cedega werfen möchte, kann einen Großteil der Software selbst herunterladen und kompilieren. Es fehlen allerdings einige wesentliche Komponenten, ohne die viele kopiergeschützte Originale nicht laufen.
Cedega aus dem CVS
Ohne Subskription sind die Quellen nur im Versionskontrollsystem CVS zugänglich. Deshalb brauchen Sie zum Herunterladen das passende Programm cvs. Ist es auf Ihrem System verfügbar, melden Sie sich zunächst beim Server an:
cvs -d:pserver:cvs@cvs.? transgaming.org:/cvsroot login
Werden Sie nach einem Passwort gefragt, geben Sie cvs ein. Bei Erfolg gibt das Programm nichts aus, beschwert sich allerdings im Fehlerfall. Dann übertragen Sie alle Dateien auf den eigenen Rechner:
cvs -z3 -d:pserver:cvs@cvs.transgaming.org:/cvsroot co winex
Nach einer Weile finden Sie den kompletten Quellcode im Verzeichnis winex. Die Übersetzung gehorcht im wesentlichen dem bekannten Muster, allerdings waren für Fedora Core 3 spezielle Optionen nötig:
./configure --enable-opengl --enable-pthreads
Der Befehl make startet die Übersetzung, su -c 'make install' verteilt die Programme auf der Festplatte. Die mitgelieferte Beispielkonfigurationsdatei kopieren Sie als Ausgangsbasis an die richtige Stelle:
cp documentation/samples/? config ~/.wine/config
Vor dem Start müssen Sie noch einige Dateien und Verzeichnisse anlegen. Cedega erwartet nämlich Teile einer Verzeichnisstruktur, die derjenigen von Windows gleicht. Die Beispieldatei geht von einem Verzeichnis ~/.transgaming aus. Legen also ein Verzeichnis mit diesem Namen an, oder ändern Sie ihn in ~/.wine/config – dann müssen Sie im Folgenden auch das von Ihnen gewählte Verzeichnis verwenden. Die geforderten Unterverzeichnisse legen Sie so an:
mkdir -p ~/.transgaming/c_drive? /windows/system32 mkdir ~/.transgaming/c_drive/windows? /fonts
Eventuell müssen Sie noch einen Eintrag für das CD-ROM-Laufwerk in der Konfigurationsdatei ergänzen. Für das erste IDE-Laufwerk im System sieht das so aus:
[Drive H] "Path" = "/media/cdrom" "Type" = "cdrom" "Label" = "CD-ROM" "Filesystem" = "win95" "Device" = "/dev/hdc"
Nun können Sie das erste Windows-Programm installieren. Zum Test dient das beliebte Moorhuhn-Spiel in der Winter-Edition. Unter Cedega starten Sie die Installation mit dem Programm wine
wine moorhuhn_we.exe
Absolvieren Sie alle nötigen Schritte (siehe Abbildung 1), landet am Ende das Moorhuhn-Programm auf der Cedega-“Festplatte”, also im Verzeichnis .transgaming/c_drive, das dem C: unter Windows entspricht.
Abbildung 1: Das Moorhuhn-Installationsprogramm zeigt die normalen Windows-Pfade.
Damit das Spiel seine Dateien findet, wechseln Sie in das Installationsverzeichnis und starten es dort:
cd .transgaming/c_drive/Program\ ? Files/Phenomedia\ AG/Moorhuhn\ ? Winter-Edition wine MoorhuhnWinter.exe
Abbildung 2: Das Moorhuhn-Spiel läuft unter Cedega ohne weiteres.
Das Spiel läuft ohne Probleme und in normaler Geschwindikeit. Die anderen, getesteten Spiele ließen sich zwar alle mit Cedega installieren, brachen jedoch beim Start mit einer Fehlermeldung ab: Sie halten den Emulator irrtümlich für ein Programm, das versucht, den Kopierschutz zu umgehen.
Das kommerzielle Cedega enthält Code, der das verhindert. Wer aktuelle, kopiergeschützte Spiele betreiben will, kommt also um diese Version nicht herum. (ofr)
Infos
[1] WineHQ: http://www.winehq.org/
[2] Wine-Pakete: http://www.winehq.org/site/download
[3] Codeweavers: http://www.codeweavers.com/
[4] Transgaming: http://www.transgaming.com/
