On Thu Sep 19 15:09:22 2024 +0000, Rémi Bernon wrote:
I actually dislike the idea of preferring native in a general way, and even initially didn't want to do it for dinput8. I think it is a dangerous game to play for us, as we must never look at Microsoft DLLs internals. Then, for this specific case, I got convinced that the advantages defeat the drawbacks, because of how all these mods actually use their own dinput8 implementation for hooking. I'm not aware of many other instances of this happening, but if it happens, we should IMO only carefully enable prefer-native on a per-module basis, where we know it is safe or useful enough.
I am not sure if KnownDlls is related to this issue anyhow? IMO it is orthogonal. KnownDlls are the few with cached mappings on Windows for which the system will always be loaded (if short dll name is used; a different one can still be loaded with full path). It is not analogous to Wine builtin handling: Wine will pretend it loads from correct location imposed by dll search rules but replace the actual image with builtin version.
I think the way how builtin preference works is intentional and was originally meant for some cases when the dll will be anywhere but that is system dll which can't work under Wine.
What I don't understand is why do we need prefer builtin for most of the dlls and deny loading the app's dll (whatever there is, just an app's dll with coinciding name or some deployed CRT runtime part)? Maybe the general solution is to switch native preference as default and only force builin when needed?
Meanwhile, there is probably nothing wrong in preferring native dinput8 also since the real Windows dinput8 generally works under Wine?