[Bug 48337] New: Support for *.local files (aka Dynamic-Link Library Redirection)
https://bugs.winehq.org/show_bug.cgi?id=48337 Bug ID: 48337 Summary: Support for *.local files (aka Dynamic-Link Library Redirection) Product: Wine Version: 5.0-rc2 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: major Priority: P2 Component: wineserver Assignee: wine-bugs(a)winehq.org Reporter: aros(a)gmx.com Distribution: --- It's really annoying, cumbersome and time consuming to make Wine use local DLLs, e.g. Direct3D libraries by first running winecfg and then finding and overriding the necessary DLLs. Windows for as long as I remember has allowed to have a .local file ( https://docs.microsoft.com/en-us/windows/win32/dlls/dynamic-link-library-red... ) which makes the windows DLLs loader first search for requested DLLs/libraries in the application directory then using system DLLs in case local DLLS are not found. Can we please have this feature implemented in Wine as well? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=48337 Nikolay Sivov <bunglehead(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|major |enhancement Component|wineserver |-unknown -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=48337 Zebediah Figura <z.figura12(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |z.figura12(a)gmail.com --- Comment #1 from Zebediah Figura <z.figura12(a)gmail.com> --- I'm not sure what the most sensible way to have such a feature interact with builtin/native load order is, but note that if you want to avoid using the GUI, you can also override DLLs from the command line, using something like the following (borrowed from winetricks): cat > override-dll.reg <<_EOF_ REGEDIT4 [HKEY_CURRENT_USER\\Software\\Wine\\DllOverrides] "*msvcr120"="native" _EOF_ wine regedit override-dll.reg ; wine64 regedit override-dll.reg rm override-dll.reg -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=48337 Austin English <austinenglish(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |austinenglish(a)gmail.com -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=48337 --- Comment #2 from Alexandre Julliard <julliard(a)winehq.org> --- (In reply to Artem S. Tashkinov from comment #0)
It's really annoying, cumbersome and time consuming to make Wine use local DLLs, e.g. Direct3D libraries by first running winecfg and then finding and overriding the necessary DLLs.
Windows for as long as I remember has allowed to have a .local file ( https://docs.microsoft.com/en-us/windows/win32/dlls/dynamic-link-library- redirection ) which makes the windows DLLs loader first search for requested DLLs/libraries in the application directory then using system DLLs in case local DLLS are not found.
Can we please have this feature implemented in Wine as well?
That wouldn't help you, because it only affects the search order for the dll file. Once the file is found it would still be subject to the native/builtin configuration, since that's not based on the search path. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=48337 --- Comment #3 from Artem S. Tashkinov <aros(a)gmx.com> --- (In reply to Alexandre Julliard from comment #2)
That wouldn't help you, because it only affects the search order for the dll file. Once the file is found it would still be subject to the native/builtin configuration, since that's not based on the search path.
In that case we should assume that the user requested "native, builtin" 'cause it's how Windows operates. Please implement this feature as I believe it's quite easy and simple to program and it's a lot more easier to use than using winecfg or creating registry files with overrides (both of which are cumbersome). -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=48337 --- Comment #4 from Alexandre Julliard <julliard(a)winehq.org> --- (In reply to Artem S. Tashkinov from comment #3)
(In reply to Alexandre Julliard from comment #2)
That wouldn't help you, because it only affects the search order for the dll file. Once the file is found it would still be subject to the native/builtin configuration, since that's not based on the search path.
In that case we should assume that the user requested "native, builtin" 'cause it's how Windows operates.
This doesn't make sense, there's no native/builtin distinction in Windows. And there's nothing special about .local, it's an alternative to using a manifest or putting dlls in the app directory, having it behave differently would be weird.
Please implement this feature as I believe it's quite easy and simple to program and it's a lot more easier to use than using winecfg or creating registry files with overrides (both of which are cumbersome).
It's not as easy as you think. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=48337 --- Comment #5 from Artem S. Tashkinov <aros(a)gmx.com> --- (In reply to Alexandre Julliard from comment #4)
This doesn't make sense, there's no native/builtin distinction in Windows. And there's nothing special about .local, it's an alternative to using a manifest or putting dlls in the app directory, having it behave differently would be weird.
I felt like Wine DLL overrides and Windows .local file + application directory DLLs work the same way but maybe I don't understand fully understand how native/builtin is handled by Wine. I've always assumed it was just a way of finding and loading libraries, i.e. native/builtin means try to find and use a DLL in the application directory and if it's not found then use the one which comes with Wine.
It's not as easy as you think.
If this feature request/Windows compliance feature/DLLs handling simplification doesn't make sense or requires a lot more effort than provides possible benefits then this bug report might be closed. Thank you for your attention anyways. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=48337 --- Comment #6 from Alexandre Julliard <julliard(a)winehq.org> --- (In reply to Artem S. Tashkinov from comment #5)
(In reply to Alexandre Julliard from comment #4)
This doesn't make sense, there's no native/builtin distinction in Windows. And there's nothing special about .local, it's an alternative to using a manifest or putting dlls in the app directory, having it behave differently would be weird.
I felt like Wine DLL overrides and Windows .local file + application directory DLLs work the same way but maybe I don't understand fully understand how native/builtin is handled by Wine. I've always assumed it was just a way of finding and loading libraries, i.e. native/builtin means try to find and use a DLL in the application directory and if it's not found then use the one which comes with Wine.
No, that's not how it works. Builtins are always used by default, no matter what files are found on disk (or even if the files don't exist at all). This is necessary because some apps come with broken versions of system dlls, and others install their dlls in the system directory. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
participants (1)
-
WineHQ Bugzilla