CS> software over which I have complete control -- when it comes CS>
time to update the software after we get the first release CS> done,
we'll probably distribute updates such that they
CS> reformat the hard disk of the system and load the most
CS> recent OS/2 and the software.  Since this software is

 CM>   Ouch.. Sounds like pounding a nail in with a jack-hammer to me. :-)

 CM>   Wouldn't it be simpler to just scan the drive (or
 CM> LIBPATH) for occurrences of the DLL and delete them?
 CM> RexxUtil's SysFileTree would make this a snap.

No, that would be more somewhat more work (i.e., more software to write and
support since we need to have a from-scratch installation program for
installing OS/2 and the software anyway) and wouldn't fix problems where
OS/2 itself became screwed up.  Given the sophistication (i.e., likely lack
of computer experience) of the users, we have to fully expect and plan for
them sometimes trashing the file systems due to repeated power on/off
cycles without proper shutdowns.  Although we're using HPFS to help
increase the odds that the auto-CHKDSK on power-up will find and fix
problems, there's still a chance that it will fail sometimes and require a
complete reload of the system.

I wish there was a way to use on/off switches on computers to signal the
system to shut itself down and then cut off its own power, but that's not
how most computers work.  Maybe if this project turns out well we might
eventually be able to commission some custom-designed hardware with such a
feature.

Besides, we're going to need a way to install OS/2 and the software on
computers quickly.  Since every site will have an optical drive, my
thinking is that we can provide a one or two diskette set of boot floppies
and put everything else on an optical disk.  If the software gets trashed,
boot from the floppies and wait for the installation program to reformat
and reload the system from the optical drive. It should just take a few
minutes.

Since we're initially going to be using uniform computer hardware at all
sites, this should be pretty easy to do when I get around to it.  It might
get tougher if at some point we have to support multiple types of computer
hardware.  Maybe OS/2 3.0's installation will be good enough that we can
depend on it to figure out the hardware on its own.  Since we only need the
OS/2 native part (no DOS or Windows support is needed or wanted), there's a
better chance of this working.

CS> the problem, or at least 90% of it.  A "standard" format
for CS> naming DLL's might help, also.  If you used the first 4

 CM>   In theory this would be nice and would work for in-
 CM> house projects. But for widespread use it would be
 CM> nearly impossible without some type of registry that
 CM> is accessible to everyone producing DLLs.

I'd agree that a registry should be set up if such a scheme is to be used.
The registry needn't cost much to run, however.  It could be as simple as a
BBS door that simple allows you to "register" various DLL names
and will refuse registration if someone else already registered that name.


--- Maximus/2 2.01wb