Mit wine-wow64 32-bit-Windowsanwendungen ohne 32-bit-Linux-Bibliotheken ausführen können

[Caramon2]

@Spontaneous: Ich habe es durchgetestet und es kann nicht an dxvk liegen, da es sonst ja auch ohne dxvk flüssig läuft:

Wie neulich geschrieben, schleppe ich Wine nicht mehr beim Produktivsystem mit, da ich es nur noch in Ausnahmefällen brauche, sondern habe dafür eine extra Installation auf einer ext. SSD.

Ich habe dort Wine durch Wine-wow64 ersetzt und wie im ersten Beitrag beschrieben, alles 32-bittige entfernt (ein späterer Test hat gezeigt, dass es keinen Unterschied macht, wenn nur Wine austausche, aber nichts anderes entferne). An der Wine-Konfiguration hatte ich nichts geändert:

Mit dem normalen Wine lädt PipeDream in ca. 6 Sek., mit Wine-wow64 braucht es ca. 43 Sek. - Außerdem ist mir inzwischen aufgefallen, dass wenn ich Esc drücke und das durchscheinende Exit-Menü erscheint, PipeDream dahinter höchstens noch mit 5 fps läuft: Beim normalen Wine bleicht es flüssig.

Wenn ich die Installation aber wie beschrieben in KVM boote (gleich am Anfang mit Strg+Alt+F auf Vollbild geschaltet), lädt PipeDream auch mit Wine-wow64 normal schnell und bleibt auch hinter dem Exit-Menü flüssig.

dxvk war dabei nie installiert (genauso wenig wie vkd3d), also kann es daran nicht liegen. In den Artix- und sogar den Arch-Quellen gibt es dxvk nicht mal mehr. Offenbar ist es generell nicht mehr wichtig.

Ich teste übrigens weiterhin mit Wine 9.20, um direkt vergleichen zu können, da es das normale noch nicht als 9.21 gibt.

Abgesehen davon hatte ich das dxvk aus dem Chaotic-AUR neulich schon mal installiert: Das hat nichts geändert.

AeroFly Pro Deluxe 1.9 läuft dagegen unter den selben Umständen immer flüssig. Aber wenn ich vsync deaktiviere, gibt es Unterschiede:

Direkt gebootet:

• normales Wine: ca. 700 fps
• Wine-wow64: ca. 430 fps

In der VM:

• normales Wine: ca. 500 fps
• Wine-wow64: ca. 350 fps

Also zumindest 32-bit-3D-Anwendungen sind durch wow64 ca. 1/3 langsamer. - 64-bit-3D-Anwendungen habe ich nicht.

Das 32-bittige XMedia-Recode encodet dagegen mit wow64 gleich schnell: Bei 2,5 Min. Encodingdauer nur 1 Sek. langsamer.

---

Im Anhang noch die Debug-Meldungen. (Wine ist so ein Messie…) Da tut sich zwischen den Versionen nicht viel.

Ich habe schon beim laden Alt+F4 gedrückt. Dann wird PipeDream sofort beendet, wenn es fertig geladen und sich initialisiert hat und das habe ich per "time" gemessen.

 

[Spontaneous]

Du verstehst schon was DXVK bewirkt und wie man es in einer manuellen Wine Prefix installiert und aktiviert?
Ich glaube, das verstehst du wohl noch nicht ganz. Daher begib dich auf die GitHub Seite von DXVK. Ich habe es selbst durchgespielt mit meinem Laptop. Artix ist installiert und das Starten ohne DXVK verhält sich wie bei dir und mit einfach schnell.

 

[Caramon2]

Du verstehst schon was DXVK bewirkt und wie man es in einer manuellen Wine Prefix installiert und aktiviert?

Nur theoretisch, da ich es nie gebraucht habe und auch nie andere Wine Prefixes. Wie geschrieben: Alles wofür ich Wine brauchte, funktionierte schon 2019 mit Wine 0,9x auf Anhieb.

Das ist jetzt das erste Mal, das etwas nicht für mich nachvollziehbares passiert.

Ich glaube, das verstehst du wohl noch nicht ganz. Daher begib dich auf die GitHub Seite von DXVK. Ich habe es selbst durchgespielt mit meinem Laptop. Artix ist installiert und das Starten ohne DXVK verhält sich wie bei dir und mit einfach schnell.

Vielleicht später. Mit Wine habe ich erst mal genug gemacht:

64-bit-3D-Anwendungen habe ich nicht.

Der Cinebench 11.5 war der letzte, den es auch in einer 32-bit-Version gab.

Die erweiterten Tests müssen aktiviert sein:

Zuerst habe ich jeweils den Multicore-Bench 2x laufen lassen und dann den OpenGL auch 2x (FullHD, 75 Hz):

Wine:
32-bit: 32,24 fps + 6,61
64-bit: 38,64 fps + 6,82

Wine-wow64:
32-bit: 17,93 fps + 6,60
64-bit: 39,53 fps + 6,83

Da ist der 32-bit-wow64-Nachteil noch gravierender, aber auf 64-bit wirkt es sich dafür leicht positiv aus.

Wine-wow64 hatte ich einfach drüber gebügelt und mich anschließend kurz abgemeldet, aber nichts von den 32-bit-Sachen entfernt:

Paket (2)   Alte Version  Neue Version  Netto-Veränderung

wine        9.20-1                            -554,04 MiB
wine-wow64                9.20-1               581,12 MiB

Gesamtgröße der installierten Pakete:  581,12 MiB
Größendifferenz der Aktualisierung:     27,08 MiB

Danach hatte ich dxvk und vkd3d (32- und 64-bit-Version) installiert (und dann wieder kurz abgemeldet), aber das hatte keinen relevanten Effekt darauf und auch PipeDream blieb so lahm.

 

[Uridium]

Schau mal in 'winecfg', ob die Bibliotheken (ich glaube es sind drei oder vier an der Zahl) als 'native' auch wirklich eingebunden sind. Im Prinzip machen die DXVK Installer nichts anderes als automatisiert die Dateien abzulegen und dort einzubinden. Das kann man auch selbst machen. Neustarten oder erneut einloggen braucht man dafür nicht.

Starte Pipe Dreams via Shell. Dort sollte sich DXVK deutlich erkennbar zeigen, wenn es korrekt eingebunden ist.

 

[Pummeluff]

@aries2747
Heut hat's mich dann doch mal gepackt. Hab mal ein Update installiert:

app-emulation/wine-vanilla -abi_x86_32 wow64

Allerdings scheint das irgendwie nicht ganz zu funktionieren. Wenn ich testweise mal Spider Solitär starte:

wine spider.exe
wine: '/home/user/Programme/Spider_win32' is a 32-bit installation, it cannot support 64-bit applications.

Also irgendwas scheint da noch nicht ganz rund zu laufen. Das passiert bei jedem Programm, was ich als 32-Bit-Installation mal installiert hatte. U.a. auch bei Tax.

Muss ich da noch was Bestimmtes setzen, also WINARCH="wow64" z.B.?

 

[aries2747]

Also ich musste nicht explizit etwas setzen, es funktioniert bei mir mit Siedler 2 TNG und Simcity 3000 Unlimited ohne das ich irgendwelche speziellen optionen setzen muss.

 

[Pummeluff]

Bin einen Schritt weiter.

Scheint so, als ob sich Wine am existierenden PREFIX stören würde. Ruf ich eine die Exe (Beispiel Spider Solitär) ohne Angabe von WINEPREFIX auf, dann klappt's problemlos.

Das ist natürlich etwas Mist, da ich jedes installierte Wine-Programm noch mal neu installieren muss. Grob überschlagen. Sind 8 Stück.

Update:
Ich geh wieder zurück auf Multilib. Grund ist nicht Wine sondern der Steam-Launcher. Der zieht den ganzen 32-bit-Rattenschwanz hinter sich her. Im Grunde genommen hab ich dann mit ein paar behebbaren Problemen Wine von 32bit befreit, muss aber trotzdem alles wegen Steam doppelt installieren.

 

[Caramon2]

Schau mal in 'winecfg', ob die Bibliotheken (ich glaube es sind drei oder vier an der Zahl) als 'native' auch wirklich eingebunden sind.

Ich hatte zuerst nur dxvk und vkd3d installiert und sonst gar nichts gemacht. Da der OpenGL-Cinebench trotzdem etwas schneller lief, bin ich davon ausgegangen, dass Wine es automatisch einbindet.

Später habe ich die EndeEnteGeh bemüht, fand das bei git absurd umständlich erklärt und mich dann nach dem englischen Arch-Wiki gerichtet: https://wiki.archlinux.org/title/Wine#VKD3D-Proton

Mit dem Erfolg, dass der OpenGL-Cinebench noch ein Tucken schneller lief, PipeDream dafür gar nicht mehr mit Wine-wow64. - erst nachdem ich in winecfg die dx9-DLL auf "Buildin" gesetzt habe, startete es, aber eben wieder so elend lahm.

Offenbar noch eine Macke vom wow64. - dxvk passt sowieso nicht gut dazu, weil es 32-bit-Abhängigkeiten hat. Und gerade die will man damit ja los werden.

Neustarten oder erneut einloggen braucht man dafür nicht.

Neulich hatte das be ersten Mal einen Unterschied gemacht, weshalb ich dabei geblieben bin. Heute konnte ich das aber nicht mehr reproduzieren. War neulich wohl was anderes.

Starte Pipe Dreams via Shell. Dort sollte sich DXVK deutlich erkennbar zeigen, wenn es korrekt eingebunden ist.

Dazu muss ich erst wieder deaktiviert, dass ich die Debugmeldungen deaktiviert habe: Die müllen mir das Terminal viel zu sehr zu, wie ich neulich als zip angehängt hatte.

Ich bin erst mal wieder zurück zum nornalen Wine, jetzt aber mit dxvk und vkd3d, da beides ja nicht groß ist und selbst bei OpenGL-Anwendungen leichte Vorteile bringt.

Neue Wine-wow64-Versionen werden ich im Auge behalten. Die sind ja schnell installiert und getestet.

Selbst nach der ganzen Entwicklungszeit (Sven hat hier schon zu Wine 7 darüber berichtet), ist das bzgl. 32-bit offenbar immer noch sehr "experimentell".

 

[Caramon2]

PipeDream dafür gar nicht mehr mit Wine-wow64. - erst nachdem ich in winecfg die dx9-DLL auf "Buildin" gesetzt habe, startete es, aber eben wieder so elend lahm.

Ich hab's!

dxvk hat einen Bug bzgl. wine-wow64 (zumindest die Versionen aus dem Chaotic-AUR - andere habe ich nicht getestet):

Wenn ich wine-wow64 installiert und eingerichtet habe und dann dxvk installiere, kopiert es die DLLs doppelt in "system32" (also wo die 64-bit-DLLs sind):

$ setup_dxvk install --symlink
'/home/ich/.wine/dosdevices/c:/windows/system32/dxgi.dll' -> '/home/ich/.wine/dosdevices/c:/windows/system32/dxgi.dll.old' umbenannt
'/home/ich/.wine/dosdevices/c:/windows/system32/dxgi.dll' -> '/usr/share/dxvk/x64/dxgi.dll'
'/home/ich/.wine/dosdevices/c:/windows/system32/dxgi.dll' wurde entfernt
'/home/ich/.wine/dosdevices/c:/windows/system32/dxgi.dll' -> '/usr/share/dxvk/x32/dxgi.dll'
'/home/ich/.wine/dosdevices/c:/windows/system32/d3d8.dll' -> '/home/ich/.wine/dosdevices/c:/windows/system32/d3d8.dll.old' umbenannt
'/home/ich/.wine/dosdevices/c:/windows/system32/d3d8.dll' -> '/usr/share/dxvk/x64/d3d8.dll'
'/home/ich/.wine/dosdevices/c:/windows/system32/d3d8.dll' wurde entfernt
'/home/ich/.wine/dosdevices/c:/windows/system32/d3d8.dll' -> '/usr/share/dxvk/x32/d3d8.dll'
'/home/ich/.wine/dosdevices/c:/windows/system32/d3d9.dll' -> '/home/ich/.wine/dosdevices/c:/windows/system32/d3d9.dll.old' umbenannt
'/home/ich/.wine/dosdevices/c:/windows/system32/d3d9.dll' -> '/usr/share/dxvk/x64/d3d9.dll'
'/home/ich/.wine/dosdevices/c:/windows/system32/d3d9.dll' wurde entfernt
'/home/ich/.wine/dosdevices/c:/windows/system32/d3d9.dll' -> '/usr/share/dxvk/x32/d3d9.dll'
'/home/ich/.wine/dosdevices/c:/windows/system32/d3d10core.dll' -> '/home/ich/.wine/dosdevices/c:/windows/system32/d3d10core.dll.old' umbenannt
'/home/ich/.wine/dosdevices/c:/windows/system32/d3d10core.dll' -> '/usr/share/dxvk/x64/d3d10core.dll'
'/home/ich/.wine/dosdevices/c:/windows/system32/d3d10core.dll' wurde entfernt
'/home/ich/.wine/dosdevices/c:/windows/system32/d3d10core.dll' -> '/usr/share/dxvk/x32/d3d10core.dll'
'/home/ich/.wine/dosdevices/c:/windows/system32/d3d11.dll' -> '/home/ich/.wine/dosdevices/c:/windows/system32/d3d11.dll.old' umbenannt
'/home/ich/.wine/dosdevices/c:/windows/system32/d3d11.dll' -> '/usr/share/dxvk/x64/d3d11.dll'
'/home/ich/.wine/dosdevices/c:/windows/system32/d3d11.dll' wurde entfernt
'/home/ich/.wine/dosdevices/c:/windows/system32/d3d11.dll' -> '/usr/share/dxvk/x32/d3d11.dll'

Ist dagegen das normale Wine installiert und eingerichtet, werden sie richtig in "system32" und "syswow64" kopiert:

$ setup_dxvk install --symlink
'/home/ich/.wine/dosdevices/c:/windows/system32/dxgi.dll' -> '/home/ich/.wine/dosdevices/c:/windows/system32/dxgi.dll.old' umbenannt
'/home/ich/.wine/dosdevices/c:/windows/system32/dxgi.dll' -> '/usr/share/dxvk/x64/dxgi.dll'
'/home/ich/.wine/dosdevices/c:/windows/syswow64/dxgi.dll' -> '/home/ich/.wine/dosdevices/c:/windows/syswow64/dxgi.dll.old' umbenannt
'/home/ich/.wine/dosdevices/c:/windows/syswow64/dxgi.dll' -> '/usr/share/dxvk/x32/dxgi.dll'
'/home/ich/.wine/dosdevices/c:/windows/system32/d3d8.dll' -> '/home/ich/.wine/dosdevices/c:/windows/system32/d3d8.dll.old' umbenannt
'/home/ich/.wine/dosdevices/c:/windows/system32/d3d8.dll' -> '/usr/share/dxvk/x64/d3d8.dll'
'/home/ich/.wine/dosdevices/c:/windows/syswow64/d3d8.dll' -> '/home/ich/.wine/dosdevices/c:/windows/syswow64/d3d8.dll.old' umbenannt
'/home/ich/.wine/dosdevices/c:/windows/syswow64/d3d8.dll' -> '/usr/share/dxvk/x32/d3d8.dll'
'/home/ich/.wine/dosdevices/c:/windows/system32/d3d9.dll' -> '/home/ich/.wine/dosdevices/c:/windows/system32/d3d9.dll.old' umbenannt
'/home/ich/.wine/dosdevices/c:/windows/system32/d3d9.dll' -> '/usr/share/dxvk/x64/d3d9.dll'
'/home/ich/.wine/dosdevices/c:/windows/syswow64/d3d9.dll' -> '/home/ich/.wine/dosdevices/c:/windows/syswow64/d3d9.dll.old' umbenannt
'/home/ich/.wine/dosdevices/c:/windows/syswow64/d3d9.dll' -> '/usr/share/dxvk/x32/d3d9.dll'
'/home/ich/.wine/dosdevices/c:/windows/system32/d3d10core.dll' -> '/home/ich/.wine/dosdevices/c:/windows/system32/d3d10core.dll.old' umbenannt
'/home/ich/.wine/dosdevices/c:/windows/system32/d3d10core.dll' -> '/usr/share/dxvk/x64/d3d10core.dll'
'/home/ich/.wine/dosdevices/c:/windows/syswow64/d3d10core.dll' -> '/home/ich/.wine/dosdevices/c:/windows/syswow64/d3d10core.dll.old' umbenannt
'/home/ich/.wine/dosdevices/c:/windows/syswow64/d3d10core.dll' -> '/usr/share/dxvk/x32/d3d10core.dll'
'/home/ich/.wine/dosdevices/c:/windows/system32/d3d11.dll' -> '/home/ich/.wine/dosdevices/c:/windows/system32/d3d11.dll.old' umbenannt
'/home/ich/.wine/dosdevices/c:/windows/system32/d3d11.dll' -> '/usr/share/dxvk/x64/d3d11.dll'
'/home/ich/.wine/dosdevices/c:/windows/syswow64/d3d11.dll' -> '/home/ich/.wine/dosdevices/c:/windows/syswow64/d3d11.dll.old' umbenannt
'/home/ich/.wine/dosdevices/c:/windows/syswow64/d3d11.dll' -> '/usr/share/dxvk/x32/d3d11.dll'

Ersetze ich dann erst wine durch wine-wow64, startet PipeDream und das in normaler Geschwindigkeit.

Daran, dass alle 32-bit-3D-Anwendungen sehr viel langsamer als beim normalen Wine sind, ändert das aber nicht:

Mit dxvk ist der Unterschied (ohne vsync) noch gravierender:

• AeroFly Pro Deluxe mit normalen Wine: ca. 1000 fps
• AeroFly Pro Deluxe mit Wine-wow64: ca. 470 fps an der gleichen Stelle

Oder der OpenGL-Test von Cinebench 11.5 (64-bit / 32-bit):

• normales Wine: 40,68 fps / 37,23 fps
• Wine-wow64: 40,41 fps / 18,18 fps

Das betrifft offenbar nur 3D, da encoding eines 720p Musikvideos mit XMediaRecode (32-bit) immer 1:40 Min. gebraucht hat: egal ob Wine oder Wine-wow64 und auch ob dxvk und/oder vkd3d installiert sind oder nicht, hat darauf keinen Effekt.

 

[Caramon2]

dxvk hat einen Bug bzgl. wine-wow64 (zumindest die Versionen aus dem Chaotic-AUR - andere habe ich nicht getestet):

Das ist offenbar bekannt:

The setup_vxdk script plays poorly with wow64 wine. It copies x64 dlls to C:\windows\system32 then overwrite those with x32 dlls.

…

They are correct that the old upstream script doesn't work if wine has been built using the new wow64 wine mode.

https://aur.archlinux.org/packages/dxvk-bin

Auch andere dxvk's, die ich getestet habe, verhielten sich so. vkd3d hat das Problem dagegen nicht.

 

[Caramon2]

Nach der Installation 1.5GB weniger Speicherplatzbedarf. Erstaunlich, dass das neue Wine so klein ist (1.4GB vs. 580MB).

Paket (2)               Alte Version  Neue Version  Netto-Veränderung  Größe des Downloads

wine                    9.20-1                           -1389,41 MiB                   
chaotic-aur/wine-wow64                9.20-1               581,12 MiB            93,01 MiB

Gesamtgröße des Downloads:               93,01 MiB
Gesamtgröße der installierten Pakete:   581,12 MiB
Größendifferenz der Aktualisierung:    -808,29 MiB

Ups! Mir war gar nicht aufgefallen, dass du alleine das Wine-Paket meintest.

Bei Artix ist das normale Wine sogar etwas kleiner als das wow64:

Paket (2)   Alte Version  Neue Version  Netto-Veränderung

wine        9.20-1                            -554,04 MiB
wine-wow64                9.20-1               581,12 MiB

Gesamtgröße der installierten Pakete:  581,12 MiB
Größendifferenz der Aktualisierung:     27,08 MiB

Auch im Download:

Repositorium             : lib32
Name                     : wine
Version                  : 9.20-1
Beschreibung             : A compatibility layer for running Windows programs
Architektur              : x86_64
[…]
Größe des Downloads      : 61,19 MiB
Installationsgröße       : 554,04 MiB
Erstellt am              : So 20 Okt 2024 03:22:58 CEST

vs.

Repositorium             : chaotic-aur
Name                     : wine-wow64
Version                  : 9.20-1
Beschreibung             : A compatibility layer for running Windows programs
Architektur              : x86_64
[…]
Größe des Downloads      : 93,01 MiB
Installationsgröße       : 581,12 MiB
Erstellt am              : Sa 17 Okt 2024 07:02:37 CET

Tipp: Da ich bei Artix problemlos den Arch-Kernel installieren konnte, als sich eine neue Version bei Artix immer weiter verzögerte, sollte das auch umgekehrt mit den Artix-Wine-Paketen bei Arch funktionieren, falls du mal vergleichen willst: Index of /packages/w/wine/

Meine Aussage bezog sich auf die ganzen eingesparten 32-bit-Abhängigkeiten:

Genau deshalb hatte ich die extra Installation erstellt: Nur für die paar kleinen Win-Tools, die ich ggfs. nochmal brauchen könnte, wollte ich auf dem Produktivsystem keine 1,5 GiB verbraten, da die genauso gut (teils besser) mit dem VM-WinXP funktionieren

Wobei sich das praktisch dadurch egalisiert, dass stattdessen ~/.wine/ ein Vielfaches größer ist (alles ohne Mono und Gecko - die brauche ich nicht):

• wine: ca. 90 MB
• wow64: ca. 470 MB

(mit "MB" meine ich MB, nicht MiB)

Im Gegensatz zum normalen Wine, bei dem sich die 32-bit-Abhängigkeiten einmalig auf der Systempartition befinden, betrifft das bei wow64 jedes genutzte Prefix, jedes Benutzers (bei einem Mehrbenutzersystem) der Wine nutzt: Da kann schnell einiges zusammenkommen.

Da wow64 außerdem bei 32-bit-3D-Anwendungen gegenüber dem normalen Wine kaum halb so schnell ist und auch keine reine 32-bit-Konfiguration zulässt (s. u.), heißt das für mich:

Ich habe wieder das normale Wine installiert und auch dxvk und vkd3d wieder runtergeschmissen, da ich das nicht brauche und es mir zu häufig aktualisiert wird = unnütze Platz- und Zeitverschwendung: Im System und auch bei den Sicherungen.

Außerdem habe ich es wieder mit "WINEARCH=win32 winecfg" initialisiert, da ich keine win64-Anwendungen nutze. - ~/.wine/ ist dann nur ca. 50 MB groß.

Ich bevorzuge ein möglichst schlankes und effizientes System und verwende viel Zeit darauf es zu optimieren. - Das geht schon etwas in Richtung Zwangsstörung…

Ergänzung (21. November 2024)

Ich habe im ersten Beitrag hinzugefügt, wie man den dxvk-wine-wow64-Bug korrigieren kann:

Da dxvk bei der Installation bei wine-wow64 einen Bug hat (s. hier), habe ich ausprobiert, wie man das korrigieren kann:

Nachdem man es installiert hat (unabhängig vkd3d), bei einem Arch-Derivat mit Chaotic-AUR z. B. so:

sudo pacman -Sy dxvk-mingw-git vkd3d-proton-mingw-git setup_dxvk install --symlink setup_vkd3d_proton install --symlink

reicht eine Schleife, um die falsch erstellten Symlinks zu löschen, die fehlenden ".old" anzulegen und die richtigen Symlinks zu erstellen:

for dx in dxgi.dll d3d8.dll d3d9.dll d3d10core.dll d3d11.dll;do rm -v ~/.wine/dosdevices/c:/windows/system32/$dx;ln -vs /usr/share/dxvk/x64/$dx ~/.wine/dosdevices/c:/windows/system32/;mv -v ~/.wine/dosdevices/c:/windows/syswow64/$dx ~/.wine/dosdevices/c:/windows/syswow64/$dx.old;ln -vs /usr/share/dxvk/x32/$dx ~/.wine/dosdevices/c:/windows/syswow64/;done

(das sollte bei jeder Distribution funktionieren, bei der der beschriebene Bug auftritt, solange nur das Standard-Prefix genutzt wird)

 

[Uridium]

falls du mal vergleichen willst: Index of /packages/w/wine/

Wine wird unter Arch zusätzlich mit 'mingw-w64-gcc' kompiliert (Cross-Compiler für Windows PE Binaries). Dadurch sind die 'wine builtin dlls' unter Arch echte Windows PE dlls im 'x86_64-windows' Ordner, während Artix die dlls als *.so Dateien im 'x86_64-unix' Ordner hat. Die sind deutlich kleiner. Welche Vor- und Nachteile das hat, weiß ich nicht.

Arch:

$ du -h usr/lib/wine
39M usr/lib/wine/x86_64-unix
675M usr/lib/wine/x86_64-windows
713M usr/lib/wine

Artix:

$ du -h usr/lib/wine
211M usr/lib/wine/x86_64-unix
37M usr/lib/wine/x86_64-windows
248M usr/lib/wine

 

[Caramon2]

Wine wird unter Arch zusätzlich mit 'mingw-w64-gcc' kompiliert (Cross-Compiler für Windows PE Binaries).

Was ist eigentlich dieses "mingw"?

Seit dem ich mich mit dem Chaotic-AUR beschäftige, ist mir das schon häufiger aufgefallen, konnte aber nichts konkretes dazu finden. (hatte aber auch nicht lange gesucht)

Dadurch sind die 'wine builtin dlls' unter Arch echte Windows PE dlls im 'x86_64-windows' Ordner, während Artix die dlls als *.so Dateien im 'x86_64-unix' Ordner hat.

Dann macht das größere ja wenigstens Sinn.

Ich hatte angenommen, das wäre mit irgendwelchem Debug-Kram, oder anderem für den reinen Anwender nutzlosen zugemüllt, das bei Artix entfernt wurde. - Die Win x.x sind ja schließlich die Developer-Versionen. Nur die x.0 sind die stable.

Die sind deutlich kleiner. Welche Vor- und Nachteile das hat, weiß ich nicht.

Vielleicht gibt es Unterschiede bei der Kompatibilität, Geschwindigkeit, oder Stabilität. Vielleicht ist auch je nach Anwendung mal das eine oder andere besser.

Ich habe mir die Arch-Version geladen (zum Glück auch noch die 9.20) und werde das mit Cinebench, XMedia-Recode und AeroFly Pro Deluxe vergleichen.

 

[ufopizza]

Im Gegensatz zum normalen Wine, bei dem sich die 32-bit-Abhängigkeiten einmalig auf der Systempartition befinden, betrifft das bei wow64 jedes genutzte Prefix, jedes Benutzers (bei einem Mehrbenutzersystem) der Wine nutzt: Da kann schnell einiges zusammenkommen.

Mit Btrfs sollte dies eigentlich nicht der Fall sein 😁

 

[Caramon2]

Ich habe mal die "Browser-KI" vom Android-Opera gefragt:

Die Verwendung von mingw-w64-gcc zur Kompilierung von Wine unter Arch Linux hat sowohl Vor- als auch Nachteile im Vergleich zu Artix, wo die DLLs als .so Dateien im x86_64-unix Ordner gespeichert werden. Hier sind einige Überlegungen:

Vorteile der Verwendung von mingw-w64-gcc unter Arch:

1. Echte Windows PE DLLs:

Die DLLs sind echte Windows PE (Portable Executable) Dateien, was die Kompatibilität mit Windows-Anwendungen erhöhen kann.


2. Bessere Unterstützung für Windows-Programme:

Programme, die auf spezifische Windows-APIs angewiesen sind, könnten unter Arch besser funktionieren, da die DLLs die Windows-Umgebung genauer nachahmen.

3. Cross-Compilation:

Die Möglichkeit, Windows-Anwendungen direkt unter Linux zu kompilieren, kann die Entwicklung und das Testen von Software erleichtern.

Nachteile:

1. Komplexität:

Die Verwendung eines Cross-Compilers kann die Entwicklungsumgebung komplizierter machen, insbesondere wenn es um Abhängigkeiten und Bibliotheken geht.

2. Fehlende Integration:

Die Integration in die Linux-Umgebung könnte schwieriger sein, da die Windows DLLs nicht nativ in das Linux-System integriert sind.

3. Potenzielle Inkompatibilitäten:

Einige Anwendungen könnten Probleme mit den Windows PE DLLs haben, insbesondere wenn sie auf spezifische Unix-ähnliche Funktionen angewiesen sind.

Fazit:

Die Entscheidung, ob man Wine unter Arch mit mingw-w64-gcc oder unter Artix mit .so Dateien verwendet, hängt stark von den spezifischen Anforderungen der Anwendungen ab, die man ausführen möchte. Wenn die Kompatibilität mit Windows-Programmen im Vordergrund steht, könnte die Arch-Variante vorteilhafter sein. Wenn jedoch eine nahtlose Integration in die Linux-Umgebung gewünscht ist, könnte Artix die bessere Wahl sein.

Die Quellenangabe:

• https://forum.winehq.org/viewtopic.php?t=6041
• https://www.reddit.com/r/programmin...ling_issues_with_mingww64_libraries_on/?tl=de
• https://www.reddit.com/r/raylib/comments/tqhcjx/compiling_to_windows_on_linux/?tl=de
• https://www.pcwelt.de/article/1156410/wine-so-nutzen-sie-wine-als-windows-ersatz.html

Ergänzung (25. November 2024)

Mit Btrfs sollte dies eigentlich nicht der Fall sein 😁

Wieso das?

Es wird doch für jeden Nutzer/Prefix neu generiert, also nix copy on write.

 

[Uridium]

Was ist eigentlich dieses "mingw"?

Wine führt Windowscode aus. MinGW-w64 kann ihn erstellen. Ursprünglich war es andersrum (mingw - Minimalist GNU for Windows). Eine Laufzeitumgebung für Windows, um Linuxcode zu erstellen. Aus Sicht des Benutzers stellt es den Compiler (GCC) bereit.

 

[Caramon2]

Wine führt Windowscode aus. MinGW-w64 kann ihn erstellen.

Ich hatte gedacht, mingw wäre eine Person, wie z. B. linux-ck: Contains patches by Con Kolivas…

Bzgl. der Wine 9.20 Varianten:

Der Wine-Ordner wird bei der Arch-Version 15x größer als bei der Artix-Version:
(jeweils vorher gelöscht, neu erstellen lassen und identisch konfiguriert)

Das ist das reine Wine: Kein Mono, Gecko, dxvk, oder vkd3d war installiert.

Die Geschwindigkeitsunterschiede liegen im Rahmen der Messtoleranz:
(natürlich bis auf wow64 vs. 32-bit-3D)

            32-bit    64-bit
wine-arch:
OpenGL:        37,75    40,57
Rendern:        6,60    6,80

wine-artix:
OpenGL:        37,77    40,14
Rendern:        6,61    6,82

wine-wow64:
OpenGL:        18,18    40,54
Rendern:        6,59    6,81

XMR und AFPD habe ich mir gespart. Da wäre es nicht sonderlich anders gewesen.

 

[Caramon2]

Wine führt Windowscode aus. MinGW-w64 kann ihn erstellen. Ursprünglich war es andersrum (mingw - Minimalist GNU for Windows).

Kaum macht man es richtig, schon funktioniert's.

Soll heißen, plötzlich finde ich es. Es gibt sogar Seiten im deutschen Wikipedia:

MinGW

MinGW oder Mingw32 (Minimalist GNU for Windows) ist eine Portierung der Entwicklerwerkzeuge GNU Compiler Collection (GCC) und GNU Debugger (GDB) für Windows. Es ist unabhängig von dem konkurrierenden Projekt Mingw-w64.

Mingw-w64

Mingw-w64 (oder Mingw64) ist eine Portierung der Entwicklerwerkzeuge GNU Compiler Collection (GCC) und GNU Debugger (GDB) um Windows PE-Anwendungen erstellen zu können. Es ist zu unterscheiden von dem konkurrierenden Projekt MinGW.

Interessante Abfallprodukt meiner Suche:

Die Entstehungsgeschichte von DirectX
(hat schon was nostalgisches )

 

[Caramon2]

Ich hatte bei meiner Windows 11 Testinstallation den proprietären GraKa-Treiber installiert (Radeon RX 560D), um auch dort den OpenGL-Bench von Cinebench 11.5 laufen lassen zu können (statt Slideshow), aber der stürzt dort ab: Egal ob Cinebench 32- oder 64-bit.

Cinebench 15 (nur 64-bit und die letzte Version mit dem OpenGL-Bench) funktionierte dagegen auch mit Windows:

Ich habe Wine-Artix genutzt (wine-arch und wine-wow64 habe ich mir gespart, da beim 11.5 gleich schnell), es auf Windows 11 konfiguriert und damit es auch die bestmöglichen Voraussetzungen hat, dxvk und vkd3d installiert und eingerichtet. Ansonsten war alles auf Standard (neues Prefix).

Monitoreinstellung bei beiden: FullHD @ 75 Hz

        OpenGL Qualität Multi Single Speedup
Win11 80,27 fps  98,0%    634    94    6,74x
Wine  79,59 fps  97,9%    620    93    6,68x

Also bis auf die Probleme bei CB 11.5 und dass ich zuerst den proprietären Treiber installieren musste (obwohl es ein reines AMD-System ist), tun sich beide OS nichts und auch bei AFPD knackten beide ohne vsync knapp die 1000 fps.

---

Downloads aller Cinebenches, die ich gefunden habe:

https://www.guru3d.com/download/cinebench-2003/

https://cinebench.mrdownload.com/en/for-windows/app/download/

https://www.guru3d.com/download/cinebench-10/

https://www.guru3d.com/download/cinebench-11-5/

https://www.guru3d.com/download/cinebench-15-download/

https://www.guru3d.com/download/download-maxon-cinebench-r20/

https://www.guru3d.com/download/download-maxon-cinebench-r23/

 

[Caramon2]

Der Vollständigkeit halber habe ich auch noch meine LMDE-Testinstallation gebencht.

Den Kernel hatte ich schon im Februar per Synaptic/Paket/"Version erzwingen" auf "stable-backport" umgestellt:

Damals war das der 6.6 und seit dem kommt meistens einmal im Monat eine neue Version als normales Update über die Aktualisierungsverwaltung: Man muss sich um nichts weiter kümmern.

Ich habe den "wine-installer" mit der grafischen Anwendungsverwaltung installiert:

Die Version 5 betrifft nur das Pakte: Wine wurde mit der Version 8.0 aus den reguläten Debian-Quellen installiert.

Für neuere Versionen braucht man zusätzliche Paketquellen *), wie auch für dxvk und vkd3d, die ich deshalb nicht installiert hatte.

*) damit beschäftige ich mich nicht - Das kann jemand anderes erklären: Dazu ist dieser Thread ja da.

Das LMDE-Wine braucht sich vor den neueren Wine-Versionen jedenfalls nicht zu verstecken:

Cinebench 11.5:
              32-bit   64-bit
wine-LMDE:
OpenGL:        38,87    42,14
Rendern:        6,59     6,83

Cinebench 15:
OpenGL:            71,22
Multi:               642
Sinlge:               95
Speedup:           6,80x

Wichtig:
Die OpenGL-Benches wurden zwar durchgeführt und die Ergebissen erscheinen plausibel, sie wurde aber bei keinem der drei Benchmarks angezeigt! - Keine Ahnung was dort fehlt: Für zweckdienliche Hinweise wäre ich dankbar.

AeroFly Pro Deluxe (OpenGL) und Pipe-Dream (DirectX 9) liefen dagegen normal: AFPD schaffte es sogar ohne dxvk die 1000 fps Marke knapp zu knacken!

Nachtrag: ~/.wine/ (wieder ohne Mono und Gecko) ist wie bei wine-arch 1,2 GiB große.