https://bugs.winehq.org/show_bug.cgi?id=48229
Bug ID: 48229 Summary: Regression on Automobilista. A lot of cars and tracks are not shown on Game menu Product: Wine Version: 4.15 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: leillo1975@gmail.com Distribution: ---
I installed the game on Lutris and found that If I use version 4.15 or more (qith and without stagin) fail. I don't try with 4.14 because you can't download it in Lutris, but using "lutris-4.13", game shows all cars and tracks. I suppose that in the last versions of wine, are additions from Proton 4.11 that makes the game don't show all its content.
I also reported this bug on Proton's Github issues: https://github.com/ValveSoftware/Proton/issues/246#issuecomment-546059058
https://bugs.winehq.org/show_bug.cgi?id=48229
leillo1975@gmail.com leillo1975@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Distribution|--- |Ubuntu
https://bugs.winehq.org/show_bug.cgi?id=48229
leillo1975@gmail.com leillo1975@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |regression
https://bugs.winehq.org/show_bug.cgi?id=48229
mickski56@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mickski56@hotmail.com
https://bugs.winehq.org/show_bug.cgi?id=48229
--- Comment #1 from Gijs Vermeulen gijsvrm@gmail.com --- Could you do a regression test please, see: https://wiki.winehq.org/Regression_Testing
https://bugs.winehq.org/show_bug.cgi?id=48229
Ben Suttor suttorp@pt.lu changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |suttorp@pt.lu
--- Comment #2 from Ben Suttor suttorp@pt.lu --- regression still present in wine 5.0 rc2
https://bugs.winehq.org/show_bug.cgi?id=48229
--- Comment #3 from Sven sven.wine@gmail.com --- A regression test shows that
8f732c66ab37b54c30d63c74f7822ba1d4f04996 is the first bad commit commit 8f732c66ab37b54c30d63c74f7822ba1d4f04996 Author: Zebediah Figura z.figura12@gmail.com Date: Mon Apr 29 22:59:36 2019 -0500
makefiles: Build with -fno-PIC on i386.
https://bugs.winehq.org/show_bug.cgi?id=48229
Paul Gofman gofmanp@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |gofmanp@gmail.com
--- Comment #4 from Paul Gofman gofmanp@gmail.com --- Created attachment 66256 --> https://bugs.winehq.org/attachment.cgi?id=66256 Test program
I've tested the game.
The game hooks kernel32.CreateFileW() and expects calls to kernel32.CreateFileA() to be routed to the kernel32.CreateFileW() where it is supposed to meet the hook. The hook does some trickery to open the actual data file while the files directly requested in CreateFile call do not exist.
Funny thing is that the reason why it breaks on commit bisected above is not the same as the reason why it doesn't work in the current git.
At the moment of the switch to no-PIC build (commit bisected above) both CreateFilaA() and CreateFileW() were implemented in kernel32.dll.so. Switch to no-PIC build triggered some different behaviour of gcc compiler which started for some reason creating a copy of CreateFileW() function so the calls from within kernel32 went to this function instead of the one which was referenced through the import table (maybe it was partially inlined though I did not analyze that disassembly thoroughly). The proof of concept fix which let me to fix the issue in Wine 4.8 source was adding __attribute__((noinline)) to CreateFileW(). I should also note that with my 4.7 or 4.8 source builds with default flags the game was crashing right away, I worked that around by compiling kernel32.dll.so with -O0 flag. Fortunately this sort of issue is not reproducible on the current git.
Later CreateFile{A|W}() were moved to kernelbase, and their availability in kernel32.dll is now provided by the following spec entries:
@ stdcall -import CreateFileA(str long long ptr long long long) @ stdcall -import CreateFileW(wstr long long ptr long long long)
So both CreateFileA() and CreateFileW() are now routed directly from their import thunks to kernelbase, and hooking kernel32.CreateFileW() has no effect on CreateFileA().
The most straightforward change which fixes the issue is to define the functions in kernel32 spec file like this:
@ stdcall CreateFileA(str long long ptr long long long) kernelbase.CreateFileA @ stdcall CreateFileW(wstr long long ptr long long long) kernelbase.CreateFileW
But this appears to be not quite correct. With these functions directly forwarded to kernelbase GetProcAddress(GetModuleHandle("kernel32.dll"), "CreateFileW") returns the address of the function in kernelbase (same address as for GetProcAddress(GetModuleHandle("kernelbase.dll"), "CreateFileW"). This appears to be not the case in my testing on Windows 7, where GetProcAddress return different addresses each in the corresponding module.
I am attaching the test program here which prints these function pointers and emulates such sort of hooking. The hook function is called when calling CreateFileA() on Windows 7 but not under Wine currently. So the correct fix seems to route kernel32.CreateFileA() to kernel32.CreateFileW() instead of kernelbase.CreateFileW().
https://bugs.winehq.org/show_bug.cgi?id=48229
--- Comment #5 from Paul Gofman gofmanp@gmail.com --- Created attachment 66257 --> https://bugs.winehq.org/attachment.cgi?id=66257 Proof of concept fix
I am attaching the patch which fixes the issue.
This patch certainly needs some refinement, as, at least:
- the straight coded '__attribute__((noinline))' is important, as without it gcc starts inlining CreateFileW() into CreateFileA() and we are back where we started. But it needs to be defined somewhere, maybe even inside the definition of WINAPI or DECLSPEC_HOTPATCH to avoid the similar issues with different functions;
- All the other code from kernel32 should probably call the same kernel32 exported functions.
https://bugs.winehq.org/show_bug.cgi?id=48229
--- Comment #6 from Alexandre Julliard julliard@winehq.org --- Does the game do things differently if you set version to Win10? Because the functions are in kernelbase there, just like in Wine, so the hooking wouldn't work.
https://bugs.winehq.org/show_bug.cgi?id=48229
--- Comment #7 from leillo1975@gmail.com leillo1975@gmail.com --- I tried the game with Wine 4.20 and Windows 10 on version and the problem persists.
https://bugs.winehq.org/show_bug.cgi?id=48229
--- Comment #8 from Paul Gofman gofmanp@gmail.com --- Created attachment 66262 --> https://bugs.winehq.org/attachment.cgi?id=66262 Add stub for LoadPackagedLibrary
(In reply to Alexandre Julliard from comment #6)
Does the game do things differently if you set version to Win10? Because the functions are in kernelbase there, just like in Wine, so the hooking wouldn't work.
Indeed, I initially tested the behaviour on Win 7 only but that appears to be different from Win8+ where such a hooking fails just like with Wine.
I tested the game further. Changing Windows version does not affect anything, but I found that the game detects Win 8+ by getting proc address of LoadPackagedLibrary from kernel32.dll (which is available starting from Win8 according to MSDN) and hotpatches differently.
Attached patch adds a stub for LoadPackagedLibrary to kernel32 and fixes the issue.
https://bugs.winehq.org/show_bug.cgi?id=48229
--- Comment #9 from Paul Gofman gofmanp@gmail.com --- Should be fixed by https://source.winehq.org/git/wine.git/commit/c28225fe5a89636d51b7fddd969793...
https://bugs.winehq.org/show_bug.cgi?id=48229
leillo1975@gmail.com leillo1975@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED
--- Comment #10 from leillo1975@gmail.com leillo1975@gmail.com --- (In reply to Paul Gofman from comment #9)
Should be fixed by https://source.winehq.org/git/wine.git/commit/ c28225fe5a89636d51b7fddd969793933752c62c
Thanks a lot, now the game works perfect with the last 5.2 wine version
Cheers!
https://bugs.winehq.org/show_bug.cgi?id=48229
Gijs Vermeulen gijsvrm@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |c28225fe5a89636d51b7fddd969 | |793933752c62c
https://bugs.winehq.org/show_bug.cgi?id=48229
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #11 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 5.3.