Cannot temporary override wow64 to win64

[t14462]

hello! I've created simple wrapper for winetricks, which temporary changing wow64 to win64 (sometimes winetricks works bad in new wow64 mode).
But my override does nothing, because wow64 hardcoded!

Can you please make check in your patch

if( !isset(WINEARCH) )
{
    WINEARCH="wow64";
}

My wrapper:

cat /usr/local/bin/winetricks

#!/usr/bin/env bash

set -x

export WINEARCH=win64

/usr/bin/winetricks "$@"

[nokia8801]

Yes, please remove the hardcoded WoW64, protontricks still complains I'm using WoW64 even though I compiled with NOLIB32=false and I can't run any Steam games anymore with Wine tree Proton rather than Valve tree.

[SveSop]

Could be related to wine-10.2 changes where wine64 no longer exists? (As a executable that is). So all the troubles with winetricks running on "new wow64 mode" is there by default >= wine-10.2
https://bugs.winehq.org/show_bug.cgi?id=57859#c28

Basically WineHQ saying "NOTOURBUG"

[Artewar67]

I understand what winetricks using file /usr/bin/wine to check arch of file. Since wine64 is been remove and wine became 64bit is cause incorrect check of wow64 mode

Now wow64 mode only work when WINEARCH set to wow64.

[nokia8801]

Since wine64 has been removed

wine64 and wine64-tkg all still exists for me when building with _NOLIB32="wow64". Should it not exist? I see the dev saying the same thing in WineHQ, that it shouldn't exist?

Just built with fix d1bc0ba

/usr/bin/wine*

wine
wine64
wine64-tkg
wine-tkg
wine-tkg-interactive
wineboot
winebuild
winecfg
wineconsole
winecpp
winedbg
winedump
winefile
wineg++
winegcc
winemaker
winemine
winepath
wineserver
winetricks

[Artewar67]

wine64 now is just symlink to wine, this need to work for proton-tkg and (winetricks? #1045).

wine-tkg, wine64-tkg and wine-tkg-interactive is scripts which put with binary files. These files exist from the first days the existence of wine-tkg-git (On github) . I don't know why there scripts need.

[Laitinlok]

I am having the same issue that games doesn't launch with upstream wine

[Kerrung]

@Artewar67 4842f85
last_build_config.log
prepare.log
I still see an error message

system.reg is not a valid registry file
userdef.reg is not a valid registry file
user.reg is not a valid registry file
wine: could not load kernel32.dll, status c000035a
system.reg is not a valid registry file
userdef.reg is not a valid registry file
user.reg is not a valid registry file
wine: could not load kernel32.dll, status c000035a

And so, my games still can't be stared.

[Artewar67]

@Kerrung try clean prefix in compatdata. Be warned that if the game does not support steam cloud then the save in the game will disappear

[Kerrung]

@Kerrung try clean prefix in compatdata. Be warned that if the game does not support steam cloud then the save in the game will disappear

@Artewar67 These error messages appear during Steam startup, before I even try to launch any game. So your advice about removing the prefix does not apply to my situation. Especially since Steam itself automatically removes and reinstalls the prefix when changing the Proton version.

[nokia8801]

I've deleted the pfx folder many times, installed stuff fresh from the Redist folder inside game install folder, no luck. Games still won't launch with Wine upstream tree Proton.

[SveSop]

All scripts and installers that resolves c:\windows\syswow64 by attempting to use wine in the cmdline (for 32-bit) does not work anymore.

So in a wow64 scenario where you need 32-bit dll's in C:\windows\syswow64 and 64-bit dll's in C:\windows\system32 one should probably use hardcoded paths instead, since the old method of putting 32-bit dlls there by resolving the path by using things like wine winepath to get the actual C:\windows\syswow64 path, will now ONLY resolve to C:\windows\system32

So, symlinking wine64 -> wine will cause the 32-bit folder to be resolved to C:\windows\system32 no matter what, even if it seemingly does not immediately crash on some missing executable.

There could be other ways to fix this, but i have not found a useful way to do so. Maybe running /lib/i386-unix/wine-preloader with some options? Dunno.. does not seem useful.

[whrvt]

There could be other ways to fix this, but i have not found a useful way to do so. Maybe running /lib/i386-unix/wine-preloader with some options? Dunno.. does not seem useful.

The scripts that are broken (e.g. winetricks) should probably be updated themselves to use a more robust method instead of us needing to hack around it with Wine patches, IMO. It doesn't seem like upstream Wine will be changing back to the old layout, since the change was made in order to some broken ARM configurations (see here: https://gitlab.winehq.org/wine/wine/-/merge_requests/7204).

For updating scripts, feel free to take ideas from my AUR package here: https://aur.archlinux.org/cgit/aur.git/tree/setup_dxvk.sh?h=dxvk-msvc-git#n55

I've tested it with a variety of combinations of different kinds of Wine builds (new and old, 32- and 64-bit, wow64 etc.) and it seems to handle them all just fine.