[PATCH 0/1] MR6527: dinput8: Prefer the native DLL.
Many mod/ASI loaders hijack this DLL to do their work so accommodate this fairly common case by preferring their library. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6527
From: Aida Jonikienė <aidas957(a)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 = \ -- GitLab https://gitlab.winehq.org/wine/wine/-/merge_requests/6527
This merge request was approved by Rémi Bernon. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6527
Isn't the actual problem that we are not picking correct module? Or it's impossible to resolve because of native/builtin distinction? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6527#note_82631
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. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6527#note_82632
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. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6527#note_82634
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. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6527#note_82635
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)
-- https://gitlab.winehq.org/wine/wine/-/merge_requests/6527#note_82658
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)? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6527#note_82667
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. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6527#note_82668
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? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6527#note_82669
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. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6527#note_82670
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. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6527#note_82674
On Thu Sep 19 17:19:30 2024 +0000, Jinoh Kang wrote:
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. 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.
-- https://gitlab.winehq.org/wine/wine/-/merge_requests/6527#note_82675
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. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6527#note_82676
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... -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6527#note_82703
a31ec8da9572672e04ae46792a398da942649875 adds some heuristics based on the version resource, please give it a try. The heuristics can be tweaked if necessary. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6527#note_134167
On Sat Mar 28 01:36:31 2026 +0000, Alexandre Julliard wrote:
a31ec8da9572672e04ae46792a398da942649875 adds some heuristics based on the version resource, please give it a try. The heuristics can be tweaked if necessary. Testing on commit `a31ec8da` confirms that the version resource heuristics are working as expected. I am now able to load a native `dinput8.dll` (ASI loader) without manual overrides.
-- https://gitlab.winehq.org/wine/wine/-/merge_requests/6527#note_134193
Most likely superseded by a31ec8da9572672e04ae46792a398da942649875 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6527#note_134225
This merge request was closed by Aida Jonikienė. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6527
On Sat Mar 28 01:36:30 2026 +0000, Brandow wrote:
Testing on commit `a31ec8da` confirms that the version resource heuristics are working as expected. I am now able to load a native `dinput8.dll` (ASI loader) without manual overrides. This commit causes a regression with Lethal Company when BepInEx is installed. The winmm.dll placed in the game directory gets picked up by the heuristic and results in "RegOpenKeyExW failed. Function result: 2 Error code 0" on startup.
`WINEDLLOVERRIDES="winmm=b"` works around the crash, but breaks BepInEx ingame since it relies on the native winmm.dll as its mod loader entry point. BepInEx also uses a native `winhttp.dll `as an entry point, but no regression was observed with this commit on that one. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6527#note_134231
On Sat Mar 28 17:50:22 2026 +0000, Brandow wrote:
This commit causes a regression with Lethal Company when BepInEx is installed. The winmm.dll placed in the game directory gets picked up by the heuristic and results in "RegOpenKeyExW failed. Function result: 2 Error code 0" on startup. `WINEDLLOVERRIDES="winmm=b"` works around the crash, but breaks BepInEx ingame since it relies on the native winmm.dll as its mod loader entry point. BepInEx also uses a native `winhttp.dll `as an entry point, but no regression was observed with this commit on that one. So previously the mod didn't load, now it crashes? I'm not sure that's a regression, but please file a bug for it on bugs.winehq.org.
-- https://gitlab.winehq.org/wine/wine/-/merge_requests/6527#note_134375
participants (12)
-
Aida Jonikienė -
Aida Jonikienė (＠DodoGTA) -
Alexandre Julliard (＠julliard)
-
Alexandre Julliard (＠julliard)
-
Brandow (＠BrandowLucas)
-
Elizabeth Figura (＠zfigura)
-
Gabriel Ivăncescu
-
Jinoh Kang (＠iamahuman)
-
Martino Fontana (＠tinozzo123)
-
Nikolay Sivov (＠nsivov)
-
Paul Gofman (＠gofman)
-
Rémi Bernon