Path: utzoo!attcan!uunet!husc6!rutgers!att!icus!dasys1!tneff From: tneff@dasys1.UUCP (Tom Neff) Newsgroups: comp.binaries.ibm.pc.d Subject: Re: SIMTEL20 to ban ARC files Keywords: lzw, atob/btoa, 7 bit pure Message-ID: <6583@dasys1.UUCP> Date: 22 Sep 88 13:52:30 GMT References: <6630@ihlpl.ATT.COM> <2736@uoregon.uoregon.edu> <8475@smoke.ARPA> <2594@csccat.UUCP> <424@pigs.UUCP> Reply-To: tneff@dasys1.UUCP (Tom Neff) Organization: Independent Users Guild Lines: 40 In article <424@pigs.UUCP> haugj@pigs.UUCP (John F. Haugh II) writes: >i'd like to see an ARC tool which did NO compression and then have >another tool which did the compression and then yet another for the >decompression. that would yield three small tools, each of which >could be highly specialized. This is somewhat reminscent of the old order-of-operations quandary in the days of LBR and SQ on CP/M and MSDOS. There you had two separate tools, a squeezer and a librarian. There were two headaches. First, people kept LBR'ing *first* and then squeezing (yielding an LQR file), which is the wrong way to do it for two well-defined reasons[1]. Second, it was an unnecessarily complicated business managing archives with so many processing steps and intermediate files. People tried to work up batch files to automate the process, but they were not reliable or portable in general. One of the things ARC (in any form) really brought to the party was unparallelled user convenience -- combining the steps invisibly and selecting an algorithm automatically were godsends. There was a certain size and performance tradeoff but it was well worth it for almost all users. Small, specialized tools are great too of course, which is why Buerg wrote the little ASM one-shot extractors and builders. -------------------------- NOTES [1] Squeezed libraries are much worse than libraries of individually squeezed members because (a) an LQR has no immediately accessible directory structure - it has to be unsqueezed before you can look at it; and (b) dissimilar member files (README, executable, fonts etc) yield a heterogeneous library which responds poorly to most types of compression. -- Tom Neff UUCP: ...!cmcl2!phri!dasys1!tneff "None of your toys CIS: 76556,2536 MCI: TNEFF will function..." GEnie: TOMNEFF BIX: t.neff (no kidding)