[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: deployment of app with lua51.dll
- From: Joshua Jensen <jjensen@...>
- Date: Wed, 30 Jan 2008 01:03:37 -0700
----- Original Message -----
From: Mark Meijer
Date: 1/30/2008 12:42 AM
Any implicitly loaded DLL relying upon lua51.dll would need its Delay
Load DLLs list to contain lua51.dll, too. A need to duplicate the
LoadLibrary code described above may be necessary if the DLL, during its
DllMain startup, accesses the Lua DLL. If your DLL is explicitly loaded
after the LoadLibrary(lua51.dll) call, then there shouldn't be any need
to put the lua51.dll in the Delay Load DLLs list of your own DLL.
On 30/01/2008, Joshua Jensen <email@example.com> wrote:
You can cheat the system, though.
Add lua51.dll to the Delay Load DLLs list. As soon as your application hits
main()/WinMain(), call GetModuleFileName() to retrieve the full filename of
MyApp.exe (don't rely on argv). Strip the MyApp.exe from there to get
the path to MyApp.exe and append support/lua51.dll to it. Call
LoadLibrary(pathExcludingMyAppExe + "support/lua51.dll").
Then everything will work as normal.
Doesn't this become a problem, if you're going to load other dll's
that themselves depend on the Lua dll being present (e.g. any C
library with lua bindings)? I could be dead wrong here, haven't tried
The ManagedLuaPlus assembly in LuaPlus actually does this a bit
differently. It sets the environment variable PATH in its DllMain and
then lets the built-in delay loading pick up the Lua DLL when it is
first accessed. This is just a code version of the .bat file approach I
described in the previous message.