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
after compilation.
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 would ensue).
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 :-)
