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?