[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Loading dynamic libraries on Windows
- From: David Manura <dm.lua@...>
- Date: Mon, 7 Nov 2011 22:07:29 -0500
On Sun, Nov 6, 2011 at 10:45 AM, Georg Lehner <firstname.lastname@example.org> wrote:
> http://lua-users.org/wiki/LoadLibrary -
> As reported earlier on the list I had problems with loading "mime.core" and
> "socket.core", while loading them individually worked without problems.
> The explanation can prominently be found in the Microsoft documentation 
> for the Windows CE/Windows Mobile API:
> "..Two different modules cannot have the same file name, even if the
> are different. These effectively have the same module name. For example, if
> LoadLibrary is made on Sample.cpl, the operating system will not load
> Sample.cpl, but instead will again load Sample.dll. .."
Thanks for pointing that out. In more detail, it says
"[...] all path information is ignored when determining if the DLL
is already loaded. This means that if a DLL with the same name is
currently loaded by any process on the system the search order is
ignored, even if the path is absolute. [...] Two different modules
cannot have the same file name, even if the extensions are different.
These effectively have the same module name. For example, if
LoadLibrary is made on Sample.cpl, the OS does not load Sample.cpl,
but instead loads Sample.dll again. A similar limitation exists for
modules with the same name but residing in different directories. For
example, if LoadLibrary is called on \\Windows\Sample.dll, and then
LoadLibrary is called on \\MyDir\Sample.dll, \\Windows\Sample.dll will
simply be reloaded."
which is problematic without your patch.
I've updated the LoadLibrary page to account for embedded versions of Windows.
> My current solution modifies "findfile()" in loadlib.c [... giving]
> filenames mime_core.dll and socket_core.dll.
Agree. The package path templating is not flexible enough to do that
without your patch. I've once thought of doing something like that
for source modules too (e.g. require "foo.bar.baz" would load from
"foo__bar__baz.lua", possibly via a custom searcher function) to avoid
deeply nesting directories in my source tree. On the other hand, I'm
forming the opinion that dots in module names are at least sometimes
best avoided (e.g my recent `find_slurp` module was not named
'file.slurp' ), although that opinion might not necessarily apply
here where `socket` and `socket.core` are maintained by the same
author and you may want to "hide away" the `core` in a subdirectory of