Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!watmath!clyde!cuae2!ihnp4!ihuxm!gmd1 From: gmd1@ihuxm.UUCP (Doughty) Newsgroups: net.sources.bugs Subject: Re: Backbone automatic news-compression question ... Message-ID: <1444@ihuxm.UUCP> Date: Fri, 3-Oct-86 19:52:14 EDT Article-I.D.: ihuxm.1444 Posted: Fri Oct 3 19:52:14 1986 Date-Received: Sat, 4-Oct-86 13:00:50 EDT References: <4012@ut-ngp.UUCP> <857@ho95e.UUCP> <212@osi3b2.UUCP> Organization: AT&T Bell Labs, Naperville, IL Lines: 51 > 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