Fix architecture detection mechanism for wrapper scripts

[jre-wine]

There are 2 general issues related to this fix, each handled in a separate commit:
winetricks: display messages for users to stderr
winetricks_get_file_arch: try workaround for wrapper scripts
winetricks_set_wineprefix: warn if binary arch is unknown

Please have a look at the detailed commit messages. E.g. not all of the stderr stuff is needed.

Feedback welcome!

3 open questions:

1. Is my readlink implementation sufficient?
   "readlink -f" is not working on MacOS < 12.3
   (https://apple.stackexchange.com/questions/464136/which-macos-version-introduced-readlink-f)

Alternatives are:
(See https://stackoverflow.com/questions/1055671/how-can-i-get-the-behavior-of-gnus-readlink-f-on-a-mac)

• greadlink (extra package, in /usr/local/bin/)
• perl -MCwd=abs_path -le 'print abs_path readlink(shift);' $FILE (if perl is installed)
• stat -f%Y $FILE (the -f%Y option will show the target of a symlink, not an absolute pathname, should still work. Does not work on Linux)

For now I just use the perl alternative on MacOS. I think that's sufficient, but if wanted and with the help of some MacOS users I might add some changes:

• If we know the MacOS version, we might use "readlink -f" on current MacOS >=12.3.
• If I know the exact filepath we might use greadlink (provided by a separate package)
• As fallback we might use "stat" - but the syntax I found on the web doesn't work on Linux.

Whatever we do, even if the implemented readlink alternative fails, there still shouldn't be a regression, because if "readlink -f" or the alternative is non-functional all error messages (as long as they are on stderr) go to /dev/null and the output should be empty. Then the binaries would be tested directly in "/" (where they really shouldn't exist), and the same "Unknown file arch" would result as without this code.

2. Should I factor the readlink logic out? [EDIT: Done]
   Since this PR uses the same readlink logic as in Workaround missing /usr/bin/wine64. #2035 I might combine both PRs and factor this out to deduplicate code. Please tell me if I should do so.

3. Should I warn, exit or completely ignore if the binary arch is unknown? [EDIT: Done: exit/w_die]
   For now I only warn, but continue.
   Depending on whether the user has an old or new style WoW64 setup, this still might give the correct outcome accidentally. See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1063466
   Once we're satisfied that my fix works I suggest to use w_die instead.

[vitlav]

Please check also
#2191
This is the way to solve it without overcomplicating the code.

[jre-wine]

Please check also #2191 This is the way to solve it without overcomplicating the code.

I'm not familiar with all requirements for handling new and classic wow64 mode. If your solution is sufficient I'd be happy to see my PR be rejected (except the output to stderr commit).

[vitlav]

(except the output to stderr commit).

I would suggest to send output to stderr commit in a separate PR. As I see, it is arch independent issue.

[jre-wine]

I updated this PR again to only warn but not exit in case of failure, as it doesn't solve all script related issues (e.g. protontricks #2183). However now Winetricks correctly and explicitly warns that it couldn't detect the wow64 type, instead of randomly choosing either classic or new wow64 type as current official Winetricks does.

To simplify the code I changed winetricks_get_file_arch to just silently return nothing in case of failure (instead of returning "try-script" as in my previous implementation, and instead of warning about this as current Winetricks does). So the calling function (winetricks_set_wineprefix) is free to try workarounds without annoying the user with warnings.

I'll make a separate PR for the stderr if you object this PR here. However I see no potential for regressions even if it doesn't solve all issues. So as long as you don't replace the whole logic with something else please accept this PR.

Finally this PR is still set to "Changes requested". No idea how to get rid of this, please review @austin987 (hope you find the time for it, greets!)

[jre-wine]

Minor update: I moved my new warning about an unknown WoW64 type next to the existing warning about the new mode WoW64 type. So it will be only shown once per session.

[austin987]

Hi @jre-wine,

This doesn't work for me with a Debian Wine package:

austin@debian:~/src/winetricks$ wineserver -k ; rm -rf ~/.wine ; winetricks -q mfc42
Executing cd /usr/local/bin
------------------------------------------------------
warning: You are using a 64-bit WINEPREFIX. Note that many verbs only install 32-bit versions of packages. If you encounter problems, please retest in a clean 32-bit WINEPREFIX before reporting a bug.
------------------------------------------------------
grep: /home/austin/.wine/*.reg: No such file or directory
------------------------------------------------------
WINEPREFIX INFO:
Drive C: total 28
drwxrwxr-x  7 austin austin 4096 Apr 27 16:51 .
drwxrwxr-x  4 austin austin 4096 Apr 27 16:51 ..
drwxrwxr-x  6 austin austin 4096 Apr 27 16:51 Program Files
drwxrwxr-x  6 austin austin 4096 Apr 27 16:51 Program Files (x86)
drwxrwxr-x  3 austin austin 4096 Apr 27 16:51 ProgramData
drwxrwxr-x  4 austin austin 4096 Apr 27 16:51 users
drwxrwxr-x 21 austin austin 4096 Apr 27 16:51 windows

Registry info:
/home/austin/.wine/*.reg:
------------------------------------------------------
------------------------------------------------------
warning: /usr/bin/wine cmd.exe /c echo '%AppData%' returned empty string, error message "" 

issue2189.txt

I've attached a log with winetricks -v

[jre-wine]

Hi @austin987 , great to see you back!

That problem is because of the missing /usr/bin/wine64 in Debian and is fixed by #2035.
I ship the Debian packages with #2035 and #2189 applied for some weeks now, and haven't gotten any report since then.

[austin987]

Hi @austin987 , great to see you back!

That problem is because of the missing /usr/bin/wine64 in Debian and is fixed by #2035. I ship the Debian packages with #2035 and #2189 applied for some weeks now, and haven't gotten any report since then.

Thanks, I tested this in several configurations (32/64bit, old/new wow, a few different versions) and saw no regressions. I appreciate your patience and making it non-Debian specific :).