[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: (should be 'static linked lua...')
- From: Duck <duck@...>
- Date: Thu, 6 Dec 2007 22:37:20 +1100 (EST)
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.
Don't think there is an easy way round this. A Windows import table is a
list of linked-to objects (usually other DLLs, or in your case the main
EXE), each with a sublist of symbols used from that linked-to object.
The imported libraries are therefore "hard wired" by name.
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
That's the only direct way I could think of, short of relinking the whole
DLL. (Use a long name for the original EXE so that you have plenty of
space for patching the import name in the DLLs (which is just an ASCIIZ
string, so can be shorter than the original name).
but that will still break if the user renames the executable
Just as it would break if you had LUA512.DLL and the user renamed
that...tho' admittedly EXEs are more likely to get renamed than DLLs.
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.
That's the only indirect way I could think of...
(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
...except for this way, which I myself don't like (emitting temp files is
a real annoyance, for example after disorderly shutdown or a program
crash, when the emitted files are leaked permanently...you can't use a
fixed temp directory and filenames in case the program is run twice...the
second time, the emitted DLLs will be locked and thus won't be
overwritten...and if the two builds were slightly different, DLL hell
You could also write a loader-wrapper for your require()able DLLs which
does its own fixups of the symbols from the main EXE when you require() a
module, calling GetProcAddress itself for the symbols in the main EXE
whilst letting the Windows loader handle any further imports. Might even
be able to plunder code from a packer like UPX (assuming GPL is not a
problem), but it's a lot of work, and probably harder than a proxy DLL.
Simplest way is simply to document that renaming the EXE isn't permitted