Wine 10.0 veröffentlicht
Wine ist eine Open-Source-Software, die es ermöglicht, Windows-Anwendungen auf anderen Betriebssystemen wie Linux, macOS und BSD auszuführen. Der Name „Wine“ steht für „Wine Is Not an Emulator“, da Wine keine Emulation bietet, sondern eine Kompatibilitätsschicht, die Windows-APIs in POSIX-kompatible Aufrufe übersetzt. Dies ermöglicht es Benutzern, viele Windows-Programme auf Nicht-Windows-Systemen zu nutzen, ohne eine virtuelle Maschine oder Dual-Boot-Konfiguration zu benötigen. Nun ist die Version 10.0 erschienen, die grundsätzliche Unterstützung für die Arm64-Plattform mitbringt.
Diese ermöglicht es, ARM64EC- und ARM64-Code in einer einzigen Binärdatei zu kombinieren. Auch die Emulation von 64-Bit-x86-Programmen wurde implementiert, wobei der Wine-Code nativ läuft und nur der Anwendungscode emuliert werden muss. Im Grafikbereich wurde laut der Entwickler die High-DPI-Unterstützung verbessert. Programme ohne native High-DPI-Unterstützung werden nun automatisch skaliert. Die Vulkan-Unterstützung wurde auf Version 1.4.303 aktualisiert und unterstützt jetzt auch Vulkan-Video-Erweiterungen. Für 3D-Rendering in untergeordneten Fenstern steht nun auch Vulkan zur Verfügung.
Die Desktop-Integration erhielt neue Funktionen zur Bildschirmverwaltung. Ein experimenteller Modus ermöglicht die Emulation von Bildschirmauflösungsänderungen ohne tatsächliche Hardware-Umschaltung. Die neue Systemsteuerung desk.cpl erlaubt die Kontrolle dieser Einstellungen. Fortschritte gibt es auch bei Direct3D. Der OpenGL-Renderer nutzt jetzt GLSL 1.20 und moderne Erweiterungen. Für Direct3D 9 wurde eine HLSL-basierte Fixed-Function-Pipeline eingeführt. Der Vulkan-Renderer verwendet neue dynamische Zustandserweiterungen zur Reduzierung von Spielverzögerungen.
Das komplette Changelog gibt es hier. Mal schauen, wann die gängigen Softwarelösungen versuchen, mit Wine 10.0 zu arbeiten. Bei Whisky scheint nichts mehr zu passieren, CrossOver hingegen wird logischerweise auf Wine 10.0 setzen, in der Vorschau ist das ja bereits der Fall. CodeWeaver ist einer der wichtigsten Entwickler des Wine-Projektes. Die Webseite des Projektes wird von dem Unternehmen gehostet und einige seiner Entwickler werden von CodeWeaver beschäftigt. Der Projektleiter von Wine arbeitet ebenfalls bei CodeWeaver. Das Unternehmen liefert eigenen Angaben zufolge zwei Drittel der Commits zur Code-Basis.
Also die Kompatibilitätsschicht, die keine Emulation bietet, hat jetzt die Emulation von 64-Bit-x86-Programmen implementiert?
Hab ich da irgendeine spitzfindige Differenzierung nicht verstanden?
Es ist halt historisch bedingt…
Namensgebend stammt Wine aus der Zeit in der man sich über verschiedene Hardwarearchitekturen (x86, x86_64, arm …) noch keine Gedanken machen musste und der Name sich ausschließlich auf die Softwarearchitektur bezieht.
Wine emuliert halt nach wie vor keine Software – namentlich Windows bzw. die ganzen Systemaufrufe, Runtimes und Frameworks die nativ unter Windows laufen. Diese werden alle in patentfreie und selbst entwickelte Aufrufe übersetzt, es findet keine (möglicherweise lizenz-/patentrechtlich bedenkliche) Emulation der Microsoft-Systemcalls statt.
Was nun emuliert wird ist die Hardwareabstraktion; dein Hostsystem hat Arm64, also würden nativ für x86_64 kompilierte Programme nicht laufen. Hier emuliert nun Wine für diese Programme zur Laufzeit eine x86_64 CPU-Architektur, und dann laufen die halt wieder obwohl physisch diese Hardware nicht zur Verfügung steht.
Spitzfindig wäre jetzt nur, eine Namensänderung des Akronyms Wine zu fordern, weil es jetzt Randfälle abseits des eigentlichen Kernzwecks gibt, wo es nicht mehr 100%ig stimmt. 😉
Für meine musikalischen Ausflüge bringt Wine via yabridge eine Menge Windowsplugins in die Linuxwelt. VST2/VST3/CLAP, da gehen sogar Sachen mit iLok, aber Obacht, soweit geht nur bis wine-staging 9.21, macht aber nichts, denn für Musik muss es nicht immer die letzte Version sein. Großes (THX)-Kino!
Beeindruckend, iLok funktioniert oft nicht mal nativ auf Windows wirklich zuverlässig ^^