lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

Or just use manifests, since that's what they're for. (ie, the name is not important, the manifest is)

Duck wrote:

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