News Windows unter Linux: Wine 10 setzt auf Wayland

[Tanzmusikus]

Oktober 2022 sah es so aus:
https://forum.winehq.org/viewtopic.php?t=37000

Dezember 2021:
https://forum.armbian.com/topic/19526-how-to-install-box86-box64-wine32-wine64-winetricks-on-arm64/

 

[xpad.c]

Und im Endeffekt macht Wine ja nix anderes. Windows-API-Aufrufe werden in Echtzeit zu entsprechenden POSIX-Aufrufen übersetzt.

Vielleicht hast Du Dich da unglücklich ausgedrückt, aber da wird überhaupt nichts "in Echtzeit übersetzt".
Wine liefert alternative Implementierungen der Windows-APIs, und sorgt vor dem Start einer Windows-Anwendung dafür, dass ihr diese zur Verfügung stehen.

Also mir wärs bisher nicht bekannt, dass man Windows Code unter Linux direkt auf ARM ausgeführt werden kann.
[...]
Falls es das schon in irgendeiner Form gibt, würde mich interessieren obs dazu mehr Infos gibt. Ich kenne jedenfalls nichts.

Es gibt Box86/Box64 und FEX-Emu, und schon eine ganze Weile auch seitens wine schon Anpassungen, damit man das Ganze kombinieren kann. Habe mich in Ermangelung passender Hardware damit aber noch nicht befasst.

Das Game Porting Kit von Apple macht das im Prinzip auch so in der Art, wenn ich das richtig verstehe.

xpad

 

[Deinorius]

Also mir wärs bisher nicht bekannt, dass man Windows Code unter Linux direkt auf ARM ausgeführt werden kann.

Meinst du jetzt grundsätzlich oder direkt ohne zusätzlichen Emulator? Denn Windows Spiele kann man im Grunde sogar auf einer gehackten Switch laufen lassen.

 

[Alexander2]

Hatte nicht hier irgendwer was von synology geschrieben? Und noch kein Tool gefunden, das unter Wayland funktioniert?
https://github.com/feschber/lan-mouse

Edit: Ich hab dich gefunden @Randnotiz

 

[mike78sbg]

Vielleicht hast Du Dich da unglücklich ausgedrückt, aber da wird überhaupt nichts "in Echtzeit übersetzt".

Dann haben die sich hier auch ziemlich unglücklich ausgedrückt.
https://www.winehq.org/

Statt interne Windows-Logik zu simulieren, wie eine virtuelle Maschine oder ein Emulator, übersetzt Wine die Windows-API-Aufrufe in Echtzeit zu entsprechenden POSIX-Aufrufen und eliminiert somit die Performance- und Speichereinbußen, ....

Meinst du jetzt grundsätzlich oder direkt ohne zusätzlichen Emulator? Denn Windows Spiele kann man im Grunde sogar auf einer gehackten Switch laufen lassen.

Ich rede immer noch von dem hier. Steht so im Artikel. Wenn das bisher auch ging, bitte um Quelle.
Eine reine Emulation ist eine Sache, die Windows APIs in Posix umzuwandeln das andere. Aber die Kombination aus beidem ist mir bisher nicht bekannt.

Viel Arbeit an Wine 10 ist auch in die Umsetzung der ARM64-Architektur geflossen.Dabei wird der Wine-Code selbst nativ ausgeführt, während die nötige x86-Emulation von Drittsoftware über ein Interface erfolgt.

 

[xpad.c]

Dann haben die sich hier auch ziemlich unglücklich ausgedrückt.
https://www.winehq.org/

Ja, haben sie. Die englische Version ist ein wenig besser: "Wine translates Windows API calls into POSIX calls on-the-fly".

Aber wie gesagt, wine hat die Funktionen der Windows-APIs nachgebaut (nach dem Black-Box-Modell), und zwar auf Basis von POSIX-Systemaufrufen und unixoiden Bibliotheken. Wenn eine Windows-Anwendung läuft, und eine solche Funktion aufruft, dann erfolgen (im Hintergrund) die entsprechenden POSIX-Aufrufe.
Mit etwas Phantasie kann man der englischen Formulierung folgen, aber "in Echtzeit übersetzt" klingt IMHO nach einem völlig anderen Prinzip.

Ich rede immer noch von dem hier. Steht so im Artikel.
["Dabei wird der Wine-Code selbst nativ ausgeführt, während die nötige x86-Emulation von Drittsoftware über ein Interface erfolgt."]

Bei wine-ARM64 geht es darum, dass der eigentliche Code für wine selbst jetzt auf ARM64 läuft, und der x86-Emulator wirklich nur noch für den Code der Anwendung selbst erforderlich ist. Es wird also nicht das komplette Konstrukt wine+Anwendung in einer emulierten x86-Umgebung ausgeführt, sondern der Code von wine läuft nativ und damit schneller.
Daran wurde schon lange gearbeitet, und man hat da seit v9 große Fortschritte gemacht. Auch wine-WOW64 ist da zu nennen, bisher brauchte man für 32bit-Anwendungen noch einen 32bit-Pfad in wine, das ist jetzt auch hinfällig. Und weil das jetzt alles separiert wurde, kann man wine jetzt auch unter ARM64 laufen lassen, für x86-Anwendungen braucht man dann halt FEX oder einen anderen Emulator, wofür es wohl nun wine v10 auch eine Schnittstelle gibt.

HTH,
xpad

 

[Tanzmusikus]

Ahh... Danke! Jetzt ist das klarer !!! 🤓👍

 

[mike78sbg]

Ja, haben sie.

Da will wohl unbedingt jemand recht behalten. Von mir aus, so sei es. 😉

Für mich ist es dennoch auch Echtzeit. Jede Verzögerung wäre, besonders im Gaming, eine Katastrophe.

Bei wine-ARM64 geht es darum, dass der eigentliche Code für wine selbst jetzt auf ARM64 läuft, und der x86-Emulator wirklich nur noch für den Code der Anwendung selbst erforderlich ist. Es wird also nicht das komplette Konstrukt wine+Anwendung in einer emulierten x86-Umgebung ausgeführt, sondern der Code von wine läuft nativ und damit schneller.

Hab ich was anderes behauptet?

Ich fände es einfach witzig, wenn Windows Anwendungen unter Linux auf nem ARM besser laufen, als unter Windows on Arm selbst.

 

[Tanzmusikus]

Ja ob man es nun Echtzeit nennt oder nicht, darüber kann man sich streiten ... oder es sonntags sein lassen. 🤷‍♂️

 

[xpad.c]

Hab ich was anderes behauptet?
Ich fände es einfach witzig, wenn Windows Anwendungen unter Linux auf nem ARM besser laufen, als unter Windows on Arm selbst.

Du hattest gefragt, ob das neu sei.

Neu ist es offenbar insofern, als dass man jetzt nur noch für die Anwendung x86 emulieren muss. Das ist der Teil aus der zitierten Änderungsliste, und das könnte schon auch bedeuten, dass es leistungsmäßig überzeugt. An FEX wird ja auch aktiv gearbeitet, vielleicht gelingt es ja, die MS-eigene Umsetzung hinter sich zu lassen.

xpad

PS: "Echtzeit" hat eine spezifische Bedeutung für Betriebssysteme und Anwendungen, und die ist hier halt nicht gegeben.

 

[mike78sbg]

Du hattest gefragt, ob das neu sei.

Jain, ich hab gefragt, obs das schon woanders gab....

Aber ehrlich gesagt hab ich jetzt keine Lust mehr darüber zu diskutieren.

Ergänzung (26. Januar 2025)

PS: "Echtzeit" hat eine spezifische Bedeutung für Betriebssysteme und Anwendungen, und die ist hier halt nicht gegeben.

Wenn du meinst.

 

[Shader]

Die Meldung habe ich zum Anlass genommen Wayland eine Chance zu geben. Bisher hab ich in all meinen Installationen immer nur auf X11 gesetzt. Seit schon einigen Jahren nutze ich nur noch Manjaro Xfce aber Xfce ist mit Wayland noch nicht so weit.

Also habe ch Manjaro KDE Plasma auf ne rumliegende alte SSD Platte installiert und mir das System angeschaut, Steam Runtime und ein Spiel ausprobiert sowie mir all meine must-have Anwendungen probiert. Nur "Subsync" hat gestreikt aber mit "alass" hab ich eine angemessene und schlanke Alternative gefunden.
Den Test hat Manjaro KDE also bestanden.
Desktop fühlt sich viel besser an und die Skalierung bei KDE Plasma ist in der Tat bessser gegenüber Xfce.

Also werde ich in Zukunft komplett auf Manjaro KDE (wayland) umsteigen.

PS:
Manjaro KDE mit X11 Sitzung war dagegen hackelig, jeder Klick hatte eine Verzögerung. Hab mich damit aber nicht weiter auseinandergesetzt.