hartung@amos.ling.ucsd.edu (Jeff Hartung) (10/28/88)
I decided to use a couple of Rahul Dhesi's ZOO programs that I had not tried yet today and used ATOZ and SEZ to turn the archive vm1088.arc into a self extracting file, vm1088ar.exe. Everything worked fine as far as creating the new zoo archive and making it executable were concerned. I then copied the file onto a floppy and put it in the A: drive of another machine which had a close-to-full hard disk and intended to extract the files directly onto the hard disk without having to copy the SEZ-created .EXE file onto the C: drive. To do this, I cd'd into the directory I wanted the files to be extracted into and entered A:VM1088AR, expecting this to work. The file began extracting in that I got the usual salutations, version number, etc., but this was followed by a statement that the file VM1088AR.EXE could not be located (presumably because it was looking in the current directory on the C: drive and not the directory in which the executable was. Is there some way this could have been done (maybe even quite an obvious one) which I may have overlooked? Is there some reason that this could *not* be incorperated into SEZ as a feature or option? It would seem to be most useful to have this if it didn't kill the efficiency of the program or make the self-extracting archive considerably larger. Comments? Rahul? --Jeff Hartung-- Disclaimer: "Nobody here really cares what I think anyhow." ARPA - hartung@amos.ling.ucsd.edu UUCP - !ucsd!ling!amos!hartung
dhesi@bsu-cs.UUCP (Rahul Dhesi) (10/28/88)
In article <5450@sdcsvax.UCSD.EDU> hartung@amos.ling.ucsd.edu (Jeff Hartung) writes: [Sez-created self-extracting archives look in the current directory only] There are two ways for a self-extracting archive to know where to find itself. Under MS-DOS 3.x, it can look at the environment area, and find its own pathname just beyond that area. Under both MS-DOS 2.x and MS-DOS 3.x, it can get the value of PATH from the environment, and search each directory in the list for itself. Adding either of these to Sez-created archives would mean additional overhead of perhaps a few hundred bytes. It didn't seem worth it at one time. It could be added if people really need it. -- Rahul Dhesi UUCP: <backbones>!{iuvax,pur-ee}!bsu-cs!dhesi
dhesi@bsu-cs.UUCP (Rahul Dhesi) (10/29/88)
In article <3048@uoregon.uoregon.edu> stevev@drizzle.UUCP (Steve VanDevender) writes: >Why should a self-extracting archive have to find itself, if it's already >loaded into memory? It's not. Only the first 2500 bytes or so, which contain the extraction code, is loaded into meory. It's possible to fudge and make MS-DOS load the whole thing. But then you would need 500 K of free memory to extract a 500 K archive. I think there would be complaints from users if this happened. -- Rahul Dhesi UUCP: <backbones>!{iuvax,pur-ee}!bsu-cs!dhesi
hartung@amos.ling.ucsd.edu (Jeff Hartung) (10/29/88)
In article <23402@amdcad.AMD.COM> phil@diablo.AMD.COM (Phil Ngai) writes: > >I don't see any point in being able to extract an archive into a machine >with so little space that it can't hold the archive itself. Particularly >if the cost is that sez overhead is increased. I vote no. >"In the West, to waste water is not to consume it, to let it flow unimpeded >and undiverted down rivers. Use of water is, by definition, beneficial use." >(from _Cadillac Desert_) >Phil Ngai, {ucbvax,decwrl,allegra}!amdcad!phil or phil@amd.com You are missing the point. Lets say you have a 600 kbyte file that has been archived using ZOO, then made self extracting with SEZ, and moved onto a floppy. The self-extracting archive is about 300 kbytes. Later, you want to move the files back. You have 800 kbytes of space left on your hard disk, so there are 200 to spare even after the files you want are moved back. However, to extract the files, you must first move the 300 kbyte archive over, execute it so that it will self extract, and then remove it again. Once it's moved over, there are only 500 kbytes left, no longer enough space for all the files. There's no way to extract everything you want and then get rid of part of the SEZ file to make more room because it can only extract all or none of the files, but not some. Furthermore, the manual task of moving the archive over and erasing it later is an unnecessary chore. --Jeff Hartung-- Disclaimer: "Nobody here really cares what I think anyhow." ARPA - hartung@amos.ling.ucsd.edu UUCP - !ucsd!ling!amos!hartung
dhesi@bsu-cs.UUCP (Rahul Dhesi) (10/29/88)
I think there may be a misunderstanding about some things.
1. If the entire self-extracting archive were to be loaded in memory,
then you would need as much main memory (main memory, also called RAM,
not disk space) as will hold the entire archive. So to extract a 300 K
archive you would need 300 K of free main memory. This means that you
would not be able to conveniently extract such an archive in a small
memory partition such as those that can be obtained with DoubleDOS or
(presumably) Deskview and Microsoft Windows, or if you were shelling to
MS-DOS from a large program like BRIEF or PROYAM.
2. No, it is not necessary to copy the self-extracting archive to the
directory where you wish to extract the files. For example, if you
wish to extract the files on disk B: and the self-extracting archive is
A:runme.exe, do the following:
a. Change to B: and execute the self-extracting archive with the
command
A:RUNME
b. When it says "CAN'T FIND RUNME.EXE" and asks you for
"File to extract: ", give it the full filename of itself
by typing:
A:RUNME.EXE
The self-extraction will now take place.
--
Rahul Dhesi UUCP: <backbones>!{iuvax,pur-ee}!bsu-cs!dhesihartung@amos.ling.ucsd.edu (Jeff Hartung) (10/30/88)
In article <4541@bsu-cs.UUCP> dhesi@bsu-cs.UUCP (Rahul Dhesi) writes:
#I think there may be a misunderstanding about some things.
#[...]
#2. No, it is not necessary to copy the self-extracting archive to the
#directory where you wish to extract the files. For example, if you
#wish to extract the files on disk B: and the self-extracting archive is
#A:runme.exe, do the following:
#
# a. Change to B: and execute the self-extracting archive with the
# command
#
# A:RUNME
#
# b. When it says "CAN'T FIND RUNME.EXE" and asks you for
# "File to extract: ", give it the full filename of itself
# by typing:
#
# A:RUNME.EXE
I thought I tried this and it didn't work, but in retrospect, it was probably
my fault and not that of SEZ. (I have the option character changed to '-' on
the machine I most frequently use and am a UN*X user as well, so I tend to use
'/' in my pathnames including, unfortunately, the one machine where the option
character is not changed. I probably entered A:/VM1088AR.EXE and not
A:\VM1088AR.EXE, or perhaps A:VM1088AR without the .EXE extension.) In that
case, I suggest that SEZ be given an option so that the resulting archive have
either the current method of prompting via standard input for a file not found
or having the archive trace how it was called if the creator wants to do that.
--Jeff Hartung--
Disclaimer: "Nobody here really cares what I think anyhow."
ARPA - hartung@amos.ling.ucsd.edu
UUCP - !ucsd!ling!amos!hartungmdf@tut.cis.ohio-state.edu (Mark D. Freeman) (10/31/88)
In <4529@bsu-cs.UUCP> dhesi@bsu-cs.UUCP (Rahul Dhesi) writes: >Under MS-DOS 3.x, it can look at the environment area, and find its own >pathname just beyond that area. > >Under both MS-DOS 2.x and MS-DOS 3.x, it can get the value of PATH from >the environment, and search each directory in the list for itself. > >Adding either of these to Sez-created archives would mean additional >overhead of perhaps a few hundred bytes. It didn't seem worth it at >one time. It could be added if people really need it. This would be wonderful! We are distributing software in a series of SEZs and we have to copy them to a hard disk, execute them, then delete them. It would be great to be able to extract them directly from the floppy. I'm still looking into the CompuServe distribution issue. -- 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