[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re:
- From: Stefan Sandberg <keffo.sandberg@...>
- Date: Thu, 06 Dec 2007 09:19:26 +0100
Not sure I follow, you have a dll as an executable's resource? How is
that dll loaded?
Eric Tetz wrote:
On Dec 5, 2007 12:57 PM, Duck <email@example.com
> > Is it possible to have my app statically link to lua but also
allow for DLL
> > based packages to work correctly?
> You need to build LUA.EXE with an export table for all of Lua's core and
> library API functions. Then you can build the DLLs you don't want to
> into LUA.EXE so that they import the Lua symbols from LUA.EXE, not from
> another DLL.
I have a similar situation, and it's painted me into a corner. Maybe
you can help.
I wrote a Lua-to-exe converter ('luax') which works by packing an
arbitrary list of files into the resource section of a statically
linked interpreter. The interpreter automagically fetches files from
within itself in response to Lua file routines -- open, loadlib,
require, etc. -- so you can package your script and any additional
scripts/files it needs into one, self-contained executable.
Luax.exe is itself a compiled script, containing luax.lua (front end),
luax.dll (Lua lib for updating executable resources), and upx.exe
(executable compressor). Luax compiles scripts by copying itself,
replacing the resources in the copy, then compressing the result with
Luax.dll is linked to the Lua API inside of luax.exe, exactly as you
described. This works because luax.dll can rely on the name of it's
However, the executables that Luax outputs can have any name. This
poses a problem if you want to include extension DLLs with your
compiled script. Those DLLs have no way of knowing where to look for
the Lua API.
I was thinking of rewriting the text inside the DLL at compiled time,
so that it knows to look for your executable name, but that will still
break if the user renames the executable after compilation.
Right now, the only solution I can think of is to:
(1) Create a proxy DLL that extension DLLs can link to. The proxy DLL
would forward API calls to the host executable.
(2) Scrap my current system and have a stub that extracts an
interpreter and an API DLL into a temp directory and runs them from
there, so your extension DLLs can link directly to the API DLL.
I kinda like my current system because it's simple and doesn't
*require* compiled scripts to create a temp directory at run time, but
this DLL problem is a bit of a showstopper.