Mail Archives: djgpp/1996/06/14/09:55:56
>
> Reply to message 8125042 from LEE_B AT CELESTI on 06/12/96 4:09PM
>
>
> >Yep, but it's still very unfriendly. A lot of people could install
> >windows by hand to, but the installer makes it a hell of a lot
> >more bearable. I'm just thinking that making the thing more
> >user-friendly is the way to get more users. I mean, that's what all
> >the other work's for, isn't it ? Most of us could do without docs,
> >and look at the source code every time we need to know something,
> >but it might increase the development time a bit =)
>
> Actually, Windows is such a disgustingly complex program that I
> wouldn't want to try manual installation if my life depended on it. :)
> OTOH, you're right about the user-friendliness issue. I use the docs
> nearly every day, and having a reader like info around makes it MUCH
> easier.
>
> >something to consider too. The other thing is that the batch file
> >was very unfriendly because you'd lots of files to choose from,
> >going through them a screen at a time.. if you changed your mind
> >about a file (for example, because of disk space restrictions) you
> >had to go through the whole process again.
>
> That's simply an example of bad batch file design. There are
> commercial installers that do things just as messily.
>
> >The point is that that a powerful script language for an installer is
> >basically just an enhanced batch file.
>
> That makes sense.
>
> >Nope, I want a generic installer that can be used for all DJGPP
> >programs, including the actual DJGPP distribution itself.
>
> Essentially, everything in the v2* tree of simtel?
>
> >Well, it's not commercial, but there's no reason why it can't be
> >presented and supported in a professional way..
>
> You're right, of course.
>
> >Yep, if we do get inline stubs, then I'd like to recommend JPTUI -
> >it's a free TUI, and it looks great..
>
> We don't even really need inline stubs - simply including CWSDPMI
> with each and every distribution zipfile might solve people's problems.
> I could see the installer program as a self-extracting archive that
> contains the installer, CWSDPMI, and a readme file. People would
> probably still find a way to screw it up, but that unfortunately is
> impossible to prevent.
>
> >No, I'm talking about when different programs that use DJGPP stuff
> >are installed, they won't install ten copies of the same file in
> >their own abitrary dirs because there's no standardised installation
> >dirs.. I don't know about you, but I've had to delete a few extra
> >copies of go32 and cwsdpmi.. not to mention .BGI files from programs
> >done in borland.. Also, if files are always in one directory, the
> >installer can check whether the file already present (if there is
> >one) is newer than the one to be installed, and not install it in
> >that case (ie, only perform updates).
>
> Well, this is a very difficult problem to solve even for professional game
> programmers. Consider the problem of DOS4GW. Every 32-bit
> game nowadays includes a copy of it with their program, simply
> because there's no way to guarantee that the user will have a current
> version of the program available. Also, consider the problem if the
> user, not knowing the file's importance, deletes it, and thus wrecks
> the game that depended on its existence.
>
> I have installed several Windoze games that use Quicktime or Indeo,
> and every single one seems to insist on installing its own version of the
> drivers, usually on top of whatever driver(s) were already there, and
> usually regardless of whether those drivers were newer or not. After
> installing Civ II, I discovered a directory called Z~MSSTFQ.T which
> apparently contains the benchmark programs the game uses to
> profile my computer's video performance. Talk about wierdness!
>
> One possibility, which seems to be what you are referring to, is for
> the installer to create (or look for) some standardized directory into
> which it installs the latest versions of CWSDPMI and any other
> needed drivers, and sets up the PATH to include that directory.
> This is a good idea, certainly, but there are many dumb users
> (and even some smart ones) who will see something like this and
> delete the drivers out of sheer pique, and then complain to us when
> their program won't run.
>
> >Hmm.. that's true about non-standard dirs, and using the env var.
> >But people using DJGPP programs aren't likely to have DJGPP, and even
> >if they have other programs which are done with DJGPP, it's not
> >guaranteed that they will have the env var set up when installing a
> >new program.. there's gotta be a safe way of finding the right
> >directory.
>
> See my point above... unless you copy stuff directly into the WINDOWS
> or DOS directory, there's no way to guarantee that a rambunctious or
> just plain stupid user won't simply go and delete the stuff because he/she
> doesn't know what it's for.
>
> >There's no need for both.. one good generic installation program
> >would do everything. It would be much more consistant too...
>
> Agreed. It would certainly also be fun working around the problems
> I mentioned above. :) I think I'll go and take a look at some of these
> windowing libraries (JPTUI, for one), and see how they work.
>
> John
>
>
Well you could tell the user what is being installed where and why. Tell them
that they should not delete these bits and pieces unless they are prepared to
reinstall. By having an uninstall option, they would not need to worry about
what goes where, if they are not interested.
It seems to me that installation is relatively easy. For instance, search the
drive to see if there's a CWSDPMI on the PATH, or QDPMI, or whatever. Questions
such as the compatibility of the later releases of programs with memory
configuration is howerver an issue: beta 3 may work in some situations an
official release does not (etc) Possibly the most difficult issue is convincing
people like me that installation won't mess up the configuration: perhaps by
saving the old configuration wherever the user may want. (like a floppy disk
:-) ) I suppose one could make one's life even more difficult by coping with:
the differences between go32 and go32-v2, the fact that the standard
distribution of GOFER uses a modified go32 and modified emu387 from the normal
ones... etc!
I think the most interesting problem is the uninstallation. How is one to know
whether if CWSDPMI is used only by the program being uninstalled or not? If the
program installed it, a later installation may not have installed it's version
of CWSDPMI. The question then is should one delete CWSDPMI or not, which
requires knowing by what CWSDPMI is used. I expect multiple methods would yield
best robustness:
* understand an installation structure built by the installer in some directory
expressing the files installed by the installer currently still not
uninstalled: this would allow one to be sure at least some of the potential
dependencies are known.
* an extension of the previous idea: somewhat like virus checkers, introduce
a library of known dependencies, between different packages, so that when
new software is released which does not use the installer, the installer can
find a possible reason as to the directory structure it finds: eg why CWSDPMI
was already there, but there is not an installation structure file from a
previous installation using the installer.
* understand the maintenance directory set up when installing current releases
of djgpp
* check the date of CWSDPMI, record the time when the installer installed
CWSDPMI, or if CWSDPMI was already there.
* for maximum robustness, if the user really does not know whether CWSDPMI is
to be kept, one could scan all executables in all directories to see if they
contain a stub with the bytes ``CWSDPMI'' in them.
Finally... as to the installer being in the archive... Can one get around this
by stubbing the installer onto the zip file, to make it into a self extracting
archive type thing: that would mean using the standard zlib directory to get
hold of the deflation algorithm. That would mean a DPMI stub inside the
executable though!
However, if you could get it to work really well, then you could try to convince
people using gcc for their products, then you could make the file expressing
the dependencies between different files a standard, which would improve the
installer's effectiveness!
I'm thinking of ID (quake), Executor (mac emulator), Gofer/hugs (Functional
Programming language), Cylyndrix (game), RHIDE, and gnu packages like emacs.
Have fun !
Sengan
- Raw text -