Many mod/ASI loaders hijack this DLL to do their work so accommodate this fairly common case by preferring their library.
From: Aida Jonikienė aidas957@gmail.com
Many mod/ASI loaders hijack this DLL to do their work so accommodate this fairly common case by preferring their library. --- dlls/dinput8/Makefile.in | 1 + 1 file changed, 1 insertion(+)
diff --git a/dlls/dinput8/Makefile.in b/dlls/dinput8/Makefile.in index f3f5fdc4fd8..ac5b89747f7 100644 --- a/dlls/dinput8/Makefile.in +++ b/dlls/dinput8/Makefile.in @@ -2,6 +2,7 @@ MODULE = dinput8.dll IMPORTLIB = dinput8 IMPORTS = dinput8 dxguid uuid comctl32 ole32 user32 advapi32 hid setupapi EXTRADEFS = -DDIRECTINPUT_VERSION=0x0800 +EXTRADLLFLAGS = -Wb,--prefer-native PARENTSRC = ../dinput
SOURCES = \
This merge request was approved by Rémi Bernon.
Isn't the actual problem that we are not picking correct module? Or it's impossible to resolve because of native/builtin distinction?
When load order is builtin first, we load the builtin library in place of the actual file on disk, regardless of where it's located. Maybe we could do that differently but it could then have a much wider impact.
I thought there was some logic on Windows (KnownDLLs is that?), to disallow certain dlls, by name, to be loaded from outside of system32. Clearly dinput8.dll isn't one of them. Impact of switching one module default is certainly smaller, but by that logic we might as well switch most of non-core modules to prefer-native.
I don't know about other modules but we've actually encountered this with dinput8 a lot of times, as it's used by a lot of game mods out there for some reason.
On Thu Sep 19 14:03:03 2024 +0000, Nikolay Sivov wrote:
I thought there was some logic on Windows (KnownDLLs is that?), to disallow certain dlls, by name, to be loaded from outside of system32. Clearly dinput8.dll isn't one of them. Impact of switching one module default is certainly smaller, but by that logic we might as well switch most of non-core modules to prefer-native.
FYI: KnownDLLs for Wine is implemented in https://gitlab.winehq.org/wine/wine/-/merge_requests/2127 (open PR)
On Thu Sep 19 14:03:03 2024 +0000, Jinoh Kang wrote:
FYI: KnownDLLs for Wine is implemented in https://gitlab.winehq.org/wine/wine/-/merge_requests/2127 (open PR)
Yeah I agree, this fix seems like a band-aid. Most DLLs on Windows will get picked by the one near the .exe (except for KnownDLLs as mentioned).
Even without KnownDLLs implemented, shouldn't prefer-native be the default then on every module, since only a certain "allow list" of DLLs are actually "KnownDLLs" (in our case, prefer-builtin)?
On Thu Sep 19 15:09:22 2024 +0000, Gabriel Ivăncescu wrote:
Yeah I agree, this fix seems like a band-aid. Most DLLs on Windows will get picked by the one near the .exe (except for KnownDLLs as mentioned). Even without KnownDLLs implemented, shouldn't prefer-native be the default then on every module, since only a certain "allow list" of DLLs are actually "KnownDLLs" (in our case, prefer-builtin)?
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.
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?
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?
Because if there's a problem with builtin we can fix it, but if there's a problem with native usually there's nothing we can do.
Obviously the app shipping an incompatible native dll is a different case, and would maybe need a different mechanism than prefer-native, which is meant for stub dlls.
On Thu Sep 19 15:44:02 2024 +0000, Alexandre Julliard wrote:
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? Because if there's a problem with builtin we can fix it, but if there's a problem with native usually there's nothing we can do. Obviously the app shipping an incompatible native dll is a different case, and would maybe need a different mechanism than prefer-native, which is meant for stub dlls.
Feels like a tension between two kinds of "native"s:
1. Microsoft-signed Windows-native DLLs 2. Third party reimplementation of (1)
Once we are able to distinguish them (check digital signature), (1) should be replaced by builtin as julliard notes, but (2) should probably take priority over anything else.
I might have missed something, though.
On Thu Sep 19 17:19:30 2024 +0000, Jinoh Kang wrote:
Feels like a tension between two kinds of "native"s:
- Microsoft-signed Windows-native DLLs
- Third party reimplementation of (1)
Once we are able to distinguish them (check digital signature), (1) should be replaced by builtin as julliard notes, but (2) should probably take priority over anything else. I might have missed something, though.
Signature check is probably extreme, but there is publisher in version info, maybe that could be checked in theory, although it probably still rather ad-hoc solution. In a generic case there might be some non-MS libs we want to prefer builtin for, like GPU vendor libs. But upstream Wine currently doesn't have such, so maybe that is not a concern.
On Thu Sep 19 17:22:53 2024 +0000, Paul Gofman wrote:
Signature check is probably extreme, but there is publisher in version info, maybe that could be checked in theory, although it probably still rather ad-hoc solution. In a generic case there might be some non-MS libs we want to prefer builtin for, like GPU vendor libs. But upstream Wine currently doesn't have such, so maybe that is not a concern.
That sounds to me like the purpose of builtin DLLs is not to replace only Microsoft DLLs; it exists to replace whatever well-known DLLs we want to reimplement (e.g., wpcap) in order to provide a functional wineprefix.
Then the current strategy of identifying DLLs solely by its basename is probably *wrong* to begin with; maybe we should check the full `(basename, publishername)` tuple or something. Like WinSxS assembly identifiers, but maybe simpler.
Again, I'm probably not the most knowledgeable person here and I have possibly missed something here. (If so, sorry about that!) But the oscillation of "native vs. builtin" has been a lingering problem since the millennium, and I can only see this debacle continue until we get rid of this dichotomy in favor of a more expressible DLL-override system.
While `dinput8.dll` is the most popular one, Ultimate ASI Loader (a popular tool for modding) supports _a lot_ of DLLs: https://github.com/ThirteenAG/Ultimate-ASI-Loader?tab=readme-ov-file#descrip....
Outside of that, other examples of DLL injection on top of my head are: - DXVK (non-global): https://github.com/doitsujin/dxvk?tab=readme-ov-file#dll-dependencies - (Plus `d3d12.dll` for vkd3d-proton) - SpecialK: https://wiki.special-k.info/en/SpecialK/Local - Optiscaler: https://github.com/cdozdil/OptiScaler?tab=readme-ov-file#optiscaler-supports...
-
Aida Jonikienė -
Aida Jonikienė (＠DodoGTA)
-
Alexandre Julliard (＠julliard)
-
Gabriel Ivăncescu (＠insn)
-
Jinoh Kang (＠iamahuman)
-
Martino Fontana (＠tinozzo123)
-
Nikolay Sivov (＠nsivov)
-
Paul Gofman (＠gofman)
-
Rémi Bernon (＠rbernon)