Legacy-Anwendungen als Lösung fürs Server-based Computing

Abbildung 1: Wine allein eignet sich für den Multiuser-Betrieb von Servern nicht besonders. Hilfe bringen Crossover, Wintools oder Wine-Doors (Bildausschnitte im Uhrzeigersinn).

Geht es um Wine als Ausweg aus der Windows-Falle, dann vorrangig um den Einsatz von Windows-Programmen auf Einzelplatzrechnern [1]. Beim Server-based Computing dagegen können Wine und Linux entweder einen Windows-Terminalserver ablösen oder einzelne (Fach-)Anwendungen, die es nur für Windows gibt, vom bisherigen Windows-Client weg auf einen Linux-Server verlagern. Damit ist der Weg frei für eine Client-Migration hin zu Linux.

Auf dem Server legt nicht jeder Benutzer eine einzelne Installation an und konfiguriert sie - das wäre kaum zu managen -, sondern der Admin pflegt eine zentrale Installation. Lediglich kleine Teile, etwa individuelle Registry-Einträge, liegen in den Benutzerkonten. Damit verbunden ist die Frage, wie man mit Updates für die benutze Windows-Software verfährt. Hier gibt Wine keine Hilfestellung. Programme in der Wine-Instanz verhalten sich wie unter Windows und mangels einheitlichen Paketsystems muss der Admin darauf hoffen, dass der Programmautor ein funktionierendes Verfahren implementiert hat. Das mag beim Einzelplatz nicht so wichtig sein, im Multiuser-Betrieb kann es zum Problem werden.

Technische Machbarkeit

Wine [2], aktuell ist Version 0.9.43, bildet die Emulationsschicht für Windows-Binärdateien. Die funktioniert nicht immer: So scheitern Anwendungen, die einen bestimmten Hardwaretreiber voraussetzen, im Wine-Betrieb. Windows-Hardwaretreiber in Wine installieren geht gar nicht, zu unterschiedlich sind die Ansätze. Einige Programme, die einen Direktzugriff auf Festplatten oder CD-Laufwerke verlangen, funktionieren trotzdem, da Wine ihnen einen Raw-Zugriff auf das Device anbietet - bei ausreichenden Benutzerrechten.

Wer wissen will, ob und wie gut seine Applikationen mit Wine laufen, schaut zunächst auf die bequeme Applikationsdatenbank des Wine-Headquarter [2]. Die Dokumentation ist jedoch mehr als lückenhaft und mit distributionsspezifischen Wine-Versionen oft nicht nachvollziehbar. Eine alternative Informationsquelle findet sich unter [3], allerdings herrscht dort ein ziemlicher Wine-Versionen-Wirrwarr.

Bleibt selber ausprobieren. Die erste ist meist auch die größte Hürde - der Installer. Programme, die sich mit dem Install Shield oder dem Microsoft Installer ins System heben wollen, benutzen kein dezidiertes Paketsystem, sondern implementieren herstellereigene Einzelfunktionen. Kommen noch Kopierschutzmaßnahmen hinzu, die fast immer sehr tief ins System eingreifen, läuft es - wenn überhaupt - auf einen Hack hinaus. Dabei stellen sich auch rechtliche Fragen.

Programme austricksen

Lassen sich Programme partout nicht zur Installation bewegen, kann der Admin sie auf einem Windows 98 installieren, auf dem er zuvor die Registry gesichert und exportiert hat. Läuft das Programm, kopiert er »C:ProgrammeName« nach »~/.wine« und sucht und kopiert neue DLLs. Nun exportiert er die Windows-Registry erneut und vergleicht die beiden Exporte. Neue und geänderte Schlüssel pflegt er unter Wine mit dem Dienstprogramm »regedit« ein, das sich wie sein Windows-Pendant verhält. Mit etwas Glück bekommt er das gewünschte Programm so zum Laufen. Ein Kandidat dafür ist der Lotus-Notes-Client. Software, die Java oder Dotnet voraussetzt, läuft dagegen nicht, weil diese Frameworks unter den derzeitigen Wine-Versionen nicht stabil zu betreiben sind.

Gut betreiben lassen sich dagegen Microsoft Office 95 bis 2000, eingeschränkt auch Office 2003, die Office-Viewer, Adobe Photoshop und Illustrator, Star Money sowie zahlreiche mit Borland-Produkten kompilierte Programme. Bei Datenbankanwendungen empfiehlt es sich, zuerst Unix-ODBC auszuprobieren, andernfalls lassen sich wahrscheinlich Microsofts Data Access Components (MDAC) anbinden, um native Windows-ODBC-Treiber zu verwenden.

Die besten Ergebnisse erreicht Wine, wenn der Windows-Programmautor den Anpassungsprozess unterstützt oder die Quellen herausgibt. Dann lässt sich in einer sorgfältig gebauten Testumgebung die Software Stück für Stück anpassen. Meist sind nur Darstellungs- oder Tastaturfehler mit einer zusätzlichen Codezeilen zu beheben; Wine selbst anzufassen ist kaum nötig.

Ziel sollte stets eine einheitliche Version für Wine und Windows sein. Auf diese Weise hat der Autor dieses Artikels jüngst für seinen Arbeitgeber eine größere betriebswirtschaftliche Standardsoftware der Textilindustrie portiert (Abbildung 2). Mit tatkräftiger Unterstützung der Softwarefirma konnte er eine komplette Softwaresuite mit Datenbankanbindung via Unix-ODBC portieren.

Abbildung 2: Ist der Programmautor der Windows-Software kooperationsbereit, gelingt die Portierung nach Wine fast immer perfekt – hier bei einer betriebswirtschaftlichen Software für die Textilindustrie.