Xref: utzoo comp.sys.amiga:38080 comp.sys.amiga.tech:6543
Path: utzoo!utgpu!watmath!att!pacbell!ames!bionet!csd4.milw.wisc.edu!uxc.cso.uiuc.edu!tank!eecae!netnews.upenn.edu!grad2.cis.upenn.edu!ranjit
From: ranjit@grad2.cis.upenn.edu (Ranjit Bhatnagar)
Newsgroups: comp.sys.amiga,comp.sys.amiga.tech
Subject: Re: Saving Disk Space (was Re: Relying on ARP)
Summary: Do crunchers interact with Resident facility?
Message-ID: <13549@netnews.upenn.edu>
Date: 8 Aug 89 05:46:52 GMT
References: <12878@well.UUCP> <26758@agate.BERKELEY.EDU> <934@corpane.UUCP> <796@medsys.UUCP>
Sender: news@netnews.upenn.edu
Reply-To: ranjit@grad2.cis.upenn.edu.UUCP (Ranjit Bhatnagar)
Organization: University of Pennsylvania
Lines: 23

I'm curious about the interaction of these 'cruncher' programs
with the Resident facility.  It seems reasonable that a cruncher,
in order to reduce the disk space taken up by a program, compresses
that program and then prepends a loader-uncruncher.  Thus when you
invoke the crunched version of emacs, for instance, it actually loads
the uncruncher, which then loads and uncrunches the rest of emacs.
The overhead of the uncruncher is made up for by the space saved.

If this is the case, then if you make emacs Resident, what will be
made resident is not emacs itself, but the uncruncher and the crunched
data file.  When you subsequently run the resident emacs, rather than
running emacs directly from the preloaded image, it will uncrunch
the datafile again into newly allocated memory - thus losing the memory
advantages of resident programs.

On the other hand, the cruncher could patch the operating system
so that the uncrunching process is transparent to the resident facility.

	-ranjit


"Trespassers w"   ranjit@eniac.seas.upenn.edu	mailrus!eecae!netnews!eniac!...
	   "Such a brute that even his shadow breaks things." (Lorca)