From:	sandmann AT clio DOT rice DOT edu (Charles Sandmann)
Message-Id:	<10210131934.AA24418@clio.rice.edu>
Subject:	Re: CLIO 2.04 exe to use UPX in the next update
To:	djgpp-workers AT delorie DOT com
Date:	Sun, 13 Oct 2002 14:34:10 -0500 (CDT)
In-Reply-To:	<3DA96BA4.9C2DC642@yahoo.com> from "CBFalconer" at Oct 13, 2002 08:48:36 AM
X-Mailer:	ELM [version 2.5 PL2]
Mime-Version:	1.0
Reply-To:	djgpp-workers AT delorie DOT com
Errors-To:	nobody AT delorie DOT com
X-Mailing-List:	djgpp-workers AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

> On general principles I would discourage it.  I don't think the
> results can hold accessible debugging info, and the practice makes
> it harder to check that the build has been duplicated by a binary
> compare of the end product.  This latter is why I object to any
> system that dumps uninitialized areas into binary files for any
> reason.

It doesn't hold debug information, true.  If we see crashes we can't 
easily symify the results.  But at this point I like the idea of trying
out UPX on a wide scale during the alpha and beta periods before we
do the release.  Hopefully we are beyond the crashes stage.

We have released some distributions in the past with UPX with no problems.
Many tests have show the load times to be equivalent/faster (the 
decompression is around 5 times slower than a memory copy; which is 
much, much faster than reading the extra stuff from disk).  The smaller
images really improve the efficiency of a disk cache.

> I don't know if such a binary compare is feasible under the
> present system.  

UPX has tools that allow you to decompress the images if you want to
for comparison/debugging.

> I always like the warm fuzzy that accompanies
> KNOWING that one has a controlled starting point, including tools
> and libraries.  It eliminates a lot of guessing when Murphy
> strikes.

Since the tools are freely available to decompress the image, you 
should be able to perform whatever diagnosis you want.

- Raw text -