[PATCH] packager: Prefer native version.

[Nikolay Sivov]

On Thu, Apr 11, 2019 at 8:44 PM Vijay Kiran Kamuju <infyquest at gmail.com>
wrote:

>
>
> On Thu, Apr 11, 2019, 6:42 PM Zebediah Figura <z.figura12 at gmail.com>
> wrote:
>
>> On 04/11/2019 10:09 AM, Vijay Kiran Kamuju wrote:
>> > From: Sebastian Lackner <sebastian at fds-team.de>
>> >
>> > Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=43472
>> >
>> > From: Sebastian Lackner <sebastian at fds-team.de>
>> > Signed-off-by: Vijay Kiran Kamuju <infyquest at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20190411/b3f79507/attachment.html>