[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: loadlib options for Windows sytems
- From: Lorenzo Donati <lorenzodonatibz@...>
- Date: Tue, 13 Dec 2011 07:28:41 +0100
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, 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
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
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?