wine/wineserver bitness detection fails for wrapped Wine binaries

[Matoking]

In some environments such as Protontricks, Wine binaries are not directly available on $PATH. Instead, a Bash script is created for each Wine binary that takes care of setting up and running the underlying binary. These scripts are then made available through $PATH.

This breaks the "new WoW mode" detection introduced in bcd7a18 that checks the architecture for wine and wineserver. This fails because the executables are no longer binaries as Winetricks expects, causing "Unknown file arch: 65" or other similar warnings.

This happens on Protontricks, Wine packaged on Nix/Nixpkgs and potentially other environments in which wine and/or wineserver uses a wrapper script.

Ideally, we should probably run a Wine command instead that we can use to determine whether wine has been compiled using new WoW mode. Or maybe there's some other way?

[austin987]

In some environments such as Protontricks, Wine binaries are not directly available on $PATH. Instead, a Bash script is created for each Wine binary that takes care of setting up and running the underlying binary. These scripts are then made available through $PATH.

This breaks the "new WoW mode" detection introduced in bcd7a18 that checks the architecture for wine and wineserver. This fails because the executables are no longer binaries as Winetricks expects, causing "Unknown file arch: 65" or other similar warnings.

This happens on Protontricks, Wine packaged on Nix/Nixpkgs and potentially other environments in which wine and/or wineserver uses a wrapper script.

Unfortunately there are a lot of wrappers out there, and each does things differently. E.g., #2035 has a patch for debian, but I suspect that would break things on macOS and possibly other platforms/wrappers.

I'd be happy to review a PR that can fix things in a generic way.

Ideally, we should probably run a Wine command instead that we can use to determine whether wine has been compiled using new WoW mode. Or maybe there's some other way?

I'm not aware of any command that can determine that, but I'd be happy to be proven wrong.

[jre-wine]

#2035 is not for wrapper scripts, but for a missing wine64 binary in path, which exists though in Wine's bindir (classic wow64)

#2189 is for wrapper scripts. I'd be interested to hear if this helps for protontricks.

Both PRs should work just fine on all platforms, including MacOS.

[Matoking]

#2035 is not for wrapper scripts, but for a missing wine64 binary in path, which exists though in Wine's bindir (classic wow64)

#2189 is for wrapper scripts. I'd be interested to hear if this helps for protontricks.

Both PRs should work just fine on all platforms, including MacOS.

@jre-wine The current implementation in #2189 doesn't work with Protontricks, and the "halt upon unknown arch" error now makes Winetricks halt as opposed to bugging the user with a few errors before continuing on. That seemed like a happy accident rather than intended behavior, though.

Proton (Valve's fork of Wine) does not ship wineboot, just wine, wine64, wineserver, wine64-preloader, wine-preloader and msidb. I also posted a full listing here of the contents here.

Protontricks sets $WINEDLLPATH to point toward the Wine shared libraries. Winetricks could look for the actual binaries in $WINEDLLPATH/../../bin as a fallback if that env var is set, but I feel that it would be very situational and not work in every case (eg. it would not help with the Nix packaged Wine, which doesn't set WINEDLLPATH at all).

---

An example of how Protontricks works:

The shared libraries (lib,lib64) and Wine binaries (bin) are located in ~/.steam/steam/common/steamapps/Proton 8.0/dist, with ~/.steam/steam/common/steamapps/Proton 8.0/dist/lib/wine:~/.steam/steam/common/steamapps/Proton 8.0/dist/lib64/wine added to $WINEDLLPATH.

For every executable in ~/.steam/steam/common/steamapps/Proton 8.0/dist/bin, a wrapper script is created under ~/.cache/protontricks/Proton 8.0/bin.

The wrapper scripts do one of two things:

• If we're in the host, set up the environment and launch the binary in a Steam Runtime container.
• If we're inside the Steam Runtime container, launch the binary directly.

---

That said, if #2191 ends up working as well the bitness checking might not be needed. I admit I'm not familiar with how Wine is packaged or whether there is a telltale "we're running new WoW64 mode" sign somewhere else that can be used, rather than deducing things based on which executables exist.

[jre-wine]

Hm, couldn't protontricks set WINESERVER_BIN and WINE_BIN then?

Otherwise if we have to deal with scripts (and can't just completely get rid of the whole logic in favor of #2191), I suggest to just add all workarounds that might work, instead of trying to find one that works for all cases. I might come up with some workaround using WINEDLLPATH, but I'd like to hear first if this is needed at all.

Anyway, I changed #2189 again to only warn, but not exit. However there's an explicit warning now, that the WoW64 type could not be detected.

[Matoking]

Hm, couldn't protontricks set WINESERVER_BIN and WINE_BIN then?

Otherwise if we have to deal with scripts (and can't just completely get rid of the whole logic in favor of #2191), I suggest to just add all workarounds that might work, instead of trying to find one that works for all cases. I might come up with some workaround using WINEDLLPATH, but I'd like to hear first if this is needed at all.

Anyway, I changed #2189 again to only warn, but not exit. However there's an explicit warning now, that the WoW64 type could not be detected.

Yes, Protontricks could set WINESERVER_BIN and WINE_BIN to point towards the underlying binaries. The current code in #2189 doesn't seem to support it, though it seems like an easy addition.