Wine 11 schreibt auf Kernel-Ebene neu, wie Linux Windows-Spiele ausführt, und erzielt massive Leistungsgewinne

• Die Ausführungsarchitektur für Windows-Spiele unter Linux wurde auf Kernel-Ebene grundlegend neu entworfen, wodurch der bisherige Synchronisations-Flaschenhals von wineserver entfällt
• Der neue NTSYNC-Treiber verarbeitet NT-Synchronisationsobjekte direkt im Kernel und erreicht dabei FPS-Steigerungen von bis zu mehr als dem Achtfachen
• Mit der Vervollständigung von WoW64 können 32-Bit-Windows-Apps auch auf 64-Bit-Linux ohne separate Bibliotheken ausgeführt werden
• Ausbau des Wayland-Treibers, Unterstützung für Vulkan 1.4, Verbesserungen bei Bluetooth und Force Feedback sowie eine breitere Kompatibilität bei Grafik und Ein-/Ausgabe
• Die Effekte auf Leistung und Stabilität breiten sich über das gesamte Wine-basierte Ökosystem aus, darunter Proton, SteamOS und Lutris

---

Die wichtigsten Änderungen in Wine 11

• Wine 11 ist nicht nur ein einfaches jährliches Update, sondern eine große Überarbeitung, die auf Kernel-Ebene neu schreibt, wie Linux Windows-Spiele ausführt

  • Neben über Jahre angesammelten Bugfixes und Performance-Verbesserungen enthält es auch strukturelle Änderungen wie NTSYNC-Unterstützung, Vervollständigung von WoW64 und den Ausbau des Wayland-Treibers
  • Die Leistungsverbesserungen breiten sich über Wine-basierte Projekte wie Proton und SteamOS hinweg aus

Bisherige Grenzen und Behelfslösungen

• Früher konnte Wine die NT-Synchronisationsprimitiven von Windows (Mutex, Semaphore, Event usw.) unter Linux nicht vollständig nachbilden
  • Für die Synchronisation zwischen Threads war jedes Mal ein RPC-Aufruf an den wineserver nötig, und Tausende solcher Aufrufe pro Sekunde verursachten Frame-Verzögerungen und unregelmäßiges Timing
• Esync verringerte die Aufrufe an den wineserver mithilfe von eventfd, stieß jedoch auf Probleme mit den Dateideskriptor-Limits
• Fsync ist auf Basis von futex schneller, benötigt aber Kernel-Patches außerhalb des Mainline-Kernels, weshalb es in normalen Distributionen schwer nutzbar ist
  • futex_waitv aus Linux 5.16 unterscheidet sich vom ursprünglichen Fsync-Ansatz und ist kein vollständiger Ersatz
• Beide Ansätze waren nur provisorische Lösungen, und einige NT-APIs (zum Beispiel NtPulseEvent oder der wait-for-all-Modus von NtWaitForMultipleObjects) ließen sich nicht exakt implementieren

NTSYNC — Neuentwurf der Synchronisation auf Kernel-Ebene

• NTSYNC fügt dem Linux-Kernel einen neuen Gerätetreiber /dev/ntsync hinzu, der Windows-NT-Synchronisationsobjekte direkt modelliert
  • Die Synchronisation wird innerhalb des Kernels statt im User Space verarbeitet, wodurch die Hin-und-zurück-Aufrufe zum wineserver entfallen
  • Queue-Verwaltung, Event-Semantik und atomare Operationen werden vollständig direkt vom Kernel ausgeführt
• Entwickelt wurde dies von Elizabeth Figura, die bereits Esync und Fsync geschaffen hat; nach der Vorstellung auf der Linux Plumbers Conference 2023 wurde es in Linux 6.14 aufgenommen

• Leistungswerte

  • Dirt 3: 110.6 → 860.7 FPS (678 % Verbesserung)
  • Resident Evil 2: 26 → 77 FPS
  • Call of Juarez: 99.8 → 224.1 FPS
  • Tiny Tina’s Wonderlands: 130 → 360 FPS
  • Call of Duty: Black Ops I ist vollständig spielbar

• Unterschiede gegenüber fsync

  • Für fsync-Nutzer sind die Zugewinne begrenzt, aber bei Spielen mit Multithreading-Flaschenhälsen sind die Verbesserungen dramatisch
  • Da es im Mainline-Kernel enthalten ist, sind keine separaten Patches mehr nötig; in aktuellen Distributionen wie Fedora 42 und Ubuntu 25.04 sofort nutzbar
  • In der SteamOS 3.7.20 Beta standardmäßig enthalten und auch in Proton GE aktiviert
  • NTSYNC ist der erste Fall in der Geschichte von Wine, in dem eine präzise Synchronisationsimplementierung auf Kernel-Ebene erreicht wurde

WoW64 vervollständigt — Vereinheitlichte 32-Bit-Kompatibilität

• Die Implementierung der WoW64-Architektur (Windows 32-bit on Windows 64-bit) ist in Wine 11 abgeschlossen
  • Auf 64-Bit-Linux-Systemen ist für die Ausführung von 32-Bit-Windows-Apps keine separate Installation von 32-Bit-Bibliotheken mehr nötig
  • Ein einzelnes Binärprogramm erkennt die Bitbreite der ausführbaren Datei automatisch und verarbeitet sie entsprechend
• Enthalten sind außerdem OpenGL-Speicherzuordnung, SCSI-Passthrough und sogar Unterstützung für 16-Bit-Anwendungen
  • Damit lassen sich auch alte Windows-Programme aus den 1990er-Jahren ausführen
• Früher erschwerten distributionsabhängige Unterschiede bei der multilib-Konfiguration die Ausführung, jetzt übernimmt Wine das intern

Wayland und weitere wichtige Verbesserungen

• Wayland-Treiber

  • Bidirektionales Kopieren über die Zwischenablage, Drag-and-Drop-Unterstützung und Compositor-Skalierung beim Auflösungswechsel verbessern die Kompatibilität älterer Spiele
  • Die meisten Wine-Kompatibilitätsprobleme beim Wechsel von X11 zu Wayland werden damit behoben

• Grafik und Medien

  • Unter X11 wird EGL zum Standard-Backend für OpenGL und ersetzt GLX
  • Unterstützung für Vulkan 1.4 sowie hardwarebeschleunigte H.264-Dekodierung auf Basis von Vulkan Video wurden hinzugefügt

• Ein-/Ausgabe und Peripherie

  • Verbesserungen bei Force Feedback stärken die Unterstützung für Rennlenkräder und Flightsticks

  • Unterstützung für Bluetooth-BLE-Dienste und Pairing**,** verbesserte Verarbeitung von MIDI-Soundfonts

    • Hinzugekommen sind Zip64-Komprimierung, Unicode 17.0.0, TWAIN-2.0-Scanning (64-Bit) und IPv6-Ping

• Leistung und Plattform-Erweiterung

  • Unter Linux und macOS wurde die Verwaltung von Thread-Prioritäten verbessert, was die Multithreading-Leistung steigert
  • Auf ARM64 wird die Simulation von 4K-Seitengrößen unterstützt, was die Kompatibilität mit ARM-basierten Linux-Geräten sicherstellt

Spielekompatibilität und Bugfixes

• Die Kompatibilität wichtiger Titel wie Nioh 2, StarCraft 2, The Witcher 2, Call of Duty: Black Ops II, Final Fantasy XI und Battle.net wurde verbessert
• Hunderte Bugfixes erhöhen insgesamt Stabilität und Leistung

Gesamtbewertung

• Mit NTSYNC, der Vervollständigung von WoW64, Wayland-Verbesserungen und umfangreichen Bugfixes ist Wine 11 die wichtigste Veröffentlichung seit Proton
• Leistung und Kompatibilität verbessern sich in allen Wine-basierten Projekten wie Proton, Lutris und Bottles
• Wer unter Linux spielt, sollte Wine 11 unbedingt ausprobieren

[kh0324]

Am Ende wird es wohl darauf hinauslaufen, dass wieder bei ein paar Jahren alter Spiele die Abwärtskompatibilität kaputtgeht..

Das scheint hier der Tausch zu sein.

[GN⁺]

Hacker-News-Kommentare

• Ich habe nahezu grenzenlosen Respekt vor dem Wine-Projekt
  30 Jahre lang das dokumentierte und undokumentierte Verhalten von Windows originalgetreu nachzubauen, klingt nach einer langweiligen und kaum belohnten Aufgabe, aber genau dadurch ist Wine tatsächlich zu einem brauchbaren Produkt geworden
  Besonders wenn man sieht, dass alte Spiele teils besser laufen als unter Windows, merkt man, wie beeindruckend die Liebe zum Detail und die Leidensfähigkeit sind

  • Früher habe ich Gaming unter Linux gemieden, weil ich dachte, Wine könne unmöglich richtig funktionieren
    Gelegentlich habe ich mal ein einfaches Spiel ausprobiert und dachte: „Das läuft ja?“, aber ich hielt es nie für zuverlässig
    Inzwischen gestehe ich ein, dass dieses Urteil völlig falsch war
  • Trotz des wirklich großartigen Projekts ist es schade, dass Business-Apps wie Word, Excel oder Outlook noch immer nicht gut laufen
    Excel 2010 soll die letzte Version mit Platinum-Bewertung gewesen sein
    Interessant ist, warum solche Apps schwieriger sind als Spiele
  • Wine führt automatisiert Kompatibilitätstests auf verschiedenen Plattformen aus
    Auf der Seite mit den Testergebnissen sieht man, dass genau diese systematische Validierung der Schlüssel zur hohen Kompatibilität ist
  • Auch ReactOS ist erwähnenswert
    Viel Wissen aus diesem Projekt ist in die Wine-Entwicklung eingeflossen
  • Als ich in den 90ern OS/2 genutzt habe, musste man zum Ausführen von Windows-Apps noch ein komplettes Windows starten
    Damals wollte ich selbst so etwas wie Wine bauen, hatte aber nicht genug Wissen dafür
    Heute nutze ich Linux nur noch für Server, habe also keinen Bedarf mehr; ich habe zwar gehört, dass es Wine auch für den Mac gibt, aber es gibt keine Windows-Apps, die ich unbedingt darauf laufen lassen möchte

• Ich war überrascht zu sehen, wie stark die Framerate dank Proton gestiegen ist
  Dass Dirt 3 von 110 FPS auf 860 FPS und Resident Evil 2 von 26 FPS auf 77 FPS steigt, ist kaum zu glauben
  Ich denke, das ist dem Umstand zu verdanken, dass Valve hier viel Geld hineingesteckt hat

  • Allerdings sind diese Zahlen etwas irreführend, weil sie Wine+ntsync mit der Standardversion von Wine vergleichen
    Im Vergleich zu Wine auf Basis von fsync liegt der Zugewinn eher nur bei einigen Prozent
    Trotzdem ist ntsync eindeutig eine Verbesserung
    Laut der ntsync-Dokumentation ist es ein Kernel-Treiber, der die Synchronisationsmechanismen von Windows unter Linux präziser nachbilden soll
  • Man sollte auch beachten, dass der Vergleich für den Fall gilt, wenn weder esync noch fsync verwendet wird
  • Mich interessiert die Beziehung zwischen Proton und Wine — ist Proton nur der Name für Valve/SteamOS, oder ein eigenständiges Projekt?

• Es gibt auch Stimmen, die davor warnen, sich wegen der ntsync-Leistungssteigerungen zu sehr zu begeistern
  In den meisten Fällen liegen die Leistungsgewinne nur im einstelligen Prozentbereich, und manche Spiele könnten sogar leicht langsamer werden

  • Wer einen Kernel ohne fsync-Patch nutzt, für den kann die Lage anders aussehen
  • Es wurde auch angemerkt, dass ein Vergleich der Performance von Wayland und X11 interessant wäre

• Wenn ich über solche Low-Level-Technik lese, schäme ich mich fast, dass ich nur CRUD-Apps baue

  • Aber auch CRUD hat seinen Wert und ist gut für die psychische Gesundheit
    Ich habe einmal eine Geschichte über einen genialen Entwickler gehört, der von extremen Deadlines ausgebrannt war und dann zu einfacher VB-CRUD-Arbeit wechselte und sagte, das fühle sich „wie bezahlter Urlaub“ an
  • Ich selbst helfe in Outlook oft nur bei simplen Dingen wie „hier klicken, dort klicken“, aber auch solche Arbeit ist essenziell
  • Umgekehrt sagen selbst Low-Level-Entwickler, dass sie sich unzulänglich fühlen, wenn sie mit High-Level-Systemen arbeiten müssen
  • Sogar ich, obwohl ich Compiler baue, bin mehrmals daran gescheitert, eine CRUD-App für ein privates Projekt umzusetzen
    Ich habe Rails, Phoenix und Django ausprobiert, aber einfach war es nicht
    In letzter Zeit habe ich mit Hilfe von Claude etwas Fortschritt gemacht
  • Auch CRUD-Apps sind nicht trivial
    Unternehmensanforderungen sind komplex, und dadurch kann die Architektur leicht kollabieren

• Es freut mich, dass die Tausende Dollar, die ich bei Valve ausgegeben habe, am Ende in die Verbesserung von Wine geflossen sind
  Ich frage mich, wie viele Entwickler und Auftragnehmer Valve dafür beschäftigt hat

  • Zwei Drittel der Wine-Entwickler gehören zu CodeWeavers und arbeiten im Rahmen von Verträgen mit Valve und Proton
    Das heißt, der Großteil der Finanzierung fließt dorthin

• Wine könnte paradoxerweise auch selbstzerstörerisch sein
  Wenn Spiele unter Linux gut laufen, könnten Entwickler direkt Linux-Ports bauen, wodurch Wine irgendwann überflüssig würde

  • Aber weil die API von Wine stabiler ist als die von Linux, könnte Wine sogar selbst zu einem erstklassigen Ziel werden
  • Ich glaube eher, dass das Gegenteil der Fall ist
    Selbst wenn es einen nativen Port gibt, ist es oft stabiler, einfach die Windows-Version über Proton laufen zu lassen
    Die Windows-API ist vertraut und verändert sich nicht, daher entwickeln viele Teams weiterhin mit diesem Ziel vor Augen
  • Heute bedeutet „Linux-Unterstützung“ letztlich oft einfach, unter Proton gut zu laufen
  • Ich halte das für ein „gutes Problem“
  • Außerdem wird Wine nicht nur für Spiele genutzt; selbst wenn es mehr native Ports gäbe, bliebe die Nachfrage bestehen
    Das Windows-ABI ist weiterhin stabiler, daher ist es effizienter, nur den Windows-Build zu pflegen, solange der Performance-Unterschied gering ist

• Es gab die Frage, ob man ntsync nicht im User Space mit Shared Memory implementieren könnte
  Claude erklärte dazu, dass „für 95 % der Spiele ein einfacher Ansatz ausgereicht habe, es daher keinen Anreiz gab, eine komplexe Shared-Memory-Logik zu implementieren, und es in dem Moment, als Genauigkeit wichtig wurde, natürlich gewesen sei, das Ganze in den Kernel zu verlagern“

  • Tatsächlich ist das aber unmöglich, weil Linux solche User-Space-Funktionen nicht bereitstellt
    ntsync ist kein bloßer API-Wrapper, sondern ein Adapter auf Kernel-Ebene, der das Synchronisationsverhalten des NT-Kernels nachbildet
    Ein Blick in den Quellcode zeigt, dass es eng mit dem Kernel-Scheduler verzahnt ist
  • Auch in der Kernel-Dokumentation steht ausdrücklich, dass „eine User-Space-Implementierung weder die Performance noch die Genauigkeit von Windows-Niveau erreichen kann“
    Link zur Dokumentation

• Es ist erstaunlich zu sehen, dass Linux Windows neu implementiert und dabei sogar besser macht
  Während Microsoft seine eigene Software immer unbequemer macht, ist diese Leistung umso beeindruckender

  • Besonders bedeutsam ist, dass Wine die unter 64-Bit-Windows weggefallene 16-Bit-Unterstützung weiterhin erhält
    Viele alte Spiele basieren auf 16 Bit, und selbst bei 32-Bit-Spielen ist das Installationsprogramm oft noch 16-bittig

• Falls ein Wine-Entwickler diesen Beitrag sieht, wäre es großartig, dazu auf der Carolina Code Conference 2026 einen Vortrag zu hören
  Der Call for Speakers läuft noch bis zum 31. März

• Wer das Gleiche unter macOS will, kann zu diesem Repository beitragen

  • Aber ehrlich gesagt gibt es für MacOS zu wenige Spiele, als dass sich viele interessierte Entwickler finden würden
    Ich erinnere mich zwar gern daran, früher auf den Macs in der Schule das Panzer-Spiel Bolo gespielt zu haben, aber das dürfte nicht einmal 1 % der Zahl an Windows-Spielen sein
  • Wenn es aus Performance-Gründen in den Kernel musste, frage ich mich allerdings, warum Linux es nicht im User Space gemacht hat