Re: Linking scripts and interpreters into an executable

Juergen.Kahrs@t-online.de (Juergen Kahrs)
10 Aug 1998 23:28:32 -0400

          From comp.compilers

Related articles
Linking scripts and interpreters into an executable jkahrs@castor.atlas.de (Juergen Kahrs) (1998-07-30)
Re: Linking scripts and interpreters into an executable rpereda@ringer.cs.utsa.edu (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 bob@netwrench.com (1998-08-13)
Re: Linking scripts and interpreters into an executable dan@control.com (1998-08-13)
Re: Linking scripts and interpreters into an executable aeb@saltfarm.bt.co.uk (Tony Bass) (1998-08-16)
Re: Linking scripts and interpreters into an executable jkahrs@castor.atlas.de (Juergen Kahrs) (1998-08-17)
| List of all articles for this month |

From: Juergen.Kahrs@t-online.de (Juergen Kahrs)
Newsgroups: comp.compilers
Date: 10 Aug 1998 23:28:32 -0400
Organization: Compilers Central
References: 98-07-238 98-08-046
Keywords: interpreter

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
stand-alone-executables.


> 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
wheel.


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/ _______________
--


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.