Xref: utzoo comp.sources.d:2033 comp.binaries.ibm.pc.d:127
Path: utzoo!mnetor!uunet!lll-winken!lll-tis!ames!pasteur!ucbvax!agate!violet.berkeley.edu!ephram
From: ephram@violet.berkeley.edu
Newsgroups: comp.sources.d,comp.binaries.ibm.pc.d
Subject: Re: Standard for file transmission
Message-ID: <9653@agate.BERKELEY.EDU>
Date: 6 May 88 04:34:35 GMT
References: <292@cullsj.UUCP> <55@psuhcx.psu.edu> <4740@teddy.UUCP> <1082@maynard.BSW.COM>
Sender: usenet@agate.BERKELEY.EDU
Reply-To: ephram@violet.berkeley.edu.UUCP ()
Organization: University of California, Berkeley
Lines: 26
Keywords: protocol compression source

In article <1082@maynard.BSW.COM> campbell@maynard.UUCP (Larry Campbell) writes:
>In article <4740@teddy.UUCP> jpn@teddy.UUCP (John P. Nelson) writes:
><>>Just one thing that needs to be known -- PC's can do no more than 12-bit
><>>compression.  So if you are compressing your file from a UNIX system,
><>>you need to say comress -b12 filename .
><>
><>This myth has been repeated several times, so I felt it was necessary to
><>speak up.  PCs most certainly CAN do a 16 bit compress/uncompress.  ...
>
>Only a subset of PCs can do 16-bit compress/uncompress.  

Hasn't anyone ever heard of a disk drive?!?  multiple segments as a limitation?
How about writing temporary results to a disk file (random access)? RAM disk?

Now I must admitt I have never cracked open the code to compress/uncompress,
but it seems to me that using a disk drive as an intermediate result area is
a very viable work around.  I would rather sit and watch my disk spin for an
extra minute than watch the RD light on my modem work 10% more time.

I admit it is not elegant but when some one says "can not do" I must speak
up.




Ephram Cohen
ephram@violet.berkeley.edu