                                EXEPAK version 1.2
                      (c)1997 Adam Ierymenko [api@one.net]
		Modifications (c) 1999 Zurk (zurk@geocities.com)

Remember that PKLITE program for DOS that created auto-decompressing
compressed executables?  Well here's the equivalent for Linux.  EXEPAK
self-decompressing executables do not require that any special libraries,
binaries, compression programs, etc. be installed on your system.
They only require a writable /tmp directory, the /proc filesystem, and
libc to properly decompress and execute.  (Unlike the old gzexe program
which requires /usr/bin/gzip and /bin/sh and a bunch of other stuff and
is slow.)

How EXEPAK works:

An EXEPAK compressed binary consists of the original uncompressed binary
in it's entirity compressed and appended onto the end of the EXEPAK
extracting 'stub'.  The stub works by opening /proc/self/exe which always
points to the binary file on disk which represents the current process,
seeking beyond the stub code to find the compressed data, and then
quickly decompressing the compressed executable into a file in /tmp and
executing it.  About a second after execution, a small subprocess which
was forked off by the stub removes the temp file and exits.  If you have a
lot of memory, the creation and deletion of the temp file may not cause any
disk access at all since the entire process would take place within the
filesystem buffers.

Installing EXEPAK:

Just put the exepak binary in /bin.  No other files are needed.  The
exepak binary does not have to be installed on a system for compressed
binaries to work.  Read HOW-TO-COMPILE to compile your own.

Using EXEPAK:

Execute EXEPAK with a list of filenames to compress.  It will only attempt
to compress recognized binary files, so you can "exepak *" in a directory
with other files and it will only compress the binaries.  When compressing,
the original uncompressed binary is saved as <filename>~.  When
decompressing, the original compressed binary is saved in the same way.

Description of command line switches:
   -x : This causes EXEPAK to decompress any compressed binaries (1.1 does
        not have a ^dc- switch for compressed binaries-- the exepak
        program itself decompresses instead)  It cannot decompress
        1.0 binaries with this switch-- use the ^dc-<filename> option
        described in the exepak 1.0 docs to decompress 1.0 binaries.
   -e : This causes EXEPAK to compress binaries in such a way as no
        text strings can be read inside them and they cannot be 
        decompressed with the -x switch.  This is not a real safeguard
        though, since any really knowledgable user could easily
        break this protection.
   -b## : This sets the blocksize in K.  Larger blocksizes will give
          slightly better compression at the expense of more memory use
          at the moment of decompression (not afterwords, since exepak
          self-extracting binaries leave nothing behind in memory).
   -t : This causes EXEPAK to just report the compressed status of all
        the files specified on the command line.  No compression or
        decompression is done.

Comments and warnings:
   - EXEPAK compressed binaries will not work unless they are READABLE
     by the person executing them.  This means that if you are root and
     you want other users to be able to execute compressed binaries on
     the system, be sure to 'chmod a+r' them to give everyone read
     permission!
   - EXEPAK should never be used on system binaries that might get executed
     during bootup before /proc gets mounted.  (Actually it's probably not
     a good idea to use it on system and admin binaries at all.)
   - EXEPAK will probably be useless on files < 32k in size.
   - Don't strip compressed binaries, or strip will probably think the
     appended compressed data is debug code and strip it, leaving you with
     nothing but a 5k decompress stub and no compressed data.
   - Compressed binaries won't work unless there is enough room in /tmp to
     create the temporary decompressed executable.
   - The 'ldd' program won't work on compressed binaries to tell what
     shared libraries they are linked with-- it will only report libc
     since ldd will only be looking at the stub.  Decompress compressed
     binaries to check which libraries they are linked with.
   - Some people have mailed me claiming that deleting a binary immediately
     after executing it somehow negatively impacts Linux's memory
     management.  In my own experience when running compressed and
     uncompressed versions of the same program simultaneously, 'ps -amx'
     reports their memory usage as identical.  If anyone can explain
     whether or not this is true, e-mail me at api@one.net please.
   - There seems to be a bug(s) in some 2.1.xx versions of Linux that
     cause compressed binaries to dump core when executed.  I have not
     investigated this in detail.  It could be a /proc filesystem bug.
     Compressed binaries work fine on Linux 2.0.xx, and if I were you I
     would stay away from 2.1.  I remember the days of 1.1 and 1.3, and
     those weren't too bad.. but 2.1 seems to be notoriously buggy.

EXEPAK is free software and may be distributed or modified freely.  It
comes with ABSOLUTELY NO WARRANTY; use at your own risk. It is released
under the terms of the GNU GPL v2.0 or later. See the license.txt file
for full details.

EXEPAK uses the LZO compression library by Markus F.X.J. Oberhumer.  Go
to: http://www.infosys.tuwien.ac.at/Staff/lux/marco/lzo.html for more info.
