Re: (should be 'static linked lua...')

[Duck <duck@...>]

> 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 
:-)