mdf@tut.cis.ohio-state.edu (Mark D. Freeman) (08/30/88)
In <3796@bsu-cs.UUCP> dhesi@bsu-cs.UUCP (Rahul Dhesi) writes: >Sez 2.30 will convert any zoo archive to an executable program that, >when executed on any MS-DOS system, will re-create the contents of the >original zoo archive. Self-extraction overhead is less than 2500 >bytes. Can you use some command line parameter to just list what is in the self-extracting zoo archive? I would want the self-extracting archive to act as if I had given zoo the 'x//' switches. Is there a way to do this? It seemed to want to extract everything to the current directory, even though the .zoo file that I fed zoo had full pathnames in it. This is probably just another case of my missing something that's in the doc files, so I ask your forgiveness but I just don't see it. Thanks for a great program! -- Mark D. Freeman (614) 262-1418 Applications Programmer, CompuServe mdf@tut.cis.ohio-state.edu [70003,4277] ...!att!tut.cis.ohio-state.edu!mdf Columbus, OH Guest account at The Ohio State University
dhesi@bsu-cs.UUCP (Rahul Dhesi) (08/30/88)
In article <20948@tut.cis.ohio-state.edu> mdf@tut.cis.osu-state.edu (Mark D. Freeman) writes [about sez 2.30]: >Can you use some command line parameter to just list what is in the >self-extracting zoo archive? No, sez is too simple for that. All that the self-extracting archive does is extract itself. >It seemed to want to >extract everything to the current directory, even though the .zoo file >that I fed zoo had full pathnames in it. Sez is too simple for this too. Everything is extracted into the current directory. Now let's examine why. First: Self-extracting archives should not be too big. The overhead is quite low now; you can have a bunch of self-extracting files on a disk and they don't take up much more space than just having them as zoo archives. Second, consider why you would use a self-extracting archive: for simplicity. Just tell the user "run this program'" If more features were added, you would gain very little over just distributing zoo archives with looz on the disk, and the self- extraction code would be much larger. You would have to give the user instructions to use the self-extracting archive anyway, so you might as well just say "run looz and it will tell you how to extract/list these archives." So, in a nutshell: If you want the recipient to be able to list files, provide a copy of looz and just use zoo archives. If you also want to unarchive to a directory subtree, provide zoo. But the question is still open. Would you, the user, rather have a 2492-byte overhead and just simple extraction, or would you rather have say a 10000 byte overhead and possibly a help screen, and be able to list contents and extract to a directory subtree? And if you chose the latter, what would you gain over simply distributing the zoo archive and the zoo archiver program, with a batch file to be executed by the user? Post your response in this newsgroup, and if enough people want a specific size/functionality trade-off that's what you wil likely get in the (possibly distant) future. Oh, by the way, you *can* list and extract (to a subdirectory) self- extracting archives created by sez 2.30. Use zoo 2.00 and add "@2566,2637" to the command. For example: zoo x.//@2566,2637 selfex.exe will extract to subdirectories. The numbers will vary with the version of sez that was used, and Fiz will tell you which ones to use. Nobody who has zoo 2.0 running on any system (AmigaDOS, VAX/VMS, UNIX) need find it impossible to extract a self-extracting archive. -- Rahul Dhesi UUCP: <backbones>!{iuvax,pur-ee,uunet}!bsu-cs!dhesi
driscoll@eecae.UUCP (Mike Driscoll) (08/30/88)
I agree with Rahul. Keep sez small and simple. Spread looz (or zoo) around if things get complex. If sez extracts to path names you either have to explain what it does, or you may make me angry by creating lots of directories I didn't want. Mike -- Michael A. Driscoll UUCP: ...uunet!mimsy!ames!philabs!fmsrl7!eecae!driscoll Dept. of Electrical Engineering ARPA: driscoll@eecae.ee.msu.edu (35.8.8.151) Michigan State University Office: (517) 353-5337 E. Lansing, MI, 48824
swh@hpsmtc1.HP.COM (Steve Harrold) (08/31/88)
Re: sez and self-extraction I have a major problem with self-extracting files: TROJANS. How does one ensure that a file purporting to be a self-extracting archive isn't really some type of vandalistic program? Can you supply an additional utility (or function within ZOO) that will extract files from a zoo archive, even one that is in SEZ format? In this way, the existing SEZ overhead can remain small, but all the contents of the SEZ file can be manipulated as if it were a pure ZOO archive. If this utility were available, I wouldn't have to trust blindly some stranger who tells me "just run the program". Obviously, some strangers are worth trusting, but not all!
mdf@tut.cis.ohio-state.edu (Mark D. Freeman) (08/31/88)
In <3806@bsu-cs.UUCP> dhesi@bsu-cs.UUCP (Rahul Dhesi) writes: >In article <20948@tut.cis.ohio-state.edu> mdf@tut.cis.osu-state.edu (Mark D. >Freeman) writes [about sez 2.30]: > >>Can you use some command line parameter to just list what is in the >>self-extracting zoo archive? > >No, sez is too simple for that. All that the self-extracting >archive does is extract itself. Not a major problem. >>It seemed to want to >>extract everything to the current directory, even though the .zoo file >>that I fed zoo had full pathnames in it. > >Sez is too simple for this too. Everything is extracted into the >current directory. We were looking into using self-extracting zoo archives as a means of software distribution, which would get around having to put a copy of zoo on every disk. Without the ability to extract the full pathnames, we might as well use self-extracting PKARCs. I had hoped to switch everything we do over to zoo files. >Now let's examine why. > >First: Self-extracting archives should not be too big. The overhead >is quite low now; you can have a bunch of self-extracting files on a >disk and they don't take up much more space than just having them as >zoo archives. Agreed. >Second, consider why you would use a self-extracting archive: for >simplicity. Just tell the user "run this program'" Exactly! Not "run this program, then run this batch file which will create all the directories and copy the files where they belong and then delete the originals". >But the question is still open. Would you, the user, rather have a >2492-byte overhead and just simple extraction, or would you rather have >say a 10000 byte overhead and possibly a help screen, and be able >to list contents and extract to a directory subtree? Would it really mean another 7K to add full path extraction? >And if you chose >the latter, what would you gain over simply distributing the zoo >archive and the zoo archiver program, with a batch file to be executed >by the user? Lack of licensing problems. We wouldn't have to put the zoo documentation on the distribution disks, and have to possibly explain "what the heck is zoo?" from end-users calling us for support. Thanks for keeping an open mind. In software development, everyone seems to have a different "one right way" something should be done. It's nice to talk to someone who is willing to haggle a bit. -- Mark D. Freeman (614) 262-1418 Applications Programmer, CompuServe mdf@tut.cis.ohio-state.edu [70003,4277] ...!att!tut.cis.ohio-state.edu!mdf Columbus, OH Guest account at The Ohio State University
sbanner1@uvicctr.UUCP (S. John Banner) (09/01/88)
In article <3806@bsu-cs.UUCP> dhesi@bsu-cs.UUCP (Rahul Dhesi) writes: >Oh, by the way, you *can* list and extract (to a subdirectory) self- >extracting archives created by sez 2.30. Use zoo 2.00 and add >"@2566,2637" to the command. For example: > > zoo x.//@2566,2637 selfex.exe > >will extract to subdirectories. The numbers will vary with the version >of sez that was used, and Fiz will tell you which ones to use. Nobody >who has zoo 2.0 running on any system (AmigaDOS, VAX/VMS, UNIX) need >find it impossible to extract a self-extracting archive. >-- >Rahul Dhesi UUCP: <backbones>!{iuvax,pur-ee,uunet}!bsu-cs!dhesi One thing that might be nice for this would be to have some kind of magic number in the self-extracting archives, so that if you tell zoo that it is extracting a self-extracting archive, it will know (or at least be able to determine), what those magic numbers you mentioned above are by it self. This would save people from having to figure it out, or try to remember it. It might be nice to make zoo automagicly recognize if it was trying to extract a self extracting archive, but I don't know how difficult that might be (you could make it as simple as just checking the file extension, or something more like checking for magic numbers at key places in the file). Anyhow, just a few suggestions to make an already great program even better. S. John Banner ...!uw-beaver!uvicctr!sol!sbanner1 ...!ubc-vision!uvicctr!sol!sbanner1 ccsjb@uvvm.bitnet (Please avoid this address if possible) sbanner1%sol.uvic.cdn@ubc.csnet sbanner1@sol.uvic.ca
haugj@pigs.UUCP (Joe Bob Willie) (09/01/88)
In article <21048@tut.cis.ohio-state.edu> mdf@tut.cis.osu-state.edu (Mark D. Freeman) writes: >We were looking into using self-extracting zoo archives as a means of >software distribution, which would get around having to put a copy of >zoo on every disk. > >Without the ability to extract the full pathnames, we might as well use >self-extracting PKARCs. I had hoped to switch everything we do over to >zoo files. you can place your distribution on the disk in two archives. the first contains all of the tools and scripts, which are all unarchived into the current directory, and the second contains the distribution files. >Exactly! Not "run this program, then run this batch file which will >create all the directories and copy the files where they belong and >then delete the originals". but what is wrong with "run this batch file", which extracts the tool kit, and then extracts the archive? this has the advantage of separating the tools from the data. if you only update data files, you don't have to create a new tool kit archive. same holds true for the tool kit, update a file there and leave the data archive alone [ data in this case could actually be a collection of programs. the idea being to separate the zoo tools from the distribution package ] > We wouldn't have to put the zoo >documentation on the distribution disks, and have to possibly explain >"what the heck is zoo?" from end-users calling us for support. doesn't looz handle all of the functions you need without going to full blown zoo on each disk? you are going to have to explain something to your users. as far as i know that curious cat is still quite dead ;-) -- =-=-=-=-=-=-=-The Beach Bum at The Big "D" Home for Wayward Hackers-=-=-=-=-=-= Very Long Address: John.F.Haugh@rpp386.dallas.tx.us Very Short Address: jfh@rpp386 "ANSI C: Just say no" -- Me
dhesi@bsu-cs.UUCP (Rahul Dhesi) (09/01/88)
In article <17560004@hpsmtc1.HP.COM> swh@hpsmtc1.HP.COM (Steve Harrold) writes: >I have a major problem with self-extracting files: TROJANS. >How does one ensure that a file purporting to be a self-extracting >archive isn't really some type of vandalistic program? The problem is more general than that. Almost everything posted to comp.binaries.ibm.pc has contained one or more executable files that you were supposed to run. So if you distribute binaries as zoo or arc archives, and they contain files that are to be executed after extraction, you haven't eliminated the problem of Trojans at all. Only providing source can do that--or so it appears at first glance. In reality, it's not difficult to hide Trojan code in source too. A 30 K executable might come from 100 K of source code, and a malicious hacker (as opposed to the benign ones, like me) could easily hide dangerous code in that 100 K that you would not easily detect. In any case, self-extracting archives should only be distributed to your private customers. They are not a good mechanism for distributing free software through BBSs etc. Self-extracting code is machine- specific and so not easily extractable by all. And self-extracting files are much harder to manipulate than regular archives. The only reasonable exception is that if you are distributing an archiving/dearchiving program it doesn't make sense to require the user to have another one already in order to extract yours, so a self- extracting archive is appropriate. This is a bootstrap mechanism to avoid the "which comes first--chicken or egg" problem. P.S. Extract a self-extracting archive made with sez by following instructions about fiz in the fiz and zoo documentation. -- Rahul Dhesi UUCP: <backbones>!{iuvax,pur-ee,uunet}!bsu-cs!dhesi
tittle@alexandre-dumas.ics.uci.edu (Cindy Tittle) (09/01/88)
With looz and booz and sez and fiz and such flying around, I'm getting
slightly confused (and glaze-eyed). Can a short summary of what all
there is connected with zoo and what they do either be posted or sent
to me?
In addition, is there an archive site I can ftp to for all this?
How about for the non-msdos versions? Are these all conveniently together
somewhere? Or do I have to rely on "random" postings to find out about
these things?
--
__ __ _______ __ Cindy Tittle ARPA: tittle@ics.uci.edu
/ / / / / _____/ / / UUCP: {sdcsvax|ucbvax}!ucivax!tittle
/ /__/ / / /____ / / BITNET: cltittle@uci.bitnet
/______/ /______/ /_/ Work fascinates me ... I can look at it for hours ...tneff@dasys1.UUCP (Tom Neff) (09/02/88)
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)
rde@eagle.ukc.ac.uk (R.D.Eager) (09/02/88)
In article <17560004@hpsmtc1.HP.COM> swh@hpsmtc1.HP.COM (Steve Harrold) writes: >Re: sez and self-extraction > >Can you supply an additional utility (or function within ZOO) that will >extract files from a zoo archive, even one that is in SEZ format? >In this way, the existing SEZ overhead can remain small, but all the contents >of the SEZ file can be manipulated as if it were a pure ZOO archive. > A combination of zoo and fiz (supplied with zoo) will do this. -- Bob Eager rde@ukc.UUCP ...!mcvax!ukc!rde Phone: +44 227 764000 ext 7589
davidsen@steinmetz.ge.com (William E. Davidsen Jr) (09/06/88)
In article <17560004@hpsmtc1.HP.COM> swh@hpsmtc1.HP.COM (Steve Harrold) writes: | Re: sez and self-extraction | Can you supply an additional utility (or function within ZOO) that will | extract files from a zoo archive, even one that is in SEZ format? | In this way, the existing SEZ overhead can remain small, but all the contents | of the SEZ file can be manipulated as if it were a pure ZOO archive. The fiz and zoo utilities combined will allow you to do this. Use fiz to find the start of the data, then check it with zoo. If the archive contains any executables you still have to run on trust if you run at all. -- bill davidsen (wedu@ge-crd.arpa) {uunet | philabs}!steinmetz!crdos1!davidsen "Stupidity, like virtue, is its own reward" -me