[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: FW: srlua extension to run with glued zip file
- From: Jay Carlson <nop@...>
- Date: Wed, 05 Jan 2005 10:50:10 -0500
I've now a basic extension to srlua running which allows you to combine
multiple (lua-) files in one zip file and than start it as a standalone
Great idea (if the amount the Lua code -- and you can precompile it, of
course, to save space -- compresses is larger than the size of the
Another way to do this on Windows would be to embed the "glued" codes
as resource entries (so they are inside the EXE proper) and then to UPX
the whole file. (UPX is a run-time in-memory unpackaging system. Highly
recommended to impress your friends when showing them how small your
Lua run-time is compared to their Perl or Python distro. The UPX
decompressor is very small.)
Has anyone tried using UPX for this (and is there an analogous way to
embed binary data into ELF binaries so that the original executable is
unaffected but the embedded data in technically "inside" as far as
exectuable packers are concerned)?
I'm confused. Why don't you just use the linker to put in the data that
you want? The most portable way to do this is just stuff everything
into a const char and compile it. If you want to skip the
octets->.c->.o overhead I suppose you could use objcopy to go directly
from octets->.o, or use a linker script for more control.
If the goal is to avoid having the whole development environment
including headers on the machine performing the append, then ship a
partially linked version of the lua executable with a weak symbol that
will be supplied by the .o containing the octets. The target machine
then just needs objcopy and a linker.
If you can't depend on having a linker on the target machine, yeah,
you're going to have to play around with libelf like lhf says. But just
about everybody has a linker.