Dmitry Timoshkov dmitry@baikal.ru writes:
Changelog: Dmitry Timoshkov dmitry@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@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 Timoshkov" dmitry@baikal.ru writes:
"Alexandre Julliard" julliard@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.