🚀 go-pugleaf

> In article <857@ho95e.UUCP>, wcs@ho95e.UUCP (#Bill_Stewart) writes:
> > ...
> > compress.  Two comments: for PC programs, the most popular compression
> > seems to be ARC, which is shareware.  Compress is PD, its behavior
> > is better known, and source is available from mod.sources; is there
> > any reason to prefer ARC?  Also, the "btoa" program that comes with ...
> 
> Until recently ARC underwent constant revisions that were incompatible with
> each other.  To the best of my knowledge no new versions have shown up in the
> last few months (aside from some Trojan Horses).  A major problem with ARC
> is that the program isn't available in a completely portable C version yet.
> I acquired the pseudo-C source for the MS-DOS with the dreams of porting it
> to portable C, but quit after realizing how much was involved.  The compiler
> it uses uses a totally incompatible preprocessor, and the program has many
> byte-ordering dependancies and size assumptions.  It also places fast and loose
> with memory allocation.  Given the fact that revisions have come out so
> frequently in the past I would hope no one would use it to post a large
> source or anything, because it could prove difficult for the PC owners to
> extract the data from it, much less owners of any other machines.
> -- 
> James R. Van Artsdalen    ...!ut-ngp!utastro!osi3b2!james    Live Free or Die

Actually the PC owners have the least problem.  ARC is available in executable
form for PCs from many BBS systems.  I have had no problem with ARC files from
USENET (except when the articles suffered some sort of damage in transmission).
Someone posted a version of ARC for Berkeley UNIX last summer where they had
determined the meaning of the funny '$emit' macros and removed them (sub-
stituting the correct C code in its place where needed).  I have taken that
source and made it work on UNIX SysV without too much trouble (I have since
found some bugs which I will fix Real Soon Now).  Unfortunately I deleted the
original posting or I would post a set of diffs (posting the whole thing
seems a bit excessive until I assure myself I've found the "next-to-the-
last bug"... I'm getting a little more realistic in my old age).  With regard
to non-PC systems, I believe that someone has been developing a group of
functions that each perform 1 of ARC's functions on CPM systems (ARC won't
fit as a whole).  I think I've even seen an ARC for the Amiga on a BBS in
Florida.

With regard to the incompatible versions, the biggest problem was that the
authors would add a new compression method which older version could of
course not handle.  This led to a scramble to find a BBS with the newest
revision.  Unfortunately it's hard to avoid this and still want to see
new and more efficient compression schemes incorporated.

I assume the reason ARC is used is that it provides a CRC on each ARC
entry.  This can detect many cases of files corrupted over the net.
Perhaps if the uuencode-uudecode and/or shar formats were augmented to
provide the same level of checking (or better), the ARC formatted files
would disappear.

Greg Doughty   ihnp4!ihuxm!gmd1