W8SDZ@SIMTEL20.ARMY.MIL (Keith Petersen) (10/16/88)
Just uploaded to SIMTEL20...
Filename Type Bytes CRC
Directory PD1:<MSDOS.ARC-LBR>
GSARC10.EXE.1 BINARY 71680 85D2H
GSARC10.INF.1 ASCII 4338 CBCBH
This is an interesting development. A new program that makes and
extracts ARC files using a more efficient variation on LZW compression,
called "Crushing". I have included the .INF file below. Beware - the
ARCs it produces cannot be read by ARC, ARCE or PKUNPAK unless GSARC's
compatibility switch is used. The program does work, and it does
produce *signficantly* smaller ARC files.
The information below is presented "as-is". I have no connection with
NoGate Consulting and this posting should not be interpreted as an
endorsement of yet another incompatible ARC-maker. However, it does
pose an interesting question: are we to resist this just because it's
incompatible - even though it is a significant step forward in
compression efficiency? It will be interesting to see what SEA's
reaction will be.
--Keith Petersen
Maintainer of the CP/M and MSDOS archives at SIMTEL20.ARMY.MIL [26.0.0.74]
Arpa: W8SDZ@SIMTEL20.ARMY.MIL
Uucp: {ames,decwrl,harvard,rutgers,ucbvax,uunet}!simtel20.army.mil!w8sdz
-------
[GSARC10.INF]
GSARC by NoGate Consulting
GSARC is a utility to create and maintain file archives in compressed form.
It is intended as a replacement for ARC by System Enhancement Associates
and PKARC by Philip Katz. While GSARC is roughly 2.5 times as fast as ARC,
speed is not the emphasis, and GSARC does not attempt to compete with PKARC
in this respect. However, GSARC produces archive files that are consistently
50% to 90% of the size produced by either ARC or PKARC, and supports files
created by either program. In particular, GSARC handles large text files and
non-text files of any length much better than the either of these programs.
In addition, the full screen version is much easier to use than ARC or PKARC.
ARC popularized the LZW method of compression, which substitutes 9 to 12
bit codes for strings of characters which occur more than once in a file.
PKARC made a very simple modification to the compression algorithm in ARC,
by allowing codes of up to 13 bits, and hence doubled the number of allowable
codes. PKARC owes some of its popularity over ARC to this, but its primary
advantage is speed.
GSARC, on the other hand, makes some radical changes to the LZW method.
GSARC increases the range from 2 to 13 bits instead of 9 to 13, dynamically
alters the compression method based on the local nature of the data, and
drops only the least used codes when the code table fills, instead of all
of them as ARC and PKARC do. As a result, GSARC performs much better on
very large files, very small files, and on difficult files (such as .EXE
and .COM files) of any length.
There are 7 compression types, created variously by ARC, PKARC, and GSARC.
GSARC can extract files compressed with any of these, and compress new files
with the Crunched, Squashed, or Crushed types.
-- No compression. Used by ARC, PKARC, GSARC.
Packed Repeated byte values replaced by codes. Used by ARC.
Squeezed Huffman encoding, used by ARC 5.20 and earlier.
crunched Lempel-Zev compression, used by ARC 4.5 and earlier.
Crunched Lempel-Zev compression, used by ARC 5.0 and later.
Squashed Lempel-Zev compression, used by PKARC.
Crushed Lempel-Zev compression, used only by GSARC.
GSARC uses the CRC checksum to verify that the file is intact.
GSARC Command Summary
a = add files to archive
m = move files to archive
u = update files in archive
f = freshen files in archive
d = delete files from archive
e = extract files from archive
x = extract and remove files from archive
l = list files in archive
v = verbose listing of files in archive
t = test files in archive
c = convert files to new packing method
Modifiers:
c = make ARC compatible files.
s = make PKARC compatible files.
g = encrypt the file with a password.
The C command extracts files from the archive and recompresses them. This
is primarily of use to convert older archives created with ARC and PKARC to
the better compression techniques used by GSARC. It is also possible to
convert files created with GSARC so that they will be compatible with ARC
or PKARC, by adding the C or S compression type modifier.
GSARC is distributed as shareware. There are three versions of the
compression routines in GSARC available.
The first is the command line version, included in the evaluation package
distributed as shareware. Registration of this version entitles you to a
disk with a copy of GSARC registered in your name (which is displayed only
if you type GSARC without any parameters).
The second is the full screen version, which displays archive contents and
file directories, and allows easy tagging of files to be compressed or
extracted. Registration of this version entitles you to a disk with both
the full screen and command line versions.
This third, for programmers, is a library of data compression routines
suitable for inclusion in your own programs. Registration of this version
entitles you to a disk with files suitable for use with Turbo Pascal, C, or
assembler, and the other two versions of GSARC.
NoGate Consulting
P.O. Box 88115
Grand Rapids, MI 49518W8SDZ@SIMTEL20.ARMY.MIL (Keith Petersen) (10/19/88)
As I said in my original posting, I do not endorse the GSARC program, but it does bring up some interesting questions. The mailing address of the author is included in the original posting and in the extracted DOC file. If you have concerns about it being incompatible why not express them to the author in a letter? The significant thing, in my opinion, is that a major breakthrough has been made in compression efficiency. Must everyone be forever locked into less efficient algorithms just because the older programs can't read the new format? If that were true, everyone would still be using SEA's original version of ARC, which cannot read files created by SEA's own ARC5xx. --Keith
zgel05@apctrc.UUCP (George E. Lehmann) (10/20/88)
In article <KPETERSEN.12439280069.BABYL@SIMTEL20.ARMY.MIL> W8SDZ@SIMTEL20.ARMY.MIL (Keith Petersen) writes: >Just uploaded to SIMTEL20... >GSARC10.EXE.1 BINARY 71680 85D2H >GSARC10.INF.1 ASCII 4338 CBCBH I tried e-mail but it bounced, and I haven't seen anybody else request it yet, sooooo... Could you either e-mail or post this guy so we can try it out? Thanks. -- George Lehmann, ...!uunet!apctrc!zgel05 Amoco Production Co., PO BOX 3385, Tulsa, Ok 74102 ph:918-660-4066 Standard Disclaimer: Contents are my responsibility, not AMOCO's.
cpt.k9@netmbx.UUCP (Bob George) (10/20/88)
PLEASE let's not start considering the use of YET ANOTHER standard. A very usable, efficient, widely available, and well supported standard now exists in the form of FREEZOO. We should expend our energy supporting this product rather than one which is VERY likely to suffer the same fate as PK*. (For details on FREEZOO, I refer you to RDhesi's article posted in this group) Bob -- Bob George, Unter den Eichen 97, 1000 Berlin 45, W. Germany cpt.k9@netmbx.UUCP Tel: (049-030) 832-8319
raf@cup.portal.com (Robert A Freed) (10/20/88)
In article <KPETERSEN.12439280069.BABYL@SIMTEL20.ARMY.MIL>, W8SDZ@SIMTEL20.ARMY.MIL (Keith Petersen) writes about the new MS-DOS program, GSARC, by NoGate Consulting: > This is an interesting development. A new program that makes and > extracts ARC files using a more efficient variation on LZW compression, > called "Crushing". I have included the .INF file below. Beware - the > ARCs it produces cannot be read by ARC, ARCE or PKUNPAK unless GSARC's > compatibility switch is used. The program does work, and it does > produce *signficantly* smaller ARC files. I have examined the output of this program, and it is impressive. "Crushing" consistently generates smaller files than either "Crunching" or "Squashing". And it does this without resorting to memory-hungry brute force methods (such as LZW compression with 16-bit codes, as used by the UNIX public domain COMPRESS program.) > The information below is presented "as-is". I have no connection with > NoGate Consulting and this posting should not be interpreted as an > endorsement of yet another incompatible ARC-maker. However, it does > pose an interesting question: are we to resist this just because it's > incompatible - even though it is a significant step forward in > compression efficiency? ^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^ Please consider this carefully, people! Most of the recent discussion pertaining to compressing archivers, such as ARC, PKPAK (nee PKARC), ZOO, DWC, and now GSARC (to name just a few :-)), has related to the issue of portability. While that is understandably of great concern to many USENET readers, it should not be overlooked that *compression efficiency* is the primary reason for the existence and popularity of these programs. Some of us, who have actively researched LZW and other data compression techniques, have known that further improvement of current methods is technologically feasible. I predict that this "Crushing" variation is not even the ultimate we are likely to see in the near future. Legal, moral, and philosophical concerns aside, I urge continued support for such advancements in the state of the art. In this spirit, I have begun making the necessary modifications to my CP/M archive extraction program, UNARC, to handle .ARC files generated by GSARC10. (Just as I did almost two years ago, when Phil Katz' PKARC20 introduced an improved compression method to .ARC files.) Bob Freed Internet: raf@cup.portal.com Newton Centre, MA UUCP: ...!sun!portal!cup!raf
ray@micomvax.UUCP (Ray Dunn) (10/21/88)
> [GSARC] ....are we to resist this just because it's >incompatible - even though it is a significant step forward in >compression efficiency? [There should be a smiley variation available which depicts rolling all over the top of desk in helpless mirth] To answer the question - yes, unless you want to perpetuate the state of non-standardisation. Standardization is invariably about just this - making do with something which might not be 100% ideal, but which is a *standard*, and is widely available. > ....It will be interesting to see what SEA's >reaction will be. Indeed. Anyone continuing to try to protect a commercial interest in something as relatively trivial as archiving software will have their work cut out in the long term, particularly when *none* of the components are "secret" or unpublished. They cannot be faulted for trying, however. Any inability to resist each improvement will also keep the whole situation in a continuous state of flux. -- Ray Dunn. | UUCP: ..!philabs!micomvax!ray Philips Electronics Ltd. | TEL : (514) 744-8200 Ext: 2347 600 Dr Frederik Philips Blvd | FAX : (514) 744-6455 St Laurent. Quebec. H4M 2S9 | TLX : 05-824090
davejag@wybbs.UUCP (Dave Jaglowski) (10/21/88)
Another version of GSARC was introduced by the author to eliminate the potential for a SEA lawsuit. It is called PAK10 and is availible on The DataBoard - (616)-897-6470.
spolsky-joel@CS.YALE.EDU (Joel Spolsky) (10/21/88)
Hi folks! I've been playing with GSARC for a couple of days and I really like it. Compression (with Crushing) is always better than PKPAK or ARC, although not by a whole lot in most cases (5-10%). It can read PKPAK and ARC archives happily and can *easily* repack old archives using the new compression technique. Also, there is a command line option to create files that can be extracted by ARC or PKPAK. So you really _can_ throw away your old archiver and still be able to create archives other people can extract. My only (small) gripe is that it crashes ungracefully if the disk you are compressing on fills up, leaving untidy .$$$ files about. This happened to me a few times (on floppies); nothing was lost. This is available from simtel20.arpa, and I just (tried) to post it to comp.binaries.ibm.pc, it should show up soon. No relation, just a satisfied user...x +----------------+---------------------------------------------------+ | Joel Spolsky | bitnet: spolsky@yalecs uucp: ...!yale!spolsky | | | arpa: spolsky@yale.edu voicenet: 203-436-1483 | +----------------+---------------------------------------------------+ #include <disclaimer.h>
jsilva@cogsci.berkeley.edu (John Silva) (10/21/88)
After downloading GSARC from simtel20, I ran my own tests comparing GSARC
to PK 3.61. I timed both on compression of 1.1MB of text files, and 1.6MB
of binaries (my bin directory).
I didn't write the figures down, but I remember that the text archiving
took about 1.1 minutes under GSARC, and only 30 seconds under PK. The
filesize savings was about 25K. (275K for GS, 300 for PK).
For the binaries, I don't recall the times offhand (the ratio was somewhat
better than with the text, however), but the disk space saved was only about
50K compared to PK.
GSARC may represent a breakthrough in compression, but for my needs PK's
phenomenal speed far outweighs GSARC's less impressive increases in
compression efficiency.
-J.
---
John P. Silva
INTERNET : jsilva@cogsci.berkeley.edu "You don't know what you're
UUCP : {backbone}!ucbvax!cogsci!jsilva getting into, friend..."d-swallow@cup.portal.com (Douglas C Swallow) (10/23/88)
> Another version of GSARC was introduced by the author to eliminate the > potential for a SEA lawsuit. It is called PAK10 and is availible on > The DataBoard - (616)-897-6470. I doubt they have made enough changes to the program to keep SEA from attempting to block this program. NoGate (the authors) still use "ARC" as a verb, which is one of the major items SEA objects to with PKWARE. Additionally, it can create .ARC files incompatible with their ".ARC" defined format. I suspect they will try something, and calling it PAK10 won't stop them. However, I wish NoGate well. SEA deserves what they are facing. --Doug Swallow. (d-swallow@cup.portal.com)
twb@hoqax.UUCP (T.W. Beattie) (10/24/88)
In article <1546@netmbx.UUCP> cpt.k9@netmbx.UUCP (Bob George) writes: > >PLEASE let's not start considering the use of YET ANOTHER standard. A very >usable, efficient, widely available, and well supported standard now exists ^^^^^^ ^^^^^^^^^ ^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^ >in the form of FREEZOO. Is this a joke !? Why? Let's keep using PK361. Why not?
pjh@mccc.UUCP (Pete Holsberg) (10/26/88)
In article <1910@hoqax.UUCP> twb@hoqax.UUCP (T.W. Beattie) writes: ...In article <1546@netmbx.UUCP> cpt.k9@netmbx.UUCP (Bob George) writes: ...> ...>PLEASE let's not start considering the use of YET ANOTHER standard. A very ...>usable, efficient, widely available, and well supported standard now exists ... ^^^^^^ ^^^^^^^^^ ^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^ ...>in the form of FREEZOO. ... ...Is this a joke !? Must be! Rahul Dhesi told me that he would start on FREEZOO in a couple of weeks!! -- Pete Holsberg UUCP: {...!rutgers!}princeton!mccc!pjh Mercer College CompuServe: 70240,334 1200 Old Trenton Road GEnie: PJHOLSBERG Trenton, NJ 08690 Voice: 1-609-586-4800
wfp@dasys1.UUCP (William Phillips) (10/26/88)
In article <10356@cup.portal.com> d-swallow@cup.portal.com (Douglas C Swallow) writes: >I doubt they have made enough changes to the program to keep SEA from >attempting to block this program. NoGate (the authors) still use "ARC" >as a verb, which is one of the major items SEA objects to with PKWARE. Interesting. I stopped reading the ARCWARS postings after a while, and didn't know about this business of using ARC as a verb, etc. It is my understanding that a trademark _must_ be an _adjective_. Thus, technically Coca Cola should always (ha) be referred to as "Coca Cola Soft Drink" or the like. But then I'm not a lawyer (thank ghawd). -- William Phillips {allegra,philabs,cmcl2}!phri\ Acting Co-administrator {bellcore,cmcl2}!cucard!dasys1!wfp BEC Public Excess Unix New York, NY, USA !!! JUST SAY "NO" TO OS/2 !!!
driesb@neabbs.UUCP (DRIES BESSELS) (10/27/88)
At Last, I fully agree with this. Why should we change to something else when pk361 works perfectly? BCNU Dries Bessels Amsterdam,Holland