|Linking scripts and interpreters into an executable email@example.com (Juergen Kahrs) (1998-07-30)|
|Re: Linking scripts and interpreters into an executable firstname.lastname@example.org (Ray Pereda) (1998-08-10)|
|Re: Linking scripts and interpreters into an executable Juergen.Kahrs@t-online.de (1998-08-10)|
|Re: Linking scripts and interpreters into an executable email@example.com (1998-08-13)|
|Re: Linking scripts and interpreters into an executable firstname.lastname@example.org (1998-08-13)|
|Re: Linking scripts and interpreters into an executable email@example.com (Tony Bass) (1998-08-16)|
|Re: Linking scripts and interpreters into an executable firstname.lastname@example.org (Juergen Kahrs) (1998-08-17)|
|From:||Juergen.Kahrs@t-online.de (Juergen Kahrs)|
|Date:||10 Aug 1998 23:28:32 -0400|
Ray Pereda wrote:
> I have not seen explicit support for this kind of feature but I think
> it is much needed. Most executable file formats have a non-executable,
> non-program data section. I would dump the script in there.
This is what I did. The GNU binutils allow adding arbitrary sections
to an ELF file. It is possible to create an executable binary that
consists of three parts
- unpacker (to be written, uses GNU zip lib)
- interpreter exe, stripped, gzipped
- script, gzipped
When the resulting exe is started, the unpacker extracts the gzipped
parts into separate temporary files and calls the interpreter with a
system() call. This causes invocation of the first temp file (exe)
which will interpret the other temp file (script). A primitive method
(not really a compiler), but it allows us to create compact
> I don't think it is that peculiar. Clint Jeffery and I hacked up a
> way to combine the Icon interpeter and a source file so that we could
> have one executable for easy distribution of binaries. The solution
> was basically to just have a special copy of the interpreter that seeks
> for a special marker where the executable ends, and the source script
> is appended to file. We did not even bother try to put the code in a
> debug section or something of the kind.
For testing purposes, I created an ELF executable that used a
hello-world-program instead of the unpacker. After adding the gzipped
section with the GNU binutils, the hello-world-program still runs and
is able to access its own file name to open it for extracting the
gzipped sections. This primitive but general method should also work
for the Bourne shell and other interpreters that do not rely on
libraries in their run-time-environment.
> The perl people have a program that creates standalone executable
> perl programs. When I asked the author what was his technique he
> said that he did not want to make it public. Bastud.
This is why I asked here in comp.compilers. Before I go on and write
the unpacker, I would like to hear some critical comments and
suggestions from people like you in order to avoid reinventing the
Thanks for your comments.
Anyone else seen something like this ?
Juergen Kahrs Tel. 0421 249 666
Millstaetter Strasse 15 Tel. 0421 457 2819
D 28359 Bremen Fax 0421 457 3578
____________ http://home.t-online.de/home/Juergen.Kahrs/ _______________
Return to the
Search the comp.compilers archives again.