Path: utzoo!utgpu!watmath!clyde!att!pacbell!ames!mailrus!uwmcsd1!marque!gryphon!keithd
From: keithd@gryphon.COM (Keith Doyle)
Newsgroups: comp.sys.amiga.tech
Subject: Amiga Roadblocks to User Friendliness
Message-ID: <9407@gryphon.COM>
Date: 8 Dec 88 18:01:05 GMT
Reply-To: keithd@gryphon.COM (Keith Doyle)
Organization: Trailing Edge Technology, Redondo Beach, CA
Lines: 118

At the risk of starting another round of heated controversy over the
"correct" way to package programs, I've run into some new difficulties
in trying to package a program to be as clean and easy-to-use as we
dream of.  Not a demo contest entry, it would seem even more important
that it adhere to such standards, even though the problems I've been
experiencing are not specifically in conflict with the BADGE rules.

1. You apparently cannot do (easily) the equivalent of a an AmigaDOS

      path xxx   REMOVE

So, if you find it useful for a disk to add a command directory to the
current path for some reason, that disk's icon will not go away once
you remove it from the drive.

Why would you want to do such a thing?  I can envision one scenario, where
you have a product that supplies several new CLI commands, and you have
an icon that you can click on (after having booted from any WB disk) that
does a path add, and gives you a NewCLI all ready for you to try out your
new commands.

One potential solution would be to do something like a "path >ram:foo"
and later do a "path reset" followed by the appropriate number of
"path xxx add"s reconstructing the users original environment.  Doable,
but messy.

Further, if a developer would like to construct an auto-install program
that adds these new commands to the users C: directory, we have the
problem that likely as not, the novice is using a completely packed WB
floppy disk that has no room for added commands.  Apparently Commodore has
encountered this problem and resolved it with questions like "would you
like to delete fonts?" or "would you like to delete narrator/translator?"
and various stuff like that.  It would seem to be clear that a "make room
on the WB disk" could be a general utility that many developers could
make use of when installing certain types of new capabilities into a
users native environment.  A lot of novice users have figured out how
to use a few basic CLI commands, but have no conception of how the C:
directory works, and are completely unsure of what they need or don't
need on their boot disk.

And the worst problem.  Those of you who have installed programs under
MSDOS are presumably familiar with various INSTALL.BAT programs that
do auto installs on hard disks, many of which actually modify the
AUTOEXEC.BAT or CONFIG.SYS to add necessary boot-time configurations
for the new package.

A similar scenario on the Amiga might be a click-on icon that installs
a package on a hard disk.  Let's say this package needs an Assign and a
path xxx add added to the startup-sequence, and the package is being
installed in DH1:.

Now lets investigate what the GVP hardcard builds as a boot sequence when
you click on *their* auto-install icon.  I pick the GVP system because that's
what I've got.

DF0:s/startup-sequence looks about like this:

mount dh0:
binddrivers
dh0:c/execute dh0:GVPScripts/HDstartup-continue

Somewhere buried in HDstartup-continue is the mount for DH1:.  Thus,
an ASSIGN foo: DH1:somedirectory  is not doable until sometime after
this mount DH1: command.

How could an auto-install program address this situation?

1. Somehow determine if we have an autoboot rom or not.
2. if autoboot, start with DH0:s/startup-sequence
3. otherwise start with DF0:s/startup-sequence
4. chase startup sequence looking for execute commands, and 
5. nest into subscripts looking for ????

What.  What do we look for?  LoadWB?  EndCLI?  The end of the script?
Then backup up and insert our ASSIGN and PATH commands?  Do we really
want to even be modifying a script like this?  (though I presume there
would be lots of *WARNING* messages letting you know what it is about
to do "Are You Sure"  "Are You Sure You're Sure"  "I Don't Think You're
REALLY Sure, Do You?"

Now, arguments that anyone who has a hard disk should be able to add
ASSIGN commands to his own startup-script are nice, but far from
reality.  I talked to a user a couple of days ago, who had a brand
new Amiga 2000 with HD which was completely installed and setup by his
local dealer.  He was trying to install packages onto his hard disk simply
by dragging the visible icons onto the hard disk.  He couldn't drag the
entire disk icon onto the hard disk (as you would expect ala-MacIntosh)
because you get a "Can't move icon out of window" error or something like
that.  We apparently don't have a "move entire disk into a drawer on the
HD" capability without the CLI.  While some packages perhaps can be
installed simply by draggin the visible icons, certainly not all can.

So, I proceeded to spend about 1-1/2 hours with this guy explaining to
him how to use the CLI for the first time (CLI, what's that?) and
over-the-phone following his startup-sequence maze to a convienient
place to add the useful ASSIGNS, how to use ED etc.  Fortunately he
had a GVP harddisk with which I had some familiarity.  After it was
all over, he said "well that isn't all that hard".  And he's right,
it isn't all that hard, but it would have been if he had tried to 
figure it out for himself.

So what's the answer?

1. make sure commercial applications never need boot time configurations
such as ASSIGN or PATH?  

2. chase startup script chains looking for something typical and adding
in the commands automatically after ultra-warning operator?

3. warn user that the Amiga is inherently unfriendly to novice Hard Disk
users who are unfamiliar with the CLI, so he'd better go out and buy a
good book, or drag his system back into his dealer and let *him* install
it?

4. ???? (god I hope there's a 4. and maybe a 5. and 6.)

Keith Doyle
gryphon!keithd