I've come across a few glitches in the recommendations I have made during the course of building our prefect Workbench, so we'll have a look at these problems before we go on to new stuff.
First, let's return to the "user directory" scheme I proposed earlier. As you may recall, the idea here is to create a separate set of directories for third party programs and files, in order to keep the original files of the Amiga OS organized. This helps keep problems like program over writing important system file to a minimum, since the install process will point to user created directories, while still allowing full access to all the files of the Amiga's OS.
The following lines show the basic commands to set this up, from the Startup-Sequence:
There are two important facts to note. The first part of each command hijacks the normal assign to point to the user created directory. The second part assigns as an addition the original directory, which means the system will look to the first directory, then the one using the ADD option.
Sharp eyed readers will notice a couple of curious things. First, both the Classes and Classes-User directories are ADDed to the LIBS: assign. Classes, which hold the datatypes and a few other things are special examples of Amiga's shared libraries, and thus are lumped in with the LIBS: assign, rather than receive their own CLASS: Assign. Notice that again, the Class-User directory is assigned before the original Classes directory, so the system will go to the user directory first.
Secondly, unlike all the others, the Devs-User directory is not assigned first, but is assigned as an additional ADDed directory. The reason for this is simple, and unfortunately, seemingly impossible to get around. In the DEVS: directory you will find the directories for DOS Drivers, monitors, printers, datatype descriptors and other stuff. The fault, dear Brutus, lies not in our stars, but in our datatypes. Note that the Datatypes directory in DEVS: is not the same as the Datatypes directory in the Classes directory. The files in the classes/datatypes, for example ilbm.datatype, contain the code to actually view the corresponding file. The files in the DEVS:Datatypes directory, are the matching descriptors, ILBM for the above example, which contain information on how to recognize the various file types. While the Amiga is perfectly happy with putting the .datatype files in a user created directory, it balks when the same approach is tried with the descriptors. Only the datatypes directory in the first DEVS: assign is recognized. The second assign using the ADD option is apparently ignored. I haven't found a workaround for this, so I guess you just have to keep all your datatype descriptors, original and third party, in the original DEVS:Datatypes directory.
Start it again Sam, or maybe not...
Figure 1:MultiStart Installation Conflict
Another crop of glitches has surfaced regarding the program MultiStart. If you recall, MultiStart allows you to customize your Amiga's boot sequence. The first problem is in regards to the manner in Which MultiStart changes the Startup-Sequence file. In essence, only the commands needed to run MultiStart are left in the original Startup-Sequence. All the other commands are put in various sub scripts, such as Start-Def, which are called by MultiStart. One of the cuts are the lines which call up the User-Startup:
IF EXISTS S:User-Startup
Execute S:User-Startup
ENDIF
These lines are removed from the Startup-Sequence, because they would interfere with the operation of MultiStart. The problems arises when you install a new program. Most programs like to add commands to the User-Startup file. In the process of this, the standard Amiga installer will check to ensure that the above three lines are present, and if not, will desire mightily to put them there. Usually you are informed of this state of affairs, (see Figure 1) and could opt not to allow the installer to do this, but chances are the program will not work without the commands added to the User-Startup. The path of least Foobar seems to be let the installer have it's way with your Startup-Sequence, then go back and manually remove the offending lines in you favorite text editor.
One more MultiStart problem I've had may be some weird glitch with my system, I've brought the wee beastie to it's knees many times in the course of researching this series. However, I did experience this problem using a clean OS install, so maybe it's a bug. MultiStart claims to be able to selectively disable programs in the WBStartup directory, as well as allow for multiple startup-Sequences. However, this refuses to work for me. All the WBStartup programs get launched, no matter which ones I select via MultiStart. I seem to remember this working at one time, but then again...
WBStartupPlus
John Hughes
Post Card Ware
http://wuarchive.wustl.edu/pub/aminet/util/boot/WBStartupPlus.lha
At any rate, if MultiStart doesn't work for you, you might want to look at WBStartupPlus. This program, by John Hughes, features a nice GUI, and the ability to selectively disable programs in the WBStartup drawer, and even choose the order (priority) in which they are run. See Figure 2 and 3.
