W8SDZ@SIMTEL20.ARMY.MIL (Keith Petersen) (09/18/88)
A group effort is *well* underway to develop a new archiving standard which
will have many new features and will be more efficient than present methods.
The following is an edited capture file from a session conducted on the
Exec-PC Business Board 414/964-5160 on Saturday September 17, 1988 by
Keith Petersen, W8SDZ.
conf: FILE COMPRESSION FORUM #1544 08-18-88 05:29 (Read 102 times)
from: DEAN COOPER
to: GRANT ELLSWORTH (Rcvd)
[speaking about a file recently uploaded which urges everyone to convert to
the DWC archiver]... The author of the note included in the file was quite
misinformed as he thought Phil would no longer be able to develop ANY
archivers after January 89. But of course, Phil is allowed and is going to
come out with a NEW archiver, it just must not use the same file format as
ARC does.
Also, the author of the note basically wanted people to switch over to
DWC, and I have heard other people say the same thing. But I would caution
people to just be a bit patient and wait for Phil's new archiver. This is
an easy thing for me to say since both Phil and I are combining are efforts
on this new archiver... So just stay tuned...
Dean
conf: FILE COMPRESSION FORUM #1550 08-19-88 21:55 (Read 103 times)
from: GRANT ELLSWORTH
to: DEAN COOPER (Rcvd)
Dean, with you and PK teamed ... I can't think of a better possibility or
probability for a superior compressor/archiver utility .... I WILL stay
tuned! Regards, Grant
conf: FILE COMPRESSION FORUM #1552 08-20-88 20:28 (Read 99 times)
from: PAUL ZIMMERMAN
to: DEAN COOPER (Rcvd)
Is this going to be a "new standard"??? Either your and Phil's work will be
merged into a single entity or the two programs will understand each
other's formats and not throw tantrums? Sounds very good. It will be hard
to be patient not knowing what is going on....
Paul
conf: FILE COMPRESSION FORUM #1553 08-21-88 00:13 (Read 101 times)
from: PHIL KATZ
to: PAUL ZIMMERMAN (Rcvd)
Paul,
Yes, it will be a completely new standard. With Dean's experience
with DWC and my experience with (name deleted to protect the innocent)
combined, we will be able to come out with something much better
than the current software, both in terms of compression performance
and functionality.
>Phil>
conf: FILE COMPRESSION FORUM #1555 08-21-88 19:45 (Read 96 times)
from: PAUL ZIMMERMAN
to: PHIL KATZ (Rcvd)
cc: DEAN COOPER
One uncertainty remains. Who will write a "converter" from ARC format to
your new one? Dean? Or someone "anonymous"??? (Probably one of those
Macrobiotic Programmers I heard about in Bull Roar? :-)
Paul
conf: FILE COMPRESSION FORUM #1556 08-21-88 22:32 (Read 98 times)
from: PHIL KATZ
to: PAUL ZIMMERMAN (Rcvd)
Paul,
Well, who writes a converter isn't a major issue. Basically,
all that will be necessary to convert to the new format is
a program to alternately invoke PKUNPAK to extract the files
and then thew new software to recompress them into the new
format. Since the new software will be using different and
better compression algorithms, it will be necessary to do
this.
Anyway, a person in New York, acting on his own cognizance, has
volunteered to write a conversion program.
>Phil>
conf: FILE COMPRESSION FORUM #1557 08-21-88 22:43 (Read 96 times)
from: PAUL ZIMMERMAN
to: PHIL KATZ (Rcvd)
Yes, I suppose a batch file with some clever application of the
"for" command could do the trick. But I was wondering if something
more exotic might pop-up.
I am VERY curious about the "new and better" methods. Any hints? Going
to full 16 bit tables, or what??? (I have heard that this requires a
lot of RAM, but who nowadays doesn't have at least 512k???) And will it be
possible to tell the new compressor to "optimize" by examining a file
at full length and the building the best possible compressed file?
Paul
conf: FILE COMPRESSION FORUM #1558 08-21-88 23:39 (Read 98 times)
from: PHIL KATZ
to: PAUL ZIMMERMAN (Rcvd)
Paul,
Well, I don't want to spill all my beans, but I have a prototype
compression algorithm that uses *less* memory than PKPAK, but
consistently compresses better. I am also evaluating an algorithm
that can compress much, much better than the current methods,
but takes a long time to compress. The extraction isn't too
bad though. This might be included as an option if you want
to maximize the compression achieved.
I think something like a 16-bit code is pretty much out of the
question. Even though the current software will run in 128K,
there are still applications where there isn't that much
available. That is the main reasons for the junior versions
of PKPAK and PKUNPAK currently. Especially when compression
is integrated into other applications, memory usage is a
major concern. One of the goals for the new software is to
be able to run in about the same amount of memory (or less)
than the current software, at least in the MS-DOS versions.
>Phil>
conf: FILE COMPRESSION FORUM #1559 08-22-88 05:53 (Read 99 times)
from: DEAN COOPER
to: PAUL ZIMMERMAN (Rcvd)
The new archiver will be a NEW format and standard. We are trying to
put in all the things that were to difficult with our older formats, so if
you have any ideas for features or things you've always wanted in an
archiver, speak up now, and if we havn`t thought of it already, we may be
able to work it in since we're starting from scratch in an attempt to do
things right...
Dean
conf: FILE COMPRESSION FORUM #1589 08-30-88 05:59 (Read 89 times)
from: DEAN COOPER
to: PATRICK LEMIRANDE (Rcvd)
The program will be designed as modular as possible, so that we will end
up with a library of routines that do compression/decompression, a library
of routines that can manipulate an archive file (all the basic things that
the user can do from the normal command line program), and then a front end
that puts a command line interface on to the top. Since many people,
including myself, like a command line program, and since it will be no big
deal to make one seeing that it is just a small part on top of the library
that does all the work, then we have a command lie version of the program.
But of course, other people like the full-screen interface, so that will
be done too...
Dean
conf: FILE COMPRESSION FORUM #1601 08-30-88 23:55 (Read 95 times)
from: PHIL KATZ
to: PATRICK LEMIRANDE (Rcvd)
cc: DOUGLAS HAY
Patrick,
Douglas Hay is working with us to develop a menu driven full screen
front end for the new software. This will be something integrated
into the design, and will have self-contained compression/extraction
routines so it won't need to shell to other programs. Of course,
there will also be command line driven versions of the software
available for use in automated procedures and batch files etc.
>Phil>
conf: FILE COMPRESSION FORUM #1576 08-29-88 00:59 (Read 89 times)
from: PHILIP BURNS
to: PHIL KATZ (Rcvd)
subject: NEW COMPRESSION PROGRAM
cc: DEAN COOPER
I see from messages here and elsewhere that you guys are working
on a new file compression/librarying program to replace the PKPAK
and PKUNPAK programs.
Many of us are looking for a replacement for ARC, partly because of
its MS-DOS based limitations (short file names, no directory
information, no indication of file type, etc.), and partly because
of the current insistence of SEA that the ARC file type is now
proprietary and ANY program which processes an ARC file in any form
requires a license from SEA. This license condition is completely
unacceptable.
My questions on your new work are these:
(1) Will you be looking at issues of using the programs
on systems besides MS DOS and OS2? For example,
I'd like to be able to use the same/similar programs
to work on the same file across a variety of systems,
like Unix, the Macintosh systems, VAX/VMS, IBM CMS
and MVS, CDC NOS/VE, etc.
(2) Will you be making the COMPLETE file specification
public domain, or copyrighted but completely free
of licensing restrictions? By that I mean, do you
intend to allow by default, anyone to process a
file in your new format without licensing restrictions?
(If not, I certainly wouldn't use your new programs,
as this would lead to the same silliness as currently
exists regarding ARC).
Thanks.
-- Pib
---------------
conf: FILE COMPRESSION FORUM #1577 08-29-88 05:34 (Read 87 times)
from: DEAN COOPER
to: PHILIP BURNS (Rcvd)
How long to file names need to be?? And in what way would you like to
have a long file name truncated down to DOS size? Also, what file types
are there? On these systems that have different file types, can one use C
functions to create the various types? If so, what's the typical arguments
needed? Do different file types need to be written out to differently?
Dean
P.S. The new archiver's format will be made public.
conf: FILE COMPRESSION FORUM #1579 08-29-88 07:55 (Read 88 times)
from: MIKE SHAWALUK
to: PHILIP BURNS (Rcvd)
Philip,
I am the co-developer for the VAX/VMS version of "our" new archiving
utility (no bruised ego here, but I just wanted to say that it's not just
Dean and Phil who are involved in the "project"). Anyways, one of the
things I am wrestling with on the VMS version is the wide variety (i.e.,
endless number) of file and/or record types available under that operating
system, and how to deal with them, both when adding files *on* a VMS
system, and when extracting them, whether under VMS or on a foreign system.
If you have any comments/suggestions/whatever, let me know, either via a
posting here, or via email, if it's more convenient.
- Mike
conf: FILE COMPRESSION FORUM #1581 08-29-88 22:54 (Read 86 times)
from: GRANT ELLSWORTH
to: DEAN COOPER (Rcvd)
cc: PHIL KATZ
cc: PHILIP BURNS
Dean, are you all going to provide enough info in the public declaimation
for a reasonably experienced pgmr to write code which will be able to
extract files and decompress them? I don't think that files can be
unCrucnched, unPacked, unSqueezed by programmers without knowledge of the
ARC source code ... and unSquashing could probably be inferred from
PK's general doc on the Squash Info file.
And the public DOC on the .ARC files doesn't seem to say too much beyond
how to get to the heaader part for each file and ident its name/date
Re: file name sizes ... for PC DOS, UNIX, VMS and other relatives (like
OhS.../2), allow up to 63 for storing fully qualified path_names; for IBM
maiframes ... MVS tolerates 44 for full DSName + 10 for library/member
identifier and delimiters "()".
Re: non-ascii systems - e.g. IBM MAINFrames ... others ... similar or
anologous file structures you can create ... but you want to CODE stuff
to play games with reversing the order of bytes in continous stream bit
streams????? I've done it for moving special bit-stream files from heavy
metal to little-iron ... it ain't fun ... but it can be done
Grant
conf: FILE COMPRESSION FORUM #1582 08-29-88 23:16 (Read 88 times)
from: GRANT ELLSWORTH
to: MIKE SHAWALUK (Rcvd)
Mike, here is a suggestion for addressing the high variety of file types
on VMS (incl. cr/lf, lf ..... cr, var-lgth, fixed lgth, blocked, etc). I
used a similar technique for doing the almost as high a variety on heavy
metal ,,, get the file-type, block0size, record-length, etc..
characteristics out of the "FCB" (? - i've forgotten the VMS control block
name --- and I'd have to let my line go out to get it out of my manuals in
the boxes on the other side of the basement), and store that encoded info
in the compressed/library filename header exactly as VMS expects to find
it. Then, when you compress the file, compress EVERYTHING --- even the
line delimters , the record length descriptor byte/word, etc., as if it
were a continuous stream of bytes ---- strip nothing! On decompress cycle,
build a large stream of output bytes in LARGE blocks.... and have the
decompressor driver call a different output writer for each general class
of file type (many of the specific file types can be grouped together in
one class --- e.g. var-lgth blocked and var length unblocked records -=--
note --- do not try to compress by total var lgth blocks --- just use the
records ---- there is no need to carry the full block structure thru the
compressor/decompressor cycle --- the FCB characteristics should suffice)
Note: You can insert the file's characteristics (record length, record-
type, block-size, etc..) in the FCB before opening the file ... dittor
for the file's name (which heavy-metal will NOT let you easily do - but
VMS does!)
Hope this is helpful. Grant
conf: FILE COMPRESSION FORUM #1586 08-30-88 03:54 (Read 89 times)
from: PHILIP BURNS
to: MIKE SHAWALUK (Rcvd)
Thanks for the message.
On Vax file types: for the Vax, one can store the relevant
RMS specs with the file, and have user exits available to
recreate the file with the proper specs, as part of the
archiver. Or you might consider converting non-text files
to VMSHEX form, and then VMSDEHing them upon extraction.
Or perhaps that should just be left up to the user. However,
the main thing is to allow enough lines of commentary to
be associated with an entry so that someone could figure
out what to do.
Similar things can be done on other systems which have
the same variety (some even MORE variety) of file types
than VMS.
-- Pib
conf: FILE COMPRESSION FORUM #1597 08-30-88 21:50 (Read 91 times)
from: GRANT ELLSWORTH
to: DEAN COOPER (Rcvd)
subject: LZW COMPRESSION
cc: PHIL KATZ
Dean, and Phil, do you really think that you've developed another
compression which is faster and produces a higher compresion than LZW? Is
LZW now as dated as SQz as a commonly used compression method? Grant
---------------
conf: FILE COMPRESSION FORUM #1604 08-31-88 00:13 (Read 92 times)
from: PHIL KATZ
to: GRANT ELLSWORTH (Rcvd)
subject: R: LZW COMPRESSION Reply to #1597
cc: DEAN COOPER
Grant,
Well, I'm not really at liberty to talk about this too much
right now. There are algorithms that can compress much
better than any ZLW implementation that I have seen, but they
also are much slower too. The trick I guess is then to have
your cake and eat it too.
I will also go out on a limb here, and say that the "conventional" ZLW
implementations that I have seen are quite inefficient in effectively
re-using or re-assigning codes when the table is full.
Anyway, I don't think that ZLW is about to be taken over like
SQueezing was. Also, I think that perhaps some of the better
refinements of SQueezing have been overlooked and that SQueezing
may not be entirely dead. In any event, I think that future
techniques might incorporate ideas from SQueezing, ZLW, arithmetic
encoding, and others, combined synergistically.
>Phil>
conf: FILE COMPRESSION FORUM #1609 08-31-88 19:19 (Read 97 times)
from: THOMAS ZERUCHA
to: PHIL KATZ (Rcvd)
subject: NEW PKPAK/UNPAK
I for one would really appreciate it if you would write an early version of
*just the unpacker* in a very portable type of C so that the rest of us
could get it running very quickly for any arbitrary non-pc system.
Otherwise I hope you have plans to port it to *everything* in existance.
If there is one thing which the current ARC has over a potential new system
is PD source so it can be made to work (with some effort) on any machine.
---------------
conf: FILE COMPRESSION FORUM #1611 08-31-88 19:59 (Read 103 times)
from: PHIL KATZ
to: THOMAS ZERUCHA (Rcvd)
subject: R: NEW PKPAK/UNPAK Reply to #1609
Thomas,
>>If there is one thing which the current ARC has over a potential new system
>>is PD source so it can be made to work (with some effort) on any machine.
I wouldn't exactly say that!! It is the contention of one New Jersey
company that anything that deals with an ARC file in any manner
requires a license from them, and any software that is even similar
to theirs when played backwards at 1/2 speed had pretty darn better
be licensed with them. They claim that the file format is proprietary,
and definitely not Public Domain.
On the other hand, the format for the new software that PKWARE is
developing will be entered into the public domain, with no restrictions
placed on other programs that read these new files.
>Phil>
conf: FILE COMPRESSION FORUM #1612 08-31-88 20:06 (Read 110 times)
from: PHIL KATZ
to: JIM DUNNIGAN (Rcvd)
subject: PLANS
Jim,
Well, I think it's a little to early for an official product
announcement or anything, but here's what is currently in
the works:
-------------------------------------------------------------
Caveat:
This is not an official press release. This is what
is currently planned for the new data compression
software forthcoming from PKWARE. The information
provided here is subject to change without notice.
o The file format for the new files will be made public.
Other software can read or write these files without
restriction. Additionally, PUBLIC DOMAIN source code
written in portable C language may be released to
demonstrate how an applications program can read the
information contained in a file created with the new
software.
o The software will be concurrently released for MS-DOS,
VAX/VMS, and Amiga. (This implies that long filenames
such as on an Amiga or Unix will be fully supported.)
OS/2, Unix, and mainframe development is currently being
investigated.
o The (MS-DOS) software will offer both a menu-driven full
screen interface and a command line interface.
o The software will provide significantly better compression
than the current software, and also offer vastly improved
reliability for recovering data from damaged and corrupted
files.
o The software will be able to process and traverse
subdirectories. The (MS-DOS) software will be able to span
multiple disks with compressed file collections.
---------------tneff@dasys1.UUCP (Tom Neff) (09/20/88)
Well now. Wasn't that special, as Church Lady says! Let's see what we got. - The file format is gonna be PD. - By the way, if you have any ideas about what that format actually ought to BE, they'd love to hear from you. - The program itself won't be PD. - But there "may" be some PD C-code published to show you how to do it yourself. - Of course, the principal author just lost his shirt in court for doing it himself. But you go right ahead, why would anyone want to sue YOU. - At least four independent programmers are on the team already. (Start multiplying, all you Mythical Man-Month devotees.) - Other packaging formats like ARC and LBR, with fewer programmers and fewer contemplated target environments, have typically gone through a couple of iterations over a period of a year or so before settling down to relative stability. - But this one is going to replace ARC immediately, starting with all the files on SIMTEL20. - Not to worry though, they might get this one perfect the first time! If not, there'll be as many new versions of the shareware as it takes. (And bringing your own compatible applications up to date will give you something to do!) -- Tom Neff UUCP: ...!cmcl2!phri!dasys1!tneff "None of your toys CIS: 76556,2536 MCI: TNEFF will function..." GEnie: TOMNEFF BIX: t.neff (no kidding)
ray@micomvax.UUCP (Ray Dunn) (09/24/88)
In article <KPETERSEN.12431393020.BABYL@SIMTEL20.ARMY.MIL> W8SDZ@SIMTEL20.ARMY.MIL (Keith Petersen) writes: >A group effort is *well* underway to develop a new archiving standard which >will have many new features and will be more efficient than present methods. > >The following is an edited capture file from a session conducted on the >Exec-PC Business Board ..... This purports to be a genuine "conversation" between various people, including Phil Katz, on their *New* *Archiving* *Development*, and *Why* *We* *Should* *All* *Wait* *For* *It*! Hmm. Is this really a genuine off-the-cuff conversation? Is it not too smooth and cutesy pie? Doesn't it just too neatly cover all the salient points - "Gee Phil, well I'm glad you asked me that....."? Can I smell the not-too-well-disguised marketing hype even from inside here? I'm I too cynical? Does someone think we are all so gullible? Are we all so gullible? Should I go back to playing in my sandbox? Does this tell us something about why somebody really thought it worthwhile to sue somebody else? Does anybody really care anyway? Hmm. I do actually, and *I've* made up *my* mind. I think someone is trying to be such a clever little thing, and I don't like the smell. I'm going to make sure none of *my* $$'s goes anywhere near *that* one!!! Hmm, again. What is somebody in .ARMY.MIL doing promoting a commercial product (the above is not the only posting)? Hmm, a last time. Am I playing with the wrong playmates?? Disclaimer: This is only me speaking. Communications received on this subject are subject to publication if I think it is of public interest. -- Ray Dunn. | UUCP: ..!philabs!micomvax!ray Philips Electronics Ltd. | TEL : (514) 744-8200 Ext: 2347 600 Dr Frederik Philips Blvd | FAX : (514) 744-6455 St Laurent. Quebec. H4M 2S9 | TLX : 05-824090
troeger@ttidca.TTI.COM (Jeff Troeger) (09/27/88)
In article <1297@micomvax.UUCP> ray@micomvax.UUCP (Ray Dunn) writes: >Should I go back to playing in my sandbox? > > >Hmm. I do actually, and *I've* made up *my* mind. I think someone is >trying to be such a clever little thing, and I don't like the smell. I'm >going to make sure none of *my* $$'s goes anywhere near *that* one!!! > >Hmm, again. What is somebody in .ARMY.MIL doing promoting a commercial >product (the above is not the only posting)? > >Hmm, a last time. Am I playing with the wrong playmates?? Get your head out of the Cat-Box Ray, If you had been following this thread with anything close to normal human intelligence, you would know that Keith is not promoting a commercial product, but instead a FREE PUBLIC DOMAIN PROGRAM INCLUDING SOURCE AND FILE FORMATS! SIMTEL20's reasoning has been stated several times and if you want to find them out, I'm sure Keith will be more than willing to give you an abridged version that even you can read. Jeff Troeger These comments belong to me and any similarity to opinions or comments by Citicorp TTI is purely coincidental. -- Jeff Troeger @ Citicorp(+)TTI 3100 Ocean Park Blvd. (213) 450-9111, ext. 3153 Santa Monica, CA 90405 {philabs,randvax,csun}!ttidca!ttidcb!troeger or troeger@ttidca
w8sdz@smoke.ARPA (Keith B. Petersen ) (09/28/88)
Ray Dunn questions the capture session I posted showing the discussion
about the new public domain archiving system. Ray, read the very first
line. It says this is an EDITED version of the capture session. That's
why it looked so "clean". There was a lot of chit-chat inbetween those
mssages. If you would like a complete UNEDITED transcript of the whole
session I'll be happy to send it to you. It's a 182K archive.
--
--Keith Petersen
Maintainer of the CP/M and MSDOS archives at SIMTEL20.ARMY.MIL [26.0.0.74]
Arpa: W8SDZ@SIMTEL20.ARMY.MIL
Uucp: {ames,decwrl,harvard,rutgers,ucbvax,uunet}!simtel20.army.mil!w8sdzmikes@lakesys.UUCP (Mike Shawaluk) (09/30/88)
In article <3218@ttidca.TTI.COM> troeger@ttidcb.tti.com (Jeff Troeger) writes: >In article <1297@micomvax.UUCP> ray@micomvax.UUCP (Ray Dunn) writes: >>Should I go back to playing in my sandbox? >> >>product (the above is not the only posting)? >> >>Hmm, a last time. Am I playing with the wrong playmates?? > >Keith is not promoting a commercial product, but instead a FREE PUBLIC >DOMAIN PROGRAM INCLUDING SOURCE AND FILE FORMATS! SIMTEL20's reasoning >has been stated several times and if you want to find them out, I'm sure >Keith will be more than willing to give you an abridged version that even >you can read. > > Jeff Troeger At the risk of adding more confusion to this conversation, I'd like to try to clarify some of the statements being made here. My "credentials", as is were, are that I am one of the principals being paid (as in $$) to develop the new file R-kiving (had to avoid spelling the "A" word there :-) utility for PKWARE, (a.k.a. Phil Katz). As has already been said/summarized/inferred here and elsewhere, Phil is developing a new and improved file collection, compression, management, and whatever-else-makes-sense-in-that-context program, to be available initially for three major program environments; MS-DOS (including IBM PC's and non-PC's, such as TI Pro's, Tandy 2000's, and other such systems), the Commodore Amiga family (A500, A1000, A2000), and the DEC VAX/VMS environment; I happen to be the individual who's developing/porting the VAX/VMS version. All of these platforms will utilize the same basic file format, with some capabilities to address features or peculiarities of those environments, but in a way which is hopefully sideways compatible with the other systems. For example, the Amiga and VMS allow for longer file names than MS-DOS, and VMS has a plethora of file/record types, so there will be provisions in the file format for handling this type of information; however, the extractor which can't use this information will have the option/ability to ignore (or at least properly handle) this extraneous information, to allow for extracting/viewing R-kive contents on machines other that those on which they were created. In any event, I feel it would be safe to say that the primary work of this project is *NOT* to produce products which are "free" or "public domain", since all of us who are working on the project are being reimbursed for our time and efforts; however, I believe I can speak for Phil in saying that the format itself, as well as example freely-distributable code, *WILL* be made available and placed in the public domain, to allow other sources to embrace and use this format to serve their needs. This is, of course, in contrast with the policies of another company (hint: name starts with an "S" and ends with an "A"), who has been resorting to lawsuits to prevent others from using its precious file format without their approval... In conclusion, I would welcome any feedback, constructive or otherwise, in regard to this project. Please respond via the appropriate newsgroup or via email, at your preference (I regularly monitor all of the above cross-posted newsgroups *AND* my mail). - Mike Shawaluk **DISCLAIMER** The above comments do not necessarily represent those of Phil Katz or PKWARE, although they probably aren't too far off of dead center.
syrbz@warwick.ac.uk (J D Mulberg) (10/01/88)
One thing that would be useful would be an ability to create 'exclusive' archives: to include all files except those already in a separate archive. Can this be done under the present systems? If not, it would be a useful feature. Jon Mulberg, Go placidly amidst the Warwick University noise and haste ... -- UUCP: ...!mcvax!ukc!warwick!syrbz PHONE: +44 203 523523 JANET: syrbz@uk.ac.warwick.daisy ARPA: syrbz@daisy.warwick.ac.uk
tneff@dasys1.UUCP (Tom Neff) (10/02/88)
In article <1068@lakesys.UUCP> mikes@lakesys.UUCP (Mike Shawaluk) writes: >...In any event, I feel it would be safe to say that the primary work of this >project is *NOT* to produce products which are "free" or "public domain", >since all of us who are working on the project are being reimbursed for our >time and efforts; however, I believe I can speak for Phil in saying that the >format itself, as well as example freely-distributable code, *WILL* be made >available and placed in the public domain, to allow other sources to embrace >and use this format to serve their needs. So far this sounds no different from what SEA did: release a shareware archiver and publish the C source. (Actually it is different, SEA released the full production code, sufficient to recreate ARC.EXE if you had their compiler, while the PK group talks about "example" source code.) > This is, of course, in contrast >with the policies of another company (hint: name starts with an "S" and ends >with an "A"), who has been resorting to lawsuits to prevent others from using >its precious file format without their approval... Sheerest speculation! Given that SEA released their code but later sued anyway, what assurance do we have PK won't do the same thing. (Hint: the answer starts with an "NO" and ends with an "NE".) I usually quiver over the "F" key when I read Ray Dunn's thoughts <grin>, but this time he has it pegged. There are no white hats in this episode except probably Vern Buerg and Wayne Chin, and there is too much posturing to take on an empty stomach. -- Tom Neff UUCP: ...!cmcl2!phri!dasys1!tneff "None of your toys CIS: 76556,2536 MCI: TNEFF will function..." GEnie: TOMNEFF BIX: t.neff (no kidding)
mikes@lakesys.UUCP (Mike Shawaluk) (10/03/88)
In article <6760@dasys1.UUCP> tneff@dasys1.UUCP (Tom Neff) writes: > >So far this sounds no different from what SEA did: release a shareware >archiver and publish the C source. (Actually it is different, SEA >released the full production code, sufficient to recreate ARC.EXE if >you had their compiler, while the PK group talks about "example" source >code.) I have probably said more than I am qualified to say in regard to Phil's motives and ambitions in regard to his new product(s). Rather than further attempt to put his "thoughts" on the net, without his explicit review or approval, I'll put down a few of my own impressions: SEA has directly stated, via a message from Thom Henderson on Magpie BBS (see the "Thom Henderson Speaks!" message chain of a few weeks ago for the exact message), that they wish to "protect" the ARC format from possible corruption, and are requesting/requiring the authors of any ARC-compatible utilities to furnish them with copies of the programs in question, including, in some cases, source code! Further, they indicate a requirement for authors of such utilities to pay them royalties on these programs, albeit after a healthy amount of income has been received by the author. To the best of my knowledge, Phil has no such plans to perform anything of this nature. It may well be true that the "corruption" of the ARC format that Mr. Henderson speaks of is Phil's addition of Squashing to his (Phil's) program, as an additional compression type; however, this addition took place during a time when SEA themselves were adding new compression types to their own format with every release (remember ARC 2.0, 3.0, and 4.0?). Unfortunately, SEA stopped improving ARC (at least in the area of file compression efficiency) shortly before Squashing came into existance, and therefore, Phil's additions become the first "corruptions" of their format. Anyways, I digress. I don't think that the term "white hats" (as in heros) is really relevant in this discussion. Many of us see SEA's actions as unfair to Phil, or as a dangerous precedent for "shareware" authors, or any number of things. What is probably important to remember is that PKWARE's products are just that -- shareware. So are SEA's products. Which, of course, includes Vern Buerg's products, since, to the best of my knowledge, he has signed a licensing agreement with SEA concerning ARCE and ARCA, making those products essentially SEA products (they are supposedly included on the SEA ARC distribution disk you get when you send in their requested Shareware donation). Like many shareware authors, Phil depends upon the income from his products to meet operating expenses, pay bills, and other sundry details. He has chosen the shareware concept for "selling" his product, and hopes that it is of a superior nature to competitive products, so that users will WANT to use it, and will WANT to send their contributions to support its author(s)' further enhancements of its functions. But, you don't need me to rehash the Shareware Credo here, so I'll stop. >-- >Tom Neff UUCP: ...!cmcl2!phri!dasys1!tneff - Mike Shawaluk (...!uunet!uwmcsd1!lakesys!mikes)
malpass@vlsi.ll.mit.edu (Don Malpass) (10/04/88)
In article <1068@lakesys.UUCP> mikes@lakesys.UUCP (Mike Shawaluk) writes: >... MS-DOS ... the Commodore Amiga family, ... and the >DEC VAX/VMS environment; Conspicuously absent from your reply is the word UNIX. One reason you guys may never succeed in killing ARC is that the INcompatible pkarc format couldn't easily be un-arc'd in most systems running UNIX. Do you plan to continue ignoring UNIX users? -- Don Malpass [malpass@LL-vlsi.arpa], [malpass@spenser.ll.mit.edu] My opinions are seldom shared by MIT Lincoln Lab, my actual employer RCA (known recently as GE), or my wife.
mikes@lakesys.UUCP (Mike Shawaluk) (10/06/88)
In article <183@vlsi.ll.mit.edu> malpass@ll-vlsi.arpa.UUCP (Don Malpass) writes: > > Conspicuously absent from your reply is the word UNIX. One >... Yeah, I know it's absent; I believe I alluded to that in my original posting, and gave the reasons for that omission. But in case I didn't, allow me to do so; there WILL be a UN*X version, if the project is a success. Unfortunately, having a UN*X version from the start would probably help MAKE the project a success, but Phil is bankrolling the project, and thus calling the shots, and he feels that the three stated platforms need to come first (especially the IBM PC version, with which he is both most familiar, and has the most business at stake). Although I do not consider myself a "guru" on VMS *or* UN*X, I have done enough programming under VMS to be doing that version, and I am becoming more and more familiar with UN*X as time goes on; with a little luck, I'll be able to convince Phil that the UN*X version should immediately follow. > Do you plan to continue ignoring UNIX users? Who said that UN*X users were being ignored? Maybe just not being served first... >Don Malpass [malpass@LL-vlsi.arpa], [malpass@spenser.ll.mit.edu] -- - Mike Shawaluk (...!uunet!uwmcsd1!lakesys!mikes)
conway@hpdtl.HP.COM (Daniel F. Conway) (10/07/88)
>>... MS-DOS ... the Commodore Amiga family, ... and the >>DEC VAX/VMS environment; > Conspicuously absent from your reply is the word UNIX. One >reason you guys may never succeed in killing ARC is that the >INcompatible pkarc format couldn't easily be un-arc'd in most systems ^^^^^^^^^^^^^^^^^^^^^^^^^^^ What am I missing here? Why not? 'Bits is bits' (aren't they?) >running UNIX. > Do you plan to continue ignoring UNIX users? >Don Malpass [malpass@LL-vlsi.arpa], [malpass@spenser.ll.mit.edu] > My opinions are seldom shared by MIT Lincoln Lab, my actual > employer RCA (known recently as GE), or my wife. Dan Conway dan_conway@hplabs.hp.com
richard@gryphon.CTS.COM (Richard Sexton) (10/07/88)
My dear children;
Please do not subject comp.sys.amiga to any further escapades of
the ARC / PKARC wars.
--
``No regrets, no apologies.'' - Ronald Reagan
richard@gryphon.CTS.COM {backbone...err, well connected site}!gryphon!richardSullivan@cup.portal.com (10/08/88)
if you are taking suggestions I have a doozy:
why not let the output symbols be user defineable. That way UNIX people
could limit them to the 95 printable ascii characters, and send them
via Email. Users of 7-bit machines such as Digital's DEC series computers
could limit transfers to those characters, possibly minus some control
characters which don't easily transfer. Put a header on each file which
includes the symbol set and voila, you would have an archive program which
doubles for UUENCODE and does so with maximum efficiency.
Other nice features to support are conversion of special symbols in file
names, defineable end of line marks (aids in bringing files to/from Un*x
from/to Mush-Dos,) file creation, last edit dates, creator (owner),
and especially directory structure (as an OPTION like zoo.) I'm sure
there are others I haven't though of yet.
-Sullivan Segall
_____________________________________________________________
/V\ Sully set the example: to fly without moving. We shall
' learn to soar on wings of thought. And the student will
surpass the teacher.
To Quote the immortal Socrates: "I drank what?" -Sullivan
_____________________________________________________________
Mail to: ...sun!portal!cup.portal.com!Sullivan or
Sullivan@cup.portal.com