Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!nrl-cmf!cmcl2!phri!cooper!dasys1!tneff
From: tneff@dasys1.UUCP (Tom Neff)
Newsgroups: comp.binaries.ibm.pc.d
Subject: Re: Sez, self-extracting zoo system 2.30
Message-ID: <6190@dasys1.UUCP>
Date: 1 Sep 88 20:13:36 GMT
References: <3796@bsu-cs.UUCP> <20948@tut.cis.ohio-state.edu> <3806@bsu-cs.UUCP>
Reply-To: tneff@dasys1.UUCP (Tom Neff)
Organization: Independent Users Guild
Lines: 29

Self extracting archives are bad for two reasons: (a) They usually deny
the downloading user, however knowledgable, any control over what goes
on, and (b) they require the user to violate a cardinal safety rule of
telecomputing today: NEVER download an .EXE file and run it as is!  I
will never distribute anything of mine as a self-extract, or pass on
anything to others in that format.

I have made these arguments in the past but to no avail: software
providers continue to like the putative convenience of self-x's.  I
yield to the wishes of the market.  Comes now Mark Freeman to ask for
things like a switch to list the self-x's contents without extracting,
and the question them becomes whether it's worth enlarging the self-x
executable envelope to fit such amenities in.

My answer is, no, it's vital to keep the "radar profile" of the
(unprotected) executable envelope as small as possible.  Only a fool
would willingly use a self-x as is, and fools don't need extra options
built in. :-)

What we DO need is for the regular ZOO extractor to be able to
recognize a SEZ-created file, *without* messy and ephemeral numeric
switch values, and to be able to treat it with the full flexibility of
a normal ZOO.  file.  That way smart users can examine and manipulate
SEZ-derived downloads safely, while novices keep the mixed blessings of
self extraction.
-- 
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)