lua-users home
lua-l archive

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

On 8/27/2008, RJP Computing wrote:
Yes I think this is a bit of a heavy approach, plus we still need to be able to run 'lua' on the command line so the PATH will still need to be updated.

One approach would be to patch package.loadlib() for Windows so that the PATH is updated in the current process environment just before each DLL is loaded. The updated PATH should include both lua.exe's folder and the folder from package.cpath where the DLL was found. That would permit Lua modules that need additional DLLs to get them from the "standard" DLL search path without requiring that the system PATH be modified any more than necessary to support command-line use of lua.exe. In fact, an application based on wlua.exe and IUP need not modify the system path at all in this case.

Another (better?) approach might be to patch package.loadlib() for Windows to use LoadLibraryEx() with the flag LOAD_WITH_ALTERED_SEARCH_PATH instead of LoadLibrary(). That flag is supposed to modify the search path used for implicitly linked DLLs to include the folder where the explicitly loaded DLL is located. According to MSDN, this feature has existed since Win95, although this is the first time I've noticed it in the documentation myself.

On a new enough version of Windows (XP SP2 I think), SetDLLDirectory() could probably be used instead of changing PATH.

Incidentally, I suspect that LuaRocks will have issues unless something like this is done because it scatters its installed rocks in a tree and implicit DLLs required by (and delivered with) a rock will have trouble loading when the rock is loaded by its customized require().

In any case, this is clearly something that should be done in the low level module loader, and not imposed as an external requirement on PATH to get complex DLL modules to work right.

Ross Berteig                     
Cheshire Engineering Corp.