Windows-Programme unter Linux

Was Wine ist und wie es funktioniert

Wine ist keine Virtualisierung und kein emulierter Windows-Computer. Der Name ist ein Akronym und steht für „Wine Is Not an Emulator". Wine übersetzt stattdessen die Systembefehle, die ein Windows-Programm an das Betriebssystem richtet, in Echtzeit in entsprechende Linux-Befehle. Das Programm läuft damit direkt auf dem Linux-System – ohne echtes Windows, ohne virtuelle Maschine, ohne Windows-Lizenz.

Vereinfacht: Wenn ein Windows-Programm sagt „Öffne ein Fenster" oder „Speichere diese Datei", übersetzt Wine diese Anweisung so, dass Linux sie versteht und ausführt. Für viele Programme funktioniert das sehr gut. Für andere – besonders für Software, die tief ins Windows-System eingreift oder auf bestimmte Windows-Treiber angewiesen ist – stößt Wine an seine Grenzen.

Tools wie Bottles oder Lutris setzen auf Wine auf und bieten eine komfortable grafische Oberfläche. Für Gaming nutzt Proton (von Valve, dem Hersteller von Steam) ebenfalls Wine als Grundlage – ergänzt um zusätzliche Schichten, die Spiele besonders gut zum Laufen bringen.

Rechtliche Lage bei Wine

Wine selbst ist quelloffen und kostenlos – und erfordert keine Windows-Lizenz. Die Programme, die über Wine ausgeführt werden, müssen jedoch rechtmäßig lizenziert sein: Wer eine Windows-Software gekauft hat, darf sie auch über Wine nutzen. Wer sie nicht besitzt, darf sie auch unter Linux nicht einsetzen.

Datenschutz und Telemetrie

Wine sendet selbst keine Daten. Da kein echtes Windows im Hintergrund läuft, gibt es auch keine Windows-Telemetrie. Das ist ein echter Vorteil gegenüber allen Ansätzen, die auf echtem Windows basieren.

Grenzen von Wine

• Software, die auf Kernel-Level-Treiber angewiesen ist (viele Anti-Cheat-Systeme, bestimmte Sicherheitssoftware), lässt sich nicht über Wine betreiben
• Microsoft-Store-Apps und stark in Windows integrierte Systemwerkzeuge funktionieren nicht oder nur eingeschränkt
• Manche Programme laufen, aber nicht stabil oder nicht vollständig

Ob ein bestimmtes Programm unter Wine funktioniert, lässt sich auf der Wine-Kompatibilitätsdatenbank↗ nachschlagen.

Was WinBoat ist und wie es funktioniert

WinBoat geht einen grundlegend anderen Weg als Wine. Es betreibt ein vollständiges Windows-Gastsystem in einem Docker-Container – also einem abgeschlossenen, virtualisierten Bereich auf dem Linux-System. Windows-Programme laufen darin über das Remote-Desktop-Protokoll (RDP) und erscheinen auf dem Linux-Desktop als normale Fenster. Für den Nutzer sehen sie aus wie gewöhnliche Linux-Fenster – tatsächlich laufen sie jedoch in einem echten Windows, das im Hintergrund als virtuelle Maschine betrieben wird.

Das bedeutet: WinBoat kann im Prinzip alles ausführen, was auf Windows läuft – weil es echtes Windows ist. Aktuell befindet sich WinBoat noch in der Beta-Phase (Version 0.9.x, Stand April 2026) und kann gelegentlich Fehler und Einschränkungen aufweisen.

Technische Voraussetzungen

WinBoat ist kein Ein-Klick-Werkzeug für absolute Einsteiger. Notwendig sind: mindestens 4 GB RAM und 2 CPU-Kerne, KVM-Virtualisierung im BIOS aktiviert, Docker und Docker Compose v2 installiert, der Linux-Nutzer in der Docker-Gruppe eingetragen, FreeRDP v3+ auf dem Hostsystem – sowie mindestens 64 GB freier Speicherplatz.

Speicherplatzbedarf: Unterschätzt und riskant

Eine frische WinBoat-Installation belegt typischerweise 30–40 GB auf der Linux-Festplatte. Dieser Wert wächst mit der Zeit: Jedes Windows-Update, jede installierte Software vergrößert die virtuelle Festplattendatei. Beim Wechsel auf eine neue Windows-Hauptversion (z. B. von 24H2 auf 25H2) legt Windows eine Sicherungskopie der alten Systemdateien an – das kostet kurzfristig 10–15 GB zusätzlich. Nach zwei bis drei Jahren mit Updates und installierten Programmen können leicht 70–80 GB oder mehr zusammenkommen – als einzelne Datei auf dem Linux-System. WinBoat meldet das nicht aktiv: Wer die Festplattenauslastung nicht selbst im Blick behält, riskiert, dass die Linux-Partition vollläuft.

Das Tool selbst ist legal

WinBoat als Software ist quelloffen, kostenlos und steht unter der MIT-Lizenz. Das Programm selbst zu verwenden ist vollkommen legal.

Das Windows darin ist eine andere Frage

WinBoat lädt bei der Einrichtung ein Windows-ISO herunter – standardmäßig eine offizielle Evaluierungsversion von Microsoft, also eine zeitlich begrenzte Testversion (je nach Version 30–90 Tage). Nach Ablauf der Testphase läuft Windows weiter, zeigt aber ein Wasserzeichen und schränkt bestimmte Funktionen ein.

Wer Windows dauerhaft und vollständig nutzen möchte, benötigt eine gültige Lizenz. Hier liegt das eigentliche Problem: Die typische Zielgruppe von WinBoat sind Linux-Nutzer – und die meisten haben keine Windows-Lizenz. Wer WinBoat dauerhaft ohne Lizenz betreibt, bewegt sich nach Ablauf der Testphase in einer rechtlichen Grauzone bis hin zur klaren Lizenzverletzung. Eine legale Dauerlösung ohne Windows-Kauf gibt es für Privatanwender kaum.

WinBoat weist in seiner Dokumentation und Benutzeroberfläche nicht ausreichend auf diese Lizenzpflicht hin. Die rechtliche Verantwortung liegt vollständig beim Nutzer.

Telemetrie: Windows läuft – mit allem, was dazugehört

Da WinBoat ein echtes Windows betreibt, gelten alle Datenschutzeigenschaften von Windows unverändert. Im Hintergrund läuft eine vollwertige Windows-Instanz, die sich genauso verhält wie ein normaler Windows-Computer – inklusive aller Telemetrie-Funktionen, die Microsoft standardmäßig aktiviert. Windows sendet Diagnosedaten, Nutzungsstatistiken und Absturzberichte an Microsoft-Server. WinBoat selbst blockiert diese Telemetrie nicht und weist nicht aktiv darauf hin.

Microsoft-Konto und Anmeldezwang

Microsoft drängt immer stärker dazu, dass Windows-Nutzer ein Microsoft-Online-Konto verwenden. WinBoat versucht, das bei der automatischen Einrichtung zu umgehen – das gelingt aktuell größtenteils. Trotzdem ist nicht garantiert, dass das dauerhaft so bleibt: Microsoft schränkt solche Umgehungsmöglichkeiten mit jeder neuen Windows-Version weiter ein. Auch nach der Ersteinrichtung können regelmäßig Aufforderungen zur Konto-Anmeldung erscheinen. Kurz gesagt: Man betreibt echtes Windows – mit all seinen kommerziellen Verhaltensweisen.

Die Isolation ist nicht vollständig

WinBoat klingt nach doppelter Abschirmung – Container plus virtuelle Maschine. Das ist gegenüber gar keiner Isolation ein Fortschritt. Aber es ist keine undurchdringliche Mauer, und einer der entscheidenden Schwachpunkte ist ein eingebautes Feature: Das Home-Verzeichnis des Linux-Hosts wird standardmäßig als gemeinsamer Ordner in den Windows-Container eingebunden. Das ist für die Bedienbarkeit praktisch – bedeutet aber gleichzeitig, dass das Windows-Gastsystem direkten Lese- und Schreibzugriff auf alle persönlichen Dateien des Linux-Nutzers hat: Dokumente, Fotos, Konfigurationsdateien, SSH-Schlüssel – alles.

Was passiert, wenn Windows im Container keine Updates mehr bekommt?

Wer keine Windows-Lizenz hat, wird früher oder später keine Sicherheitsupdates mehr installieren – entweder weil die Evaluierungsversion abgelaufen ist oder weil Windows ohne Aktivierung zunehmend eingeschränkt reagiert. Ein nicht gepatchtes Windows ist ein Windows mit bekannten, ungepatchten Sicherheitslücken. Das ist unter normalen Umständen ein Problem. Im WinBoat-Setup ist es gefährlicher:

Gelangt Schadsoftware in das Windows im Container – etwa durch einen Browser-Angriff auf eine bekannte, ungepatchte Lücke – hat sie über den gemeinsamen Ordner direkten Zugriff auf die Dateien des Linux-Hosts. Ransomware, die die Windows-Partition verschlüsselt, kann genauso die Linux-Dateien verschlüsseln. Das ist kein theoretisches Szenario, sondern ein konkretes Risiko.

VM-Escape: Selten, aber nicht ausgeschlossen

Virtualisierungsschichten wie KVM/QEMU haben in der Vergangenheit Sicherheitslücken gehabt, die es Angreifern ermöglichten, aus dem virtuellen System auf den Host zu gelangen (sogenannter VM-Escape). Solche Lücken werden in aktuellen, gepatchten Systemen geschlossen – aber nur, wenn der Linux-Host selbst aktuell gehalten wird. Ein gepflegter Linux-Host schützt also auch gegen Schwächen in der Virtualisierungsschicht.

Wenn Wine für ein bestimmtes Programm nicht ausreicht und WinBoat's Beta-Status sowie die beschriebenen Risiken abschreckend wirken, gibt es eine ältere, bewährtere Lösung: Windows bewusst, mit einer echten Lizenz, in einer klassischen virtuellen Maschine betreiben – zum Beispiel mit KVM/Virt-Manager oder VirtualBox.

Der entscheidende Unterschied zu WinBoat: Man weiß, was man tut. Man hat eine gültige Windows-Lizenz. Man richtet die VM bewusst ein, bestimmt selbst, welche Ordner freigegeben werden, und entscheidet aktiv über Updates und Datenschutzeinstellungen. Man wird mit Windows aktiv konfrontiert – und das ist bei dieser Variante auch der Sinn der Sache.

Der Vorteil gegenüber WinBoat: keine Beta-Software, klare Lizenzlage, vollständige Kontrolle über die Konfiguration, ausgereifte Werkzeuge mit umfangreicher Dokumentation und Community-Unterstützung.

Wine ist die erste Wahl für die meisten Szenarien: keine Windows-Lizenz nötig, kein Datenschutzproblem, keine Lizenzfrage. Wer ein Windows-Programm benötigt, sollte zunächst auf der Wine-Kompatibilitätsdatenbank↗ nachschauen – und dann direkt über Wine oder das einsteigerfreundliche Bottles↗ starten.

WinBoat ist dann interessant, wenn Wine nicht ausreicht und man die Beta-Phase und die beschriebenen Einschränkungen akzeptiert. Wer WinBoat nutzt, sollte sich jedoch bewusst sein: Der legale Dauerbetrieb erfordert eine eigene Windows-Lizenz. Im Hintergrund läuft ein echtes Windows mit Telemetrie. Das Home-Verzeichnis ist standardmäßig mit dem Windows-Container geteilt. Und ein ungepatchtes Windows im Container ist ein Sicherheitsrisiko für die eigenen Linux-Dateien.

KVM oder VirtualBox mit echter Windows-Lizenz ist die ehrlichste Lösung, wenn Wine nicht ausreicht: Man wird aktiv mit Windows konfrontiert, hat aber vollständige Kontrolle, eine klare Rechtslage und ein ausgereiftes Werkzeug. Wer dauerhaft auf bestimmte Windows-Programme angewiesen ist, sollte diese Option ernsthaft in Betracht ziehen – oder ehrlich prüfen, ob ein Dual-Boot-Setup die bessere Antwort wäre.