https://bugs.winehq.org/show_bug.cgi?id=53792
Bug ID: 53792 Summary: Doorstop: builtin winhttp.dll is loaded instead of native Product: Wine Version: 7.18 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: kubastaron@hotmail.com Distribution: ---
Repro: 1. Download TestGame from https://github.com/BepInEx/TestGame/releases/download/latest/TestGame.Mono.W... (or any other unity game) and extract it 2. Download doorstop from https://github.com/NeighTools/UnityDoorstop/releases/download/v4.0.0/doorsto... and extract `x86/winhttp.dll` (or `x64/winhttp.dll` if your game is 64-bit) next to `TestGame.exe` 3. Run `TestGame.exe`
On Windows it will create a `doorstop_*.log` file and start the game, but wine will just start the game without running doorstop at all because it loads a builtin winhttp.dll.
A working workaround is to set WINEDLLOVERRIDES="winhttp=n,b".
A potential solution is to make wine prefer native winhttp.dll like so:
diff --git a/dlls/winhttp/Makefile.in b/dlls/winhttp/Makefile.in index 97266fbc92a..eb3618a0e5e 100644 --- a/dlls/winhttp/Makefile.in +++ b/dlls/winhttp/Makefile.in @@ -3,6 +3,8 @@ IMPORTLIB = winhttp IMPORTS = uuid jsproxy user32 advapi32 ws2_32 DELAYIMPORTS = oleaut32 crypt32 secur32 iphlpapi dhcpcsvc
+EXTRADLLFLAGS = -Wb,--prefer-native
C_SRCS = \ cookie.c \ handle.c \
This is essentially the same bug as https://bugs.winehq.org/show_bug.cgi?id=47053, but that one was using forked doorstop and was specific to beat saber.
$ sha1sum doorstop_win_verbose_4.0.0.zip TestGame.Mono.Windows.2020.3.22f1.zip ddb2de0fb15b7739127dd12b519c011182f7a628 doorstop_win_verbose_4.0.0.zip 943f40919616181ddf0555b77098ec94d1483f76 TestGame.Mono.Windows.2020.3.22f1.zip
https://bugs.winehq.org/show_bug.cgi?id=53792
--- Comment #1 from Rafał Mużyło galtgendo@o2.pl --- Correct me if I'm wrong, but the way I understand it, that particular winhttp.dll is an injection proxy.
If so, your argument is at least slightly flawed.
I could bring up an old HD patch for Fallout (or was it Fallout 2 ?), that used ddraw.dll as such proxy. That is to say, your argument, if correct, would fit pretty much any Windows system dll (well, any that Windows allows to be proxied).
I mean, even apitrace needs to live with explicit DLLOVERRIDES when its Windows version is run with wine.
https://bugs.winehq.org/show_bug.cgi?id=53792
--- Comment #2 from Jakub Staroń kubastaron@hotmail.com --- (In reply to Rafał Mużyło from comment #1)
Correct me if I'm wrong, but the way I understand it, that particular winhttp.dll is an injection proxy.
Yes it is an injection proxy but whats wrong with that? Windows allows it without any registry hacks so why wouldn't wine? I can understand wine intercepting the load of system libraries from system directories but why would it do it for libraries in the application directory? Doorstop works by (ab)using the fact that Windows will load winhttp.dll from the current directory instead the system one, but then it loads the real winhttp.dll from C:\windows\system32, so why couldn't wine intercept just the real one?
https://bugs.winehq.org/show_bug.cgi?id=53792
--- Comment #3 from Alexandre Julliard julliard@winehq.org --- Because there are apps that ship broken dlls, so we need to be able to configure the behavior either way. Builtin is the default because in general it's easier to fix a builtin if it causes a problem.
https://bugs.winehq.org/show_bug.cgi?id=53792
Neko-san nekoNexus@protonmail.ch changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |nekoNexus@protonmail.ch