jvc@mirror.UUCP (04/21/87)
/* Written 8:44 am Apr 17, 1987 by jvc@mirror.UUCP */ >I mailed dalegass@dalcs.uucp a copy PKX34A20.COM. >If others are interested in a copy, let me know > -or- >if there's enough interest, someone suggest where I can post it. >There doesn't seem to be a comp.sources.ibm or comp.sources.msdos >and net.sources is now comp.sources.unix. I've only received 3 or 4 requests for PKX34A20.COM since I posted the above message. It doesn't seem that there is enough interest to post it here (comp.sys.ibm.pc). Also, comp.sources.* isn't really appropriate since 1) it isn't source 2)interest is lacking [maybe because its available on most BBSs]. I noticed there is a new(?) notesfile comp.binaries.amiga but I couldn't find any other comp.binaries.*. If a comp.binaries.[ibmpc | msdos] is started, I'll add PKX34A20.COM to it. Until this happens or until there's sufficient interest to post it here, I will mail copies to those who request it. ------------------------------------------------------------------------- Jim Champeaux jvc@mirror.TMC.COM {mit-eddie, ihnp4, wjh12, cca, cbosgd, seismo}!mirror!jvc Mirror Systems, 2067 Massachusetts Avenue, Cambridge, MA 02140 Telephone: (617) 661-0777
res@ptsfa.UUCP (Bob Stockwell) (07/03/87)
What are the symptoms of a Squashed file when using ARC? At various times I have downloaded .ARC files, only to discover that I couldn't DeArc them, I assumed that there was some sort of transmission problem (Yes I know all about binary transfers and have successfully transferred .COM and .EXE files). Now I have PKARC and PKXARC. But I'll bet that Squashing was my problem all along(????). Needless to say, I've long since forgotten all the useful (??) programs that I gave up on. Bob Stockwell ptsfa!res
bobmon@iucs.UUCP (07/07/87)
In article <3187@ptsfa.UUCP> res@ptsfa.UUCP (Bob Stockwell) writes: > >What are the symptoms of a Squashed file when using ARC? > [...] I believe that both ARC and PKARC will complain about an "unrecognized compression method" if they encounter one. At any rate, the new PKARC would simply show a Squashed file in its archive listing of the suspect .ARC file. Speaking of Squashing, I would like to propose a (manual voluntary) work-around for the recently-complained-about incompatibility problem. Both ARC and PKARC will accept archives whose extension is something other than .ARC -- you just need to specify the entire name-plus-extension. Accordingly, how about if archives with Squashed entries are given an extension of .ARS? (If this is a bit too racy for you, .ARK or .KRC (for Katz) are alternatives) Personally, I use PKARC exclusively, for its speed. However, the Squash method doesn't improve that much over Crunching, and as someone else pointed out ARC has been ported to other machines (such as the VAX785 I'm attached to right now) while PKARC exists only on MSDOS machines. I think avoiding Squashed files in public distributions is the way to go, but if they do get out they should at least be labelled as such.
craiga@phred.UUCP (07/08/87)
In article <4587@iucs.UUCP> bobmon@iucs.UUCP (Che' Flamingo) writes: > >Speaking of Squashing, I would like to propose a (manual voluntary) work-around : : >archives with Squashed entries are given an extension of .ARS? (If this >is a bit too racy for you, .ARK or .KRC (for Katz) are alternatives) On my own machine, any ARC type file that I produce that ends up with a squashed entry, I rename to a .PKA extension (Phil Katz Arc). I would tend to stay away from .ARK extensions because Bob Freed is working on a CP/M version of Arc that he will call NOAH that produces *.ARK files. Bob chose the .ARK extension to point out the fact that the archive was created on a CP/M system instead of MSDOS. The resulting .ARK file is supposed to otherwise be compatible with the MSDOS verions of ARC. NOAH is sourced in Z80 assembly. Bob is currently trying to verify that there aren't any bugs left in his code before releasing it to the public. Bob has released several versions of UNARC for CP/M, the latest of which is called UNARC16.ARK (self extracting if renamed to UNARC16.COM). UNARC16 will unpack the archives created by Phil Katz that have SQUASHED members, I have verified this. As for why you haven't seen PKARC on a Unix type box; I have been told that PKARC was written in Microsoft MASM (assembly) for the PC. Assembly code is not very portable. 8-<)
emv@pepe.cc.umich.edu (Ed Vielmetti) (07/08/87)
Don't use .ARK for an extension for pkarc files - that's already in use in the rcp/m world for cp/m arc files. Edward Vielmetti, U-Michigan Workstation Support Group, seismo!umix!emv
dragon@oliveb.UUCP (Give me a quarter or I'll touch you) (07/10/87)
in article <1589@phred.UUCP>, craiga@phred.UUCP (Craig Arno TE N9) says: > > squashed entry, I rename to a .PKA extension (Phil Katz Arc). I would > tend to stay away from .ARK extensions because Bob Freed is working on > a CP/M version of Arc that he will call NOAH that produces *.ARK files. > Bob chose the .ARK extension to point out the fact that the archive was > created on a CP/M system instead of MSDOS. The resulting .ARK file is > supposed to otherwise be compatible with the MSDOS verions of ARC. > A point I don't understand: If the resultant ARC file is compatible with the MS-DOS ARC files (especially the SEA ones) why bother giving then a different extension? I mean, ARC files created on any other computer (VAX, Atari, Commodore, Amiga, and I know of people working on Mac versions) still have the same extension--ARC. Since all these files are compatible, there isn't a reason to change the extension. Whereas PKARC files aren't compatible...so there IS a reason to change the extensions there. -- Dean Brunette {ucbvax,etc.}!hplabs!oliveb!olivej!dragon Olivetti Advanced Technology Center _____ _____ __|__ _____ 20300 Stevens Creek Blvd. | | _____| | | Cupertino, CA 95014 |_____| |_____| |__ |_____
jdia@osiris.UUCP (Josh Diamond) (07/10/87)
FLAME ON :-( FLAME ON :-( FLAME ON :-( In article <1589@phred.UUCP>, craiga@phred.UUCP (Craig Arno TE N9) writes: [stuff deleted] > As for why you haven't seen PKARC on a Unix type box; I have been told that > PKARC was written in Microsoft MASM (assembly) for the PC. Assembly code > is not very portable. 8-<) I will repeat: WHY DOESN'T HE PUBLISH THE FORMAT OF HIS NEW ARC FILES? :-( IF PK IS SUCH A COOL DUDE, THEN HE SHOULD PUBLISH THE COMPRESSION FORMAT!!!! YO! PHIL! WAKE UP!!! THERE ARE A LOT OF PEOPLE OUT HERE WHO LIKE YER' ^*&%$*^%$ NEW SQUASHING SYSTEM, BUT CAN'T USE IT CAUSE YOU DON'T PUBLISH THE FORMAT AND WONT PORT IT TO OTHER SYSTEMS!!! SOME OF US USE SYSTEMS BESIDES IBM-PieceofCrap/MeSs-DOS!!!!!!!!!!!!!!!!!! PPPPP UU UU BBBBB LL IIIIII SSSS HH HH PP P UU UU BB B LL II S HH HH PPPPP UU UU BBBBB LL II SSSS HHHHHH PP UU UU BB B LL II S HH HH PP UUUU BBBBB LLLLLL IIIIII SSSS HH HH TTTTTT HH HH EEEEEE TT HH HH EE TT HHHHHH EEEEEE TT HH HH EE TT HH HH EEEEEE FFFFFF OOOO RRRRR MM MM AAAA TTTTTT !! !! FF OO OO RR R MMM MMM AA AA TT !!!! !!!! FFFF OO OO RRRRR MM MM MM AAAAAA TT !! !! FF OO OO RR R MM MM AA AA TT !! !! FF OOOO RR R MM MM AA AA TT !! !! :-( :-( :-( :-( :-( :-( :-( :-( :-( :-( :-( :-( :-( :-( :-( :-( :-( :-( :-( Yes, I'm PISSED and I'm Spidey!!! -- We're on an express elevator to hell -- GOING DOWN!!! /\ Josh /\ THRILL //\\ .. //\\ SEEKERS A message from Spidey, and the Spidey Team. ----->>> //\(( ))/\\ UNITE!!! Available via UUCP: ...[seismo,mimsy]!jhu!osiris!jdia / < `' > \
craiga@phred.UUCP (Craig Arno TE N9) (07/13/87)
In article <1924@oliveb.UUCP> dragon@oliveb.UUCP (Give me a quarter or I'll touch you) writes: >in article <1589@phred.UUCP>, craiga@phred.UUCP (Craig Arno TE N9) says: >> >> squashed entry, I rename to a .PKA extension (Phil Katz Arc). I would >> tend to stay away from .ARK extensions because Bob Freed is working on >> a CP/M version of Arc that he will call NOAH that produces *.ARK files. >> Bob chose the .ARK extension to point out the fact that the archive was >> created on a CP/M system instead of MSDOS. The resulting .ARK file is >> supposed to otherwise be compatible with the MSDOS versions of ARC. >> > >A point I don't understand: If the resultant ARC file is compatible with >the MS-DOS ARC files (especially the SEA ones) why bother giving then a >different extension? I mean, ARC files created on any other computer (VAX, >Atari, Commodore, Amiga, and I know of people working on Mac versions) >still have the same extension--ARC. Since all these files are compatible, >there isn't a reason to change the extension. During the brief time that I exchanged e-mail with Bob Freed, I got the impression that he wanted to be cautious and provide a way to track down compatibility problems, so the default extension on his CP/M archive files are .ARK. He also liked the "SQUASHING" algorithm so I would guess that may have been included also. I won't argue with him, it's his program. 8-<) I am very happy with the performance of SEA's ARC, Phil Katz's PKARC, Bob Freed's CP/M UnArc, and the version of Unix ARC that ended up here (I don't know who but thanks). An interesting difference in philosophy between the MSDOS arc's and Bob Freed's CP/M versions; Bob Freed does not ask for money of any sort, and he has provided full Z80 M80/Z80ASM source for version 15 (He is up to version 16 now) of his UnArc program. I have looked briefly through the 124K of Z80 source and see that he has code for UnSQUASHING. If you are interested in this source, please send a polite note with your mailing address. If there are too many notes, I'll try to post it (To a CP/M group). My communication with Bob Freed was not through the UUCP Net, so I do not have an electronic mailing address for any further questions. This information came from the PKARC documentation, they might appreciate a **polite and positive** phone call. Mr. Wettstein in article 5441 said he will be calling for information on the SQUASHing algorithm, so you might wait and see what he comes up with. >If you have any questions or comments about PKARC send them to Phil >Katz at: > >RBBS-PC of FARGO, Loren Jones SYSOP >Fargo, North Dakota >701-293-5973 >300/1200/2400 baud, 24 hours a day > >or > >Exec-PC IBM BBS, Bob Mahoney SYSOP >Shorewood, Wisconsin >414-964-5160 >300/1200/2400 baud, 24 hours a day If there is a CP/M ARC (NOAH) program available, could someone send me a UUEncoded version of it? (Thanks in advance) While I'm at it, I'm also looking for Microsoft C 4.0 compatible source for the UUDecode and UUEncode utilities. Again, if you have a PD version of this, I would be most grateful for an e-mailed copy. (Thanks in advance) After the last flame, I feel a disclaimer is in order: ============================================================================== - Physio Control is in no way responsible for any of my messages. - Flames can be sent to /dev/null - I am not associated with any of the ARC efforts, I merely suggested a change to the CP/M UnArc program that is included in versions 15 and higher. - I am new to the net, and not yet comfortable with it. Your tolerance is appreciated. - Just recently found out: Use "uupath" for the best route to "phred"
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
creps@silver.bacs.indiana.edu (Steve Creps) (02/26/88)
In article <20180@bu-cs.BU.EDU> madd@bu-it.bu.edu (Jim Frost) writes: >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 [ stuff deleted ] >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 [ more deleted ] Yes, the squashing can be easily overridden with the -oct option. Another thing I like better is that PKARC is much faster when it comes to compressing files. I've started compressing large files with ARC before, and after a few minutes, gotten tired of waiting. Then I tried it again (^Break out of ARC) with PKARC, and PKARC seemed to do it so fast that there was no comparison. Of course, I think ARC is the original version of the thing. I still keep a copy lying around just in case. - - - - - - - - - - Steve Creps on the VAX 8650 running Ultrix 2.0-1 at Indiana University. creps@silver.bacs.indiana.edu (192.12.206.2), ...iuvax!silver!creps, creps@iubacs.bitnet "Hey fellas, it's a four-legged V-8!"
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
rce229@uxa.cso.uiuc.edu (02/27/88)
> (paraphrase) PKARC's source code hasn't been released
No, but the author released a text file detailing the minor differences
between the Squash and Crunch (original) compression routines. It just
has to do with using a 13-bit table size instead of 12-bit. What that
means I can't say, except the more bits, the better compression and the
larger the memory requirements. I think UNIX's compress program uses
14 bits. (I know one of the Macintosh 'arc'-like programs uses 14)fulton@navion.dec.com (26-Feb-1988 1916) (02/27/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. If you are using PKARC, you might give some serious consideration to reading the documentation (I do understand that doing so is quite a novel idea for many). There are command line options for PKARC which allow you to disable squashing, which is the only part of PKARC not compatible with SEA's ARC. >The *occasional* 1-3% savings in compression is hardly >worth the problems caused by incompability. Gee, I wish I had as much free time as you do. I only had to run PKARC ***ONE TIME*** to know that I would never go back to SEA's tortoise. If you get big thrills from watching your hard disk access light go on and off and are mesmerized by your hard disk sounding like a washing machine, then by all means continue to use SEA's ARC.
akk2@ur-tut.UUCP (Atul Kacker) (02/29/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. > And how much did you get paid for posting this to the net ;-) -- ------------------------------------------------------------------------------- Atul Kacker | Internet: akk2@tut.cc.rochester.edu | UUCP: {ames,cmcl2,decvax,rutgers}!rochester!ur-tut!akk2 -------------------------------------------------------------------------------
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
fulton@navion.dec.com (28-Feb-1988 2248) (02/29/88)
tr@bellcore.bellcore.com writes: >I know I can use the /oct option to prevent PKARC from using >sqashing. But someone just mentioned a patch to make this permanent. >I would like this so that I don't have to remember to type /oct >every time I make an archive. Can you say BATCH files? Can you say (P)CED synonyms? I knew you could. uucp: ...decwrl!comet.dec.com!fulton ARPA: fulton@comet.dec.com
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 ! |
pjh@mccc.UUCP (Peter J. Holsberg) (03/01/88)
In article <8802290547.AA14788@decwrl.dec.com> fulton@navion.dec.com (28-Feb-1988 2248) writes: |tr@bellcore.bellcore.com writes: | |>I know I can use the /oct option to prevent PKARC from using |>sqashing. But someone just mentioned a patch to make this permanent. |>I would like this so that I don't have to remember to type /oct |>every time I make an archive. | The patch is very simple. Just use DEBUG to change the byte at F25 from 75 (squash is the default) to 74 (must use /oc to get squashing) or EB (permanently disables squashing, iorrespective of /oc). -- Peter Holsberg UUCP: {rutgers!}princeton!mccc!pjh Technology Division CompuServe: 70240,334 Mercer College GEnie: PJHOLSBERG Trenton, NJ 08690 Voice: 1-609-586-4800
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!!!
jvc@prism.TMC.COM (03/03/88)
>/* Written 9:45 am Mar 1, 1988 by pjh@mccc.UUCP */ >In article <8802290547.AA14788@decwrl.dec.com> fulton@navion.dec.com (28-Feb-1988 2248) writes: >|tr@bellcore.bellcore.com writes: >| >|>I know I can use the /oct option to prevent PKARC from using >|>sqashing. But someone just mentioned a patch to make this permanent. >|>I would like this so that I don't have to remember to type /oct >|>every time I make an archive. >| > >The patch is very simple. Just use DEBUG to change the byte at F25 from >75 (squash is the default) to 74 (must use /oc to get squashing) or EB >(permanently disables squashing, iorrespective of /oc). It's highly unlikely that this patch will work for all versions of pkarc. One should never advertise a patch without stating exactly what version it applies to.
jpn@teddy.UUCP (John P. Nelson) (03/04/88)
>>I applied the "official" patch to PKARC35, which turned off "Squashing" > >What is the "Official" Patch? OK, OK. I guess this patch isn't really "official", but it was posted to USENET at about the same time PKX35A35.EXE was first posted. I am posting it uuencoded/arced, because it contains DEBUG scripts, which are sensitive to having carriage returns. I am including enough of the READ.ME to let you know what it does. I wish whoever had posted pkarc.exe and pkxarc.exe had not done so: If you dont have the COMPLETE distribution (PKX35A35.EXE), then you really should get it! Extract from READ.ME: PKARC v3.5 added a configuration file to allow the compatibility option defaults to be changed. Although the ability to change the defaults is a good idea, the implementation is poor because (1) an environment variable is usually needed to point to the configuration file, (2) the configuration file wastes disk space, and (3) it takes time to open and process the file whenever PKARC is run. It would have been much better if the compatibility option defaults were simply specified with the environment variable directly, making the file unnecessary! If, like me, you want to change the default(s), but you don't want to set up the configuration file, the simplest method is to patch the program to permanently change the defaults. The two patch files OC and OT are DEBUG scripts which will patch PKARC v3.5 (and NO OTHER VERSION) to change the two defaults. Otherwise the operation of PKARC is UNAFFECTED: even the -nc and -nt switches and the configuration file will still work! begin 644 pkarc35p.arc M&@A/0P`E)24E)24E)24E<@```+$.=D^H)IP````,=4#4L(%#(,$&"@+6"'-#6 M($.$`6/(B$$&A$2*$$'0P&%#C$:.8A"&,8@#89LW=D#<>2.G(APZ<K:4"2,F; M3!<6,!"*='C#)$J5+%W"E$G3)HL8.A6,O$@&H1H]%F70,)-TY,:.3MU`W7A#3 M1M([".,@U``:"$]4`"4E)24E)24E)25T````L0YI3[K?G0````QU0-2H$48@^ MP08*`M;(D4,@0X0!8]`8(P:$1(H00=#`$>:&1HXW$!8<&`9AFS=V0-QY(X<,P M"#ATY&PI$T9,F2XL8"`4Z3"'290J6;J$*9.F39PQ=BHH>%$,0C5N]%BD0::,X MTH(;.SZ-^C&,504([R",@U`#&@A214%$+DU%`"4E)24E>`4``+$.<51/S+<(1 M```,#10D&`BB()0E0:0,`6%GAHL:`0,>3+BPX4,08<B0*4,&(X@Q;]R827.FG MCIPP=-*$!#&231D0=-Y@9,/FS1V8:%Z";`,'91HQ:=BDH9,GX!LX*5=N-!.F> M#ALZ<V#*%*,331@W9SBZ*!CD*9HW=<Z@P?DR#%"A1*5^M(JU3$`Z.4$L;?HT* M:IJH84"<>?.F8YJ-85B0!9&&I\LV9=S0\;GR+@@X?.6`H#JFZ1RW"E#$2('1" M#8C$=M+("8E8,<,P<M*8=4DX:ITY=<+0S`/"31F.'-5"3F,Z)MF`($62-,G8^ M<\LR@E'(X`Q79\B1)4\F-1[TY9TP<^B4B4KF[IJ`<WJ.0=ZY(XH9G(?"#+-FT M.\S"+WT?35S^\>CQ<Z(V9UD]X)V<MME1AF03*=0:"'+4X<96("1!!PAW@,5&[ M1U8).-EMGK51QQAC446'=I*E8<9O"NS44TIG#47;4=/)50933D$%X8`OS5$8: M'&S0%EX98XB81FYW##56<P&!)AIIB3UH!VJJB<%:=W+P2$>.@K7!'F]G#'8<U M"`K:AM\<J.410D0*)&&&8$*U!P)B@N4!%H17/>@;AU=E-=A<,:(P1PJ"B5''D M@V[6(5=()]#A7YQJ7?9@'7`,%AQTQ+5XG&#[V6C8=@\B!E=?K;TETXD<#@;'\ M:&><U(9N`UIIFV(YKE5G?''A61>#5.3T5H2/H13J<5$]L=!5'3U!!491@D!$@ M$4)4<00(<XR1&E)1_9=&J$'2E"L='$J$D($6U0`""L""X,03(`B+1!%2@&`%, MNE,D\803S,E$9UN#T8&KK%"Y$-`3S<D1Y&6#S2>=2IZ],6*!"SE6A1-!&&%$I M$4-04001.GPFH&?[M>#&&`&%J_&#<P2);4YXN='1?H\.-_!*6U;+!K,I61NA- M'&N,J4!`4I2!6!M42>:;&&&,L0:7C2+LPA!/-'&A&6\4BY)V/*6$E6ZZCC54Q M0&J\]B!O'V%7XQN:HH&E7F^X=\=H6-E,)D&0'(!T$U!(4<04[;YK;!%&!%$%8 M$U20286\;-F),MBC;F>C4B_2)>=4+YGA5*LF^N2D=4(&1!%#WJ*0A@ME;.6&I M3"+,$4=L<XB-E0B<)>B&#F0>F^RR1K\-`@^^DAF$G'%1=09O;HQM\&#-/DL'' MI3DY72P-'X&M*AGZR=1=>&R$490"^Z%6!G9J474MAUH5)$2-)L&*TIUWX2C]3 M@45@$43$3&014)JP-OX&339AR?K-"K0@:`TVX``"_S@(B`QD$`,8Z``&``3!( M$&X``QL((0A%"`(,"@B#@C3A"58HB`:O\`0I$`$$4*!"NK80P0=V@04P2&$,E M`J*__X7A!BZ\@0`):$`$!@&&"VS@`R.8PA1:$(,:+`@'/0A"$8*`A$$P(0I[= MR$)!Q8"`'7EB#,@PPP+J0(H?O$$-9E!!2"A`"4[00A!!\$0:&*&)(*`!#FP@Z MAC2N40Q5-*`:'0B"&]``@2#PHA+$"`D#J/$&,B!30`:2@()0(0E-*,+=\K:W" MON'O;ZZBUWY2@IAOA8L,*'G)[_9#$;%9Z#B<P5?V,..XV22/)Y)CC<C&<CD[$ M9&YSG2O(YT`0NM%AQW1G0!V"%'2_@+A.62#<UA".EK39"<MVN'N)[GCGNQ%5F MREEI0`KQ:$2LER!O)\MKGES*%[WI52]*V/O92T"5$S(PZ'O,"A].QK>?YYF/# M-HY)W_JHT+[WI4%-^V$:_8*$E5[F;W\UR$L-`AK'`PXT"`IDH`.+P$,*_C"#E M01SB!T,XPA(6X80]7.$__Y>#''`T!P5%8$<3JD.&2K"'#QVC1(M8T21>=(DI0 M1&,,:#"&-LZTI@6=Z1"$4$<:Q"`&>?PB'PTPTV.A48TO=.,+"ZK&&_84CWH<G M:E.+$!`-`!H`````````````````````````````````````````````````/ E````````````````````````````````````````````````````` `` end size 1792
manes@dasys1.UUCP (Steve Manes) (03/09/88)
In article <1895@uwspan.UUCP> root@uwspan.UUCP (John Plocher) writes: > SEA used PUBLIC DOMAIN code to produce ARC (compress, squeeze, > etc - look at the comments in the source if you doubt) Actually, as I understand it, the Lempel-Ziv compression algorithm used by both S.E.A. ARC and PKARC is copyright AT&T so an argument could be made that they both claim-jumped. -- +----- + Steve Manes Roxy Recorders, Inc. NYC + decvax!philabs!cmcl2!hombre!magpie!manes Magpie BBS: 212-420-0527 + SmartMail: manes@magpie.MASA.COM
james@bigtex.uucp (James Van Artsdalen) (03/14/88)
IN article <3322@dasys1.UUCP>, manes@dasys1.UUCP (Steve Manes) wrote: > Actually, as I understand it, the Lempel-Ziv compression algorithm used by > both S.E.A. ARC and PKARC is copyright AT&T so an argument could be made > that they both claim-jumped. The ARC source I have uses a Lempel-Ziv routine straight from compress.c in the standard usenet distribution, with a comment to the effect that the ARC implementor, Thom Henderson, didn't really understand it. I did find it amusing to see Thom's copyright message only a dozen lines above that confession... :-) I did not find it amusing to see that Thom had removed the compress.c author names :-( -- James R. Van Artsdalen ...!uunet!utastro!bigtex!james "Live Free or Die" Home: 512-346-2444 Work: 328-0282; 110 Wild Basin Rd. Ste #230, Austin TX 78746
wnp@killer.UUCP (Wolf Paul) (03/14/88)
In article <3322@dasys1.UUCP> manes@dasys1.UUCP (Steve Manes) writes: ->In article <1895@uwspan.UUCP> root@uwspan.UUCP (John Plocher) writes: ->> SEA used PUBLIC DOMAIN code to produce ARC (compress, squeeze, ->> etc - look at the comments in the source if you doubt) -> ->Actually, as I understand it, the Lempel-Ziv compression algorithm used by ->both S.E.A. ARC and PKARC is copyright AT&T so an argument could be made ->that they both claim-jumped. Well, SEA and PKARC use the Lempel-Ziv implementation from the UNIX compress program, but that is a public domain UNIX utility, not one supplied by AT&T. The standard file compression utility supplied by AT&T with System V is pack, which is based on Huffman encoding. I understand that the Lempel-Ziv algorithm is also public domain. The only thing SEA could claim a copyright or some other protection for is the specific file format of an *.arc file -- i.e. the header structure, etc., but I believe that this is too minimal to be considered copyrightable. -- Wolf N. Paul * 3387 Sam Rayburn Run * Carrollton TX 75007 * (214) 306-9101 UUCP: ihnp4!killer!dcs!wnp ESL: 62832882 INTERNET: wnp@EESDES.DAS.NET or wnp@dcs.UUCP TLX: 910-280-0585 EES PLANO UD One Austrian's Opinion: Waldheim must go!
rce229@uxa.cso.uiuc.edu (03/16/88)
Thom Henderson by now understands the compression processes in ARC (he made many modifications to the LZW code after it was initially installed in ARC version 4? (exact # not important). His comments are not well-updated though.