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

[Caramon2]

Ich habe wine-wow64 erst letztens entdeckte und da ich dazu nichts im Forum finden konnte, beschreibe ich es hier, damit andere, die sich mehr mit Wine beschäftigen, sich darüber austauschen können: Z. B. wie man wine-wow64 bei anderen Distributionen installiert, oder ggfs. Probleme löst (es gilt noch als experimentell).

Für mich funktionierte es auf Anhieb mit einem alten "AeroFly Pro Deluxe", dem alten AMD-Pipe-Dream-Demo und ein paar kleineren Tools. Nur fürs alte "XMedia-Recode 3.4.3.6" musste ich in "winecfg"/Bibliotheken "opencl" auf "Native dann Builtin" setzen.

Für mehr brauche ich Wine nicht und alles davon hat schon 2015 mit Wine 0.9x auf Anhieb funktioniert. Mit Winetricks und anderen kenne ich mich nicht aus, da ich mich nie damit beschäftigen musste.

Btw: Da alles was mit Windows zu tun hat für mich alt ist, hatte ich kurz überlegt, ob ich das in der Retro-Ecke veröffentliche.

---

Wichtig: Meine Befehlszeilen bitte nicht hirnlos übernehmen, da "-Rscn" gründlich ist und u. U. das System zerschießen kann, wenn man nicht aufpasst:

Falls ungewolltest entfernt werden soll, abbrechen und es mit "-Rcn" versuchen oder als letzte Möglichkeit nur "-Rn".

Nachtrag von 21.11.2024: 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)

---

So habe ich mein Artix-Runit (ein Arch-Derivat ohne systemd) auf ein reines 64-bit-System umgestellt:

Zuerst das alte Wine entfernen:

sudo pacman -Rscn wine

Dann sämtliche nicht mehr benötigten Abhängigkeiten:

pacman -Qdtq | sudo pacman -Rscn -

Das so oft wiederholen bis "Fehler: Argument »-« mit leerer Standardeingabe angegeben" ausgegeben wird.

Die restlichen evtl. noch verbliebenen 32-bit-Pakete:

pacman -Qsq lib32 | sudo pacman -Rcn -

Und zuletzt noch das 32-bit-Repository in der Konfigurationsdatei auskommentiert:

sudo nano /etc/pacman.conf

(mit Strg+O + Enter wird gespeichert und mit Strg-X nano beendet)

Das Chaotic-AUR wird so eingebunden (darüber beziehe ich "wine-wow64"):

sudo pacman-key --recv-key 3056513887B78AEB --keyserver keyserver.ubuntu.com && sudo pacman-key --lsign-key 3056513887B78AEB && sudo pacman -U 'https://cdn-mirror.chaotic.cx/chaotic-aur/chaotic-keyring.pkg.tar.zst' 'https://cdn-mirror.chaotic.cx/chaotic-aur/chaotic-mirrorlist.pkg.tar.zst'

Und in die Konfigurationsdatei (sudo mousepad /etc/pacman.conf) hinzugefügt:

[chaotic-aur]
Include = /etc/pacman.d/chaotic-mirrorlist

Anschließend habe ich wine-wow64 inkl. der optionalen Abhängigkeiten installiert:

sudo pacman -Syu wine-wow64 && sudo pacman -S --asdeps --needed $(expac %o wine-wow64)

Jetzt kann man mit "winecfg" die Konfiguration starten.

Das ist optional:

Da ich weder Mono noch Gecko brauche und auch nicht möchte dass wine mir das Terminalfenster zumüllt, wenn ich ich es dort starte, erstelle ich mit "sudo nano /etc/environment" die entsprechende Konfigurationsdatei (oder sie damit erweitern, falls schon vorhaben):

WINEDLLOVERRIDES=mscoree=d;mshtml=d
WINEDEBUG=-all

Dann kurz abmelden oder rebooten, damit es übernommen wird.

Da ich auch keine automatisch erstellten Startmenü-Einträge von Wine haben möchte, entferne ich sie prophylaktisch (falls es von früher welche gibt):

rm -v ~/.local/share/applications/wine-ext* ~/.local/share/icons/hicolor/*/apps/*x-wine-ext* ~/.local/share/mime/*/x-wine-ext*

Und starte "winecfg" so, dass es keine neuen erstellt:

WINEDLLOVERRIDES="$WINEDLLOVERRIDES;winemenubuilder.exe=d" winecfg

Dort im Tab "Desktop-Integration" "kein Thema" wählen, darunter "Dateizuornungen verwalten" deaktivieren und bei allen "Shell-Ordnern" "Verknüpfen mit" deaktivieren, damit Windowsanwendungen nicht darauf zugreifen können.

Und der Rest dann je nach Bedarf.

 

[ksk23]

Klingt ja schon nicht uninteressant, kurz mal gegoogelt

as of at least Wine 8.20 Staging -- if you've enabled WoW64 support during the build [wine will be able to run 32-bit apps on a system with only 64-bit libraries]

Bin ich ja mal gespannt ob und wann das Einzug in wine-stable und proton/lutris/whatnot erhalten wird.

 

[Caramon2]

Aktuell ist die 9.20 und so sieht die weitere Planung aus:

https://www.phoronix.com/news/Wine-10.0-Release-Plans

 

[Uridium]

Ich probier's mal aus. Ich brauche eigentlich nur lib32-glibc für einen alten Druckertreiber.

Nebenbei: pacman -Rn entfernt nicht die Konfigurationsdateien in ~/.config, sondern ignoriert lediglich die Erstellung der .pacsave Dateien. Das ist in den Docs sehr verwirrend formuliert.
https://bbs.archlinux.org/viewtopic.php?pid=516741#p516741

Edit:
Nach der Installation 1.5GB weniger Speicherplatzbedarf. Erstaunlich, dass das neue Wine so klein ist (1.4GB vs. 580MB). Ich gehe mal davon aus, dass das nicht die gleichen "Symptome" nach sich zieht wie bei Windows, wo der syswow64 Ordner gerne mal mehrere GB annehmen konnte. Ansonsten, funktioniert soweit. Super Sache!

$ yay -S wine-wow64
Sync Explicit (1): wine-wow64-9.20-1
Abhängigkeiten werden aufgelöst …
Nach in Konflikt stehenden Paketen wird gesucht …
:: wine-wow64-9.20-1 and wine-9.20-1 are in conflict. Remove wine? [j/N] j

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

$ pacman -Qsq lib32 | sudo pacman -Rusc -
Gesamtgröße der entfernten Pakete:  719,55 MiB

 

[aries2747]

Vorab ich benutze Gentoo.
Ich nutze auch seit einiger Zeit Wine mit der wow64 Use-Flag das schöne dabei ist das die abhängigkeiten nicht mehr zusatzlich in 32Bit kompiliert werden müssen. Bislang habe ich nur SimCitiy 3000 Unlimited damit ausprobiert und was soll ich sagen es läuft einwandfrei.

Probleme habe ich bisher keine.

 

[Caramon2]

Ich probier's mal aus. Ich brauche eigentlich nur lib32-glibc für einen alten Druckertreiber.

Dto.: Brother HL-2030 aus dem AUR.

Für Wine habe ich eine extra abgespeckte Installation, wo ich den nicht brauche.

Nebenbei: pacman -Rn entfernt nicht die Konfigurationsdateien in ~/.config, sondern ignoriert lediglich die Erstellung der .pacsave Dateien. Das ist in den Docs sehr verwirrend formuliert.
https://bbs.archlinux.org/viewtopic.php?pid=516741#p516741

Danke. Sehe ich mir an.

Die Benutzerdaten will ich damit aber nicht löschen, sondern nur alles von der Systempartition: Ich hatte "-Rn" als Äquivalent von "apt purge …" (statt "apt remove …") angesehen.

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

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 genausogut (teils besser) mit dem VM-WinXP funktionieren, das ich für ntfs-chkdsk sowieso brauche und dessen HD-Image gerade mal 303 MiB (zStd komprimiert) groß ist.

Ich gehe mal davon aus, dass das nicht die gleichen "Symptome" nach sich zieht wie bei Windows, wo der syswow64 Ordner gerne mal mehrere GB annehmen konnte. Ansonsten, funktioniert soweit. Super Sache!

Irritierend ist, dass "syswow64" die 32-bit-Komponenten enthält und "system32" die 64-bit-Komponenten.

Vorab ich benutze Gentoo.
Ich nutze auch seit einiger Zeit Wine mit der wow64 Use-Flag das schöne dabei ist das die abhängigkeiten nicht mehr zusatzlich in 32Bit kompiliert werden müssen.

Ja, dafür ist Gentoo ideal.

Mich schreckt aber die Kompilierungsdauer ab, da meine Kiste schon zum kompilieren von 7-zip-full aus dem AUR mindestens 3 Minuten braucht. - Um den ganzen Kernel 5.15 aus dem AUR zu kompilieren, hat es witzigerweise genau 5:15 Stunden gebraucht, da das grosenteils nur auf einem Kern läuft.

Deshalb bleibe ich bei Artix und freue mich, dass es 7-zip-full im Chaotic-AUR als Binärpaket gibt und ich es nicht mehr kompilieren brauche.

Bislang habe ich nur SimCitiy 3000 Unlimited damit ausprobiert und was soll ich sagen es läuft einwandfrei.

Was ist es eigentlich mit vkd3d, dxvk?

Bei "meinem" wine-wow64 sind die nicht mal als optionale Abhängigkeit angegeben und nach meiner obigen Bereinigung nicht mehr installiert: Es funktioniert zwar alles, aber mir ist inzwischen aufgefallen, dass das Pipe Dream Demo sehr lange (jedes Mal 43 Sek. - statt ca. 5-6 Sek.) zum laden braucht. - AFPD nutzt OpenGL und ist davon nicht betroffen.

Auch mit vkd3d lädt es so langsam (wahrscheinlich weil das für DX 12 ist, Pipe Dream aber DX 9 nutzt) und dxvk (aus dem Chaotic-AUR - In den Artix-Paketquellen gibt es das gar nicht mehr) hat 32-bit-Abhängigkeiten.

Wieder mit dem 32-bit-Repo:

lib32-vkd3d bringt keine Besserung - aber auch mit dem dxvk-async-git aus dem Chaotic-AUR lädt es immer noch so lahm.

Spiele ich die letzte Sicherung mit dem "normalen" wine zurück und bringe sie auf den gleichen Stand, startet es normal schnell - auch wenn ich beide (32 und 64 bit) vkd3d deinstalliere. dxvk war sowieso nicht installiert.

Offenbar noch ein bug der wow64.

Wer es selbst ausprobieren möchte. Ich hatte es schon 2020 in mein Google-Drive hochgeladen:  PipeDream.7z

Einfach die .exe starten. Es muss nicht installiert werden.

In der "sushi.ini" lassen sich Auflösung, Seitenverhältnis, AA, usw. konfigurieren: Das Demo ist auf 4:3 auausgelegt.

Ergänzung (3. November 2024)

Das ist merkwürdig:

Ich habe die Sicherung mit wine-wow64 wiederhergestellt und wie üblich per VM einen Funktionstest durchgeführt, aber dort startete Pipe Dream mit normaler Geschwindigkeit (gleich beim booten mit Strg+Alt+F auf Vollbild geschaltet):

qemu-system-x86_64 -nodefaults -enable-kvm -cpu host -smp cores=4 -m 4G -vga none -device virtio-vga-gl -display sdl,gl=on -audio sdl,model=hda -drive file=/dev/sdc,if=virtio,aio=io_uring,snapshot=on,format=raw

Dann habe ich es normal gebootet: Es startete wieder elend lahm.

Bei Gegentest wieder in der VM startete es wieder mit normaler Geschwindigkeit: Beides lässt sich beliebig reproduzieren.

Was ist das denn?

Ich würde ja auf ein Treiberproblem von Linux tippen, aber das aufwändigere AeroFly Pro Deluxe und alles andere läuft mit normaler Geschwindigkeit. Einzig das Pipe Dream Demo hat diese Probleme.

 

[aries2747]

Ja, dafür ist Gentoo ideal.

Mich schreckt aber die Kompilierungsdauer ab, da meine Kiste schon zum kompilieren von 7-zip-full aus dem AUR mindestens 3 Minuten braucht. - Um den ganzen Kernel 5.15 aus dem AUR zu kompilieren, hat es witzigerweise genau 5:15 Stunden gebraucht, da das grosenteils nur auf einem Kern läuft.

Deshalb bleibe ich bei Artix und freue mich, dass es 7-zip-full im Chaotic-AUR als Binärpaket gibt und ich es nicht mehr kompilieren brauche.

Wenn du den kernel manuell kompilierst mit dem entsprechenden "make -j32" (z.B. für 32 Threads) für deinen Prozessor, geht es schneller da er alle Kerne deines Prozessors benutzt also bei einem Achtkerner wäre es "make -j8" mit HT dann "make -j16"

 

[Uridium]

Dto.: Brother HL-2030 aus dem AUR.

Richtig!
Musste den bisher nur ein Mal reparieren (Mehrfachpapiereinzug).

Um den ganzen Kernel 5.15 aus dem AUR zu kompilieren, hat es witzigerweise genau 5:15 Stunden gebraucht, da das grosenteils nur auf einem Kern läuft.

Erscheint mir auch etwas viel. Unter 30 Minuten oder so, je nach kconfig.

 

[Caramon2]

Wenn du den kernel manuell kompilierst mit dem entsprechenden "make -j32" (z.B. für 32 Threads) für deinen Prozessor, geht es schneller da er alle Kerne deines Prozessors benutzt also bei einem Achtkerner wäre es "make -j8" mit HT dann "make -j16"

Beim AUR wird quasi nur ein Skript geladen, was dann alles weitere automatisch macht: Quellcodes laden, kompilieren, daraus ein pacman-Paket konstruieren und dann pacman aufrufen, damit es installiert wird: Erst dann wird für sudo das Passwort benötigt.

Es gibt zwar die Möglichkeit dieses ursprüngliche Skript zu bearbeiten, aber damit habe ich mich noch nicht beschäftigt, da ich noch viele andere "Baustellen" habe, die mich mehr interessieren.

M. E. hätte der Ersteller dieses Skripts dort also nur noch einbauen müssen, dass die Anzahl der Kerne ermittelt wird und die dann per "-j" übergeben müssen.

Für mich wäre das eine Selbstverständlichkeit gewesen, es möglichst allgemeingültig zu halten. Wie z. B. hier bei meinem "gov"-Skript (2. Hälfte des Beitrags):

https://www.computerbase.de/forum/t...ster-bei-ntfs-und-exfat.2129056/post-27854058

Bzgl. des Problems mit Pipe Dream gestern hätte ich noch dazu schreiben sollen, dass ich ein reines AMD-System habe (FX-8350+560D). Also keine proprietären Treiber.

 

[Uridium]

Beim AUR wird quasi nur ein Skript geladen, was dann alles weitere automatisch macht

Die Parallelisierung wird über die globale Konfiguration des Buildsystems gesteuert und muss explizit gesetzt werden. Am besten via drop-in file.
https://wiki.archlinux.org/title/Makepkg#Parallel_compilation

 

[Caramon2]

Danke für den Link!

Das mit "$(nproc)" meinte ich, was ich ins Skript eingebaut hätte.

 

[Spontaneous]

Servus. Ich habe Artix mal wieder nebenbei in einer VM installiert und die Sache mal durchgespielt. Fazit, guter Ansatz vom TE, aber es hängt wieder vieles an Artix, das man kein Systemd hat und das die 32 libs doch bei dem ein oder anderen Paket dann doch fehlen. Viele Aur Pakete lassen sich nicht bauen, alles über Flatpak zu beziehen, zu benutzen funktioniert leider auch nicht. Ich habe einige Games bei Steam und das mag über Flatpak überhaupt nicht unter Artix und es geht nur über die Repo Quellen mit aktivierten lib32, Steam zu installieren. Mein persönliches Gefühl bleibt bei Artix. Bleibst du nicht bei der Anleitung und bei den vorgeschrieben Wiki, dann funktioniert Artix nicht vernünftig.

 

[Caramon2]

@Spontaneous: Primär geht es hier um wine-wow64. Es ist keine Empfehlung für Artix, da das schon etwas speziell ist.

Da ich Artix (seit Anf. 2020) als Hauptsystem nutzt, habe ich es dafür beschrieben, was sich auch auf Arch und Arch-Derivate übertragen lassen sollte. - Ausgenommen vielleicht Manjaro, wegen des anderen Konzepts: Wäre schön, wenn das jemand testen würde.

Wie schon im ersten Beitrag geschrieben, habe ich den Thread dafür geöffnet, dass andere es für "ihre" Distro hinzufügen können (Ubuntu, Debian, Suse, Fedora, usw.), so dass dann jeder etwas davon hat.

 

[Pummeluff]

Vorab ich benutze Gentoo.
Ich nutze auch seit einiger Zeit Wine mit der wow64 Use-Flag das schöne dabei ist das die abhängigkeiten nicht mehr zusatzlich in 32Bit kompiliert werden müssen.

equery u wine-vanilla

- - wow64 : Enable running 32bit applications without 32bit ELF
multilib by mapping to 64bit calls (experimental, may
have worse/unusable OpenGL performance or other issues
compared to USE=abi_x86_32, also lacks 16bit support) --
still need dev-util/mingw64-toolchain with abi_x86_32
which itself does not need multilib

Ich wollte mal vor ein paar Jahren die ganzen 32-bit-Libs loswerden. Dazu hab ich dann einen Docker-Container gebastelt. Die Nvidia-Karte konnte ich durchschleusen. D.h. Grafikbeschleunigung hatte geklappt. Gescheitert bin ich damals an dbus und Pulseaudio.

Wieviele 32-bit-Libs kannst du damit entfernen? Oder bekommst du damit sogar alle weg? Bisher hab ich 85 Pakete in 32 bit installiert.

 

[aries2747]

Wieviele 32-bit-Libs kannst du damit entfernen? Oder bekommst du damit sogar alle weg? Bisher hab ich 85 Pakete in 32 bit installiert.

Er will gar keine 32Bit Libs mehr, ich musste allerdings bei vitual/wine und app-emulation/wine die Flag -abi_x86_32 setzen.

 

[Caramon2]

https://www.phoronix.com/news/Wine-9.21-Released

Wine 9.21 delivers more DirectPlay improvements, I/O completion fixes, expanded format coverage for Direct3D 9, and more.

Das könnte vielleicht bei Pipe Dream helfen.

Wine 10.0 is aiming for a mid-January release and for that to happen after the Wine 9.22 release in two weeks will then be the Wine 10.0-rc1 release in early December rather than Wine 9.23.

Die Nummerierung ist bei denen etwas merkwürdig:

Die 9.0 war der Release und mit den 9.x arbeitete man schon auf die 10.0 hin. Die .x-er sind also keine Produktpflege *), sondern eher Vorabversionen der nächsten .0-er.

*) die gibt es üblicherweise als .0.x-er, aber dieses Jahr nicht: https://www.winehq.org/news/

Letztes Jahr zweimal (8.0.1 und 8.0.2): https://www.winehq.org/news/25

 

[Pummeluff]

@aries2747 Wie hast du das mit dem Steam-Launcher geregelt?

The following USE changes are necessary to proceed:
 (see "package.use" in the portage(5) man page for more details)
# required by virtual/libudev-251-r2::gentoo
# required by sys-libs/libudev-compat-186-r1::gentoo
# required by games-util/steam-launcher-1.0.0.81::steam-overlay
# required by @selected
# required by @world (argument)
>=sys-apps/systemd-256.7 abi_x86_32
# required by virtual/opengl-7.0-r2::gentoo
# required by games-util/steam-launcher-1.0.0.81::steam-overlay
# required by @selected
# required by @world (argument)
>=media-libs/mesa-24.2.6-r1 abi_x86_32

Was auch nachvollziehbar ist:

less /var/db/repos/steam-overlay/games-util/steam-launcher/steam-launcher-1.0.0.81.ebuild

RDEPEND="
        app-arch/tar
        app-arch/xz-utils
        app-shells/bash
        media-libs/fontconfig[abi_x86_32]
        sys-libs/libudev-compat[abi_x86_32]
        sys-process/lsof
        virtual/opengl[abi_x86_32]
        virtual/ttf-fonts

Der Steam-Launcher hat zwingende 32-bit-Abhängigkeiten.

Die könnten auch nicht über die USE-Flags deaktiviert werden:

equery u steam-launcher
[ Legend : U - final flag setting for installation]
[        : I - package is installed with flag     ]
[ Colors : set, unset                             ]
 * Found these USE flags for games-util/steam-launcher-1.0.0.81:
 U I
 + + desktop-portal     : Enable desktop integration, e.g. for file pickers
 + + dialogs            : Support additional dialogs before the client starts
 + + joystick           : Add support for joysticks in all packages
 + + pulseaudio         : Add sound server support via media-libs/libpulse (may
                          be PulseAudio or PipeWire)
 + + steamruntime       : Use the official Steam runtime libraries
 - - steamvr            : Enable SteamVR virtual reality support
 - - trayicon           : Enable system tray icon
 + + udev               : Enable virtual/udev integration (device discovery,
                          power and storage device support, etc)
 - - video_cards_nvidia : VIDEO_CARDS setting to build driver for nvidia video
                          cards
 + + wayland            : Enable dev-libs/wayland backend

 

[aries2747]

Ich habe steam nicht installiert, nur app-emulation/wine-proton. Steam hatte ich mal installiert aber da unter Linux keine Trainer (Single Player) funktionieren habe ich dafür Windows 11 installiert falls ich mal was spielen möchte :-)

 

[Pummeluff]

habe ich dafür Windows 11 installiert

Das tut mir leid für Dich.

Ich bleib dann erst mal bei den 32-bit-Libs.

 

[Spontaneous]

Installiere und aktiviere DXVK in wine und dann läuft Pipe Dream auch rund.