werner@aecom.YU.EDU (Craig Werner) (06/24/88)
I realize that nobody likes a law suit in the industry, but
my personal opinion was that it was bad form on Phil Katz's part to
label his incompatible files with the same .ARC suffix. It should
have been something else, like .ARK. And for that, SEA should have
probably taken legal action a long time ago.
I know that PXARC turned out to be better, but the files still
should have had a different extension!
--
Craig Werner (future MD/PhD, 4 years down, 3 to go)
werner@aecom.YU.EDU -- Albert Einstein College of Medicine
(1935-14E Eastchester Rd., Bronx NY 10461, 212-931-2517)
"Never go to a doctor whose office plants have died."w8sdz@brl-smoke.ARPA (Keith B. Petersen ) (06/24/88)
Someone suggested that Phil Katz should have used .ARK for a file extension. That is already in use by the CP/M program that makes MSDOS-compatible archives. The .ARK extension was chosen to indicate that the program was for CP/M rather than MSDOS because some BBS systems carry files for both operating systems.
scjones@sdrc.UUCP (Larry Jones) (06/25/88)
In article <1861@aecom.YU.EDU>, werner@aecom.YU.EDU (Craig Werner) writes: > > I realize that nobody likes a law suit in the industry, but > my personal opinion was that it was bad form on Phil Katz's part to > label his incompatible files with the same .ARC suffix. It should > have been something else, like .ARK. And for that, SEA should have > probably taken legal action a long time ago. > I know that PXARC turned out to be better, but the files still > should have had a different extension! Yeah, and hows about Microsoft, Mark Williams, Computer Innovations, and all them other guys using the same .C suffix as Lattice when everybody knows you can't compile most C programs using a different compiler than the guy that wrote them uses! Think of all the confusion this has caused us nieve users; we get .C files off our bulletin boards and then can't compile them! They should have all used different extensions (.MSC, .MWC, .CIC, etc.)!!! And what about MS-DOS? How can they still call it MS-DOS when my version 1 system can't read all them files in those new-fangled subdirectories?!? C'mon, folks, SEA has made changes that weren't backward compatible without changing the file suffix, why shouldn't Phil? Or do we all believe that change, even for the better, is bad? ---- Larry Jones UUCP: ...!sdrc!scjones SDRC AT&T: (513) 576-2070 2000 Eastman Dr. BIX: ltl Milford, OH 45150 "When all else fails, read the directions."
jamesd@percival.UUCP (James Deibele) (06/26/88)
In article <8151@brl-smoke.ARPA> w8sdz@brl.arpa (Keith B. Petersen (WSMR|towson) <w8sdz>) writes: >Someone suggested that Phil Katz should have used .ARK for a file >extension. That is already in use by the CP/M program that makes >MSDOS-compatible archives. The .ARK extension was chosen to indicate >that the program was for CP/M rather than MSDOS because some BBS systems >carry files for both operating systems. So call it .ARP for ARchive from Phil or whatever if he wants to keep the default as incompatible. I guess I can see a use for the .ARK extension, because it's a quicker way of saying "This SEA-standard archive is designed for CP/M machines"; you could have FILEDATE.ARC and FILEDATE.ARK in the same directory. I agree that PKware's utilities are much faster than SEA's, but I wish that Phil Katz had been more respectful of the standards. When there were complaints at the time 3.5 was first released, he (Katz) defended by saying that some catalog programs (for example) were hard-coded to accept .ARC as the extension and that he didn't want to cut his market by using something else. What exactly happened to those utilities when they tried to use one of his non-standard .ARC files, he never said. -- James S. Deibele jamesd@qiclab or jamesd@percival TECHbooks: The Computer Book Specialists (800) TECH-BKS 3646 SE Division Portland, OR 97202 (503) 238-1005 TECHbooks One BBS (#1:105/4.0); 3/12/24 (503) 760-1473
johnl@n3dmc.UUCP (John Limpert) (06/26/88)
In article <1282@percival.UUCP> jamesd@percival.UUCP (James Deibele) writes: >So call it .ARP for ARchive from Phil or whatever if he wants to keep the >default as incompatible. I guess I can see a use for the .ARK extension, >because it's a quicker way of saying "This SEA-standard archive is designed >for CP/M machines"; you could have FILEDATE.ARC and FILEDATE.ARK in the same >directory. I agree that PKware's utilities are much faster than SEA's, but >I wish that Phil Katz had been more respectful of the standards. SEA was not the first to use .ARC for a file extension. I remember using several other file archiver programs that used .ARC, none of them were compatible with SEA's ARC program. The same can be said for other popular file extensions like .LBR and .LIB. At least PKARC was upwards compatible with SEA's ARC. The simplest solution would have been to add squashing to the SEA ARC program, making it fully compatible with PKARC. SEA had already made many additions/modifications that obsoleted old versions of ARC, the only difference in this case was that it wasn't done by SEA. Since the SEA ARC program's user interface and compression algorithms were largely derived from previous software, it is difficult to understand the reason for the lawsuit. It sounds like someone at SEA is suffering from a bruised ego. SEA, like many others before them, took the best features of existing software, added some new ideas and wrote a program. There is nothing wrong with that. They shouldn't be upset if someone does it to them. -- John A. Limpert UUCP: johnl@n3dmc.UUCP uunet!n3dmc!johnl PACKET: n3dmc@n3dmc.ampr.org n3dmc@wa3pxx
berger@clio.las.uiuc.edu (06/28/88)
I can understand why Sea didn't take the bait and become compatible with
pkarc. Until now, everybody who improved on Sea arc was respectful enough
to maintain compatibility, and let Sea set the standards. Without
defacto archive standards, we'd be back to having hundreds of competing
programs without any compatibility.
Mike Berger
Department of Statistics
Science, Technology, and Society
University of Illinois
berger@clio.las.uiuc.edu
{ihnp4 | convex | pur-ee}!uiucuxc!clio!bergerlowey@damask.UUCP (Kevin Lowey) (07/02/88)
In article <1861@aecom.YU.EDU>, werner@aecom.YU.EDU (Craig Werner) writes: > > I realize that nobody likes a law suit in the industry, but > my personal opinion was that it was bad form on Phil Katz's part to > label his incompatible files with the same .ARC suffix. It should > have been something else, like .ARK. And for that, SEA should have > probably taken legal action a long time ago. Wait a minute, it was my understanding that AT THE TIME PKARC ADDED THE EXTENSIONS they were just that ... extensions. Phil's program could still READ all of the .ARC files. He also added the capability to not use these extensions if you needed compatible archives for SEA's ARC. How is that any different than adding extensions to something like UUENCODE so it can handle multi-section files, or adding extensions to KERMIT for long packets and sliding windows, or adding extensions to MS-DOS to support networks. In fact, how is it any different than SEAware releasing a new version of their program that handles a new archiving method. They still use the extension .ARC, even though older versions of the program won't unpack the archives. Your reasoning would imply they should use .A01, .A02, .A03 etc. for different releases (which makes sense, but wasn't done). I see the .ARC file as a standard, and the alternating new releases of the SEA and PK archivers as just new extensions to the .ARC standard. As long as each new release supports all the modes from either program in previous releases, then I'm happy, even if there is a new mode added. PKware has been very careful to follow this. However, I *think (correct me if I'm wrong)* that SEA was the first to decide NOT to support the other's formats. This means (to me anyway) SEA is the one introducing incompatibilities into the .ARC file, NOT PKware. PKARC is a superset of ARC, but the reverse is not true. So how can you blame Phil Katz for causing the compatibility problems? ______________________________________________________________________________ | Kevin Lowey |The above is the personal opinion of Kevin | | University of Saskatchewan |Lowey. It does not reflect the position of| | Computing Services |the University of Saskatchewan in any way. | | SaskTel: (306) 966-4826 | | | Bitnet:LOWEY@SASK. (preferred) |I am in no way affiliated with any of the | | UUCP: ihnp4!damask!lowey.uucp |above mentioned companies other than U of S| |________________________________|___________________________________________|
NU079509@NDSUVM1.BITNET (07/10/88)
I don't see what the problem is with the two versions of arc. I have both programs on one disk that is my utilities disk. If one program won't do the job then I use the other. Takes me about 15 seconds to find the right one :-) I lik the .ARC extension.