PKARC (Phil Katz's original response) (long)
Indra K. Singhal
indra at amdcad.AMD.COM
Tue Mar 1 17:34:03 AEST 1988
In article <4671 at ozdaltx.UUCP> root at ozdaltx.UUCP (Scotty) writes:
>
>... Also the authors of PKARC won't release
>the code so that it can be ported to other systems, (CPM,
>*NIX, etc.)
The following is the original posting that Phil Katz (author of
PKARC) made in July when the PK-ARC controversy was hot. Maybe this
will refresh some memories and get some porters busy !!
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
Indra K. Singhal |The truth doesn't mean anything |
{ucbvax,decwrl,allegra}!amdcad!indra | |
amdcad!indra at decwrl.dec.com | It just IS ! |
------------------------------------------------------------------------
+Path: psuvm.bitnet!ukma!gatech!rutgers!uwvax!uwmacc!uwmcsd1!uwm-cs!katz
+From: katz at uwm-cs.UUCP ( Phil Katz)
+Newsgroups: comp.sys.ibm.pc
+Subject: PKARC, The REAL story.
+Message-ID: <651 at uwm-cs.UUCP>
+Date: 22 Jul 87 03:50:22 GMT
+Organization: U of Wi-Milw, College of Engineering
+Distribution: usa
+Lines: 205
+Keywords: pkarc pkxarc
+
+
+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
--
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
Indra K. Singhal |The truth doesn't mean anything |
{ucbvax,decwrl,allegra}!amdcad!indra | |
amdcad!indra at decwrl.dec.com | It just IS ! |
More information about the Comp.unix.xenix
mailing list