lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


On Windows Embedded CE/Windows Mobile (WinCE) DLL loading is even more "simplified":
no two DLLs in the whole filesystem must have the same filename.

The Lua team helped out with this problem by adding LUA_CSUBSEP to loadlib.c, which
allows to create systemwide unique lua-dll file names.

My guess is, that the DLL-loading problems on Desktop Windows could be tackled also
by this approach.

On WinCE I #define LUA_CSUBSEP '_', so the module is in the same directory as the foo module, but named foo_bar.dll, is foo_bar_baz.dll and so forth.



P.S.: the respective snippet from loadlib.c
** LUA_CSUBSEP is the character that replaces dots in submodule names
** when searching for a C loader.
** LUA_LSUBSEP is the character that replaces dots in submodule names
** when searching for a Lua loader.
#if !defined(LUA_CSUBSEP)

#if !defined(LUA_LSUBSEP)
- - -

On 12/13/11 07:28, Lorenzo Donati wrote:
On 13/12/2011 2.14, David Manura wrote:
On Sun, Dec 11, 2011 at 12:35 PM, Lorenzo Donati
<>  wrote:
BTW, I think this will be a fairly common option for Windows users, thus wouldn't it be better to place it in luaconf.h or at least to mention its existence in a more visible place, such a Windows configuration section in
the readme?

Last time I looked into it [1], I still wasn't completely satisfied
with it.  For example, 'LoadLibraryEx triggering undefined behavior
like package.cpath=".\\?.dll"'.


Thank you very much for the pointer!

I have a local "HTTracked" mirror of the WIKI which I don't update often and I missed that page.

Extremely interesting, and a big headache too! :-(

I didn't know loading a DLL was *so* painful. Especially that thing about LOAD_WITH_ALTERED_SEARCH_PATH triggering undefined behaviour (my *very* old Win32 API docs didn't mention anything about it) is *scary*, especially because building an absolute path in Lua is not always reliable (you have to know the absolute path of your script, and this in turn relies on using debug info AFAIK, since arg[0] gets a relative path sometimes.)!!!

From what I understand it seems that no good solution exists that makes most people reasonably happy :-(

I wonder whether expanding the interface of package.loadlib could be a flexible solution (some extra parameters? an extra table with fields a la os.time?) to allow tweaking the loading process.

I know Lua Team hate adding stuff that isn't ISO-C compliant, especially if this is so system dependent, but otherwise what reliable alternative is left to users with little or no knowledge of C and Win32 API, beyond cramming all the DLLs in the dir of Lua.exe, but this has other problems: say lua-foo.dll depends on sqlite.dll and lua-bar.dll depends on another version of sqlite.dll!

Would it be a better solution to provide a new standard library which would provide a small set of carefully selected system-dependent non-ISO features (e.g. system.abspath?, system.scriptdir?, system.sleep?, etc.)?

After all Lua already calls some non-ISO functions under the hood, so exposing them in a carefully designed way could help write more robust scripts. The problem would be to select the right stuff without bloating or uglifying Lua.

BTW wasn't there a proposal to integrate lfs into Lua? Expanded with a couple of functions to "complete the picture", it seems a good choice for a standard "system" library. Perhaps also *NIX systems have their own quirks that may be addressed by a common system library.

Moreover a separate library could be easily not be loaded (from the Lua C side, I mean) if one wanted less non-ISO dependencies or for embedded systems who, for example, have no OS.

Another approach would be to add a generally useful FFI library to Lua, but IIRC Lua Team didn't like the idea (IIRC someone suggested it some time ago, following the success of LuaJIT FFI). But probably this would really bloat Lua.

Am I talking nonsense or are there better approaches?


-- Lorenzo