Xref: utzoo comp.sources.d:2102 comp.binaries.ibm.pc.d:232
Path: utzoo!attcan!uunet!husc6!bloom-beacon!mit-eddie!uw-beaver!microsoft!danno
From: danno@microsoft.UUCP (Dan Norton)
Newsgroups: comp.sources.d,comp.binaries.ibm.pc.d
Subject: Re: Standard for file transmission
Summary: Some corrections
Keywords: protocol compression source
Message-ID: <1453@microsoft.UUCP>
Date: 12 May 88 17:23:30 GMT
References: <292@cullsj.UUCP> <55@psuhcx.psu.edu> <4740@teddy.UUCP> <145@elgar.UUCP>
Organization: Microsoft, Inc., Redmond, Washington
Lines: 24

In article <145@elgar.UUCP>, ford@elgar.UUCP (Ford Prefect ) writes:
> In article <9644@agate.BERKELEY.EDU> laba-5ac@web7f.berkeley.edu.UUCP (Erik Talvola) writes:
> >What's wrong with getting a 16-bit Compress executable file for the PC...
> 
> There are a few problems with this approach:
> 
> 1)	Such a compiler has to exist for the operating system you are
> 	running...
> 	                                               ... But one of
> 	the articles that was being followed up to mentioned an O.S.
> 	that only supported 64k segments.  Compress just won't work
> 	in such an environment without major redisign (like keeping
> 	the arrays in a disk file :-).

You are wrong.  In fact, such a compress exists, using memory only.
Several people, including myself, have been able to modify the standard
compress with little trouble, and it works just fine on IBM PC's.
.
.
.
.
.
.
.