[comp.sys.amiga] New public domain archiving system development

mikes@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.
 







 

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)

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!richard

Sullivan@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