Re: LoadLibrary and 5.2

[Joshua Jensen <jjensen@...>]

----- Original Message -----
From: David Burgess
Date: 1/12/2010 6:29 AM
> Just so I got this problem right we have -
>
> luadir -
>   - C module dir A which contains a C module DLL
>     - subordinate DLLs  which contain DLLs that A is dependent upon
>   - C module dir B which contains a C module DLL
>     - subordinate DLLs  which contain DLLs that B is dependent upon
>   - C module dir C which contains a C module DLL
>     - subordinate DLLs  which contain DLLs that C is dependent upon
I solve this problem with delay loading of DLLs.  It works fantastically 
by adding delayimp.lib to your linked libraries and using the 
/DELAYLOAD:nonlua.dll to the link flags.  See 
http://msdn.microsoft.com/en-us/library/151kt790.aspx.

At this point, there are several choices.  The one I've most commonly 
used is to simply call LoadLibrary("full/path/to/nonlua.dll") at the 
first opportunity within the Lua module.

The second is to modify the PATH to include "full/path/to/".  I use that 
one very rarely.

The final method (and apparently recommended, although I only recently 
learned of it) is to provide a callback function for 
__pfnDliNotifyHook2.  See 
http://msdn.microsoft.com/en-us/library/z9h1h6ty.aspx.

I'm not sure if this is Visual C++ specific.  What I do know is the 
technique works really well.  In fact, LuaPlus even uses it for the Lua 
executable itself.  A file called lua.link sits side by side with the 
executable.  The lua.link file specifies the path to the Lua DLL.  The 
Lua DLL and modules can exist anywhere, and only the Lua executable and 
lua.link file need be in the PATH.

Josh