Re: RESEND: Try to avoid loading 16-bit DLLs into memory for accessing version info

[Alexandre Julliard]

Dmitry Timoshkov <dmitry(a)baikal.ru> writes:
> Changelog:
>     Dmitry Timoshkov <dmitry(a)codeweavers.com>
>     Try to avoid loading 16-bit DLLs into memory for accessing
>     version info, this might lead to undesired side effects like
>     loading a bunch of other 16-bit DLLs.

The problem I see is that this will bypass the loadorder config, and
retrieve the version of the native dll in all cases. I think it would
be better to try to take loadorder into account, though I admit it's
not trivial to do.

-- 
Alexandre Julliard
julliard(a)winehq.org

RESEND: Try to avoid loading 16-bit DLLs into memory for accessing version info

[Dmitry Timoshkov]

"Alexandre Julliard" <julliard(a)winehq.org> wrote:
> The problem I see is that this will bypass the loadorder config, and
> retrieve the version of the native dll in all cases.

I see.
> I think it would
> be better to try to take loadorder into account, though I admit it's
> not trivial to do.

Any idea how to do it without breaking DLL separation?

-- 
Dmitry.

RESEND: Try to avoid loading 16-bit DLLs into memory for accessing version info

[Alexandre Julliard]

"Dmitry Timoshkov" <dmitry(a)baikal.ru> writes:
> "Alexandre Julliard" <julliard(a)winehq.org> wrote:
> > I think it would
> > be better to try to take loadorder into account, though I admit it's
> > not trivial to do.
>
> Any idea how to do it without breaking DLL separation?

A possibility would be to use wine_dll_get_owner; if the dll doesn't
have an owner then you know it's native only and you can access the
file directly. This way you only do the LoadLibrary16 for dlls that
have a builtin implementation, it's not perfect but probably good
enough.

-- 
Alexandre Julliard
julliard(a)winehq.org