Date : Thu, 20 Oct 1988 01:15:57 GMT
From : portal!cup.portal.com!@uunet.uu.net (Robert A Freed)
Subject: GSARC - non-compatible more efficient archiver
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
Date: Saturday, 22 October 1988 20:35-MDT
From: olmiller@ludwig.scc.com (Otto Miller)
Subject: Kermit-80 for a Xerox 16/8
A little background info... I am posting this request to both
info-kermit and info-cpm since I am not sure where my problem is.
I have installed several variations of unix c-kermit and now I am
ting to install cpm-80 kermit.
The specifics; I am using a Xerox 16/8 (5.25" floppy + HD). Since
the hart of the 16/8 is a Xerox 820 (like) board I used the sys-dep.
overlay for the Xerox 820 (cpvxer.hex) with the sys-indep. (cpsker.hex)
hex file to generate the .com file. All went well up to this point.
The problem appears when I connect... I get nothing out the serial
port! I looked at the source to see if port B was used, but everything
points to port A. I have been unable to hang a protocol analyzer
to confirm no output, but when I hang a known good modem on the port
I get nothing... not even garbage. WHAT's WRONG?
Any and all help, pointers, etc. with constructive flames are solicited.
PLEASE email directly to me in that I am not on regular distribution
for this group; Thanks. Thank you in advance for all the help.
=======================
#include std_disclaim.h In real(?) life: Otto L. Miller
Contel FSS/ASD
email olmiller@ludwig.scc.com Fairfax, VA 22033
703-359-7500