WinBoat: Windows-Apps unter Linux nahtlos ausführen

 (winboat.app)
13 Punkte von GN⁺ 2025-10-10 | 1 Kommentare | Auf WhatsApp teilen
  • WinBoat legt den Schwerpunkt auf Bedienkomfort durch automatisierte Einrichtung und eine intuitive Benutzeroberfläche statt auf den bisherigen WinApps-Ansatz
  • Unterstützt wichtige Apps wie die Adobe-Produktfamilie, Affinity Photo u. a., die mit Wine oder CrossOver nicht kompatibel sind
  • Mit der experimentellen USB-Passthrough-Funktion lässt sich Windows-exklusive Hardware konfigurieren
  • GPU-Virtualisierung sowie Unterstützung für Flatpak und Podman sind geplant und erhöhen die Erweiterbarkeit
  • Typische Windows-Apps wie Office 365 lassen sich frei verwenden

Was ist WinBoat?

  • WinBoat ist ein Tool, das dabei hilft, Windows-Apps in einer Linux-Umgebung reibungslos auszuführen
  • Ohne umständliche manuelle Einrichtung erhalten Nutzer mit nur einer Konfiguration und den nötigen Grundvoraussetzungen ein integriertes Nutzungserlebnis
  • Es sind weder Änderungen an separaten Konfigurationsdateien noch das Erlernen komplexer CLI-Befehle nötig; alles lässt sich direkt über eine einzige Oberfläche nutzen

Vergleich mit WinApps

  • Bei WinApps müssen verschiedene Konfigurationsschritte manuell durchgeführt werden; außerdem sind TUI, Taskleisten-Widgets oder CLI-Befehle erforderlich
  • WinBoat automatisiert nach der Installation die komplette Einrichtung auf einmal und bietet eine intuitive UI, wodurch ein rundes Gesamterlebnis entsteht
  • Einfache Bedienung ohne direkte Pflege von Konfigurationsdateien oder das Auswendiglernen von CLI-Befehlen

Vorteile gegenüber CrossOver oder WINE

  • Auch verschiedene Apps, die unter Wine, CrossOver schwer auszuführen sind (z. B. Affinity Photo, die komplette Adobe Suite, Paint Tool Sai, AeroChat, Acrobat, Office usw.), funktionieren
  • Bietet eine vollständige Windows-Desktop-Umgebung und sorgt für breite Software-Kompatibilität

Unterstützung für Peripherie/Hardware und Passthrough

  • Für USB-basierte Geräte unterstützt WinBoat seit 0.8.0 USB-Passthrough (experimentell), sodass sie mit Windows-Software konfiguriert werden können
  • Nutzer älterer WinBoat-Versionen können USB-Geräte durch direkte Anpassung von docker-compose.yml hinzufügen
  • Ab 0.8.0 ist nur noch die integrierte Methode kompatibel

GPU-Passthrough und Grafikvirtualisierung

  • GPU-Passthrough wird derzeit nicht unterstützt
  • Geplant sind später GPU-Beschleunigung und die Integration mit Looking Glass unter Nutzung von para-virtualized Treibern und dem Indirect Display Driver
  • Tests haben gezeigt, dass einige Treiber für den Praxiseinsatz noch ungeeignet sind; eine Integration ist vorgesehen, sobald alles bereit ist

Spiele und Sicherheit

  • Spiele mit Anti-Cheat auf Kernel-Ebene lassen sich aufgrund der Grenzen virtualisierter Umgebungen nicht ausführen

Erweiterbarkeit und Distributionspläne

  • Unterstützung für Podman (als Docker-Alternative) ist geplant, befindet sich wegen Netzwerkproblemen aber noch nicht in einem abgeschlossenen Zustand
  • Auch Flatpak-Pakete sind geplant, allerdings gibt es technische Herausforderungen bei System-/App-Schnittstellen und der Freigabe von Tools

Unterstützung für Windows-Software und Office

  • Wichtige Windows-Apps wie Microsoft Office 365 laufen ordnungsgemäß

Fazit

  • WinBoat ist eine Lösung, die mit benutzerfreundlicher Automatisierung, Kompatibilität und Erweiterbarkeit die nahtlose Nutzung von Windows-Anwendungssoftware unter Linux unterstützt

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2025-10-10
Hacker-News-Kommentare
  • Das ist im Grunde einfach nur eine Windows-VM mit ein paar zusätzlichen Tools. Es sieht zwar ziemlich cool aus, fühlt sich aber nicht wirklich wie „Windows-Apps unter Linux ausführen“ an.
    Ähnliche Projekte wie Looking Glass gibt es im Gaming-Bereich schon länger, und auch diese nutzen eine Windows-VM auf KVM. (Es wird so dargestellt, als würde Windows direkt in einem Docker-Container laufen, tatsächlich läuft die Architektur aber auf KVM.)
    Aus UX-Sicht ist es RAIL ähnlich.
    Das heißt nicht, dass das Projekt schlecht ist, aber letztlich ist es wie bisher auch nur einer von zwei Ansätzen: API-Simulation/-Reimplementierung oder das eigentliche Ausführen des OS selbst, also Windows. Ganz neu ist das also nicht.
    Wenn es einen dritten Weg gäbe, etwa eine In-Place-ABI-Transformation, wäre das meiner Meinung nach wirklich eine große Nachricht.
    • Ich musste erst zu Hacker News kommen, um herauszufinden, was das Projekt tatsächlich macht und wie es funktioniert.
      Projektseiten sagen meist nicht klar, was sie eigentlich tun.
      Die Hälfte klingt eher nach „Plorglewurzle nutzt Big-Data-Blockchain, um sublineare Microservices auf Azure-Cloud-Infrastruktur bereitzustellen“.
      Immerhin zeigt dieses Projekt zumindest, dass eine Windows-Installation erforderlich ist.
    • Es wäre lustig gewesen, wenn sie es wirklich „Linux Subsystem for Windows“, kurz LSW, genannt hätten.
    • Das hier ist eine Kombination aus dockur/windows:latest, FreeRDP im Rootless-Modus und einem kleinen Daemon, der per API mitteilt, welche Apps in der VM installiert sind.
      Wenn man den letzten Teil nicht braucht, ist man mit dem dockur/windows-Image und FreeRDP allein vielleicht besser bedient.
    • In-Place-ABI-Transformation ist doch genau das, was Wine macht. Ich frage mich, was damit gemeint war.
    • Exakt dieselbe Struktur wie bei WSL2.
  • Ich habe im GitHub-Repository eine Erklärung dazu gefunden, was die Software tatsächlich macht.

WinBoat ist eine Electron-App, mit der sich Windows-Apps unter Linux in containerisierter Form ausführen lassen.
Windows läuft in einer VM innerhalb eines Docker-Containers, und über den WinBoat Guest Server holen wir die benötigten Daten aus Windows.
Um Windows-Apps als Fenster auf Native-OS-Niveau zusammenzusetzen, verwenden wir FreeRDP und das Windows-RemoteApp-Protokoll.

  • Ich frage mich, warum dafür sowohl ein Docker-Container als auch eine VM nötig sind.
  • Mein Tipp, um unter Linux glücklich zu werden, lautet:
    Immer native Apps verwenden. Nicht einmal WINE benutzen und grundsätzlich nicht versuchen, Kompatibilität mit etwas herzustellen, das einem im Grunde feindlich gegenübersteht.
    Keine VMs benutzen und vor allem niemals Dual-Boot empfehlen. Das ist wirklich nicht gut.
    Am besten komplett auf Linux umsteigen und nicht zurückschauen.
    Proton ist ein etwas besonderer Fall, denn dass es so gut läuft, liegt nur daran, dass Valve täglich enorm viel Energie hineinsteckt.
    Die gute Nachricht ist, dass Investitionen in die Weiterentwicklung von Linux-APIs/-ABIs definitiv Früchte tragen.
    Was Valve zu MESA und amdgpu beigetragen hat, ist wirklich großartig.
    Ich wünschte, Valve würde AAA-Titel und Indie-Spiele unter Linux als eine Art Steam-Exklusivstatus behandeln.
    Und ich hoffe, Spieleentwickler nehmen daraus mit: „Ein Linux-Port gehört unbedingt in die Hände von Linux-Entwicklern.“
    PS: Ich fand es wirklich lange schade, dass Counter-Strike unter Linux nicht lief, aber seit Valve es nativ portiert hat, ist es großartig.
    PPS: Wegen zweier inkompatibler Apps, Garmin Express und Zwift, nutze ich auch einen Mac. Der macht weniger Wartungsaufwand als Windows, aber man kann damit weniger machen als unter Linux.
    Der Dateibrowser ist wirklich schlecht, und auch das Fenstermanagement nervt.
    Dafür verursacht es mir nicht den ganzen Tag Kopfschmerzen.
    Counter-Strike 2 läuft auf dem Mac nicht, also muss Linux diesen Teil übernehmen.
    • Ich halte diesen Rat nicht für besonders gut.
      Gegenposition: Wine funktioniert wirklich gut, besonders bei älterer Software.
      Wenn Menschen sich mit solchen Regeln unnötig selbst einschränken, können viele Linux am Ende gar nicht nutzen.
    • Meine Empfehlung: „Immer nur native Apps nutzen, kein WINE.“
      Meine Sicht: Richtiger wäre eher „Versuche nicht, dich an fundamental instabile APIs anzupassen“.
      Passender Artikel: Win32 is the stable Linux userland ABI and the consequences
      Weiterer Blogpost: Win32 the only stable ABI
      Genauer gesagt finde ich, dass native GNU/Linux-Apps ideal wären, aber dafür müssten APIs zuerst über sehr lange Zeit stabil gehalten werden, mindestens 20 Jahre.
    • Ich habe meinen Gaming-Desktop letztes Jahr auf Linux umgestellt.
      Meiner Erfahrung nach gibt es nur wenige wirklich gut gemachte native Linux-Versionen.
      Oft war die Windows-unter-Proton-Version qualitativ sogar besser.
      Ich bin Unternehmen wie Larian dankbar, die wie bei BG3 eine native Version hervorragend umgesetzt haben.
      Dass Proton so gut ist, liegt eindeutig an Valves kontinuierlichem Einsatz, da stimme ich völlig zu.
      Spieleentwicklern native Ports zu predigen, funktioniert in der Realität aber nicht besonders gut.
      Letztlich ermöglichen Steam Deck, Valve und Proton gemeinsam erst, dass sich der Markt langsam in Richtung Linux bewegt.
    • Was einen normalerweise ausbremst, sind nicht die großen AAA-Spiele, sondern unerwartete Spezialsoftware.
      Zum Beispiel kleine dedizierte Tools wie eine App zum Entwerfen von Strickmustern, die nicht Open Source ist.
      Dafür kann eine reibungslos kompatible Umgebung unbedingt nötig sein.
      (Spiele sind dank Proton inzwischen einigermaßen abgedeckt.)
    • „Wenn du unter Linux glücklich werden willst, nutze nur native Apps, kein WINE, keine VM und kein Dual-Boot.“
      Ich halte das nicht für einen besonders guten Rat.
      Viele Menschen wollen Linux nutzen und trotzdem Windows-Apps ausführen, und Wine funktioniert dabei oft gut.
      Für Apps, die unter Wine nicht laufen, ist auch Dual-Boot eine vollkommen brauchbare Lösung.
  • Es ist schade, dass es auf der Website der Software keine Screenshots vom tatsächlichen Lauf gibt.
    Statt nur zu behaupten, dass Office-Apps laufen, sollte gezeigt werden, wie das konkret aussieht.
    Es wird eine „seamless“ Erfahrung betont, aber es gibt keine Demo.
    Das kann ich wirklich nicht nachvollziehen.
    • Dem stimme ich vollkommen zu.
      Es gibt überhaupt keine Informationen dazu, wie einzelne Windows-Fenster in den Linux-Desktop integriert werden, etwa bei Alt-Tab oder im Ubuntu Dock, oder ob man am Ende einfach nur ein riesiges VM-Fenster bekommt.
      Ich frage mich, warum man so etwas auf der Website nicht zeigt.
  • Die UX sah cool und interessant aus, also habe ich es letztes Wochenende selbst ausprobiert.
    Leider funktionierte nicht einmal die grundlegende Nutzung richtig.
    Wenn man den Edge-Browser startet, erscheint zwar ein Fenster, aber es hängt und es scheint keine Möglichkeit zur Wiederherstellung zu geben.
    Selbst wenn man das Fenster schließt, verschwindet der Fensterrahmen nicht und bleibt stehen.
    Wenn man versucht, die Option „Desktop“ zu verbinden, friert alles ein.
    Über die eingebaute Webview konnte ich zwar eine Verbindung zur Sitzung herstellen, aber es schien zu verlangen, RDP-Verbindungen zu erlauben.
    Ich habe nicht tiefer gegraben, und da es für den Einsatzzweck meiner Frau nicht passte, habe ich den Laptop wieder auf Windows zurückgesetzt.
    Ich hoffe, dass sich die App-/Systemintegration auf der Windows-Seite künftig noch verbessert.
    • Darf ich fragen, wofür deine Frau es gebraucht hätte?
      Viele Windows-Apps laufen unter Wine gut und benötigen nur ein paar kleine Tweaks, daher könnte das auch eine brauchbare Option sein.
  • Ich mag Projekte wirklich, die Open-Source-Software mit einer benutzerfreundlichen UX versehen, damit sich unter Linux notwendige Software leichter nutzen lässt.
    Es wäre schön, wenn es etwas Ähnliches gäbe, um auch macOS-Apps unter Linux auszuführen.
    • Es wäre schön, wenn sich macOS gut unter Linux ausführen ließe, aber realistisch gesehen gibt es viele Hürden.
  1. Apple verbietet rechtlich, seine Software auf Nicht-Mac-Hardware auszuführen.
  2. Windows mag noch so viel Kritik einstecken, aber es zu virtualisieren und überall laufen zu lassen, ist Industriestandard; bei macOS wird das erst langsam überhaupt möglich.
  3. Apple hätte wirtschaftlich viel zu verlieren und versucht deshalb aktiv, so etwas zu verhindern.
  4. Apple führt eine eigene Plattform namens „Apple Containers“ als Docker-Ersatz ein und lenkt Mac-Nutzer damit davon weg, Docker zu verwenden.
    Daher dürfte es noch eine Weile dauern, bis macOS-Apps plus Linux etwas Alltägliches werden.
  • Nicht ganz dasselbe, aber es gibt darling, das nur CLI-Apps unterstützt: darling
    Wenn du eine vollständige macOS-VM brauchst, kannst du dir das Projekt von dockur ansehen: dockur/macos
    Beide unterstützen derzeit allerdings keinen „seamless“-Modus.
  • macOS hat keine Rootless-RDP-Funktion, mit der man einzelne macOS-Apps selbst anzeigen könnte.
    Wenn man ohnehin den ganzen Desktop verwenden muss, halte ich eine hardwarebeschleunigte Grafikansicht für sinnvoller als RDP.
  • Das WinBoat-Projekt finde ich interessant und werde es weiter beobachten.
    In den letzten Jahren habe ich WSL vor allem für die Arbeit genutzt, und dass sich GUI-Apps fast so verwenden lassen, als liefen sie direkt unter Windows, steigert die Produktivität.
    Es gibt ein paar seltsame Stellen, aber insgesamt ist es ziemlich ordentlich.
    In umgekehrter Richtung habe ich mich immer gefragt, ob es für Linux nicht etwas Ähnliches geben könnte.
    Tatsächlich musste ich unter Linux nur selten Windows-Programme verwenden.
    Am ehesten erinnere ich mich daran, dass ich früher GTA: Vice City mit Wine fast perfekt zum Laufen gebracht habe.
    In letzter Zeit denke ich oft, dass es großartig wäre, wenn es so etwas wie ein „Linux Subsystem for Windows“ gäbe, mit dem sich einfach jedes Programm sofort ausführen ließe.
    Ich habe auf dem Laptop meiner Tochter Debian installiert, und ich hoffe, dass WinBoat künftig eine Alternative sein könnte, falls für Schulaufgaben einmal zwingend ein Microsoft-Produkt benötigt wird.
  • Für die Integration von Windows-Apps würde ich das Projekt WinApps empfehlen (WinApps-Link).
    Wayland-Support ist zwar noch in Arbeit (Wayland-bezogenes Issue), aber vorerst lässt es sich mit xwayland zumindest einigermaßen nutzen.
  • Der Looking Glass Indirect Display Driver (IDD), der in den Projekt-FAQs erwähnt wird, klingt wirklich vielversprechend.
    Wenn IDD erscheint, wird Looking Glass auch auf iGPU-Setups laufen, was trotz fehlender 3D-Beschleunigung sinnvoll ist.
    Die große Leistung von Looking Glass bestand ursprünglich darin, den Videospeicher zwischen dem Kompositor im Windows-Gast und dem Client-Programm auf dem Host zu teilen, mithilfe von qemu.
    Leider muss man noch immer einen Treiber außerhalb des Kernels (kvmfr) separat installieren. Trotzdem hoffe ich, dass sich durch das Teilen nicht nur von Videospeicher, sondern auch von normalem Speicher die Performance bis zu einem gewissen Grad verbessern lässt.
    Demo-Video: YouTube-Link
  • Eine Bitte an das Projektteam:
    Bitte platziert Discord nicht so prominent auf der Hauptseite der Website.
    Discord wird auch häufig als C2-Server missbraucht, weshalb in gehärteten Umgebungen beim Aufruf Warnungen erscheinen.
    Bei uns im Unternehmen gehen diese Warnungen zum Glück direkt an mich, aber es verursacht trotzdem unnötige Alarme.
    Am besten sollte der Link zumindest etwas versteckter platziert werden.