Xref: utzoo comp.sys.ibm.pc:12620 comp.unix.xenix:1590 Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!amdahl!amdcad!indra From: indra@amdcad.AMD.COM (Indra K. Singhal) Newsgroups: comp.sys.ibm.pc,comp.unix.xenix Subject: Re: PKARC (Phil Katz's original response) (long) Message-ID: <20601@amdcad.AMD.COM> Date: 1 Mar 88 07:34:03 GMT References: <4671@ozdaltx.UUCP> Reply-To: indra@amdcad.UUCP (Indra K. Singhal) Organization: Advanced Micro Devices Lines: 236 In article <4671@ozdaltx.UUCP> root@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@decwrl.dec.com | It just IS ! | ------------------------------------------------------------------------ +Path: psuvm.bitnet!ukma!gatech!rutgers!uwvax!uwmacc!uwmcsd1!uwm-cs!katz +From: katz@uwm-cs.UUCP ( Phil Katz) +Newsgroups: comp.sys.ibm.pc +Subject: PKARC, The REAL story. +Message-ID: <651@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@decwrl.dec.com | It just IS ! |