[Bug 58162] New: GetPrivateProfileIntA/W and WritePrivateProfileStringA/W does not detour properly.
http://bugs.winehq.org/show_bug.cgi?id=58162
Bug ID: 58162 Summary: GetPrivateProfileIntA/W and WritePrivateProfileStringA/W does not detour properly. Product: Wine Version: 10.6 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: kernel32 Assignee: wine-bugs@winehq.org Reporter: hibbsncc1701@gmail.com Distribution: ---
Created attachment 78443 --> http://bugs.winehq.org/attachment.cgi?id=78443 sone_patch's debug log under Windows 10.
When trying to detour a Recettear - An Item Shop's Tale's custom.exe using https://gitlab.com/redpolline/sone_patch, all attempts to update the game's config ini file fail under Wine, but work under Windows.
The game's custom.exe uses the GetPrivateProfileIntA() and WritePrivateProfileStringA() functions to access the game's ini file instead of calling CreateFileA(), ReadFile(), and WriteFile() directly.
I assume that the cause is Wine possibly having GetFullPathNameW() as a statically linked symbol within the context of GetPrivateProfileIntA() and WritePrivateProfileStringA(). (As all three of them are exported by kernel32.dll, and therefore the compiler would not need to search for the symbol at build time.) But I could be wrong here.
What matters is that when sone_patch detours GetFullPathNameA/W(), GetPrivateProfileIntA() and WritePrivateProfileStringA() should be affected by that detour without being detoured themselves.
A good way to see this is by using sone_patch's debug build, as it logs when a detoured function is hit, along with the given arguments.
Under Windows 10, multiple calls to GetFullPathNameA/W() are seen in the log. (But no CreateFileA/W() for the ini file.)
Under Wine, no calls are logged at all for the ini file. The only call to GetFullPathNameW() seen under Wine is for C:\windows\resources\themes\light\light.msstyles. Which isn't present under the Windows log, so that one is Wine specific.)
As a result, the game's button config and display settings cannot be altered by the game's custom.exe. As it gets the original (developer intended) file which is read-only (and owned by another user) on my system. Which sone_patch is supposed to workaround through the detouring of GetFullPathNameA/W() to point custom.exe to an accessible file elsewhere.
http://bugs.winehq.org/show_bug.cgi?id=58162
--- Comment #1 from Patrick Hibbs hibbsncc1701@gmail.com --- Created attachment 78444 --> http://bugs.winehq.org/attachment.cgi?id=78444 sone_patch's debug log under Wine.
http://bugs.winehq.org/show_bug.cgi?id=58162
--- Comment #2 from Alexandre Julliard julliard@winehq.org --- In general we can't support that sort of thing, because the call sequences that Wine makes internally differ from Windows. That's intentional, we don't want to investigate or replicate the internal workings of Windows dlls.
http://bugs.winehq.org/show_bug.cgi?id=58162
--- Comment #3 from Patrick Hibbs hibbsncc1701@gmail.com --- (In reply to Alexandre Julliard from comment #2)
In general we can't support that sort of thing, because the call sequences that Wine makes internally differ from Windows. That's intentional, we don't want to investigate or replicate the internal workings of Windows dlls.
I can understand that Wine doesn't want to be too much like Windows, and that doing so could cause legal issues for Wine.
That being said, current-as-of-this-posting Wine does call GetFullPathNameW() at https://gitlab.winehq.org/wine/wine/-/blob/f7503d0a996ae1243dd6c87b39a914362... Via the call chains: GetPrivateProfileIntA() -> GetPrivateProfileIntW() -> GetPrivateProfileStringW() -> GetPrivateProfileSectionNamesW() -> PROFILE_GetSectionNames() -> PROFILE_Open() -> GetFullPathNameW().
WritePrivateProfileStringA() -> WritePrivateProfileStringW() -> PROFILE_Open() -> GetFullPathNameW().
I don't see how making a call that Wine already performs internally, detourable, is a problem. It's just an IAT lookup, something that depending on your compiler / linker version and settings could be done accidentally already.
I would also be negligent not to point out that there are some things in Wine that solely exist for issues like this, Direct3DShaderValidatorCreate9() (Bug #46735) for example.
If making the existing internal call to GetFullPathNameW() detourable is not acceptable, then what would be the proper solution as far as Wine is concerned?
As I see it, the current options outside of Wine are:
The ideal solution (which would be the game developer fixing their app) is not likely to happen in general. (In this specific case, the developer abandoned the GOG version of Recettear years ago.)
The secondary solution (someone makes a unique patch for the game itself) is less likely given that the third option already exists and works. (And may run afoul of their legal obligations depending where in the world they live.)
The third option was a generic fix. (sone_patch in this case) That already exists and is functional under Windows. It's only Wine that's the problem here. Asking a third party to patch both the upstream proprietary binary blob's API calls *and* the downstream runtime is a bit much. Especially when that downstream fix effectively means detouring every top level Windows API call that has a path argument, or forking the downstream and providing their own patches. (Which only creates further fragmentation of Wine's user base.)
Have I missed something?
http://bugs.winehq.org/show_bug.cgi?id=58162
--- Comment #4 from Alexandre Julliard julliard@winehq.org --- (In reply to Patrick Hibbs from comment #3)
I don't see how making a call that Wine already performs internally, detourable, is a problem. It's just an IAT lookup, something that depending on your compiler / linker version and settings could be done accidentally already.
If it's called already then it should work. GetFullPathNameW is already marked as DECLSPEC_HOTPATCH so it should be detourable. There must be something else going on here.
http://bugs.winehq.org/show_bug.cgi?id=58162
--- Comment #5 from Patrick Hibbs hibbsncc1701@gmail.com --- Created attachment 78543 --> http://bugs.winehq.org/attachment.cgi?id=78543 POC patch
(In reply to Alexandre Julliard from comment #4)
(In reply to Patrick Hibbs from comment #3)
I don't see how making a call that Wine already performs internally, detourable, is a problem. It's just an IAT lookup, something that depending on your compiler / linker version and settings could be done accidentally already.
If it's called already then it should work. GetFullPathNameW is already marked as DECLSPEC_HOTPATCH so it should be detourable. There must be something else going on here.
Replacing the direct call to GetFullPathNameW() on https://gitlab.winehq.org/wine/wine/-/blob/f7503d0a996ae1243dd6c87b39a914362... with a GetModuleHandleEx(), GetProcAddress(), and function pointer call combo fixes this bug. (See attached patch file.)
So it appears that the issue is something that the compiler is doing when it sees that direct call.
http://bugs.winehq.org/show_bug.cgi?id=58162
--- Comment #6 from Patrick Hibbs hibbsncc1701@gmail.com --- Created attachment 78555 --> http://bugs.winehq.org/attachment.cgi?id=78555 Minimal test app
It seems that Windows' behavior changed sometime between Win7 and Win10.
Windows 7 has the same behavior as Wine with regards to this bug (i.e the detour fails), but Windows 10 works and the file is redirected by sone_patch.
I've attached a minimal test program if anyone wants to try this out to check for additional behavioral differences.
You'll still need sone_patch from: https://gitlab.com/redpolline/sone_patch/-/releases
But once you've gotten sone_patch extracted into the same folder as the test app, you can just run the included launch_test.bat.
If the detour is successful, the test app will place a W.ini file in the same folder as itself.
Otherwise, the test app will place a L.ini file.
-
WineHQ Bugzilla