Message-ID: <19980325155846.17376@freebie.lemis.com>
Date: Wed, 25 Mar 1998 15:58:46 +1030
From: Greg Lehey <grog@lemis.com>
To: "Steven M. Schultz" <sms@moe.2bsd.com>, pups@minnie.cs.adfa.oz.au
Subject: Re: More on Disk Images -> Disk
References: <199803250506.VAA16340@moe.2bsd.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
In-Reply-To: <199803250506.VAA16340@moe.2bsd.com>; from Steven M. Schultz on Tue, Mar 24, 1998 at 09:06:26PM -0800
WWW-Home-Page: http://www.lemis.com/~grog
Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia
Phone: +61-8-8388-8286
Fax: +61-8-8388-8725
Mobile: +61-41-739-7062
Sender: owner-pups@minnie.cs.adfa.oz.au
Precedence: bulk

On Tue, 24 March 1998 at 21:06:26 -0800, Steven M. Schultz wrote:
> Greg -
>
>> I've done a little bit of playing around with gzip 1.2.4.  It works on
>
> 	Are gzip and gunzip comparable in size? 

They're links to the same executable.

>       I'm curious if the
> 	decompression is more 'address space' hungry than the act of
> 	compression (or vice-versa).

I haven't looked at the process images on systems on which they run.
I suspect it wouldn't relate directly to 16 bit platforms anyway,
since they have a slightly modified algorithm.

>> 16 bit MS-DOS platforms with a bit of  tweaking, and I got all modules
>> to compile under 2.11BSD.  Unfortunately, I ended up  with a couple of
>> undefined references on linking, and I haven't had time  to look at it
>
> 	Which symbols came up missing/undefined?

Various things defined in the program.  They relate to the area in
which I was tweaking.

>>> If we can get gunzip running in 64K on V7, I can then move it to a
>>
>> Should be doable.
>
> 	It's actually 56kb or less - have to leave room for the stack and
> 	other data (strings, etc)

Yes, I understand.  It may of course be that we need separate I and D.

Greg