james@osi3b2.UUCP (James R. Van Artsdalen) (09/25/86)
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
gmd1@ihuxm.UUCP (Doughty) (10/04/86)
> 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