Nikolay Sivov bunglehead@gmail.com writes:
On Thu, Apr 11, 2019 at 8:44 PM Vijay Kiran Kamuju infyquest@gmail.com wrote:
On Thu, Apr 11, 2019, 6:42 PM Zebediah Figura z.figura12@gmail.com wrote:
On 04/11/2019 10:09 AM, Vijay Kiran Kamuju wrote:
From: Sebastian Lackner sebastian@fds-team.de
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=43472
From: Sebastian Lackner sebastian@fds-team.de Signed-off-by: Vijay Kiran Kamuju infyquest@gmail.com
dlls/packager/packager_main.c | 2 ++ 1 file changed, 2 insertions(+)
diff --git a/dlls/packager/packager_main.c b/dlls/packager/packager_main.c index d70202b73b2..1ce184a5c74 100644 --- a/dlls/packager/packager_main.c +++ b/dlls/packager/packager_main.c @@ -675,6 +675,8 @@ BOOL WINAPI DllMain(HINSTANCE instance, DWORD reason, void *reserved) TRACE("(%p, %u, %p)\n", instance, reason, reserved);
switch(reason){
case DLL_WINE_PREATTACH:return FALSE; /* prefer native version */ case DLL_PROCESS_ATTACH: g_instance = instance; DisableThreadLibraryCalls(instance);While our packager is enough of a stub that this might make sense anyway, I feel it's worth pointing out that this is not really the correct way to fix this bug.
The application is also providing another dll with same name. So it should load that first, but it's not. Hence I believe that it is a correct fix.
Same happens on Windows, and presumably it loads correctly from exe directory. So, no, it's not correct if lookup happens in different order.
It's not a lookup order issue, even if we find the right one by default builtin always gets priority. Still, DLL_WINE_PREATTACH is not the right solution because it doesn't take loading directory into account either.