root@ozdaltx.UUCP (Scotty) (02/25/88)
If you are using PKARC, you might give some serious consideration to going back to the Standard ARC. I talked with Thom Henderson today of S E A who authored ARC and they are getting complaints about PKARC not being system compatable (backwards) with ARC. PKARC is in violation of S E A's copywrite. Also the authors of PKARC won't release the code so that it can be ported to other systems, (CPM, *NIX, etc.) The *occasional* 1-3% savings in compression is hardly worth the problems caused by incompability. -- ============================================================ | Scotty | Adapt - Enjoy - Survive | | ihnp4!killer!ozdaltx!sysop | "Ad Venerem Securiorem" | ============================================================
madd@bu-cs.BU.EDU (Jim Frost) (02/25/88)
In article <4671@ozdaltx.UUCP> root@ozdaltx.UUCP (Scotty) writes: >If you are using PKARC, you might give some serious >consideration to going back to the Standard ARC. I talked >with Thom Henderson today of S E A who authored ARC and they >are getting complaints about PKARC not being system >compatable (backwards) with ARC. PKARC is in violation of >S E A's copywrite. Also the authors of PKARC won't release >the code so that it can be ported to other systems, (CPM, >*NIX, etc.) From what I remember about PKARC/PKXARC, they were a complete rewrite (I thought in assembly language) of the ARC utility. If this is the case, they are not in violation of the SEA ARC copyright, since they could not have used the source. I'd say that it's unlikely that they are in violation -- otherwise, how could there be THAT much of a performance increase? I could see 20-50% increase in performance for fine-tuning, but it takes real effort to hit 200%+. As for backwards compatibility, it is simple enough to repack a pkarc file to eliminate squashed files (which I believe are what's different between the two programs). For my personal archives, I like the idea of another form of compression. Putting 30Mb of source/executables on floppies is not fun -- I appreciate any help I can get, and that extra compression technique could add up to fewer floppies. BTW, does anyone have the documentation file with PKARC (any version, although 3.5 is best) unpacked? My only copy is in a self-extracting archive and (wouldn't you know it) I don't have a PC handy. If you have the doc file, please email it to me. jim frost madd@bu-it.bu.edu
mdf@tut.cis.ohio-state.edu (Mark D. Freeman) (02/25/88)
In <4671@ozdaltx.UUCP> root@ozdaltx.UUCP (Scotty) writes: >If you are using PKARC, you might give some serious >consideration to going back to the Standard ARC. I talked >with Thom Henderson today of S E A who authored ARC and they >are getting complaints about PKARC not being system >compatable (backwards) with ARC. Only if you use one of their new compression modes. You can turn this mode off. This incompatibility can be turned on and off at will. >PKARC is in violation of S E A's copywrite. No it isn't. >The *occasional* 1-3% savings in compression is hardly >worth the problems caused by incompability. I don't use it for better compression, I use it because it is AMAZINGLY faster than arc. On the order of 2-3 times faster. -- Mark D. Freeman (614) 262-1418 mdf@tut.cis.ohio-state.edu 2440 Medary Avenue ...!cbosgd!osu-cis!tut.cis.ohio-state.edu!mdf Columbus, OH 43202-3014 Guest account at The Ohio State University
jpn@teddy.UUCP (John P. Nelson) (02/26/88)
>If you are using PKARC, you might give some serious >consideration to going back to the Standard ARC. I would NEVER go back to ARC. I applied the "official" patch to PKARC35, which turned off "Squashing" by default. Therefore my copy of pkarc is 100% compatible with ARC 5.21. Why would I bother? Because PKARC is 10 TIMES FASTER than arc. I don't know about anyone else, but that means a LOT to me! >PKARC is in violation of S E A's copywrite. This would be AWFULLY hard to prove. I believe that pkarc is a complete rewrite. It's not a look-and-feel issue either. The only thing in common between the two programs is the compression algorithm (Lempel-Ziv), and that is public domain! >The *occasional* 1-3% savings in compression is hardly >worth the problems caused by incompability. I agree. But with the official patch from PK which turns off the new compression mode (unless you use the right options), it blows the pants off ARC from SEA. --- John P. Nelson decvax!genrad!teddy!jpn mit-eddie!genrad!teddy!jpn ARPA!talcott.harvard.edu!panda!jpn
bobmon@iuvax.cs.indiana.edu ([bob, mon]) (02/26/88)
...but I can't resist this topic :-) <4638@teddy.UUCP> jpn@teddy.UUCP (John P. Nelson) writes (among other things): >>If you are using PKARC, you might give some serious >>consideration to going back to the Standard ARC. > >I would NEVER go back to ARC. > >Why would I bother? Because PKARC is 10 TIMES FASTER than arc. >I don't know about anyone else, but that means a LOT to me! > >>PKARC is in violation of S E A's copywrite. > >This would be AWFULLY hard to prove. I believe that pkarc is a >complete rewrite. It's not a look-and-feel issue either. The >only thing in common between the two programs is the compression >algorithm (Lempel-Ziv), and that is public domain! I measured a 7:1 speed ratio on my test suite. I have occasional can't- write-the-dam'-file problems with pkarc, but not v1.2 -- which I keep around as a backup for this reason :-( The speed improvement (8-9 minutes versus AN HOUR on biggish archives) makes the hassle worth it. The superior compression is nice too, but I'd pay a slight size penalty for that speed. Pkarc and ARC have something fairly valuable in common, namely their whole approach to the task. I like being able to group files together (like UNIX shar does). I like being able to compress the files (like UNIX compress does (usually better than pk/arc does)). I like having a CRC available, not to mention the "test validity" option. They make for a more robust archive. By the way, I've seen "arc t badarc" report an error where "pkxarc /t badarc" hung the whole machine...when I suspect trouble I use arc first now. These abilities aren't really available to me on Unix right now. I can compress some stuff, and I can uuencode and shar it, and I can run CRC's on everything, but if I send it to someone I can't be sure that their unshar can handle my shar (okay, it probably will), and I can't be sure that they can generate the same CRC or checksum or whatever that I used -- there are variations on the algorithms that produce different values; there are additional characters that mailers sometimes add to files that can change those values. I can't be sure that the recipient will in fact do all the right things to get files out intact. The ARC format makes much of that easier and more automatic. While I'm at it, the ZOO format yields most of these same benefits, and I like the extract-and-run-from-memory feature a lot for infrequently used programs. It's biggest problem is that it isn't used much. Both zoo and arc have been ported to UNIX systems so files can be exchanged quite conveniently (although the machine I'm on right now has neither). p.s. Henderson and Katz: you're on my list of people to register with, right along with Buerg. Pray for me to get out of school and get a job :-) RAMontante bobmon@iuvax.cs.indiana.edu Computer Science Department If you listen to Tools... Indiana University the Slide Rules!
cpc@vaxine.UUCP (Chris Cullen) (02/27/88)
In article <7186@tut.cis.ohio-state.edu>, mdf@tut.cis.ohio-state.edu (Mark D. Freeman) writes: > In <4671@ozdaltx.UUCP> root@ozdaltx.UUCP (Scotty) writes: > >If you are using PKARC, you might give some serious > >consideration to going back to the Standard ARC. I talked > >with Thom Henderson today of S E A who authored ARC and they > >are getting complaints about PKARC not being system > >compatable (backwards) with ARC. > > Only if you use one of their new compression modes. You can turn this > mode off. This incompatibility can be turned on and off at will. Then will people posting stuff to the net PLEASE PLEASE PLEASE ***NOT*** use the new compression modes. I don't have the new PKARC, and haven't been able to find it on local BBS's (if some kind soul would mail it to me, I'd be grateful). More important, tho, the files can't be worked with on the unix version of arc which otherwise works on everything, and is wonderful for testing the integrity of what's been uudecoded before downloading to a PC. (Being able to test file integrity is absolutely THE reason why uuencoded ARC'd files are the way to send binaries over the net. I often get 'short file' warnings from uudecode for perfect files, and occasionally have gotten garbage from ok uudecodes. Compression efficiency is moot if you've gotten garbage and have to start over, assuming you managed to find out you got garbage in the first place.) -- Chris Cullen UUCP: {ucbvax!allegra,decvax}!encore!vaxine!cpc Automatix, Inc. Phone: 617-667-7900 x2066 1000 Technology Park Dr. Billerica, Mass. 01821
madd@bu-cs.BU.EDU (Jim Frost) (02/29/88)
In article <783@vaxine.UUCP> cpc@vaxine.UUCP (Chris Cullen) writes: >More important, tho, the files can't be >worked with on the unix version of arc which otherwise works on >everything, and is wonderful for testing the integrity of what's been >uudecoded before downloading to a PC. Does anyone out there have a UNIX version of ARC that doesn't core dump on archive creations? The version that I have is nice for unpacking but it would be better if I could build archives as well. The version I have has the following header: (begin header) static char *RCSid = "$Header: arc.c,v 1.2 86/07/15 07:52:04 turner Exp $"; /* * $Log: arc.c,v $ * Hack-attack 1.3 86/12/20 01:23:45 wilhite@usceast.uucp * Bludgeoned into submission for VAX 11/780 BSD4.2 * (ugly code, but fewer core dumps) * * Revision 1.2 86/07/15 07:52:04 turner * first working version for the vax * * Revision 1.1 86/06/26 14:59:15 turner * initial version */ (end header) Many thanks for any help. jim frost madd@bu-it.bu.edu
indra@amdcad.AMD.COM (Indra K. Singhal) (03/01/88)
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 ! |
root@uwspan.UUCP (John Plocher) (03/02/88)
+---- root@ozdaltx.UUCP (Scotty) writes in <4671@ozdaltx.UUCP> ---- | PKARC is in violation of | S E A's copywrite. How? Cuz it can process ARCs data files? The only thing that Thom can copyright is his code, NOT THE IDEAS BEHIND IT. SEA used PUBLIC DOMAIN code to produce ARC (compress, squeeze, etc - look at the comments in the source if you doubt) and if Phil also used that code as the basis for PKARC, there is no violation. I don't like the ATTITUDE that Phil took, but I respect him and his program is fantastic nonetheless. Accusing him of Copyright violation is a SERIOUS matter - can you back it up? | Also the authors of PKARC won't release | the code so that it can be ported to other systems, (CPM, | *NIX, etc.) So what. I can't get the source to PC-DOS and I want to make it run on my VAX... :-) | The *occasional* 1-3% savings in compression is hardly | worth the problems caused by incompability. This, at least, is one thing that I agree with completely! | ============================================================ | | Scotty | Adapt - Enjoy - Survive | | | ihnp4!killer!ozdaltx!sysop | "Ad Venerem Securiorem" | | ============================================================ -John -- Comp.Unix.Microport is now unmoderated! Use at your own risk :-)
abcscnge@csuna.UUCP (Scott "The Pseudo-Hacker" Neugroschl) (03/02/88)
In article <4638@teddy.UUCP> jpn@teddy.UUCP (John P. Nelson) writes: >I would NEVER go back to ARC. I applied the "official" patch to >PKARC35, which turned off "Squashing" by default. Therefore my >copy of pkarc is 100% compatible with ARC 5.21. What is the "Official" Patch? I have PKARC 3.5 as posted to the net a couple of months ago, and would be interested. Also, does this patch affect self-extracting archives? -- Scott "The Pseudo-Hacker" Neugroschl UUCP: ...!ihnp4!csun!csuna!abcscnge -- "They also surf who stand on waves" -- Disclaimers? We don't need no stinking disclaimers!!!