crs@cpsc6b.UUCP (07/09/87)
First, let me say that I have NOTHING agianst Phil Katz, PK ARC (in concept), or the adoption of any *new* standards in technology. I Have copies of the latest postings of PKARC and PKXARC from comp.binaries. My problem with PKARC is not the quality of compression, or the speed of execution. It is the incompatibility of the software itself, and the lack of convenient features. When I first downloaded the software, I held my breath in anticipation, having read numerous claims as to the incredible speed of the software. I selected a sizable arc file, and timed the execution of "arc t filename". After recording the results, I proceeded to execute "pkxarc t filename", and to my amazement, the the program was completed in 1 SECOND!!! Only then did I realize that what I actually was looking at was the message: insufficient memory. Interesting, that a ~30K COM file should determine that my 640K PC didn't have enough memory. I started poking around, and found that the problem was not really a lack of memory on my PC's part, but some confused interaction on the part of the software with my environment (I have it expanded to about 450 bytes). I discovered that, in order to run the PK ARC family, I must *completely* wipe out my environment! (I am using an AT&T PC6300, if that has any bearing). After getting the software to work, I then discovered that it apparently (correct me if I am wrong) can't deal with acrhive files outside the current directory. And, as if that weren't enough, PKXARC *requires* that you preface switches with a "/", and doesn't even check the value of SWITCHAR. I have gotten PKARC sort of limping along, but I find these inconveniences almost outweigh the speed and improved compression provided. I would be grateful for any information on how to overcome the problems I am having, as I have seen just how fast PKARC is (38 seconds to create an archive that took over 3 minutes with arc). Also, for any who recall my postings of the System V port of ARC, I would be more than willing to add the Squash algorithm, should it become available. Chris Seaman .signatures? We don't need no steenking .signatures! crs@cpsc6a.ATT.COM or ..!ihnp4!cpsc6a!crs
dbercel@sun.uucp (Danielle Bercel, MIS Systems Programming) (07/09/87)
In article <287@cpsc6b.cpsc6a.att.com> crs@cpsc6b.cpsc6a.att.com (C. R. Seaman) writes: > >Interesting, that a ~30K COM file should determine that my 640K PC didn't >have enough memory. I started poking around, and found that the problem >was not really a lack of memory on my PC's part, but some confused >interaction on the part of the software with my environment (I have it >expanded to about 450 bytes). I discovered that, in order to run >the PK ARC family, I must *completely* wipe out my environment! (I >am using an AT&T PC6300, if that has any bearing). > >After getting the software to work, I then discovered that it apparently >(correct me if I am wrong) can't deal with acrhive files outside the >current directory. And, as if that weren't enough, PKXARC *requires* that >you preface switches with a "/", and doesn't even check the value of >SWITCHAR. > >I have gotten PKARC sort of limping along, but I find these inconveniences >almost outweigh the speed and improved compression provided. > >I would be grateful for any information on how to overcome the problems >I am having, as I have seen just how fast PKARC is (38 seconds to create >an archive that took over 3 minutes with arc). > You have described an environment that is *NOT* anywhere close to my experience with PKARC and PKXARC. I run Phil's programs on my XT and everything is fine. The environment doesn't have to be changed and everything I've set for other programs remains unchanged. Paths are no problem and I have never encountered a situation when I could not use a path name. For example, I have a directory called \tmp. This is the directory where all my downlods go. However, I usually extract files into other directories. The following command works perfectly using PKXARC: pkxarc arcname \dirname\dirname From the various system I access, and the people I've spoken to, nobody has been reporting the problems with PKARC and PKXARC that you are having. Perhaps the environment problem is related to your AT&T PC6300. danielle -- UUCP: {hplabs,decvax,}!sun!toto!{danielle,dbercel} /-------------------------------------\ | Toto, I don't think this is Kansas. | -- Danielle Bercel \-------------------------------------/ Sun Microsystems, Inc.
jio@cpsc55.UUCP (James Odom) (07/09/87)
I do not know what is causing the problems you are experiencing. My PC is PC6300, 640K, 10-M hard drive, 360K floppy. Currently, I am using MS-DOS 3.2. The only problems I have had using either ARC512 or PK[X]ARC on any file has been related to bad or incomplete copies getting to our site. I have patched COMMAND.COM under MS-DOS 2.11 for the maximum environment space I could have running 2.11. I have recently upgraded to MS-DOS 3.2 R1.02 and have the maximum environment space I can get. I have no problem using the PK[X]ARC programs. I have several TSR programs that load from the autoexec.bat file. After booting the PC, I have about 475K free memory. I did have an occasional problem under DOS 2.11 with programs not freeing up the memory when they terminated. I have not noticed this problem running DOS 3.2. > insufficient memory There are times that I get this message. Usually because of what I am doing. Working in UNIX(TM AT&T), I manage to use up all of the processes available to me quite often. This is carried over to the PC. If I run a word processor(MS WORD Copyright Microsoft), leave it using the "Library" "Run" COMMAND, execute a communications program and log into the 3B5, upload the file I have created in WORD, print it, and ,while waiting for the file to print, try to drop back into DOS on the PC I often get the 'insufficient memory' message. > > After getting the software to work, I then discovered that it apparently > (correct me if I am wrong) can't deal with acrhive files outside the > current directory. And, as if that weren't enough, PKXARC *requires* that > you preface switches with a "/", and doesn't even check the value of > SWITCHAR. > I have not experienced any problem un-arcing files in other directories nor even in sub-directories on drive A: to the current directory on drive C:. I have SWITCHAR set to "-" with no problems. > > Chris Seaman > .signatures? We don't need no steenking .signatures! > crs@cpsc6a.ATT.COM or > ..!ihnp4!cpsc6a!crs AW...Why not.... +------------------------------------------------------------------------+ |James I. Odom | |AT&T-IS CPSC Denver, Co Voice: (303) 889-0211 | |ATTMAIL: JODOM Compuserve: 70070,137 uucp: ihnp4!cpsc55!jio | |------------------------------------------------------------------------| |Disclaimer: Any opinions expressed are my own etc. | +------------------------------------------------------------------------+
dragon@oliveb.UUCP (Give me a quarter or I'll touch you) (07/10/87)
in article <23065@sun.uucp>, dbercel@sun.uucp (Danielle Bercel, MIS Systems Programming) says: > > In article <287@cpsc6b.cpsc6a.att.com> crs@cpsc6b.cpsc6a.att.com (C. R. Seaman) writes: >> >>Interesting, that a ~30K COM file should determine that my 640K PC didn't >>have enough memory. I started poking around, and found that the problem >>was not really a lack of memory on my PC's part, but some confused >>interaction on the part of the software with my environment (I have it >>expanded to about 450 bytes). I discovered that, in order to run >>the PK ARC family, I must *completely* wipe out my environment! (I >>am using an AT&T PC6300, if that has any bearing). lots deleted for brevity... > From the various system I access, and the people I've spoken to, > nobody has been reporting the problems with PKARC and PKXARC that > you are having. Perhaps the environment problem is related to > your AT&T PC6300. > > danielle > I've used PKARC on a PC6300 here for ALONG time and experienced none of the problems mentioned with the latest version (3.5). Sounds like C. R. has a case of the outdated version blues... (possibly?) I've used with an expanded environment both on an AT&T and on clones with no problems. And I require extensive use of paths. Anyhow, most of us find PKARC suitable for our uses just fine, as often times it doesn't cause problems for us. -- Dean Brunette {ucbvax,etc.}!hplabs!oliveb!olivej!dragon Olivetti Advanced Technology Center _____ _____ __|__ _____ 20300 Stevens Creek Blvd. | | _____| | | Cupertino, CA 95014 |_____| |_____| |__ |_____
darrylo@hpsrlc.HP.COM (Darryl Okahata) (07/10/87)
In comp.sys.ibm.pc, dbercel@sun.uucp (Danielle Bercel, MIS Systems Programming) writes: >In article <287@cpsc6b.cpsc6a.att.com> crs@cpsc6b.cpsc6a.att.com (C. R. Seaman) writes: >> >>Interesting, that a ~30K COM file should determine that my 640K PC didn't >>have enough memory. I started poking around, and found that the problem >>was not really a lack of memory on my PC's part, but some confused >>interaction on the part of the software with my environment (I have it >>expanded to about 450 bytes). I discovered that, in order to run >>the PK ARC family, I must *completely* wipe out my environment! (I >>am using an AT&T PC6300, if that has any bearing). >> [ ... ] >You have described an environment that is *NOT* anywhere close to >my experience with PKARC and PKXARC. I run Phil's programs on my XT and >everything is fine. The environment doesn't have to be changed and >everything I've set for other programs remains unchanged. > [ ... ] > >From the various system I access, and the people I've spoken to, >nobody has been reporting the problems with PKARC and PKXARC that >you are having. Perhaps the environment problem is related to >your AT&T PC6300. > >danielle > > > >-- >UUCP: {hplabs,decvax,}!sun!toto!{danielle,dbercel} >/-------------------------------------\ >| Toto, I don't think this is Kansas. | -- Danielle Bercel >\-------------------------------------/ Sun Microsystems, Inc. >---------- I don't know what version I have, but pkarc gives me the same "out of memory" error on my PC -- and I have a true blue PC (64K motherboard). Pkxarc runs fine, however. Pkarc has about 300K of memory in which to play, so I know that the error message is bogus. Perhaps I'll look at it this weekend (maybe) using Periscope; I think the problem may have something to do with the values of the segment registers upon startup (Chris Dunford's PMAP utility says that pkarc is being loaded at segment 0x4030, 0x4040, or somesuch). -- Darryl Okahata hplabs!hpcea!hpsrla!darrylo CompuServe: 75206,3074 Disclaimer: the above is the author's personal opinion and is not the opinion or policy of his employer or of the little green men that have been following him all day.
krause@uicsrd.csrd.uiuc.edu (07/11/87)
/* Written 5:36 pm Jul 8, 1987 by crs@cpsc6b.cpsc6a.att.com in uicsrd:comp.sys.ibm.pc */ /* ---------- "PK ARC, Another View" ---------- */ insufficient memory. Chris Seaman .signatures? We don't need no steenking .signatures! crs@cpsc6a.ATT.COM or ..!ihnp4!cpsc6a!crs /* End of text from uicsrd:comp.sys.ibm.pc */ What you have found is indeed a bug in some older versions of the PK ARC distribution. It is indeed related to the environment size. I would recommend digging up a newer version.... Another thing to watch out for is that PKXARC has trouble de-archiving files that have been corrupted in transmission...hung my machine every time. But dig out ARC and what happens? It unpacks what it can and has a nice error message saying that the archive is corrupt. And it gives me my machine back.... James Krause
jvc@mirror.UUCP (07/14/87)
>Another thing to watch out for is that PKXARC has trouble de-archiving >files that have been corrupted in transmission...hung my machine every >time. But dig out ARC and what happens? It unpacks what it can and >has a nice error message saying that the archive is corrupt. And it >gives me my machine back.... > James Krause All at once now, PLEASE STATE VERSION NUMBERS!!!!! Does the above happen with the current version (PKX35A35.EXE)? Thanks, jvc@mirror.tmc.com [ I have ARC and it has about 50 known bugs and locks up the computer frequently and creates duplicate entries in the archive and ... I suggest that you don't use ARC. At least not the outdated version I'm talking about (version 2.*) ;-) ]
tes@whuts.UUCP (STERKEL) (07/15/87)
In article <206900061@mirror>, jvc@mirror.UUCP writes:
*
*>Another thing to watch out for is that PKXARC has trouble de-archiving
*>files that have been corrupted in transmission...hung my machine every
*>time. But dig out ARC and what happens? It unpacks what it can and
*>has a nice error message saying that the archive is corrupt. And it
*> James Krause
*
*All at once now,
* PLEASE STATE VERSION NUMBERS!!!!!
OK!....!
WARNING WARNING WARNING WARNING WARNING
PKARC 3.5 and PKXARC 3.5 (the latest) hangs my machine so bad that
not even my "cboot" or my "little red switch (boots without dis-
turbing memory)" CANNOT FIX. I LOOSE HOURS OF WORK IN RAMDISK.
WARNING WARNING WARNING WARNING WARNING
DO NOT USE PKARC (ANY VERSION) OR PKXARC (ANY VERSION) IF YOU HAVE
SOMETHING IN RAMDISK. THE MOST MINOR CORRUPTION WILL HANG YOUR
MACHINE SO BAD THAT YOU MUST TURN OFF THE POWER.
Other sins of PK* not found in SEA ARC:
1: Random incompatibility with LIM EMS
2: Random inability to determine how much memory is available
3: Incompatible with some write-through cache programs
4: Will not check if something has been previously archived
and will re-archive. The user is left with the exercise
of figuring out how "deep" the re-re-re-archiving got.
My machines: at home I have an IBM PC-1 (64K Motherboard)
at work I have an AT&T 6300 old model
My environment: very little TRS, especially due to PK*
getting confused about memory available.
PCDOS 3.2 at home, MSDOS 2.11 at work
My testing: insertion/removal of TRS, different config.sys,.
different PCDOS versions, enabling/disabling EMS, different
cache programs, editing one (1) byte of *.ARC file to see
how minor a flaw will cause the fragile PK* to hang the PC,
etc, etc.
All in all, PK* is very fast and poorly engineered for the
reality of PC computing. PC computing is notorious for the
lack of standards and incompatibilities. The caveat emptor
attitude of people selling programs continues to disturb me.
(ooops, I got on that soap box again)
--
Terry Sterkel
{clyde|harvard|cbosgd|allegra|ulysses|ihnp4}!whuts!tes
[opinions are obviously only my own]rod@cpocd2.UUCP (Rod Rebello) (07/16/87)
In article <2406@whuts.UUCP> tes@whuts.UUCP (STERKEL) writes: > >PKARC 3.5 and PKXARC 3.5 (the latest) hangs my machine so bad that >not even my "cboot" or my "little red switch (boots without dis- >turbing memory)" CANNOT FIX. I LOOSE HOURS OF WORK IN RAMDISK. > >DO NOT USE PKARC (ANY VERSION) OR PKXARC (ANY VERSION) IF YOU HAVE >SOMETHING IN RAMDISK. THE MOST MINOR CORRUPTION WILL HANG YOUR >MACHINE SO BAD THAT YOU MUST TURN OFF THE POWER. > Hmmm....I use pkarc/xarc 3.5 quite abit and have never had it hang my PC. I also have a ramdisk, and several TSRs. At home I have a PC XT Clone with 640K, and a PC AT at work with 512 + 1.5 meg above board. pkxarc has never hanged either one. All the BBS's in my area use it as the standard form of achiving downloadable files. They usually insist that you use it for uploads. Rod Rebello ...!intelca!mipos3!cpocd2!rod
jvc@mirror.UUCP (07/17/87)
/* Written 7:28 am Jul 15, 1987 by tes@whuts.UUCP */ >PKARC 3.5 and PKXARC 3.5 (the latest) hangs my machine so bad that >not even my "cboot" or my "little red switch (boots without dis- >turbing memory)" CANNOT FIX. I LOOSE HOURS OF WORK IN RAMDISK. Thanks for stating the version number. >DO NOT USE PKARC (ANY VERSION) OR PKXARC (ANY VERSION) IF YOU HAVE >SOMETHING IN RAMDISK. THE MOST MINOR CORRUPTION WILL HANG YOUR >MACHINE SO BAD THAT YOU MUST TURN OFF THE POWER. What ramdisk are you using? I'm using the vdisk.sys supplied with the dos on the following machines: Compaq, IBM XT (PC converted to XT with expansion unit - this machine also has hardware from Visage for the videodisc project I'm working on), Tandy 3000HL. I also have either dosedit or PCED running on each machine as well as some software from visage (TSR). I've corrupted several archives (both very minor corruption and major corruption). Both ARC and PKARC react the same: indicate CRC failure and or file (the archive file) is not an archive. Neither crashed the system or affected the ramdisk. >Other sins of PK* not found in SEA ARC: > 1: Random incompatibility with LIM EMS > 2: Random inability to determine how much memory is available > 3: Incompatible with some write-through cache programs I don't have LIM EMS or any cache programs running so I can't test this stuff > 4: Will not check if something has been previously archived > and will re-archive. The user is left with the exercise > of figuring out how "deep" the re-re-re-archiving got. Both ARC520 and PKX35A35 do the same thing if you try to re-add a file to an archive. Both report the following the first time a file is added: Adding file: __________ analyzing, *********, done. Both report the following next time you attempt to add that file: Updating file: ________ analyzing, **********, done. Have I miss-interpreted what you meant by "Will not check if something has been previously archived"? If so, what did you mean and how does ARC handle it? jvc@mirror.tmc.com Almost forgot, I'm using PC-DOS 3.1, PC-DOS 3.2, MS-DOS 3.2.
allbery@ncoast.UUCP (Brandon Allbery) (07/21/87)
As quoted from <2406@whuts.UUCP> by tes@whuts.UUCP (STERKEL): +--------------- | PKARC 3.5 and PKXARC 3.5 (the latest) hangs my machine so bad that | not even my "cboot" or my "little red switch (boots without dis- | turbing memory)" CANNOT FIX. I LOOSE HOURS OF WORK IN RAMDISK. +--------------- My experience is that ARC has a tendency to infinite-loop on my machine on corrupted archives (it can be ^C'ed, though), while PKXARC tells me the archive is corrupted. +--------------- | 4: Will not check if something has been previously archived | and will re-archive. The user is left with the exercise | of figuring out how "deep" the re-re-re-archiving got. +--------------- As I remember it, this was considered a feature. I don't remember the rationale. -- [Copyright 1987 Brandon S. Allbery, all rights reserved] [Redistribution permitted only if redistribution is subsequently permitted.] Brandon S. Allbery, moderator of comp.sources.misc and comp.binaries.ibm.pc {{harvard,mit-eddie}!necntc,well!hoptoad,sun!cwruecmp!hal,cbosgd}!ncoast!allbery <<ncoast Public Access UNIX: +1 216 781 6201 24hrs. 300/1200/2400 baud>>
allbery@ncoast.UUCP (Brandon Allbery) (07/24/87)
As quoted from <206900063@mirror> by jvc@mirror.UUCP: +--------------- | > 4: Will not check if something has been previously archived | > and will re-archive. The user is left with the exercise | > of figuring out how "deep" the re-re-re-archiving got. | | Both ARC520 and PKX35A35 do the same thing if you try to re-add | a file to an archive. Both report the following the first | time a file is added: +--------------- He meant that ARC 5.{12,20} will not add to an archive a file which is itself an ARC archive. I don't see why not; ARC is a librarian as well as a data compression utility. Has nobody ever used Unix ar to archive archives? (I have cpio'd cpio archives....) -- [Copyright 1987 Brandon S. Allbery, all rights reserved] [Redistribution permitted only if redistribution is subsequently permitted.] Brandon S. Allbery, moderator of comp.sources.misc and comp.binaries.ibm.pc {{harvard,mit-eddie}!necntc,well!hoptoad,sun!cwruecmp!hal,cbosgd}!ncoast!allbery <<ncoast Public Access UNIX: +1 216 781 6201 24hrs. 300/1200/2400 baud>>