paul@cgh.UUCP (Paul Homchick) (06/30/87)
First the evidence: ================================================================ I cannot un-arc all of the files from the uuencoded wordwiz.arc sent to comp.binaries.ibm.pc. Either the uuencoded binaries of wordwiz.arc were not sent over the net properly, ... It lets me get wordwiz.com out, but complains for (I believe) wordwiz.dat. ---------------- This file is in "squashed" format. I used pkxarc (which was also distributed on Usenet not so long ago, so it shouldn't be so hard to find) and it unarced without a hitch. ---------------- The answer is that I am supposed to use pkxarc to get the files from it. Honestly, though, how is one supposed to know to use pkxarc instead of arc? The filename extensions are the same (.arc), and there is no mention of which program he used in the message. ---------------- According to PKARC, wordwiz.dat has been "squashed". The moderator of comp.binaries.ibm.pc has stated that uuencode and pkarc are the programs to be used for packing files and has posted both uuencode/decode and pkarc (they are still there today) to the group. ---------------- >If most people would resolve to stop using PKARC, or if its author could >be persuaded to adopt another filetype extention when "squashed" format >files are created, [...] then [these] problem[s] would not exist... It's obvious that you've never used PKARC. Pkarc is 6 times faster than ARC and also offers an improved compression technique (ARC has stopped keeping up with the latest techniques). However, the authors of PKARC have offered a patch (pkarc 3.4) to permanently disable squashing (without the patch you could prevent squashing with a switch) making it totally compatible with the outdated techniques used by ARC. The latest version (pkarc 3.5) allows you to create a config file (pkarc.cfg) and place a variable in the dos environment to tell pkarc where to find this file. In the file you can specify SQUASH=ENABLE or SQUASH=DISABLE. You can also specify the method of date stamping. ================================================================ Now the argument: I have used PKARC and think it is an amazing program. It is fast, but its incorporation of the SQUASHED file format into the standard ARC file can create MASS CONFUSION. I help to run a large IBM bulletin board on a national timesharing service, and it has been my experience that "ARC" files that cannot be unARC'd by either ARC.EXE or ARCE.COM are not well received. An ARC file with SQUASHED members is like an EXE file that cannot be run on MS-DOS. If the moderator of comp.binaries.ibm.pc is suggesting that PKARC (with SQUASHING) is to be the standard, that is very unfortunate. It is also unnecessary. ================================================================ The solution: Vern Buerg, author of the best Public Domain (now, alas, shareware) program ever (LIST.COM) has written three programs that make using ARC files very easy. ARCA.COM adds files to ARChives. ARCE.COM takes them out, and ARCV.COM lists the directories. These programs are written in assembly language, and are small and extremely fast. They are also COMLETELY STANDARD in their behavior. They are not quite as fast as the newest PKARC, but they are very, very close. I will post these programs to comp.binaries.ibm.pc. I urge the moderator of comp.binaries.ibm.pc to standardize on ARC files without SQUASHING. There is little to be gained, but much to be lost by allowing these non-standard files. I don't care if people use PKARC: just be sure it is in a compatible mode. I urge others to urge the same!!! -- Paul Homchick Chimitt Gilman Homchick, Inc.; One Radnor Station, Suite 300; Radnor, PA 19087 {seismo!bpa | ihnp4!cbmvax} !vu-vlsi!cgh!paul
feg@clyde.ATT.COM (Forrest Gehrke) (07/01/87)
Why all this refusal to accept improvements and innovation? Are we turning into a bunch of Luddites? I think Phil Katz is doing a fantastic job. He has included several means for turning off squashing if not desired. But even C standards have been subject to change--hopefully for improvements. Sure, there will be some confusion initially, but these things can be accommodated eventually. Many BBS are adopting PKARC with squashing as their standard method of archiving because it reduces file size and for its speed. Come on guys, get with it!! Forrest Gehrke
jvc@mirror.UUCP (07/02/87)
Those out there who are so resistent to adding a new technique to the "standard" must have been just as upset when ARC added "crunching" (it started out with only squeeze) and then again when they added "Crunching" (same name but with a capital "c", a slightly different and more effective technique). Each time Seaware made an improvement or added a new technique they kept the same extention. And, of course, old versions of ARC couldn't handle these new techniques. jvc@mirror.TMC.COM How many of those complaining about pkarc are using an old version of ARC? (I think the current version of ARC is 5.2)
IKS@PSUVM.BITNET (Indra K. Singhal) (07/02/87)
I have seen too many people suggest negative solutions to this ARC-PKARC
confusion:
eg: "IF people stopped using PKARC, we would not have this problem", some-
one suggested. "Disable SQUASHING", someone else suggested...
On the contrary, if everyone used PKARC (even renamed it to ARC (sic dont
do that)) and used it exclusively, WE WOULD HAVE NO PROBLEMS too !!!
Think about it. PKARC is compatible with SEA-ARC, not vice-versa. Use
PKXARC and you will only get the benifits of speed & it will always work !
NOTE: Flames -----> my bit bucket. Discussions ---> entertained.
-------
Keep Smiling (-:-) --Indra K. Singhal
>> <<
>> email : psuvm.bitnet!iks | bitnet: iks at psuvm <<
>> usmail: 1300 Fayette Street # 243, <<
>> Conshohocken, PA 19428-1320. <<
>> ring : 215-646-7710 (w), 215-828-1322 (h) <<
w8sdz@brl-smoke.ARPA (Keith B. Petersen ) (07/04/87)
If SEA and Vernon Buerg won't see the usefulness in the more efficient
compression (on some files) of squash, why should we all suffer? Who
says SEA is the "standard"? Since PKARC is 6 times faster than ARC and
faster than ARCA/ARCE, why do we continue to use the slower programs?
Maybe it's because Phil Katz hasn't released the source code? I haven't
seen any source code released for Buerg's programs, and there has been
no release that I know of for ARC521 source.
SEA, during the early history of ARC, revised the "standard" to include
more efficient compression methods. It did generate some complaints
from users who didn't have the latest version. I suggest that PKARC is
no different.
--
Keith Petersen
Arpa: W8SDZ@SIMTEL20.ARPA
Uucp: {bellcore,decwrl,harvard,lll-crg,ucbvax,uw-beaver}!simtel20.arpa!w8sdz
GEnie: W8SDZallbery@ncoast.UUCP (Brandon Allbery) (07/04/87)
As quoted from <16207IKS@PSUVM> by IKS@PSUVM.BITNET (Indra K. Singhal): +--------------- | I have seen too many people suggest negative solutions to this ARC-PKARC | confusion: | eg: "IF people stopped using PKARC, we would not have this problem", some- | one suggested. "Disable SQUASHING", someone else suggested... | | On the contrary, if everyone used PKARC (even renamed it to ARC (sic dont | do that)) and used it exclusively, WE WOULD HAVE NO PROBLEMS too !!! | Think about it. PKARC is compatible with SEA-ARC, not vice-versa. Use | PKXARC and you will only get the benifits of speed & it will always work ! +--------------- I have made PKARC the standard for comp.binaries.ibm.pc because it is (a) fast and (b) it makes smaller files, courtesy squashing. This is nearly a necessity for me, as ncoast is at a space premium; we just got thrown willy- nilly into being the N.E. Ohio "backbone" and we're hurting for space!!! BTW, on a similar subject: I can no longer do archiving for *.binaries.*.pc due to the space problem. Can those who are archiving it please send me mail so I can give directions to people who ask for re-mails? (I will get out what requests I have before I wipe the current archives.) ++Brandon -- ---- Moderator for comp.sources.misc and comp.binaries.ibm.pc ---- Brandon S. Allbery <BACKBONE>!cbosgd!hal!ncoast!allbery ('til Aug. 1) aXcess Company {ames,mit-eddie,harvard,talcott}!necntc!ncoast!allbery 6615 Center St. #A1-105 {well,sun,pyramid,ihnp4}!hoptoad!ncoast!allbery Mentor, OH 44060-4101 necntc!ncoast!allbery@harvard.HARVARD.EDU (Internet) +01 216 974 9210 ncoast!allbery@CWRU.EDU (CSnet -- if you dare) NCOAST ADMIN GROUP Brandon Allbery on 157/504 (Fidonet/Matrix/whatever) * ncoast -- Public Access UN*X -- (216) 781-6201, 24 hrs., 300/1200/2400 baud * * ncoast is proud to be carrying alt.all -- contact me for more information *
NU013809@NDSUVM1.BITNET (Greg Wettstein) (07/04/87)
I have been following the controversy regarding utilitzation of Phil Katz's
program for some time now and frankly I am somewhat concerned. This reply
will probably entitle me to a great number of flames but I would like to come
out in favor of Phil and his new programs. I have had the opportunity to
visit with him via Loren Jones' Bulletin Board here in Fargo and I find Phil
to be a very reasonable person, who if you questioned him closely, would
probably consider releasing the PK series of programs one of the biggest
mistakes of his career.
Phil worked very hard to come up with a series of improvements to what is
probably the most universally used program by the PC and BBS community. He
not only provided a tremendous speed improvement but also added squashing
which I find to provide a very significant compression factor in my large
FORTRAN and C program source files. I have yet to see anyone who has really
come out and congratulated him on a very fine accomplishment. He has been
maligned, rumors have been spread about him and his program has been the
subject of what I consider almost malicious treatment. People have gone so
far as to suggest that his program poses a threat to hard disk data structures
which it has never been proven to do.
The incorporation of SQUASHING seems to be the primary objection which people
have to the PK series of archival programs. I think Phil knew this when he
wrote PK.. and very reasonably offered command level control and environmental
control switches to disable this if people did not like to use it. People in
general seem to have ignored this and continually complain about the presence
of SQUASHING when it can be very conveniently disabled. Even if a SQUASHED
file is received by someone, considering how widespread Phil's programs are, I
can hardly believe that anyone with enough knowledge to download a file would
not have a copy of PKXARC around to unpack the file. Since Phil's program
handles the standard SEA arc format quite well I just keep his program around
and that pretty well solves all the problems. If the file has been SQUASHED
there is no problem, if not it gets unpacked as well only about 6x faster.
I guess my biggest concern over this whole controversy is what it says about
the micro-computer hobby/industry as a whole. I see the future for good public
domain/shareware software growing dim in the light of this debate. Everyone
seems to concede that he wrote a fine program but there doesn't seem to be any
reward for doing this, only condemnation and second guessing. If the
microcomputer industry as a whole was this afraid of change we would still be
dosing DOS 1.0 with no pathnames, 8 sector floppies, primitive software and
little or no graphics (EGA, CGA) capabilities.
produced when people strive to produce a better product. Our industry is going
Progress in any field is only achieved when individuals or concerns attempt
to improve upon the performance of existing techniques or products. Our
industry and the tremendous change it has produced in society as a whole is
the result of people striving to improve upon the standard. If this industry
gets the reputation of stagnation or unwillingness to change due to sheer
stubborness or jealousy we will no longer be able to advance as we have in the
last seven years. I actively seek out new software and technology and I feel
that since my job exists because of these advances my continued success will
be due to my ability to learn new things and take advantage of the edge that
these techniques give me in terms of increased and enhanced productivity.
I would like to conclude by congratulating Phil on a very fine accomplishment.
I also hope that he continues to improve on an already fine product.
As always,
G.W. Wettstein
The usual disclaimers apply. These are my opinions and in no way reflect the
opinions of the North Dakota State University Quantum Chemistry Research
Group.
-----------------------------------------------------------------------------egray@fthood.UUCP (07/04/87)
Yeh, but you're missing an important point... ARC is available in source form!!! I have it running on 4 different Unix boxes. If PKARC can do that, I'll gladly switch.
gmd1@ihlpf.ATT.COM (Doughty) (07/05/87)
In article <10710@clyde.ATT.COM>, feg@clyde.ATT.COM (Forrest Gehrke) writes: > > Why all this refusal to accept improvements and innovation? Are > we turning into a bunch of Luddites? > > etc. > > Come on guys, get with it!! > > Forrest Gehrke There is one very important difference between ARC and PKARC. The author's of ARC have released the sources. Consequently ARC can be ported onto other systems (such as UNIX) without writing an equivalent program from scratch. Thus ARC'd files are portable between many different machines while PKARC files are restricted to the PC. That along should justify PKARC using a different file extension than '.arc'. Greg Doughty ihnp4!ihlpf!gmd1
jdia@osiris.UUCP (Josh Diamond) (07/07/87)
I agree that Squashing is a good idea, and that PKARC/PKXARC are good
programs.
But if Phil Katz is such a great dude, why won't he let us get a compatible
arc on unix? He could publish a full description of the new compression
technique, and the format of the new arc file. At he very least he could
create a unix version himself. That way he could keep all of the profits :-)
Just a thought from...
Spidey!!!
--
DON'T PANIC!!! /\ Josh /\ At last! a
//\\ .. //\\ spider that
A message from Spidey, and the Spidey Team. ----->>> //\(( ))/\\ looks like
Available via UUCP: ...[seismo,mimsy]!jhu!osiris!jdia / < `' > \ a spider!brianc@cognos.uucp ( Brian Campbell ) (07/07/87)
In article <10710@clyde.ATT.COM> feg@clyde.ATT.COM (Forrest Gehrke) writes:
!
! Why all this refusal to accept improvements and innovation? Are
! we turning into a bunch of Luddites? I think Phil Katz is doing
! a fantastic job. He has included several means for turning off
! squashing if not desired. But even C standards have been
! subject to change--hopefully for improvements. Sure, there
! will be some confusion initially, but these things can be
! accommodated eventually. Many BBS are adopting PKARC with
! squashing as their standard method of archiving because it
! reduces file size and for its speed.
!
! Come on guys, get with it!!
!
! Forrest Gehrke
Improvement and innovation is great!
The space and time savings from using PKARC have made it *the* file
archiving program of choice on all Ottawa area Fido's and PC Boards (and, no
doubt, on almost every board where the sysop is not paid for his time or
equipment). I saved in excess of 2 megabytes of disk storage when I converted
all my archives using PKARC (due mostly to squashing although crunching is
sometimes better than SEA's).
The point here, is that while squashing may be incompatible, it is saving
a *LOT* of disk space on a *LOT* of BBS's, not to mention slightly decreased
download (and upload) times.
The increased speed of PKARC is a blessing, but one I could live without
for the sake of compatibility -- if that were the only issue. As it is, the
speed is an added bonus.
Some boards have adopted a 'PKA' extension to make it crystal clear that
PKXARC is needed to extract the files in a particular archive (though this is
really only necessary if PKARC squashes one or more of the files). What more
could anyone want?
The only problem with all of this innovation is that it hasn't yet
filtered down (up?) to usenet. I have been running ARC on the Sun where I
read the news for quite awhile now. But recently, some of the ARC'd files
coming over the net have had squashed files in them to which ARC complains
that "I need a newer version of ARC". No problem, I can just transfer them to
my PC and unarc them there. Not an incredible problem, but a time waster.
I'd like to be able to extract the files on the Sun, or Vax, or DG, or
whatever machine I happen to be on. So ...
Where is the source for this "squashing" algorithm. Does anyone have an
"unsquasher" written in C? Has anyone modified the existing ARC source to
handle squashing? Help!
--
Brian Campbell uucp: decvax!utzoo!dciem!nrcaer!cognos!brianc
Cognos Incorporated mail: 3755 Riverside Drive, Ottawa, Ontario, K1G 3N3
(613) 738-1440 fido: sysop@163/8caf@omen.UUCP (Chuck Forsberg WA7KGX) (07/07/87)
In article <2779@ncoast.UUCP> allbery@ncoast.UUCP (Brandon Allbery) writes:
:I have made PKARC the standard for comp.binaries.ibm.pc because it is (a) fast
So post the source code for the Unix "arc" modules needed to decode squashed
files already.
Or is encryption your bag?
Chuck Forsberg WA7KGX Author of Pro-YAM communications Tools for PCDOS and Unix
...!tektronix!reed!omen!caf Omen Technology Inc "The High Reliability Software"
17505-V Northwest Sauvie Island Road Portland OR 97231 Voice: 503-621-3406
TeleGodzilla BBS: 621-3746 2400/1200 CIS:70007,2304 Genie:CAF Source:TCE022
omen Any ACU 1200 1-503-621-3746 se:--se: link ord: Giznoid in:--in: uucp
omen!/usr/spool/uucppublic/FILES lists all uucp-able files, updated hourlyrgale@pnet01.CTS.COM (Ryan Gale) (07/08/87)
Greg Wettstein writes > I have yet to see anyone who has really come out and congratulated [Phil > Katz] on a very fine accomplishment. You mean, here on the net? OK: thanks, Phil! But so what? I showed *my* thanks by sending him a check. Talk's cheap. --- Ryan Gale UUCP: {hplabs!hp-sdd, sdcsvax, nosc}!crash!pnet01!rgale ARPA: crash!pnet01!rgale@nosc.mil INET: rgale@pnet01.CTS.COM
vg55611@ihuxy.UUCP (07/08/87)
In article <1262@osiris.UUCP>, jdia@osiris.UUCP (Josh Diamond) writes: > But if Phil Katz is such a great dude, why won't he let us get a compatible > arc on unix? He could publish a full description of the new compression > technique, and the format of the new arc file. At he very least he could > create a unix version himself. That way he could keep all of the profits :-) > Just a thought from... > Spidey!!! Really, ladies and gentlemen - Let's not get kill or idolize personalities here - after all, most of have an inkling of rationality within us. Let us look at the issue, not the people. It is up to us to determine whether to use PKARC or not. It seems to me that most people who post would think of NOT using squashing so as to reach the maximum number of people (otherwise, why post it ?) given the current controversy. Also, seems to me that the major objection to squashing is that it is an unpublished algorithm and, if the creator of an algorithm wants it to become a standard, it has to be a known algorithm. Venu P. Gopal ihnp4!ihuxy!vg55611
bobmon@iucs.UUCP (07/08/87)
jdia@osiris.UUCP (Josh Diamond) writes: > >I agree that Squashing is a good idea, and that PKARC/PKXARC are good >programs. > >But if Phil Katz is such a great dude, why won't he let us get a compatible >arc on unix? He could publish a full description of the new compression >technique, and the format of the new arc file. At he very least he could >create a unix version himself. That way he could keep all of the profits :-) Perhaps Mr. Katz doesn't have access to a Unix box, or to these newsgroups. It's not quite impossible that he's completely unfamiliar with VAXlike environments... While you're waiting for your flamethrowers to get up to operating temperature, consider that SEA's ARC was written in "portable" C. I recall reading that PKARC was/is written in MASM, for speed. If so, that would make it highly non-portable.
caf@omen.UUCP (Chuck Forsberg WA7KGX) (07/09/87)
In article <231NU013809@NDSUVM1> NU013809@NDSUVM1.BITNET (Greg Wettstein) writes:
:I guess my biggest concern over this whole controversy is what it says about
:the micro-computer hobby/industry as a whole. I see the future for good public
:domain/shareware software growing dim in the light of this debate. Everyone
:seems to concede that he wrote a fine program but there doesn't seem to be any
:reward for doing this, only condemnation and second guessing. If the
:microcomputer industry as a whole was this afraid of change we would still be
:dosing DOS 1.0 with no pathnames, 8 sector floppies, primitive software and
:little or no graphics (EGA, CGA) capabilities.
Such comments are appropriate for an editor or disk maintenance utility.
But, for the Usenet community, the purpose of ARC programs is to expedite
the transfer of data between computer systems. The ARC program, crufty as
it is, serves a useful function by virtue of the fact that it has been
made to operate (after a fashion) on many different computer systems.
PKARC proposes to supplant this "compressed Esperanto" with a unique,
incompatible, dialect. That's fine for files that will never be used on
any computer other the one on which the files were written.
So, I welcome any advances in compression techniques which PKARC or any
other program might be capable of.
But, please don't post files that have been ENCRYPTED by such programs
until the decoding programs are generally available.
:I would like to conclude by congratulating Phil on a very fine accomplishment.
:I also hope that he continues to improve on an already fine product.
Adding what amounts to efficient encryption to PKARC is a dubious
accomplishment in the context that ARC is used on the net.
If Phil's new and improved compression is to be acknowledged as a contribution
to the net, portable C source code to deal with squashed archives must be
made available to update the Unix ARC programs.
ARC programs constitute a class of software that places special
obligations on software hackers to support their creations with public
release of compatible.dbercel@sun.UUCP (07/09/87)
In article <2022@ihuxy.ATT.COM> vg55611@ihuxy.ATT.COM (gopal) writes: >objection to squashing is that it is an unpublished algorithm and, if >the creator of an algorithm wants it to become a standard, it has to be a >known algorithm. > >Venu P. Gopal >ihnp4!ihuxy!vg55611 I'm finding that on the majority of systems in the bay area PKARC with squashing is indeed becoming the standard. In some cases SYSOPS are announcing this in logon bulletins but in a few cases they are not. My personal preference is to use PKARC and PKXARC for everything I do because the speed is impressive. However, it does appear that with, or without, published specs it is starting to become the standard. At least around my area it appears to be. Is anyone else experiencing this? danielle
jvc@mirror.UUCP (07/09/87)
>In article <2779@ncoast.UUCP> allbery@ncoast.UUCP (Brandon Allbery) writes: >:I have made PKARC the standard for comp.binaries.ibm.pc because it is (a) ^^^^^ ^^^^^^^^ ^^^ ^^^^^^^^^^^^^^^^^^^^ > >So post the source code for the Unix "arc" modules needed to decode squashed >files already. > >Or is encryption your bag? > >Chuck Forsberg WA7KGX Author of Pro-YAM communications Tools for PCDOS and Unix Why would you want to decode MS/PC-DOS *binaries* on a non-MS/PC-DOS machine??? Remember, binaries will only run on the machine they were designed for; if you can run the binaries on your UNIX machine then you can run PKARC to unpack them. :-)
jdia@osiris.UUCP (Josh Diamond) (07/09/87)
In article <4591@iucs.UUCP>, bobmon@iucs.UUCP (Che' Flamingo) writes: > jdia@osiris.UUCP (Josh Diamond) writes: > >But if Phil Katz is such a great dude, why won't he let us get a compatible > >arc on unix? He could publish a full description of the new compression > >technique, and the format of the new arc file. At he very least he could > >create a unix version himself. That way he could keep all of the profits :-) > > Perhaps Mr. Katz doesn't have access to a Unix box, or to these newsgroups. > It's not quite impossible that he's completely unfamiliar with VAXlike > environments... > > While you're waiting for your flamethrowers to get up to operating temperature, > consider that SEA's ARC was written in "portable" C. I recall reading that > PKARC was/is written in MASM, for speed. If so, that would make it highly > non-portable. I seem to recall that my original request was that he PUBLISH THE FORMAT OF HIS NEW COMPRESSION SCHEME so that *WE* CAN DESIGN A COMPATIBLE ARCer for unix or vms or whatever. Publish does not mean post; for all I care he can sell a book about it, or sell an article about it to one of the PC magazines The question here is not speed. I don't care about the speed -- on a real machine like a vax, or a pyramid, the gain of going to assembly isn't necessary. The problem is that *I* would like to have a squashing compatible arc on systems other than MeSs-DOS/IBM-PieceofCrap, because it would be even faster than pkarc, and because I like squashing, and because I like to archive my files on a unix system, to take some of the load off of my IBM-PieceofCrap's measly small hard disk. 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 / < `>command
NU013809@NDSUVM1.BITNET (Greg Wettstein) (07/10/87)
Loren Jones here in Fargo has a well known BBS where a lot of the who's who
in the PC community hang their hats, eg. John Friel III, Phil Katz, V. Buerg
etc.
Loren's Board was one of the first places that Phil released the PK series of
programs. When Loren heard about SQUASHING he was immediately concerned about
compatibility problems and suggested that Phil release information on the
SQUASHING algorithm. If memory serves me correctly Phil posted a message on
the board that describes the SQUASHING technique and algorithm.
I will contact Loren here in Fargo to find out if the information is still
available. If it is I will pick it up off the board and post it to the
NET.
As always,
G.W. Wettstein
NU013809@NDSUVM1
jjboritz@watdragon.UUCP (07/11/87)
In article <23007@sun.uucp> dbercel@sun.UUCP (Danielle Bercel, MIS Systems Programming) writes: >In article <2022@ihuxy.ATT.COM> vg55611@ihuxy.ATT.COM (gopal) writes: >I'm finding that on the majority of systems in the bay area PKARC >with squashing is indeed becoming the standard. In some cases >SYSOPS are announcing this in logon bulletins but in a few cases >they are not. > >My personal preference is to use PKARC and PKXARC for everything >I do because the speed is impressive. However, it does appear >that with, or without, published specs it is starting to become >the standard. At least around my area it appears to be. Is >anyone else experiencing this? > >danielle Well in the Kitchener-WATERLOO-Guelph-Cambridge area PKARC has also become the standard. I'll leave Bill out this time. Ack!
caf@omen.UUCP (Chuck Forsberg WA7KGX) (07/11/87)
In article <206900054@mirror> jvc@mirror.UUCP writes:
:Why would you want to decode MS/PC-DOS *binaries* on a non-MS/PC-DOS
:machine???
Because .ARC files contain more than binaries, for openers. With
executables, I often wish to look at them on the Xenix system for
Trojan Horses, Copyright notices, etc.
Sometime RSN VP/ix or whatever this year's name for DOS partition under
Xenix will appear, but the problem will still apply to most Unix systems.guest@vu-vlsi.UUCP (visitors) (07/12/87)
In article <23007@sun.uucp> dbercel@sun.UUCP (Danielle Bercel, MIS Systems Programming) writes: >I'm finding that on the majority of systems in the bay area PKARC >with squashing is indeed becoming the standard. In some cases >SYSOPS are announcing this in logon bulletins but in a few cases >they are not. > >My personal preference is to use PKARC and PKXARC for everything >I do because the speed is impressive. However, it does appear >that with, or without, published specs it is starting to become >the standard. At least around my area it appears to be. Is >anyone else experiencing this? I also use the PK* software for handling all of the ARCing precisely since many of the BBS's in my area [around Philadelphia] are doing just this--only using/supporting PK*. Since I don't like to keep many different programs that do the same thing all over my hard disk and using trial and error, I decided to keep only the PK* programs for this purpose. However, if I send/post something that is intended to be used on machines other than a PC (i.e. machines like a VAX with ARC programs that don't support squashing) I don't squash them. What I don't understand is all of the complaining about using PK* in the comp.binaries.ibm.pc newsgroup. Practically everyone and his/her cousin has either PKARC or knows someone who does if they own a PC. So, if the moderator stated in the administrivia that PKARC is supposed to be used, don't be so stupid as to use SEA's ARC program. MORAL: when all else fails, read the directions. (Now, where did I put my asbestos underware? :-) ) ============================================================================== | Mark Schaffer | BITNET: 164485913@vuvaxcom | | Villanova University | UUCP: ...{ihnp4!psuvax1,burdvax,cbmvax,pyrnj,bpa} | | (Go Wildcats!) | !vu-vlsi!excalibur!164485913 | ============================================================================== please respond/reply to the above addresses and not to guest@vu-vlsi.UUCP
dmimi@ecsvax.UUCP (Miriam Clifford) (07/13/87)
It is well and good to say (as several have said) that one can use pkarc as long as the .arc files are not put on any non-ibm/clone machines. The problem is that one can't tell what machines a give file will end up on. For example, I up- and down-load to several different bulletin boards, including fido type boards as well as this usenet unix board. Keeping track of which board has which files is hard enough without worrying about whether or not the files are arc or pkarc. If pkarc used a different extension the whole problem would become simpler.
NU013809@NDSUVM1.BITNET (Greg Wettstein) (07/13/87)
I had commented before that I thought that Phil Katz had published some
information on the SQUASHING algorithm when he released it to Loren Jones'
board in Fargo. He did this in response to Loren's concern about the presence
of the new (and unsupported in other utilities) SQUASHING technique.
I logged onto the board and found the document which I am enclosing from Phil
concerning the SQUASHING technique.
I am sure the document is not as complete as some people would like, especially
since it does not actually have any code with it but it does give some
references which may prove helpful. I hope the following information is
helpful in reducing the PK <--> ARC controversy.
As always,
G.W. Wettstein
NU013809@NDSUVM1
############################################################################
$$$$$$$$$$$$$$$$$$$$$$$$$$$$ SQUASH DOCUMENTATION $$$$$$$$$$$$$$$$$$$$$$$$
############################################################################
The purpose of this document is to detail the format of "squashed"
files created by PKARC version 2.0 or later. This document assumes
some basic knowledge of existing ARC formats and various compression
techniques. For more information consult the references listed at the
end of this document.
The general format for an ARC file is:
archive-mark + header_version + file header + file data... +
archive-mark + end-of-arc-mark
The archive-mark is 1 byte and is the value 1A hex. The file header
can be defined by the following 'C' structure, and is 27 bytes in size.
typedef struct archive_file_header
{ char name[13]; /* file name */
unsigned long size; /* size of compressed file */
unsigned short date; /* file date */
unsigned short time; /* file time */
unsigned short crc; /* cyclic redundancy check */
unsigned long length; /* true file length */
};
The name field is the null terminated file name.
The size is the number of bytes in the file data area following the
header.
The date and time are stored in the same packed format as a DOS
directory entry.
The CRC is a 16-bit CRC on the file data area based on a CRC polynomial
from the article by David Schwaderer in the April 1985 issue of PC
Technical Journal.
The length is the actual uncompressed size of the file.
The header versions are defined as follows:
Value Method Notes
----- -------- -------------------------------
0 - This is used to indicate the end of the archive.
1 Stored (obsolete) (note 1)
2 Stored The file is stored (no compression)
3 Packed The file is packed with non-repeat packing.
4 Squeezed The file is squeezed with standard Huffman squeezing.
5 crunched The file was compressed with 12-bit static Ziv-Lempel-
Welch compression without non-repeat packing.
6 crunched The file was compressed with 12-bit static Ziv-Lempel-
Welch compression with non-repeat packing.
7 crunched (internal to SEA) same as above but with different
hashing formula.
8 Crunched The file was compressed with Dynamic Ziv-Lempel-Welch
compression with non-repeat packing. The initial
ZLW code size is 9-bits with a maximum code size
of 12-bits (note 2). An adaptive reset is used
on the ZLW table when it becomes full.
9 Squashed The file was compressed with Dynamic Ziv-Lempel-Welch
compression without non-repeat packing. The initial
ZLW code size is 9-bits with a maximum code size
of 13-bits (note 3). An adaptive reset is used
on the ZLW table when it becomes full.
Note 1:
For type 1 stored files, the file header is only 23 bytes in size,
with the length field not present. In this case, the file length
is the same as the size field since the file is stored without
compression.
Note 2:
The first byte of the data area following the header is used to
indicate the maximum code size, however only a value of 12 (decimal)
is currently used or accepted by existing ARC programs.
Note 3:
The algorithm used is identical to type 8 crunched files with the
exception that the maximum code size is 13 bits - i.e. an 8K entry
ZLW table. However, unlike type 8 files, the first byte following
the file header is actual data, no maximum code size is stored.
References
----------
Source code for ARC 5.0 by Tom Henderson of Software Enhancement Associates,
usually found in a file called ARC50SRC.ARC.
Source code for general Ziv-Lempel-Welch routines by Kent Williams, found
in a file LZX.ARC. Kent Williams work is also referenced in the SEA
documentation.
Source code and documentation from the Unix COMPRESS utilities, where most
of the ZLW algorithms used by SEA originated, found in a file called
COMPRESS.ARC.
Ziv, J. and Lempel, A. Compression of individual sequences via
variable-rate coding. IEEE Trans. Inform. Theory IT-24, 5 (Sept. 1978),
530-536.
The IBM DOS Technical Reference Manual, number 6024125.
- Phil Katz, 12/27/86
#############################################################################
$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
Disclaimer: This document travelled through more than a couple of computers
on its way to the NET. Any errors may be the result of any
number of translation difficulties. GW
jvc@mirror.UUCP (07/13/87)
>In article <206900054@mirror> jvc@mirror.UUCP writes: >:Why would you want to decode MS/PC-DOS *binaries* on a non-MS/PC-DOS >:machine??? > >Because .ARC files contain more than binaries, for openers. With >executables, I often wish to look at them on the Xenix system for >Trojan Horses, Copyright notices, etc. >... Like what? The archived binaries in the comp.binaries.ibm.pc will contain DOC files and maybe some text data files but this would be of no use unless you could run the programs (which means you need MS/PC-DOS whether or not MS-DOS is run as a process under Unix or not). If you can run the binaries, then you can run PKARC to unpack them. As for using Xenix system to look for Trojan Hourses, Copyright notices, etc, you can do that after you've unpacked it using MS/PC-DOS (if you can run it, then there's no need to check such things). Why would it be necessary to do the unpacking on a UNIX machine to reach this goal? jvc@mirror Are the people resisting PKARC the same ones who resisted ARC when it first came out (because it was a change) but now are happy with ARC?
dragon@oliveb.UUCP (Give me a quarter or I'll touch you) (07/14/87)
in article <206900056@mirror>, jvc@mirror.UUCP says: > Like what? The archived binaries in the comp.binaries.ibm.pc will > contain DOC files and maybe some text data files but this would be > of no use unless you could run the programs (which means you need > MS/PC-DOS whether or not MS-DOS is run as a process under Unix or not). > If you can run the binaries, then you can run PKARC to unpack them. > As for using Xenix system to look for Trojan Hourses, Copyright > notices, etc, you can do that after you've unpacked it using > MS/PC-DOS (if you can run it, then there's no need to check such things). > Why would it be necessary to do the unpacking on a UNIX machine to reach > this goal? Apparently you don't have ARC for the machine you receive news on. UnARCing the binaries on UNIX is QUITE helpful in a number of ways. First one can tell if the archive is intact (no downloading for an hour to get 'CRC error' or some other problem). One could look at the text files, and since one would probably have a PC too, one could run them after printing out the docs on UNIX :-). Just take the word of those who have tried it, UNIX ARC is useful to MS-DOS users. > jvc@mirror > Are the people resisting PKARC the same ones who resisted ARC when it > first came out (because it was a change) but now are happy with ARC? I support PKARC fully... what I really want is UNIX ARC to be compatible, and archives that have squashed contents to be easily recognizable so I know which program to use! (Vern Buerg's ARCE is just about as fast, and easier to use than PKARC...) -- Dean Brunette {ucbvax,etc.}!hplabs!oliveb!olivej!dragon Olivetti Advanced Technology Center _____ _____ __|__ _____ 20300 Stevens Creek Blvd. | | _____| | | Cupertino, CA 95014 |_____| |_____| |__ |_____
allbery@ncoast.UUCP (Brandon Allbery) (07/14/87)
As quoted from <1069@cognos.UUCP> by brianc@cognos.uucp ( Brian Campbell ): +--------------- | Some boards have adopted a 'PKA' extension to make it crystal clear that | PKXARC is needed to extract the files in a particular archive (though this is | really only necessary if PKARC squashes one or more of the files). What more | could anyone want? +--------------- If someone will post the source (or algorithm, even) for squashing, I am willing to add it to the System V arc. I will also start converting the uuencodes to extract to *.PKA to indicate PKARC. Further than this... Space savings applies not only to BBS (and ncoast) disk space, but also to download time... and, more importantly, net transfer costs, especially if the FCC has its wonderful way. Ncoast got the experience of being a (local) backbone for a weekend; I now have a healthy respect for the backbone sites and what phone bills they must pay. If I'm going to throw huge binaries at them, I should at least have the consideration to make them as small as possible; for a single binary it's not much, but for Hack parts 1-8, or for the entire list of submissions, it adds up. In this age of cursing the backbone, people ought remember what will happen to the Usenet if they can or will no longer operate. (With which I retire this particular discussion to news.admin.) -- [Copyright 1987 Brandon S. Allbery, all rights reserved] \ ncoast 216 781 6201 [Redistributable only if redistribution is subsequently permitted.] \ 2400 bd. Brandon S. Allbery, moderator of comp.sources.misc and comp.binaries.ibm.pc {{ames,harvard,mit-eddie}!necntc,{well,ihnp4}!hoptoad,cbosgd}!ncoast!allbery <<The opinions herein are those of my cat, therefore they must be correct!>>
jvc@mirror.UUCP (07/14/87)
Dean Brunette writes: >Apparently you don't have ARC for the machine you receive news on. ... >one can tell if the archive is intact (no downloading for an hour to get >'CRC error' or some other problem). ... I have ARC but my PC is also etherneted. >(Vern Buerg's ARCE is just about as fast, and easier to use than PKARC...) I thought ARCE was just a quick unarchiver (at least the program I have called ARCE in only an unarchiver) and has the following command format for unarcing a file named "file": ARCE file To unarc the same file with pkxarc the command is: PKXARC file or PKXARC * to unarc all archives in the current directory. What makes ARCE any easier??? jvc@mirror.tmc.com
dragon@oliveb.UUCP (Give me a quarter or I'll touch you) (07/14/87)
in article <206900057@mirror>, jvc@mirror.UUCP says: > I thought ARCE was just a quick unarchiver (at least the program I have > called ARCE in only an unarchiver) and has the following command format for > unarcing a file named "file": > ARCE file > To unarc the same file with pkxarc the command is: > PKXARC file > or > PKXARC * > to unarc all archives in the current directory. > > What makes ARCE any easier??? > > jvc@mirror.tmc.com A hunt & peck typist surely thinks four letters are easier to type than six. That's a 1/3 reduction! :-) But actually, I believe ARCE also accepts wildcards as arguments. My PC is also ethernetted, but it doesn't help me any on the Mac, Atari, and Amiga stuff that comes across that I store in the same directory to test with ARC (on a VAX) before downloading. And I still use PKARC on my PC. -- Dean Brunette {ucbvax,etc.}!hplabs!oliveb!olivej!dragon Olivetti Advanced Technology Center _____ _____ __|__ _____ 20300 Stevens Creek Blvd. | | _____| | | Cupertino, CA 95014 |_____| |_____| |__ rockroc
brianc@cognos.uucp (Brian Campbell) (07/20/87)
The following is a response from Phil Katz (author of PKX?ARC) outlining the "squashing" algorithm: +-- | Brian, | | Squashing is simply a 13-bit version of the standard 12 bit "crunching" | with the important exception that no non-repeat packing is performed. | | If you have a program that does "crunching", it can easily be modified | to do crunching by removing the DLE coding/encoding stuff, declaring | tables to be 8192 entries in size rather than 4096, and adding 13-bit | code sizes to any getcode() or putcode() type of routines. | | Otherwise, it uses the same dynamic code sizes, clear codes, and | everything else as the crunched files. | | >Phil> +-- Armed with this information it should be a relatively simple task to convert the existing versions of SEA's ARC that run under unix to handle squashed files. Alas, probably slower though. -- Brian Campbell uucp: decvax!utzoo!dciem!nrcaer!cognos!brianc Cognos Incorporated mail: 3755 Riverside Drive, Ottawa, Ontario, K1G 3N3 (613) 738-1440 fido: sysop@163/8