© Markus Feilner

Immer mehr Windows-Anwendungen laufen dank Wine auch auf Linux. Dem Admin helfen zuvor Konfigurationstools, Debugger und zahlreiche Addons dabei, das gefürchtete “Totinstallieren” oder die “DLL-Hölle” zu vermeiden. Klappt alles, winken zahlreiche Vorteile gegenüber nativen Installationen.

Sie sind der Showstopper für Linux-Migrationen und der Alptraum vieler Admins: Fachanwendungen, die nur auf Windows laufen und sich nicht nach Linux portieren lassen.

Showstopper Windows

Abseits der leicht ersetzbaren großen Office- und Grafik-Pakete tummeln sich auf dem Markt unzählige, meist kleinere Programme, die als ganz spezielle Fachanwendungen die Bedürfnisse kleiner bis mittelgroßer Nischen bedienen. Nicht selten wurden sie von Ingenieurbüros für Kunden maßgeschneidert entwickelt und haben sich fürs Unternehmen oder die Behörde als die zentrale Anwendung erwiesen. Ist der Hersteller nicht in der Lage, eine Linux-Version zu erstellen, verhindert dies eine vollständige Migration zu freien Desktops.

Solche Anwendungen schrittweise in einem typischen Linux-Umfeld abzubilden, stellt sich daher immer wieder als zentraler Dreh- und Angelpunkt in Migrationsszenarien heraus. Verstärkt vom Trend zum Cloud Computing setzen Admins immer mehr auf Linux und eben auch auf die Systembibliotheken von Wine [1]. Die gibt es mittlerweile in Version 1.2, kurz nach Weihnachten 2011 erschien die Entwicklerversion 1.3.36, für Version 1.4 steht der Code Freeze vor der Tür.

Eben kein Emulator!

Die Software, deren Entwickler nicht müde werden zu betonen, man baue keinen Emulator (Wine steht für “Wine Is Not an Emulator”) kann auf zahlreiche Referenzen verweisen, aus deren Migrationserfahrungen eine nicht zu unterschätzende Hilfestellung entsteht.

Erst kürzlich kam am Robert-Musil-Institut der Universität Klagenfurt noch eine hinzu: Es nutzt eine Kombination aus einem virtuellen Linux-System und der Flexibilität der Wine-Konfiguration für die Klagenfurter Ausgabe von Robert Musils Gesamtwerk. Die elektronische Edition basiert auf der Windows-Anwendung Folioviews, die sich problemlos unter Linux starten lässt (siehe Kasten “Virtuell: Robert Musil in Klagenfurt”).

Virtuell: Robert Musil in Klagenfurt

Die Klagenfurter Ausgabe von Robert Musils (Abbildung  1) Werk ist 2009 als elektronische Edition auf DVD erschienen – realisiert mit der Windows-Anwendung Folioviews (Abbildung  2). Um den Kreis der potenziellen Benutzer zu erweitern, entschied sich das Institut die 2012 mit umfangreichen inhaltlichen Ergänzungen und Berichtigungen erscheinende zweite Ausgabe mittels Linux und Wine auch als fertige Installation innerhalb einer Virtualbox anzubieten.

Abbildung 1: Ein Graffiti-Portrait von Robert Musil am Musilhaus im österreichischen Klagenfurt.

Abbildung 2: Die digitale Ausgabe des Gesamtwerks des Klagenfurter Schriftstellers und Theaterkritikers Robert Musil bringt die Uni Klagenfurt mit Folioviews, Wine, Linux und Virtualbox dauerhaft für alle Betriebssysteme ins interne Netz der Anwender.

Damit wollen die Verantwortlichen vor allem auch die Benutzer aus dem Kreis der Linux- und Mac-OS-X-Anwender ansprechen. Zudem ist die Konfiguration so vorbereitet, dass eine möglichst einfache Integration in ein lokales Netz gelingen kann, ohne in zusätzliche Software investieren zu müssen.

Dekantieren und installieren

Wine ist auf allen gängigen Distributionen schnell installiert, besonders freundlich für den Admin erweist sich Ubuntus Repository. Das Einrichten des Meta-Pakets »wine« über den Standard-Paketmanager »apt« berücksichtigt nicht nur die notwendigen Libraries und Kernanwendungen, sondern liefert auch gleich die erforderlichen Konfigurationswerkzeuge, eine Integration von Gecko zum Rendern von HTML-Anzeigen sowie die im Windows-Umfeld häufig eingesetzten Schriftarten.

Unter Ubuntu 11.10 hat der Admin (die richtigen Repositories vorausgesetzt) sogar die Wahl zwischen der aktuellen stabilen Version 1.2 oder der Entwicklerversion 1.3 (bei Redaktionsschluss bereits 1.3.36). Den Unterschied macht nur die Wahl zwischen »apt-get install wine1.2« oder »wine1.3« – sofern das Ozelot auch Backports und Entwicklerpakete gestattet –, einstellbar im Softwaremodul der Systemsteuerung. Welche Versionen verfügbar sind, zeigt die Suche mit »apt-cache search wine« oder »aptitude search wine« (Listing 1).

01 playonlinux - Frontend für Wine
02 wine1.2-gecko - Microsoft Windows-Kompatibilitätsschicht (Webbrowser)
03 wine1.3-gecko - Microsoft Windows-Kompatibilitätsschicht (Webbrowser)
04 [...]
05 q4wine - Qt4 GUI for wine (W.I.N.E)
06 wine - Microsoft-Windows-Kompatibilitätsschicht (Meta-Paket)
07 wine1.2 - Microsoft Windows-Kompatibilitätsschicht (Emulator für Binärdateien und Bibliothek)
08wine1.2-dbg - Microsoft Windows Compatibility Layer (debugging symbols)
09 wine1.2-dev - Microsoft Windows Compatibility Layer (Development files)
10 [...]
11 winetricks - Microsoft Windows Compatibility Layer (winetricks)
12 gnome-exe-thumbnailer - Wine .exe and other executable thumbnailer for Gnome
13 [...]
14 wine1.3 - Microsoft Windows Compatibility Layer (Binary Emulator and Library)
15 wine1.3-dbg - Microsoft Windows Compatibility Layer (debugging symbols)
16 wine1.3-dev - Microsoft Windows Compatibility Layer (Development files)
17 [...]

Einfachere Konfiguration mit Cups und Bottles

Die Konfiguration von Wine hat sich im Laufe der Jahre völlig geändert. Galt sie noch vor nicht allzu langer Zeit als kompliziert, wurde sie zuletzt vor allem deutlich einfacher und übersichtlicher und nimmt dem Admin viele früher nervige Details ab. Dazu zählen das Einbinden entfernbarer Geräte wie DVDs oder die Integration des Drucksystems Cups. Beides übernehmen inzwischen zuverlässig Prozesse des Wine-Servers.

Eine ebenso bedeutende Änderung in der Architektur von Wine brachten so genannte Präfixe (seit 2003, auch als Bottles bezeichnet). Mit dem Einrichten eines Präfixes lässt sich Windows-Software in diesem Kontext installieren und betreiben, ohne anderer Software ins Gehege zu kommen. Potenzielle Störer landen in ihren eigenen Flaschen.

Wine legt ein Präfix immer dann an, wenn eines dem Aufruf der Windows-Anwendung voranstehen soll, aber noch nicht vorhanden ist. Doch der Admin kann – und sollte – solche vorab explizit erstellen. Wineboot legt mit dem Befehl

env WINEPREFIX=~/Name_des_Präfixeswineboot -u

das Wine-Präfix »Name_des_Präfixes« im Homeverzeichnis des Benutzers als Verzeichnisstruktur an.

Das macht ein relativ sicheres Experimentieren möglich, bei dem der Anwender nicht Gefahr läuft, die gesamte Software-Installation mit einer simplen Aktion unbrauchbar zu machen. Das von älteren Windows-Systemen gefürchtete “Zu-Tode-Installieren” gehört damit der Vergangenheit an. Auch der parallele Betrieb von Software, die sich nativ unter Windows am gleichen Rechner eigentlich gegenseitig ausschließt, wird so möglich, weil jedes Programm glaubt, das System exklusiv für sich zu haben.

Komplettumzug eines Weinregals

Für die Migration besonders interessant ist dabei, dass sich ein einmal erstelltes und passend konfiguriertes Präfix beim Umzug auf einen anderen Rechner oder auch im Mehrbenutzerbetrieb einfach in das neue Homeverzeichnis kopieren lässt. Der Admin muss nur darauf achten, die Rechtestruktur der Dateien und Verzeichnisse zu erhalten oder sie in korrekter Weise neu anzulegen. Am besten hilft das Kommando »tar cfzv Name_des_Präfixes.tgz Name_des_Präfixes« , um das komplette Verzeichnis dieses Präfixes für den Umzug vorzubereiten. Das Entpacken gelingt mit »tar xfzv« im Homeverzeichnis des gewünschten Benutzers.

Wer kein eigenes Präfix anlegt oder die Angabe beim Programmaufruf vergisst, erhält die Ergebnisse sämtlicher Vorgänge im Defaultverzeichnis »~/.wine« des Benutzers und muss ohne die Präfix-Vorteile leben.

Simulierter Neustart

Wineboot führt im Grunde nur jene Aktionen aus, die ein Windows-System auch erledigt, meist bei einem seiner gelegentlichen Neustarts. Die weiteren Optionen, die es zu bieten hat, beschreibt [2]. Mit der so generierten Verzeichnisstruktur richtet es eine lauffähige Umgebung ein, die der Admin mit den Standardwerkzeugen von Wine genauer inspizieren kann. Das Kommando

env WINEPREFIX=~/Name_des_Präfixeswine C:\\windows\\explorer.exe

ruft den in Wine eingebauten Explorer auf und präsentiert die Sicht des Wine-Servers auf die eingehängten Filesysteme und die darin enthaltenen Dateien (Abbildung 3).

Abbildung 3: Der eingebaute Wine-Explorer eignet sich gut, um die frische Installation erstmals zu testen.

So kann der Admin auch verifizieren, ob beim Anlegen oder Updaten des aktuellen Wine-Präfixes die Filesysteme in der gewünschten Weise eingebunden, also mit den richtigen Laufwerksbuchstaben aus der Windows-Welt versehen sind. CD-ROM- und DVD-Laufwerke zeigt Wine ohne Eingriff nur dann an, wenn sie im Linux-System gemountet sind.

Eine parallele Erkundung des Präfix-Directory mit Linux-Mitteln zeigt rasch die sich im Wesentlichen selbst beschreibende Verzeichnisstruktur: »~/Name _des_Präfixes/drive_c« bildet die “gebootete” Festplatte einer typischen Windows-Installation ab, »~/Name_des_Präfixes/dosdrives« listet die angelegten Laufwerke mit den entsprechend zugewiesenen Buchstaben auf.

Regedit

Das Wine-Tool Regedit (Abbildung 4) startet der Benutzer mit dem Befehl:

Abbildung 4: Wine bringt seinen eigenen Registry-Editor mit.

env WINEPREFIX=~/Name_des_Präfixes wine C:\\windows\\regedit.exe

Er bearbeitet hier die für das Präfix spezifisch abgebildete Registry des Systems. Die inspizierten oder editierten Werte legt das Tool in drei Files unter »~/Name_des_Präfixes/« ab: in »system.reg« , »user.reg« und »userdef.reg« . Selbst wenn die Versuchung groß ist, sollten aber auch eingefleischte Shell-Anwender von diesen Dateien lieber die Finger lassen und Regedit verwenden. [4] liefert eine handliche Übersicht zu den Startoptionen von Regedit.

Winecfg oder CLI

Zentrale Schaltstelle für die weitere Konfiguration des Präfixes ist ab jetzt das grafische Wine-Tool »winecfg« (Abbildung 5), das der Anwender mit Hilfe von »env WINEPREFIX=~/Name_des_Präfixes winecfg« startet. Über dieses GUI stellt er einerseits komfortabel das Verhalten von Wine ein, andererseits dient es auch zum Starten oder Installieren von Anwendungen. Volle Kontrolle über den Installationsvorgang bekommt der Admin jedoch nur, wenn er Programme auf der Kommandozeile startet.

Abbildung 5: Die Karteireiter von »winecfg« helfen bei der Konfiguration eines Präfixes.

Abbildung 5 zeigt jenen Reiter von Winecfg, der sich für das Konfigurieren eines Präfixes meist als zentral entpuppt: »Bibliotheken« . Bereits mit der Wine-Installation gelangt eine beachtliche Anzahl dieser Bibliotheken (DLLs) auf den Zielrechner. Die meisten haben die Wine-Entwickler durch Reengineering selbst erstellt, was den Besitz einer Windows-Lizenz oft unnötig macht.

Weil diese DLLs bereits zahlreiche Systemaufrufe abdecken, funktionieren in der Regel auch viele Anwendungen ohne große Starthilfe. Wenn doch etwas hakt, hilft es oft, auf dem »Bibliotheken« -Reiter nachzusehen: So kann Wine beispielsweise die Windows-Libraries auch in einer anderen Reihenfolge laden.

Keine Geschmacksache: Builtin oder nativ?

Der Kater nach einer Wine-Installation tritt jedoch immer dann in Erscheinung, wenn die mitgelieferten Bibliotheken wesentliche Funktionen für eine spezifische Anwendung eben gerade nicht abdecken. Dann ist es notwendig, die von Microsoft in einer Windows-Installation nativ bereitgestellten DLLs zu übernehmen und sie anstelle der von Wine ausgelieferten zu laden.

Das Tool »winecfg« bietet dafür eine komfortable Schnittstelle. Abbildung 5 zeigt den Fall der DLL »cfgmgr32« , die Wine nicht »Builtin« laden soll, sondern »Native« , also in der Microsoft-Version. Dazu muss der Admin die Datei »cfgmgr32.dll« einer Windows-Instanz entreißen und Wine an der in seinem Verzeichnisbau entsprechenden Stelle zuführen.

Im konkreten Beispiel heißt das: Die Datei aus dem Windows-Verzeichnis »c:\windows\system32\cfgmgr32.dll« landet im Präfix von Wine unter »~/Name_des_Präfixes/drive_c/windows/system32« .

Gemütliches Nebeneinander

Die Änderung, die Winecfg hier durchführt, hinterlässt folgenden Eintrag in der Datei »user.reg« und einen entsprechenden im Verzeichnis der Registry:

[Software\\Wine\\DllOverrides] 1320056438 "cfgmgr32"="native,builtin"

Dies versetzt Wine in die Lage, das Verhalten abzubilden, das Microsoft mit Windows XP eingeführt hat und Side-by-Side (SxS) nennt [5]. Im Verzeichnis »c:\windows\WinSxS« liegen nebeneinander mehrere Versionen ein und derselben Systembibliothek, gegliedert nach Unterverzeichnissen. Windows-Anwendungen können sie in eindeutig spezifizierten Versionen vom System anfordern.

Gerade Installationsroutinen machen davon oft Gebrauch, während die Anwendungen später zuweilen auf dort hinterlegte Systembibliotheken verzichten. Sollte also das Installieren einer Anwendung fehlschlagen und sollten keine besonderen Hinweise auf die Gründe dafür vorliegen, kann das Austauschen dieses Verzeichnisses gegen das einer Windows-Installation zumindest für die Dauer der Installation hilfreich sein.

Doch ist hier besondere Sorgfalt angebracht: Systembibliotheken sind zwar schnell ausgetauscht, ganze Verzeichnisse rasch verändert und Werkzeuge wie Winetricks [6] übernehmen in einem Rutsch eine Fülle an frei oder kostenlos verfügbaren Microsoft-Dateien in die Wine-Umgebung. Doch nicht immer ist das nachvollziehbar. Auch deshalb warnen die Wine-Entwickler: Wer aus der Community Hilfe erwartet, sollte davon absehen, seine Installation mit zu vielen DLLs vermeintlich aufzuwerten [7]. Die Installation einer Windows-Anwendung geht der Anwender besser erst einmal ohne tiefere Eingriffe ins System an.

Kredenzen

Der Aufruf eines bei Fachanwendungen wie auch bei Spielen unter Windows üblichen Setup-Programms (Abbildung 6) gelingt von einem DVD-Laufwerk mit dem zugewiesenen Buchstaben »D« in der Kommandozeile mit:

Abbildung 6: Das Setup der Klagenfurter Ausgabe unter Wine.

env WINEPREFIX=~/Name_des_Präfixeswine D:\\Setup.exe

Wine kennt jedoch unterschiedliche Mechanismen, um ein Programm zu starten. Der offizielle Aufruf lautet dem Wine-Wiki zufolge

env WINEPREFIX=~/Name_des_Präfixeswine start 'D:\Setup.exe'

beziehungsweise mit der Pfadangabe in Unix-Schreibweise:

env WINEPREFIX=~/Name_des_Präfixeswine start /Unix /media/Setup.exe

Die zweite Variante bietet sich besonders an, wenn die Installationsroutine oder das Programm einzelne Pfade nicht richtig umsetzt [8].

Wenn das Setup-Programm ohne abzubrechen durchläuft, stehen die Zeichen für einen erfolgreichen Aufruf gut. Wine arbeitet in diesem Fall genauso, wie es auch Windows täte: Sofern die Installation dies vorsieht, erstellt es einen Eintrag auf dem Desktop über ein (verknüpftes) Icon. Doch auch im Menü des Linux-Desktops erscheint ein Eintrag zu Wine, unter dem im Weiteren die installierten Programme aufzufinden sind (siehe Abbildung 7).

Abbildung 7: Auf Ubuntu 11.10 legt Wine einen eigenen Menü-Eintrag für alle installierten Anwendungen an, hier unter KDE 4.8.

Vorab informieren und degustieren

Gelingt die Installation oder der Start der Windows-Anwendung nicht, auch wenn die Anzahl der problemlos laufenden Anwendungen stetig steigt, hilft dem Admin die folgende Checkliste – am besten noch vor den ersten Tests. Hilfreich bei der Fehlersuche sind:

• Der zur Anwendung passende Eintrag in der Kompatibilitätsdatenbank des kommerziellen Wine-Entwicklers Codeweavers [9].
• Eine gründliche Recherche im Web. Viele Installationsversuche – geglückte und misslungene – sind dokumentiert, jedoch bei Codeweavers nicht eingetragen.
• Das Programm auf einer nativen Windows-Instanz als Vergleich vorhalten.
• Der Einsatz des speziellen Wine-Debuggers [10].

Die Arbeit mit einer parallelen Windows-Instanz verlangt ein wenig Vorbereitung, weil geeignete Hilfsmittel den Installationsvorgang und den Aufruf der Anwendung möglichst detailgenau erfassen sollen. Das Tool der Wahl sollte während der Installation mitprotokollieren, welche Verzeichnisse und Dateien die Installationsroutine anlegt, welche Einträge sie in der Registry vornimmt und welche Bibliotheken sie ins System einfügt. Auch wenn das mit ein wenig Handarbeit passabel machbar ist, bietet sich hier Software wie die Freeware Track Winstall ([11], Abbildung 8) an, die auch mit ein wenig Komfort aufwartet.

Abbildung 8: Die Ergebnisliste zeigt alle von Track Winstall gefundenen Änderungen an einer Windows-Installation.

Ideal wäre es, wenn ein Tool die nach einer kontrollierten Installation angelegten Verzeichnisse und Dateien, die hinzugekommenen Einträge der Registry sowie die relevanten Systembibliotheken unkompliziert exportieren und sie direkt in eine möglichst frische, unangetastete Wine-Umgebung überführen kann. Wer auf diesem Weg eine erneute Installation vermeidet, startet die Anwendung über die oben beschriebenen Kommandos oder Icons.

Scheitert dieser Weg, ist eine genauere Inspektion der laufenden Anwendung in der parallelen Windows-Installation notwendig. Der erste Schritt ist das Starten der Anwendung und das Überprüfen der Systembibliotheken, die sie nach dem Start lädt. Auch dafür reichen einfache Werkzeuge, die als Freeware oder in einer Demoversion zur freien Verwendung vorliegen. DLL Show [12] zählt mittlerweile schon zu den Veteranen, leistet jedoch immer noch gute Dienste und zeigt zuverlässig die in den Arbeitsspeicher des Betriebssystems geladenen Anwendungen und die zugehörigen Bibliotheken.

Gärprozesse überwachen

Ähnliches leistet das für 30 Tage kostenlose Process Info ([13], Abbildung  9). Die Einschränkungen gegenüber der Vollversion sollten die meisten Linuxer nicht wirklich stören, vor allem weil das Werkzeug auch in einer Wine-Umgebung installier- und ausführbar ist.

Abbildung 9: Process Info listet die mit einer ausführbaren Windows-Datei verknüpften DLLs auf.

Anhand der Liste jener Bibliotheken, die die zu überwachende Software lädt, erhält der Admin einen ersten Eindruck davon, worauf er in der Folge sein Augenmerk legen sollte. Eventuell verrät ihm bereits die Ausgabe auf der Startkonsole, ob tatsächlich eine Wine-Bibliothek einer Anwendung nicht alle relevanten Funktionen anbietet und deshalb durch eine native Version zu ersetzen ist. In jedem Fall hilft der Aufruf des Wine-Debuggers beim Start der Anwendung.

Cuvée: Der Verschnitt

Dass das fortgeführte Ersetzen von Libraries letztlich ein Ansatz ist, der nur eingeschränkt zum Ziel führt, zeigt sich in jenem Umstand, den Windows-Administratoren gerne als “DLL-Hölle” bezeichnen – nicht alle Versionen der Systembibliotheken vertragen sich miteinander. An diesem Punkt erfordert das Vorgehen Geschick, Recherche, Glück und nicht zuletzt Geduld.

Um unkompliziert an Debug-Informationen zu gelangen, übergibt der Admin Wine beim Start die Umgebungsvariable »WINEDEBUG« . Der Wert »+relay« veranlasst im Debug-Modus von Wine, dass sämtliche Funktionsaufrufe sowie die Bezeichnung der zugehörigen Bibliothek sichtbar auf der Konsole landen. Damit erhält der Admin erste Informationen, bei welchem Funktionsaufruf Wine scheitert und welche DLL dafür verantwortlich ist.

Wer die Standardausgabe in ein Logfile umleitet, kann anschließend den Startprozess in Ruhe analysieren:

env WINEPREFIX=~/Name_des_PräfixesWINEDEBUG=+relay wine Anwendung.exe&>debug.log

Deutlich gesprächiger macht den Debugger der Parameter »+all« für die Umgebungsvariable »WINEDEBUG« (Abbildung 10):

Abbildung 10: Das Starten einer Wine-Anwendung mit der gesetzten Umgebungsvariablen »WINEDEBUG=+relay« erzeugt jede Menge Output.

env WINEPREFIX=~/Name_des_PräfixesWINEDEBUG=+all wine Anwendung.exe&>start_anwendung.log

Dann schreibt Wine sämtliche Informationen, die im Debug-Modus zugänglich sind, auf die Standardausgabe. Der Startvorgang der Anwendung verzögert sich dadurch zwar erheblich, mit einiger Übung kann sich der Admin aber auf diesem Weg einen deutlich intensiveren Eindruck von den implementierten Mechanismen und den Stolpersteinen verschaffen, die er anschließend zu umgehen versucht.

Neben dem Setzen der Umgebungsvariablen »WINEDEBUG« kann er eine Anwendung auch direkt mit dem eingebauten Wine-Debugger starten:

env WINEPREFIX=~/Name_des_Präfixes winedbgAnwendung.exe

Dieser bringt erfahrenen Testern die von anderen Debuggern vertrauten Eigenschaften mit und integriert sich in die Umgebung der Systembibliotheken von Wine. Mit ihm sind umfangreiche Methoden zugänglich, um Anwendungen kontrolliert zu starten.

Die Ähnlichkeiten zu anderen Debuggern sind kein Zufall, denn die Befehle des Wine-Debuggers (Abbildung 11) bilden ein Subset des GNU Project Debuggers (GDB). Die Website der Entwickler zum Wine-Debugging [10] gibt einen guten Überblick zum schrittweisen Annähern an ein unbekanntes Problem, das sich beim Ausführen einer Windows-Anwendung in einer Wine-Umgebung einstellt.

Abbildung 11: Die erlaubten Befehle des Wine-Debuggers.

Keltermeister Codeweavers

Wenn all das Debuggen und Testen nicht dabei geholfen hat, eine Anwendung unter Linux und Wine zum Laufen zu kriegen, hat der Admin zum Schluss doch noch ein paar Möglichkeiten. Unter dem Motto “Kleine Kerle versuchen die Computerwelt für andere kleine Kerle zu verändern” treiben die Codeweavers [14] die Integration von Windows-Anwendungen in Wine voran.

Zwar sind die Produkte Crossover, Crossover Games und das Bundle aus beiden kostenpflichtig und Closed Source, doch sie helfen vielen Usern dabei, Applikationen für Microsoft-Systeme auch auf Linux auszuführen – allen voran den Gamern. Für den Preis von rund 50 Euro versprechen die Entwickler im C4 (Codeweavers Crossover Compatibility Center) Unterstützung für mehrere Tausend Anwendungen. Anführer der Kompatibilitätsliste ist derzeit das Multiplayer-Rollenspiel The Elder Scolls (TES) in der aktuellsten Version 5: Skyrim [15], das inklusive aufwändiger 3-D-Grafiken vollständig funktioniert. Codeweavers Produkte sind auch für den Mac verfügbar.

Playonlinux für Autocad, Catia und Adobe

Ebenfalls hilfreich, aber kostenlos und Open Source ist das Projekt Playonlinux (POL, [16]). Es ist in den meisten Distributionen enthalten und bringt ein eigenes grafisches Frontend für Wine mit (Abbildung 12). Die lange Liste unterstützter Software enthält zwar überwiegend Spiele, aber auch Programme wie Autocad, Catia, Microsoft Office, I-Tunes, Googles Sketchup oder Adobes Photoshop und Dreamweaver.

Abbildung 12: Playonlinux bringt eine umfangreiche Datenbank an Konfigurationsoptionen mit, die das Einrichten zahlreicher Windows-Spiele und -Anwendungen auf Linux vereinfachen.

Ein simpler Doppelklick installiert die proprietäre Software von der eingelegten DVD oder einem Datei-Image. Ist die eigene Anwendung nicht im Playonlinux-GUI aufgelistet, hilft die Suche nach einer ».pol« -Datei im Online-Repository. Auch Playonlinux nutzt übrigens die oben beschriebenen Präfixes, was im Fall des Falles eine unerwünschte Interaktion mit anderen Spielen und Programmen verhindern kann.

Fenster in neue Welten

Eine Anwendung unter Wine zum Laufen zu kriegen ist oft erst der Anfang. Nicht nur erlaubt ein solcher Erfolg in vielen Fällen überhaupt erst die Linux-Desktop-Migration, sondern er ermöglicht auch völlig neue Ansätze für die Architektur der Firmen- oder Behörden-IT.

Mit Linux als Betriebssystem lassen sich Anwendungen nicht nur lokal, sondern auch als Netz-Installation einrichten und in Umgebungen etablieren, in denen ein Mehrbenutzerbetrieb notwendig ist – auch wenn die Anwendungen das eigentlich nicht vorsehen. Dabei sollten Admins aber einen genauen Blick auf die Lizenzen der Windows-Software werfen. Nicht immer gestatten es die Hersteller ihren Kunden, die Software zu befreien.

Richtig lagern

Darüber hinaus bilden Kombinationen wie etwa Wine, Linux und Virtualbox [17] eine vollständige und plattformunabhängige Open-Source-Lösung, mit der sich auch Linux-fremde Anwendungen in einen Container packen und dauerhaft konservieren lassen. Templates, die vom Betriebssystem bis zu den Applikationsdaten alles für den Betrieb notwendige enthalten, lassen sich leicht starten, verschieben oder durch simples Kopieren installieren. Wem das noch nicht reicht, der leitet die Ausgabe der virtuellen Instanzen auf Protokolle wie VNC, RDP oder NX um und verschafft so auch Uralt-Windows-Anwendungen Multiuser- und Netzwerkfähigkeiten [18].