Wie funktioniert eigentlich ein Emulator, mit dem Windows-Anwendungen unter Linux laufen? Warum ist dafür manchmal eine Windows-Lizenz nötig und manchmal nicht? EasyLinux klärt auf.
Die Software-Box beim Discounter war zu verlockend: Nur 4 Euro für eine DVD mit dem kompletten Physik- und Chemielernprogramm samt Fachwörterbuch in fünf Sprachen. Daheim unter Linux offenbart sich wie so oft: Die Software läuft nur unter Windows, und die Daten liegen in keinem lesbaren Standardformat auf dem Datenträger. Um den Neuerwerb nicht abschreiben zu müssen, ist jetzt die Hilfe eines Emulators gefragt, damit das Windows-Programm auch unter Linux läuft.
Dieses Standardszenario führt viele Linux-Anwender zur Windows-Emulation, und das Thema ist so beliebt, dass in EasyLinux regelmäßig Workshops dazu erscheinen [7,8,9]. In diesem Artikel geht es um die Grundlagen der Emulation – wie funktioniert das Ganze?
Zwei Wege, ein Ziel
Das Ziel ist, die Windows-typischen exe-Dateien unter Linux laufen zu lassen. Da gibt es verschiedene Hürden:
- Linux muss die exe-Datei als Programm, also als eine ausführbare Datei erkennen – das tut es nicht, weil Windows-Programmdateien im Inneren einen anderen logischen Aufbau als Linux-Programmdateien haben (so, wie sich auch Word- und OpenOffice-Writer-Dateien prinzipiell unterscheiden).
- Beim Versuch, das Programm zu starten, muss Linux es zunächst von der Platte in den Hauptspeicher laden. Dann sucht es nach zusätzlichen Programmbibliotheken, ohne die das Programm nicht laufen kann – unter Windows heißen die “DLL-Dateien” (Dynamically Linked Library), unter Linux “shared libraries” (etwa: gemeinsam genutzte Bibliotheken) mit Dateiendung .so (shared object). Das Konzept ist dasselbe, aber auf einem Linux-System fehlen die unter Windows installierten Bibliotheken, und umgekehrt. Auch die Art und Weise, auf die Windows und Linux aus der Programmdatei die Information beziehen, welche Bibliotheken nötig sind, ist verschieden.
- Selbst wenn es Linux möglich wäre, die Programmdatei sowie die (woher auch immer beschafften) Bibliotheken in den Hauptspeicher zu laden, folgt als letztes großes Problem, dass Windows-Programme ständig Windows-eigene Betriebssystemfunktionen aufrufen, um etwa eine Datei zu öffnen, ein neues Fenster zu erzeugen oder eine Benutzereingabe zu lesen – all diese Funktionen gibt es auch unter Linux, aber sie heißen anders und verhalten sich auch unterschiedlich.
Programmierer, die ein Windows-Programm unter Linux laufen lassen wollen, müssen also diese Hürden umgehen. Dafür gibt es zwei Ansätze, die ganz unterschiedliche Konsequenzen haben.
Windows-Umgebung nachbauen
Ein möglicher Weg ist, die oben beschriebenen drei Hürden zu umgehen und damit eine Sammlung von Software und Bibliotheken bereitzustellen, die in der Lage ist, Windows-Anwendungen in den Speicher zu laden, Bibliotheken hinzuzufügen und das Programm auszuführen. Damit das klappt, muss diese Softwarelösung auch alle (Windows-)Betriebssystemaufrufe “abfangen” und sinnvoll umsetzen. Diesen Ansatz verfolgt das Projekt WINE [1]. Die ersten beiden Hürden umschifft es problemlos, aber die dritte verursacht noch Probleme, weil Windows sehr viele (teils undokumentierte) Systemfunktionen bietet und WINE nicht alle davon umsetzt. Darum gibt es viele Windows-Programme, die mit WINE sehr gut unter Linux laufen, aber noch viel mehr Anwendungen, die nicht kompatibel sind.
Über WINE laufende Windows-Programme erhalten ein normales Programmfenster, das sich nicht von Linux-Programmen unterscheidet (Abbildung 1).
PC-Emulation und Virtualisierung
Einfacher ist ein anderer Weg, der auf den ersten Blick komplizierter aussieht: Anstatt sich mit den Details der Windows-Systemfunktionen zu beschäftigen, simulieren Programme wie VMware Workstation [2], VirtualBox [3] und Qemu [4] gleich einen vollständigen Computer mit allen üblichen Komponenten, also u. a. BIOS, Festplattencontroller, Festplatte, Grafikkarte, Hauptspeicher, Netzwerkkarte und sonstigen Schnittstellen. Die Gesamtkomplexität einer solchen virtuellen Maschine ist aber immer noch geringer als die des Windows-Systems und ändert sich vor allem nicht permanent – jede neue Windows-Version bringt zusätzliche Features mit, die Entwickler in Projekten wie WINE dann auch ergänzen müssen; die Spezifikation eines virtuellen PCs kann aber über Jahre unverändert bleiben.
Der Nachteil bei diesem Ansatz ist, dass das resultierende System ein “nackter” virtueller PC ist: Der Emulator stellt nur die virtuelle Hardware bereit, und nutzbar wird dieses System erst nach Installation eines Betriebssystems. Es ist also eine reguläre Windows-Lizenz nötig, bevor das erste Windows-Programm im Emulator laufen kann.
Damit verbunden ist direkt der Vorteil: Weil ein Original-Windows auf dem emulierten PC läuft, werden auch die meisten Windows-Programme fehlerfrei arbeiten. Nur wenn ein Programm spezielle Hardwarekomponenten nutzen will, welche der Emulator nicht an die virtuelle Maschine “durchreicht”, fallen einige Anwendungen aus.
Das vielleicht wichtigste Stück Hardware, das ein solcher Emulator nachbilden muss, ist die CPU, also der Prozessor, der die Maschinenbefehle ausführt, aus denen Programme bestehen. Hier gibt es zwei Varianten:
- echte Emulation: Ein Emulator wird jeden einzelnen Maschinenbefehl im Programm lesen und dann so interpretieren, als würde eine richtige CPU den Befehl ausführen. Das ist zeitaufwendig, erlaubt es aber z. B., Emulatoren für fremde Architekturen zu programmieren: Viele Emulatoren alter Home-Computer (wie Commodore C64 und Schneider CPC) arbeiten so.
- Virtualisierung: Wenn die emulierte Plattform und der vorhandene PC dieselbe CPU einsetzen, kann der Emulator den echten Prozessor direkt die Befehle ausführen lassen, zumindest die meisten. Das ist viel schneller, und darum arbeiten z. B. VMware und VirtualBox so. Hier beherrscht dann die CPU im virtuellen PC nur genau die Funktionen, die auch die echte CPU beherrscht – auf einem 32-Bit-System laufen darum keine 64-Bit-Gastsysteme, weil die Hardware-CPU kein 64-bittiger Prozessor ist.
Programme, die unter Windows auf einem virtuellen PC laufen, sind auch gleich als solche zu erkennen, da der Emulator im Fenster den kompletten Windows-Desktop anzeigt. (Abbildung 2 zeigt die Installation von Vista im Emulator VMware Workstation.) Selbst beim Einsatz einer neueren Betriebsart, die den Desktop verbirgt und Fenster einzeln darstellt, bleiben die Windows-Fensterdekorationen sichtbar.

Abbildung 2: Emulatoren lassen gleich ein ganzes Betriebssystem im Fenster laufen, hier Windows Vista.
Meist keine Wahl
Auch wenn es klingt, als ob Sie zwischen beiden Methoden die Wahl haben, ist meist nur der Weg über den Emulator möglich, wenn WINE ein Programm nicht ausführen kann. Wer etwas Geld in die Hand nehmen mag, kann noch sein Glück mit den von kommerziellen Anbietern verbesserten WINE-Versionen versuchen: CrossOver Linux [5] und Cedega [6] sind darauf optimiert, eine Auswahl von populären Windows-Anwendungen gut zu unterstützen. Wer einen großen Fundus an Software aus der Windows-Welt unter Linux weiterverwenden will oder muss, hat mit einem Emulator die besten Chancen, und das muss nicht mal teuer sein: VirtualBox und Qemu sind gratis erhältlich, lediglich eine Windows-Installations-DVD ist dann noch nötig.
[1] WINE: http://www.winehq.org/
[2] VMware Workstation: http://www.vmware.com/de/products/ws/
[3] VirtualBox: http://www.virtualbox.org/
[4] Qemu: http://www.nongnu.org/qemu/
[5] CrossOver Linux: http://www.codeweavers.com/products/cxlinux/
[6] Cedega: http://www.cedega.com/
[7] Artikel zu VMware und CrossOver Office, Hans-Georg Eßer und Thomas Leichtenstern: “Nachgemachte Fenster”, EasyLinux 05/2005, S. 29 ff., http://www.easylinux.de/2005/05/029-vmware/
[8] Artikel zu Linux unter Windows, Andreas Bohle, Hans-Georg Eßer und Kristian Kißling: “Pinguin-Fenster”, EasyLinux 09/2006, S. 40 ff., http://www.easylinux.de/2006/09/040-emu-unter-win/
[9] Test: VirtualBox 2.0 und VMware Workstation 6.5, Hans-Georg Eßer: “Frisch emuliert”, EasyLinux 04/2008, S. 114 ff.






