Mail Archives: djgpp/1996/06/14/15:50:49
Reply to message 2301159 from SENGAN.SHORT@ on 06/14/96 9:51AM
One note before I begin: PLEASE don't quote the entire previous
post if you are only going to reply to some of it! We CAN go and
look it up if we need to!
>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.
You are assuming that the user is intelligent enough to understand these
things.
>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)
Do you remember the threads we've had on here about the problems
with various versions of QDPMI, memory limitations under Windoze, and
the heap size bug of CWSDPMI? Suppose the user, one day, decides to
turn off QDPMI. Unless there is a copy of CWSDPMI floating around, no
DJGPP programs he has installed will work. I honestly think the easiest
way to handle this problem is to simply provide CWSDPMI with every
program, and tell the user that he or she can simply put it into a common
directory to save space. Intelligent users will do this; dumb ones will never
know the difference.
>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!
Well, if you areinstalling any kind of tools or utilities (DJGPP comes to
mind),
you almost have to assume that your configuration may have to be altered.
However, most games/basic utilities don't and should not care about these
things. If GOFER uses modified programs, then our smart installer should
know enough to leave it the heck alone.
>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:
If CWSDPMI is placed into a common directory by an installer program,
then the uninstaller should NOT touch it. I don't care how fancy you get,
there is no absolute way to tell if it is needed by anything else.
>* 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.
Yuck! Did you hear yourself? "At least some" of the dependencies? The
uninstaller must be able to find them ALL or you will have problems.
>* 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.
Who's going to maintain this library? Do you want to add a section to the
DJGPP license that requires that anyone who writes a program in DJGPP
and distributes it inform the library maintainers as to the exact directory
structure they're going to use? I can see it now...
>* understand the maintenance directory set up when installing current releases
> of djgpp
That is simple enough. Then again, you will always have crackpots like
the ones that install v2 over v1 and get their files completely messed up.
>* check the date of CWSDPMI, record the time when the installer installed
> CWSDPMI, or if CWSDPMI was already there.
Agreed. CWSDPMI's datestamp is the easiest way to tell one version
from another.
>* 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.
And how many minutes did you want the uninstaller to take searching every
file on the user's hard disk?
>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!
That was more or less my idea too, but you'd have to essentially rewrite
the zip program to allow a self-extractor to autorun a program immediately
after decompression. Kinda hairy.
>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!
If we could get people to do that, it would be really neat.
>I'm thinking of ID (quake), Executor (mac emulator), Gofer/hugs (Functional
>Programming language), Cylyndrix (game), RHIDE, and gnu packages like emacs.
I am sure that ID will write their own installer for Quake. :) Most of the
gnu
packages are already self-contained - just unzip them the right way and you're
set to go. They also come with makefiles for easy rebuilding. Writing an
installer for something like that would be a relatively minor task.
I still think that the hardest part of any installation program is detecting
hardware/software configuration to advise the user of any changes
necessary. I, for example, don't want any program touching my config
and autoexec without my express permission, and I have found that many
programs simply add lines to the beginning or end of those files, which
in many cases destroys their effectiveness. I use the multiple configuration
feature of MSDOS 6.2, and any installer would have to be very damn smart
to figure out where to put anything it needed.
John
- Raw text -