Commit graph

3 commits

Author SHA1 Message Date
Poul-Henning Kamp 4efda9261d Based on the applause (in this case: not downright rejection :-) I have
cleaned up much of the cruft in this thing.

No printf's in the case where things go well.

Gzip-headers can contain filenames and comments (as long as they're
shorter than the page-size.)

I don't think we leak memory, in the "exec/aout" code.  I'm not quite sure
about the inflate code yet, but I don't think memory is lost.

Q:  Can I add a class M_GZIP to <sys/malloc.h> and bump M_LAST one up
without any thing else needing tweaking ?

Poul-Henning
1994-10-04 03:09:13 +00:00
Poul-Henning Kamp 4dd5a68318 First bug-fix. This this depends on something odd. I am looking at it,
but every now and then it will fail without an explanation :-(
1994-10-03 23:14:48 +00:00
Poul-Henning Kamp 37c32e9f3a ***
WARNING:  THIS MATERIAL MIGHT GO AWAY!
This material needs the core-groups approval to stay here for the 2.0 release.
If the core-group does not concent to this commit, it will be backed out.
***

It is a non-gpl'ed "unzip" which will allow execution of a.out files which
have been sent through "gzip -9".  The idea being saved disk-space.

Just now this code has quality rating:  "working prototype".

To compress a file to be used with this, do it exactly this way:

gzip -9 -v < /bin/FOO > /tmp/FOO
remember to chmod /tmp/FOO as needed.

DON'T compress all of you binaries right away !  There are several things
which you should consider first:

1. Using compressed binaries, you use >MUCH< more VM, and thus swap-space.

2. It is slow.

3. It might crash your machine.

Apart from that, I welcome comments...

NB:  There is also a change to sys/conf/files, but cvs core-dumped on me,
so it didn't get into the logs or emailed, but the commit seems to have
happended OK.
1994-10-03 05:23:01 +00:00