[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: loadlib options for Windows sytems
- From: Georg Lehner <jorge-lua@...>
- Date: Tue, 13 Dec 2011 21:58:54 +0100
On Windows Embedded CE/Windows Mobile (WinCE) DLL loading is even more
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
allows to create systemwide unique lua-dll file names.
My guess is, that the DLL-loading problems on Desktop Windows could be
by this approach.
On WinCE I #define LUA_CSUBSEP '_', so the foo.bar module is in the same
as the foo module, but named foo_bar.dll, foo.bar.baz 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.
#define LUA_CSUBSEP LUA_DIRSEP
#define LUA_LSUBSEP LUA_DIRSEP
- - -
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
BTW, I think this will be a fairly common option for Windows users,
wouldn't it be better to place it in luaconf.h or at least to
existence in a more visible place, such a Windows configuration
Last time I looked into it , I still wasn't completely satisfied
with it. For example, 'LoadLibraryEx triggering undefined behavior
with LUA_LLE_FLAGS=LOAD_WITH_ALTERED_SEARCH_PATH and relative paths
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 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?,
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?