Wine wow64 or abi_x86_32?

[e8root]

Like in the topic name: which solution it the best today?

In theory abi_x86_32 way should be more compatible, performant and stable but will spam system with dozen of abi_x86_32 dependencies. I thought it will be just few packages that Wine really needs but in practice even trying to minimize number of abi_x86_32 packages at some point their number quickly got out of hand and installing completely unrelated to wine packages I got messages during emerge I need to add abi_x86_32 USE flags to bunch of packages. Portage is designed in such a way that that to guarantee everything works exactly as configured and in that it can be quite irritating and forcing me to emerge 32-bit binaries for things Wine will most probably never need just because dependent packages for dependent packages have abi_x86_32 flag. Not only this uses disk space but most importantly causes emerge world take much longer.

Personally after reading about improvements in wow64 in wine 9 I quickly emerged newest wine-stating without abi_x86_32 with wow64 flag and I ran 3dmark2001se and got roughly similar score. Immediately after I got to purge system from abi_x86_32 packages. It required much more manual effort than it in theory should need. Probably I didn't do it correctly and I ended up backing up world file and then removing most of my system (eg. I even dropped Xorg) as I figured it might be quickest way. Not sure if it was but after I made system abi_x86_32 free I emerged everything right back up from world file and it works fine.

The only abi_x86_32 packages I have currently are app-emulation/wine-gecko and dev-util/mingw64-toolchain installed by wine and dev-libs/boehm-gc, dev-libs/libatomic_ops and sys-apps/sandbox which use flags are probably part of profile because I cannot make them emerge without abi_x86_32.

So far the only difference I noticed is no support for 16-bit applications and because some older programs used 16-bit installers they are more problematic to install. Otherwise I didn't see any issues running old 32-bit Windows applications. The only issue is that since I purged abi_x86_32 packages I had no easy way to test if something doesn't work if its due to using wow64. For that I installed Gentoo in a folder, configured system to be able to run X11 applications and then installed wine-staging with abi_x86_32 in there with the same portage config I normally use and interestingly enough it even works and even 3d acceleration runs just fine. Very old 16-bit applications work in Wine using this method. It also feels like good way to have spare system to test bunch of unstable versions of packages reducing risk of breaking my main system.

Anwys, Gentoo wiki for Wine doesn't really mention wow64 as an alternative for emerging bunch of 32-bit versions of packages but seeing how there is no "stable" Wine 9.x and there are supposedly great improvements in this function specifically in Wine 9 it makes some sense. It feels that as soon as we have stable Wine 9 it might might be a good idea to update Wiki to mention wow64. If 16-bit support is all we loose we are all used to not being able to run those on 64-bit versions of Windows and it isn't such a big deal. Personally I found all this abi_x86_32 both confusing at first and very irritating... not only at first but each time I had to add bunch of packages to portage configuration. It is also apparently the only solution to run old Windows games for systems without multilib which is overtime becoming more common configuration.

Anyways, what are the opinions on Wine with wow64?
_________________
Unix Wars - Episode V: AT&T Strikes Back

[Ionen]

[Chiitoo]

I am a bit surprised that at least 3dmark2001se indeed seems to run okay from a quick test (didn't do any comparison or anything).

I've been mainly testing with something else from around 2001 (originally), that runs at less than 1 FPS in the new wow64 mode, and just now gave an Alien VS Predator D3D11 benchmark a test that I had laying around, and that one isn't happy about it either, so it's definitely still an "expect problems" kind of a deal.

Additionally, at least some people working on Wine refer to it with "crippled 3D support" [1] still (and there are indeed other issues too), which doesn't seem too great either. :]

So I would definitely not recommend it for any general use yet, but could recommend trying it out, if one is keen to test it, and if it works for their application(s)... that's great!

As for our wiki article, yeah, been meaning to give it some time and update it... but it just has not happened... in a while. Maybe soon!?

1. https://www.winehq.org/mailman3/hyperkitty/list/wine-devel@winehq.org/message/K4AKMFXJ27KHE6LMVLWXV5QU5UBXDENV/
_________________
Kindest of regardses.

[cameta]

The pharaoh game doesn't work with wine-vanilla-9.0. Once the presentation has been run, the screen remains black except for the mouse and only the sound is heard. With wine-vanilla-8.0.2 it works perfectly.
Could the problem be related to this USE?
+ + wayland : Enable dev-libs/wayland backend
_________________
Si algo falla LEE el jodido manual, Si sigue fallando LEE BIEN el jodido manual.

[e8root]

I figured to move to "stable" wine package since I can use chrooted environment and so I installed wine-vanilla 9.0 in my main system and it seemed to work fine but during tests in hacky Wayfire-9999 build with adaptive sync (VRR) (note: wayfire-9999 doesn't build at the moment) it worked fine until I alt-tabbed out of the game Prodeus after which when I tried to switch back to it it didn't grab my keyboard/mouse in effect making it impossible to continue.
I guess the definition of 'stable' depends on various things and when living on wayland bleeding edge it is best to just grab newest versions. I general if its just to play games its probably best to grab latest ~amd64 version of staging and/or proton. 9999 stuff seems to just be upstream and it isn't always guaranteed to build let alone work depending on what pull requests were just merged

Anyways, regarding abi_x86_32 I think the only source of overhead can be calls between Windows domain and Linux so things like OpenGL calls mentioned by wine devs. Also other types of system calls including Vulkan used by wrappers. Still when I did tests with 3dmark2001se it didn't result in significant score reduction or really any. It is hard to say because score fluctuates between the runs and on abi_x86_32 the highest score I saw was ~250K and on wow64 ~248. To be honest I ran tests only few times. In either case unless 16-bit support is needed I think wow64 is good to go in wine 9.x.
_________________
Unix Wars - Episode V: AT&T Strikes Back

[HealerLFG]

I am interested in WoW64 for the purpose of dumping 32-bit dependencies as well. The biggest hurdle for me is the steam client itself... The steam client makes wine prefixes specific to each game, with per-game fixes within the prefix, and it also specifies the version of Proton needed on a per-game basis.
The steam client *itself* is 32-bit, so if we were to try and run the windows steam client under WoW64, we would lose the tight coupling of how the linux steam client handles proton prefixes per-game. If valve were to just release a 64-bit client, it wouldn't be so terrible, we would be able to run the (hypothetical) 64-bit linux steam client, and just use an up-and-coming version of proton with WoW64 support for the games that require 32 bit libraries and binaries...

[e8root]

I didn't install Steam yet but now I see you are right - Steam requires bunch of abi_x86_32 dependencies in which case one might as well continue to use wine with 32-bit packages it rather than trying wow64. Alternatively gentoo wiki mentions Flatpak as possible Steam 32-bit dependency hell solution...
Personally I will attempt to configure Steam on separate chrooted gentoo install where abi_x86_32 is configured. I already tested such solution working for wine-staging on Xorg but I have yet to try using gui-wm/gamescope and Steam. If that works then I will go with that approach for now. Even if it ultimately wont save build time now having to update two gentoo systems I will definitely not want to install any 32-bit packages on my main system.

BTW. I tested latest stable wine-proton 8.0.5c and wow64 works on it just fine. Apparently Wine 9.x only improves wow64 support.
_________________
Unix Wars - Episode V: AT&T Strikes Back

[Ionen]

[HealerLFG]

[e8root]

You need 32-bit support in enabled kernel to run Win32 application via either abi_x86_32 or wow64 USE flags.
Multilib not sure. I still need multi-lib for printer drivers which despite being for amd64 are actually just the same 32-bit drivers as ones for i386. Here I would also need few CUPS abi_x86_32 dependencies but I used workaround and just copied SO files from chrooted Gentoo install where I have abi_x86_32 USE flag set in make.conf and made a script to update these SO's and it works.

Where it comes to Steam I installed Steam via flatpak and it runs in Gamescope beautifully. Starts full screen and launches games no issues... after using

[jhon987]

I want to add to this thread, as someone who used a no-multilib until a few days ago - the reason i switched to multilib was WINE. And also, if i'm wrong, please feel free to correct me.

So, i had CONFIG_IA32_EMULATION enabled in the kernel, i don't quite remember well but i think i also had:

CONFIG_X86_X32_ABI
CONFIG_COMPAT_32
CONFIG_COMPAT
CONFIG_COMPAT_FOR_U64_ALIGNMENT

all enabled in the kernel, and yet when i tried installing Fallout game (which has a 32bit installer) i kept getting segmentation fault upon trying to run the installer, although WOW64 was enabled.
I also tried using flatpak for that purpose, but that failed too.
Notepad, which came bundled with WINE - did run (accorindg to file tool, it seems it is a 32bit program).

Obviously, being able to run notepad was not the reason i installed WINE in the first place. And so, i embarked at the tedious task of switching to multilib profile and reinstalling packages with ABI_32 and all of a sudden everything worked in WINE, including the Fallout installer.

So, yes, i'm saying that multilib is compulsory, according to my experience.
I'd love to be proven wrong (maybe outdated) on that one, so i could rid of the ABI_32 stuff

[e8root]

Ok but does Fallout installer work with the same version of Wine with multilib with wow64 instead of abi_x86_32?
You can test this only reemerging wine itself with wow64 instead abi_x86_32.

Also which version of wine?
_________________
Unix Wars - Episode V: AT&T Strikes Back

[Genas]

[Chiitoo]

[xgivolari]

[Genas]

[Chiitoo]