Subject: PKARC, The REAL story.
Date: 22 Jul 87 03:50:22 GMT
Organization: U of Wi-Milw, College of Engineering
What is this article?
It's an response from me, Phil Katz, author of PKARC and
PKXARC, in an attempt to answer common questions,
misconceptions, and downright ugly rumours propogated by the
misinformed in regards to PKARC and PKXARC.
The specs for Squashing were never released.
FALSE! In early Januaury 1987, shortly after PKARC 2.0 with
Squashing was released, the file SQSHINFO.DOC was released
detailing the format of Squashed files. This file can be
found on many BBS's across the country.
Why wasn't a different extension used for archives with
Squashed files?
Mainly, because using a different extension would cause many
more problems than it would solve. By the time PKARC 2.0
was being developed, there were many programs with .ARC
specific code in them, such as disk cataloguers, directory
programs, communications software, BBS software, and others
that treated .ARC files special from ordinary files. The
vast majority of these programs never extracted files, and
couldn't care less if files were "Squashed", "Stomped", or
"Mashed". Changing the extension of archives created by
PKARC would mean that all these programs would have to be
kludged for the new extension.
Earlier versions of PKARC could handle archives with
Squashed members with no problems whatsoever. Earlier
versions of PKXARC would simply skip over any Squashed
files, and issue a warning that the file was compressed in
an unkown way. Only SEA's ARC program and Buerg's programs
would bomb out completely on these files.
Since PKARC and PKXARC could read *ALL* archives made by
*ANY* archive program back to SEA's ARC 1.00, keeping the
extension of .ARC creates much less confusion than creating
an entirely new extension for everyone to have to deal with.
Why was type 9 used for Squashed files, rather than type 8
with a 13-bit identifier?
Type 8 "crunched" files are non-repeat packed (DLE encoded)
before the file is crunched, and similarily are non-repeat
unpacked after the file is uncrunched.
When developing Squashing, I found that on the vast majority
of files, that slightly higher compression ratios could be
achieved by *NOT* performing the non-repeat packing/unpacking.
Also, a significant amount of execution time could be saved if
it wasn't necessary to do the packing and unpacking.
If Squashed files, which were NOT packed, were stored as
type 8 in the archive header with a 13 bit identifier, it
would be inconsistent with the type 8 12-bit files, which
were packed. Therefore, it was necessary to give Squashed
files a unique file type number.
PKARC has problems with memory allocation.
Well, PKARC 2.0 had problems when a large DOS environment
was present. It would abort with the message "Insufficient
memory". The Lattice C startup module copies the
environment strings into the static 64K data segment before
calling _main(). Since PKARC 2.0 had already used up nearly
all of the static data segment with tables and buffers etc.,
the startup module would abort if it couldn't allocate
enough heap space in the data segment to hold a copy of the
environment.
Note that all error messages displayed by PKARC start with
the phrase "PKARC: " whereas this one didn't, and was
generated by the Lattice library routines. In addition,
there is not *ANY* documentation in the Lattice C manuals
that the startup module copied the environment strings into
the data segment when using the small memory model. I found
this out by tracing the execution of the startup module.
This problem has been resolved in PKARC version 3.5.
PKXARC crashes on damaged archives.
Not anymore. Admittedly, earlier versions of PKXARC would
lock up, crash, burn, cause floods and other major natural
disasters when a damaged or corrupted archive was
encountered.
However, PKXARC 3.5 is *UNCRASHABLE*! PKXARC 3.5 has loop
checks and other fault tolerant reliability mechanisms built
in to it. To date, there have been *NO* verifiable reports
of PKXARC 3.5 ever crashing. If anyone can make PKXARC 3.5
crash, please inform me ASAP.
PKARC and PKXARC have trouble with RAMdisks, EMS memory etc.
NO! PKARC and PKXARC are completely MS-DOS generic
programs. They will run on TI Pro's, DEC Rainbows and all
MS-DOS machines. All I/O is done through standard MS-DOS
file handle calls. All memory allocation is done through
standard MS-DOS memory allocation calls. Neither PKARC nor
PKXARC make any BIOS calls, or directly manipulate any
hardware. If there are any incompatibilies with memory or
device drivers, it is because they fail to execute legal
MS-DOS calls, or otherwise affect the normal operation of
MS-DOS. To date, I have not received any verifiable reports
of any problems with RAMdisks or EMS memory.
The -g option of PKARC is not compatible with SEA's -g option.
FALSE! The encrypt/decrypt functions added to PKARC and
PKXARC version 3.5 were designed to be totally compatible
with SEA's (rather primitive) encryption algorithm. Any
instances where PKARC creates a non-degarbleable file with
SEA's ARC should be considered to be either a bug in PKARC
or ARC. Again, if anyone knows of any instances where the
-g option of PKARC and ARC work differently, please let me
know ASAP.
What ARE the known problems with PKARC and/or PKXARC version 3.5?
There are two known bugs in PKARC version 3.5 dealing with
temporary files.
Under DOS 2.x, PKARC by default will try to create a file
called "./$PKARC.CRN". This works in every subdirectory,
except the root directory in DOS 2.xx. If you try to open
this file in root directory under DOS 3.xx however, it works
just fine. When archiving a large file or using the archive
comment feature of PKARC while in the root directory in DOS
2.xx, PKARC will abort with the message "PKARC: Can't create
./$PKARC.CRN".
This problem can be solved by using the PKARCTMP environment
variable to tell PKARC what drive/directory to use for
temporary files, such as SET PKARCTMP=/ for example.
Alternatively, PKARC can be patched to eliminate the bug as
follows:
debug pkarc.com
e 4aa8 2f 0
w
q
Under DOS 3.xx, after archiving many large files, PKARC may
abort with a "Can't create" error, and the file name given
will be different each time. This is due to an error in the
Lattice C ver 3.1 manual for the dunique() function. In the
Lattice C ver 3.1 manual on page F-65 it says:
"Note that dunique does not actually open the file, so
the return value on success is not a file handle."
WRONG! dunique() calls MS-DOS function 0x5A, which sure as
anything opens the file for read/write access and returns a
file handle!
The result is that PKARC first calls dunique() and then
calls dcreat() to open the file (because dunique() doesn't
according to the manual . . .) which would cause two file
handles to be consumed each time a temp file is created, and
only one handle is returned via dclose(). Depending on the
FILES=xx value in the CONFIG.SYS file, PKARC can eventually
run out of handles. (As an aside, Lattice C will probably
be abandoned in all future MS-DOS releases of PKARC/PKXARC).
This problem can fixed by the following patch:
debug pkarc.com
e a62 eb 14
e 105a a3 46 ea eb 20
w
q
There are *NO* known bugs in PKXARC version 3.5.
When will we see a UNIX version of PKARC and PKXARC?
Hopefully rather soon. Since the original MS-DOS versions of
PKARC and PKXARC used a significant amount of assembly code,
it wasn't easy to convert these to portable C. Nevertheless,
a portable C version of PKXARC now exists which works under
MS-DOS, Amiga, and VAX/VMS. An Amiga version of PKXARC is
slated for release this August. VAX/VMS and Unix versions of
the software are currently under development.
>Phil Katz>
Exec-PC BBS, Shorewood WI ......... 414-964-5160, 24 hours, 1200/2400 baud
Fargo BBS, Fargo ND ............... 701-293-5973, 24 hours, 1200/2400 baud
Sound of Music BBS, Oceanside NY .. 516-536-8723, 24 hours, 1200/2400 baud
USENET ............................ uwvax!uwmcsd1!uwm-cs.milw.wisc.EDU!katz
BIX ............................... Username: philkatz
U.S. Mail ......................... 7032 N. Ardara Ave., Glendale, WI 53209