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