	ZLIBC -	Uncompressing C Library (For Linux and SunOs)

				by

			Alain Knaff, 1993


 Zlibc is a library patch that allows executables to uncompress the
datafiles that they need on the fly. No kernel patch, no recompilation
of these executables and no recompilation of the libraries is needed.

 This package patches the "open" function (and other system call
functions) in the shared library. You don't need to have sources to
the shared library, as the binary is patched directly.

 On Linux, this package should work with every .4 shared library
(tested on 4.3.3, 4.4, 4.4.1, 4.4.4). This is because it patches the
jumptable, and the jumptable should remain constant for the same major
release number (4) of the shared library.

 On SunOs, this package uses the LD_PRELOAD/LD_LIBRARY_PATH mechanism
to redirect the dynamic linker to use the relevant functions out of
uncompress.o instead of the shared library. Thus, it should work with
every release of the shared library (tested on ). On SunOs, you don't
need to be superuser to install this package. (* Resisting hardly to
make the obvious puns *)

How it works:
=============

 Usually, programs don't make system calls directly, but instead call
a function which does them. To open a file, first the "open" function
is called, and then this function makes the actual syscall.  This
package patches the "open" function and other related functions.

 With the zlibc, if the "open" system call fails, the "open" function
now tries to open a file with .gz appended to its name. If such a file
is found, it is piped trough gunzip, and the descriptor of the read
end of the pipe is returned to the caller.
 For certain extensions, the .gz file is first uncompressed into a
temporary file, and a read descriptor for this file is returned to the
caller. This is necessary if the caller wants to call lseek on the
descriptor, or mmap it. A description of data files for which this is
necessary can be given in the configuration files /usr/lib/zlibrc and
~/.zlibrc. There are also some compiled-in defaults, which are in the
file config.c.

 With the zlibc, if the "open" system call fails because the file
doesn't exist, the "open" function constructs the filename of a
compressed file by appending .gz to the filename supplied by the user
program. If this compressed file exists, it is opened and piped trough
gunzip(1), and the descriptor of the read end of this pipe is returned
to the caller.
 For certain extensions, the .gz file is first uncompressed into a
temporary file, and a read descriptor for this file is passed to the
caller. This is necessary if the caller wants to call lseek on the
descriptor or mmap it. A description of data files for which this is
necessary can be given in the configuration files /usr/lib/zlibrc and
~/.zlibrc. See zlibrc(5) for a detailed description of the syntax of
these configuration files.


Further Documentation:
======================

 There is a description of the installation is in the files
INSTALL.linux and INSTALL.sun .

 The manpage zlibc.so.2 describes the general operation of the zlibc.

 The manpage zlibrc.5 describes how to use the runtime configuration
of the zlibc. There is also a sample configuration file called
zlibrc.sample. The compiled-in defaults are fairly complete, so
normally you don't need to use the run-time compilation. (The
zlibrc.sample file reflects roughly the compiled-in defaults.)

 The file CAVEATS describes the limitations of this package.

 The file BUGS describes the bugs of this package.

 The configure script (compile-time configuration) is self
explaining. It is run automatically by make when the file config.h
doesn't exist yet.

 The file config.c contains comments on how to edit it. It should
however not be necessary to edit this file, as the same things which
can be achieved by editing this file can also be achieved by the
runtime configuration (see zlibrc.5).

 Bugs:
 =====
 1. Unlike with tcx, there is no cache for uncompressed files. Each client
    must uncompress its own copy. Fortunately, most files are only used once
    during the life of a program, and only by that program.


 Have fun,

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Alain L. Knaff						Alain.Knaff@imag.fr
   
