From:	sandmann AT clio DOT rice DOT edu (Charles Sandmann)
Message-Id:	<9610151446.AA12922@clio.rice.edu>
Subject:	Re: Install thingy
To:	grendel AT ananke DOT amu DOT edu DOT pl
Date:	Tue, 15 Oct 1996 09:46:29 -0600 (CDT)
Cc:	eliz AT is DOT elta DOT co DOT il, fighteer AT cs DOT com, djgpp-workers AT delorie DOT com
In-Reply-To:	<Pine.NEB.3.95.961015134531.10709J-100000@ananke.amu.edu.pl> from "Mark Habersack" at Oct 15, 96 01:47:26 pm

> There will be at least four files needed to run install:
>   1) CWSDPMI.EXE
>   2) djvrf2.exe
>   3) install.bat
>   4) instl.exe
> Users have to load all of them and I bet $100 that there will be ones to
> download only a part of them.

This is exactly the reason it needs to be a self-extracting executable 
image - just to make sure all the pieces are there.  You can also put them
in a zip and expect the user to get an unzip, but then you are starting
to assume some level of user intelligence :-)

Some self-extracting formats even allow you to execute a bat file after
explode - which is perfect for an install type application.

Yes, at one time I modified the stub to imbed a copy of CWSDPMI, then write
it on disk if there wasn't a DPMI available.  There was never a well defined
need for it, so it got ignored.  For example, in the example above, since
you need a zip/sfx anyway, how much value is there in reducing the number
of files by one, but increasing the size of the custom stub in djvrf2.exe
to include the exact same code?  BTW, I'm not even sure where that code
is - it might have been nuked in the last disk purge - I just don't know.

For a program which is COMPLETELY standalone, with no external data, bat,
configuration, or help files, the bound stub might help, but since almost
all distributions contain either a help, readme, configuration or data
file in addition to the .EXE, dumping the additional CWSDPMI.EXE in there
isn't a big deal.  But eventually I'll finish the compressed, imbedded
stub.  Someday.  Maybe.

- Raw text -