Das Unmögliche möglich machen: Darum geht es im Schwerpunkt dieses Ausgabe. Konkret z. B. um den Wunsch, lieb gewonnene Windows-Anwendungen auch unter Linux zu nutzen. Warum das schwierig ist und wie Emulation und Virtualisierung helfen, verraten wir in diesem Einstiegstext.

Für viele PC-Besitzer ist es gar nicht wichtig, ob auf ihrem Rechner Windows, Linux oder ein sonstiges Betriebssystem läuft – sie denken eher an Anwendungen wie Word, Gimp und Firefox, und der Rechner soll schnell und sicher arbeiten. Viele Benutzer haben (nach entsprechenden Hinweisen aus den Medien) ein Linux-System auf ihrem Rechner installiert und waren dann überrascht, dass sie ihre Windows-Programme nicht mehr nutzen konnten.

Woran liegt es, dass sich Microsoft Office nicht unter Linux installieren lässt und auch umgekehrt Klassiker der Linux-Welt nicht unter Windows laufen? Ist das eine absichtliche Einschränkung, um Anwender vom Wechsel des Betriebssystems abzuhalten? Nein, es liegt an technischen Grundlagen.

Programme starten und ausführen

Es geht schon damit los, dass Linux ein Windows-Programm gar nicht als Programmdatei erkennt (Abbildung 1). Die bekannten .exe-Dateien aus der Windows-Welt haben das Dateiformat PE (Portable Executable) und besitzen am Dateianfang einen Header-Bereich, der für den Programmstart nötige Informationen enthält: Da steht z. B., welche Teile der Programmdatei wo in den Speicher kopiert werden müssen und welche Bibliotheken (bei Windows: DLL-Dateien) das System zusätzlich laden muss, damit das Programm laufen kann.

Abbildung 1: Der Internet Explorer (“iexplore.exe”) kann nur mit Hilfestellung unter Windows laufen; hier bietet KDE an, das Programm in Wine zu starten.

Versuchen Sie, eine solche Programmdatei unter Linux zu starten, wird das System nur darauf hinweisen, dass die “Binärdatei” ein ungültiges Format hat:

[esser@linux:~]$ ./texexec.exe
bash: ./texexec.exe: Kann die Binärdatei nicht ausführen: Fehler im Format der Programmdatei

Denn Linux erwartet ebenfalls, dass Programmdateien Header-Informationen enthalten, allerdings in einem ganz anderen Format – Linux verwendet ELF (Executable and Linking Format).

Prinzipiell leisten ELF und PE dasselbe; Windows und Linux benötigen für Programmstarts ähnliche Informationen. Im Detail sind die Unterschiede dann aber doch zu groß: Selbst wenn Linux das PE-Format von Windows verstehen würde (das wäre kein allzu großes Problem), wäre das keine Hilfe, denn die enthaltenen Anweisungen, welche Programmteile in welchen Speicherbereich zu laden sind, passen nicht zur Speicheraufteilung von Linux – das System müsste sie als ungültig ablehnen und den Programmstart verweigern.

Übrigens verwendet macOS mit Mach-O (Mach Object file format) ein drittes Format, das zu ELF und PE inkompatibel ist.

Bibliotheken

Nehmen wir an, man könnte all diese Hürden überwinden und Linux so anpassen, dass es das PE-Format versteht und die unterschiedliche Speichernutzung kein Problem darstellt – dann folgt nach der ersten Analyse der exe-Datei das Nachladen der Bibliotheken.

Bibliotheken sind im Wesentlichen auch ausführbare Dateien, die Windows-Dateien mit Endung .dll (Dynamic Link Library) liegen wieder im PE-Format vor, und Linux speichert seine Dateien (mit Endung .so für Shared Object) im ELF-Format. Auch das Finden und Nachladen der Windows-Bibliotheken ließe sich also regeln, wenn denn alle benötigten Windows-Bibliotheken in der jeweils richtigen Version unter Linux installiert werden.

Ein angepasster Programmlader (der PE versteht) und eine Sammlung der Windows-Bibliotheken sollten also ausreichen, um ein Windows-Programm vollständig unter Linux zu laden und auszuführen – oder fehlt doch noch etwas?

System Calls ins Betriebssystem

Die Bibliotheken stellen Funktionen bereit, über die Anwendungen z. B. Dateien öffnen, Mausbewegungen und Tastendrücke auswerten, Netzwerkverbindungen aufbauen und Informationen in Fenstern oder auf der Konsole ausgeben können. Dazu nutzen sie (die Bibliotheken) selbst Dienste des Betriebssystems – über so genannte System Calls (Systemaufrufe).

Hier liegt das Hauptproblem: System Calls sind sehr spezifisch und auf das jeweilige Betriebssystem zugeschnitten. Ein Großteil der System Calls von Windows hat zwar unter Linux eine Entsprechung, aber es gibt kleinere oder größere Abweichungen, und die verhindern letzten Endes, dass sich ein Windows-Programm in der Linux-Umgebung zurechtfinden kann.

Lösungsansätze

Um das Problem zu lösen, gibt es im Wesentlichen zwei Lösungsansätze.

• Der erste Ansatz baut die ganze Windows-Ausführumgebung (also den Programmlader und die Bibliotheken) unter Linux nach. Es reicht dafür nicht, den Quellcode der Bibliotheken einfach unter Linux neu zu übersetzen, denn dort werden ja die falschen System Calls verwendet. Es sind also umfangreiche Anpassungen nötig. Diesen Ansatz verfolgt das Wine-Projekt [1], und darauf aufbauend auch das kommerzielle CrossOver [2]. Die nachgebauten Bibliotheken sind aber nicht 100?% kompatibel zum Original, und deswegen laufen viele Windows-Anwendungen nicht mit Wine oder CrossOver. Ein großer Vorteil beim Wine-Modell ist, dass keine Windows-Installation nötig ist, denn mit Hilfe von Wine laufen die für Windows gedachten Anwendungen direkt unter Linux.
• Der zweite Ansatz baut gleich einen ganzen Computer nach, auf dem dann ein reguläres Windows installiert werden kann. Und dieses Windows hat dann (in fast allen Fällen) keine Probleme, Windows-Programme auszuführen. Für das “Nachbauen” gibt es dabei zwei Methoden – Emulation und Virtualisierung. Auch da gibt es große Unterschiede, mehr dazu in den folgenden Absätzen.

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, und mit Qemu [3] gibt es auch einen Emulator für PCs. (Tatsächlich ist Qemu ist Kombiprodukt, das Emulation und Virtualisierung beherrscht.)

Emulation bedeutet in jedem Fall, dass Programme deutlich langsamer als native Versionen laufen. Lediglich bei der Emulation von sehr schwachen Maschinen spielt das keine Rolle; so kann etwa ein moderner PC problemlos die nötige Leistung bereitstellen, um einen alten Homecomputer vollständig zu emulieren, ohne dass die Programme langsamer als auf der echten Hardware wirken – tatsächlich wird in solchen Fällen sogar eine Bremse eingebaut.

Virtualisierung

Wenn die nachzubildende 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. VirtualBox [4] und VMware Workstation [5] genau so (und nennen sich auch nicht mehr Emulatoren). Hier beherrscht dann die CPU im virtuellen PC nur 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.

Bei der Virtualisierung gibt es im Idealfall fast keinen Performance-Verlust, so dass diese viel besser als die Emulation geeignet ist, um Software eines modernen Systems (wie Windows) auf einem anderen modernen System (wie Linux) laufen zu lassen.

Lektüre

Auf den folgenden Seiten finden Sie mehrere Artikel, in denen wir die verschiedenen Methoden beleuchten, mit denen Sie Windows- und andere Nicht-Linux-Programme unter Linux zum Laufen bringen können.

• Auf der folgenden Seite starten wir mit Virtualisierung und stellen dazu das Programm VirtualBox vor. Es bietet den sichersten Weg, was die Erfolgschancen angeht.
• Ab Seite 38 besprechen wir Wine und CrossOver: Wenn diese Ihre Software unterstützen, kommen Sie ohne Windows-Installation (und damit auch ohne eine Lizenz) aus.
• Spielerisch wird es dann ab Seite 42: Da geht es um die Emulation alter Spielerechner – wer sich an MS-DOS-PCs und die Homecomputer der 80er Jahre (Abbildung 2) erinnert, kann die alten Schätzchen unter Linux wiederbeleben.

Abbildung 2: Der Commodore C64 war der beliebteste Homecomputer der 80er Jahre.