Path: utzoo!attcan!uunet!samsung!sdd.hp.com!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!midway!mimsy!jds
From: jds@mimsy.umd.edu (James da Silva)
Newsgroups: comp.os.minix
Subject: Re: compress (2nd)
Message-ID: <26757@mimsy.umd.edu>
Date: 28 Sep 90 16:20:18 GMT
References: <31676@nigel.ee.udel.edu>
Reply-To: jds@cs.umd.edu (James da Silva)
Organization: University of Maryland, Department of Computer Science
Lines: 26

In article <31676@nigel.ee.udel.edu> michael@sunham.germany.sun.com 
(Michael Joswig (Vertriebsunterstuetzung Hamburg)) writes:
>
>Jaime (jds@cs.umd.edu) asked
>>Are you CERTAIN that this version of compress you mention will uncompress
>>16bit-compressed files under normal PC Minix?  You aren't talking about DOS
>>or 32-bit Minix?
>>
>>If so, please do let us know where you got it.  Such a beast would be quite
>>a feat of bit-bumming: the normal compress wants more than 400k of data
>>space to do 16bit compress/uncompress.
>
>Well, I use this compress on my Atari ST and it seems to work fine. There
>is an option "-b n", where n means the maximal bit-number and ranges up
>to 16. 

Ah, that explains it.  The original person you "corrected" was running on
IBM-PC Minix, which *does* have a 64k data space restriction, and *cannot*
do 16-bit compression.  So your correction was not correct.  

The fact that Atari-ST Minix is capable of 16-bit compression is not
surprising.  The stock off-the-net compress program should compile and run
fine under ST Minix.  At least, it compiles and runs fine under Bruce's
compiler on 32-bit 386 Minix.

Jaime