The Rise and Fall of Installation Procedures

by Dr.Morbius & Tokai

3 - Installation Procedures and MorphOS

3.1 - Fall of Installation Procedures

3.2 - Minimal Installation Procedures

3.1 - Fall of Installation Procedures

At first sight, the title of this section, and even the title of the full article, now seem to be inconsistent. All the subjects discussed above show clearly that the complexity of installation procedures increases with time, and that they are essential for unskilled users. Thus their use should rise towards highest peaks: where are the conditions for the above-mentioned fall? The answer to this legitimate question is dual. (1) There is no doubt that installation procedures are (and will certainly be for long time) software monsters on all the alien platforms. However, (2) a new revolutionary concept seems to be encouraged by the MorphOS team: installation procedures could disappear in this environment or, at most, they should have the smallest possible size and the simplest structure.

As a consequence of the previous argument, there is no need for further discussions concerning installation procedures on other platforms: these will not fall and will remain uncontrollable software monsters in the next future. Therefore, from now on, our attention will focus exclusively on a single subject of interest: MorphOS environment.

You know very well that MorphOS programmers are a jealous people. They give us almost no news about the state of advancement of their project, as well as about the road that it will run in the future. So, like for many other things related to MorphOS, we have no explicit statements, but must deduce what is in the mind of OS programmers by a number of mostly vague indications and statements. Here we will take into account even fragments of information contained in sentences dispersed in IRC discussions and comments, in forgotten e-mails sent to the MorphOS mailing list or elsewhere, as well as more or less explicit suggestions by people who appear to be very close to members of the MorphOS team.

There is an evidence that is very well known by every user: no Installer is present in MorphOS. It is very strange that just this single program was forgotten by a team that, on the other hand, was able to create from scratch the ABox (the AmigaOS 3.1 API compatible environment), as well as clones of all the hard disk based components of AmigaOS. This is neither a coincidence nor the result of laziness, but could be seen like a sentence of death! The message for the users is: use the Installer for the installation of legacy applications programs, but forget this program for future applications. The MorphOS CD-ROM, of course, does not contain a complex installation procedure written for the Installer, but a simple CLI script that does the job. The entire script is formed by a number of hardware and security checks (as well as salvage operations of previous installations, if any), as it should be for such an important and delicate operation. Actually the commands that do the real job are in two lines of the script that copy the boot.img file to its reserved partition and the OS to the boot-enabled system partition. In case of emergency you could install the entire OS by hand, simply typing in a shell window:
Copy MorphOSBoot:boot.img To BT0:
Copy MorphOSBoot:MorphOS To DH0: ALL CLONE
(here I assumed that the boot.img destination is a partition named BT0: and the system partition is named DH0:; you should insert your names). In other terms, besides the new kickstart (that is the boot.img file), you simply must copy all the files and directories contained in the MorphOS directory of the CD-ROM to the boot-enabled partition of your hard disk.

It seems that MorphOS programmers forgot or deliberately ignored the ISO 9660 AMIGA specification for CD-ROMs supported by MakeCD (and introduced by Angela Schmidt, if I remember correctly). So on the MorphOS installation CD-ROM (1.4.x) the Amiga protection bits "hspa" are not stored, as well as filenotes. As a consequence, you should integrate the manual installation described above by typing also
Execute MorphOSBoot:hdinstall.fixc
to activate the "p" bit for pure commands that can be made resident.

This is the real concept of installation that seems to be supported by the MorphOS team: copy and use! Any other available information concerning the will of the MorphOS team seems to point towards a similar strategy for every application. This means that you should find all the files related to an application in a directory of the distribution CD-ROM or archive. Ideally you should simply copy that directory and all its contents to the selected partition of your hard disk. This should be enough for a successful installation!

There is no doubt that everyone will agree that the latter is certainly the simplest and smallest installation procedure that can be imagined. But there is still an important question that should receive a precise answer: will such a procedure be always successful?

3.2 - Minimal Installation Procedures

Here we will see that ideal installations like those mentioned in the previous paragraphs can really be adopted, but sometimes could create problems that the application programmer(s), the OS, and/or the user must face with adequate actions. The best installation procedure has to be minimal, but usually will not be the smallest.

When the application only comprises one or more executable files and a suitable collection of data files, and possibly uses a number of OS files, the smallest installation is clearly perfect. On the other hand, when the application package also contains some auxiliary files like libraries, handlers, devices, fonts, a few problems can arise. In such a case there are three possible strategies for the installation:

  1. The classic solution requires that all the auxiliary files are copied to the relevant system directories SYS:C, SYS:Devs, SYS:L, SYS:Libs, SYS:Fonts, where the OS will automatically find them when they should be used.
  2. The second conceivable solution requires that all the auxiliary files are stored in the application directory and that additional logical assignments are created. In such a way, C:, DEVS:, L:, LIBS:, FONTS: will also point to the relevant subdirectories of the application directory, and the auxiliary files contained therein can be found by the OS.
  3. The third solution is the simplest/smallest installation defined above: all the auxiliary files should go into the application directory without additional assignments. It is evident that this will work only if the application is smart enough to search for all the auxiliary files in its own directory as well as in the OS directories.

Item [1] above is just the standard installation method always used in the Amiga environment. It requires the programming of proper actions in the installation procedure. Usually, the auxiliary files of the new application must be copied to the correct destinations, and this operation requires a number of checks. In fact the installation procedure should avoid that important files in the SYS: directories are overwritten, unless these pre-existing files are older versions. Another usual step of the installation procedure is the editation of the S:user-startup file, where possibly an assignment to the application directory is set and/or some relevant initialization commands are inserted.

Actually MorphOS has minimised the overwriting problem because the OS files are segregated in separate directories collected in SYS:MorphOS, under the MOSSYS: logical assignment. So, the files that possibly can be overwritten are only user files collected in SYS: directories.

Item [2] above is similar to item [1], but requires a different activity: the activation of additional assignments through editation of the S:user-startup file or creation of a specific startup file in the application directory. This can be done by the installation procedure (but there are very few installations programmed in such a way) or can be forced by the user. I don't know if there are other users that followed this way, but I did. I like to have self-contained installations, with applications that live together with all their auxiliary files and do not scatter them throughout the SYS: directories. So I decided to force the segregation using two CLI scripts that allowed me to intercept all the attempts, done by installation procedures, to copy files to the system directories. Then, all the files sent to LIBS:, and intercepted, were put manually by me in a directory Libs created in the application directory; all the files sent to FONTS:, and intercepted, were put by me in a directory Fonts in the application directory, and so on. Finally I added assignments to the new subdirectories
Assign LIBS: <application directory path>/Libs ADD
Assign FONTS: <application directory path>/Fonts ADD
so the OS was able to find those files.

Item [3] above is the simplest approach, but requires a preventive activity by the application programmer(s), who should take care of inserting the necessary ability (to search in its own directory for the auxiliary files) in the application code, and/or should write a loader that takes care of all the necessary initializations.

If we want to judge these approaches in terms of their advantages and disadvantages, we must say that method [1] guarantees the centralised management of all the shareable files, but it always implies the risk that some undesired overwriting occurs. It is important to note that this event is very dangerous: if the user is not aware, he could discover sooner or later that other applications, already installed, are no more able to run. This usually happens because these applications rely on SYS: files that were erroneously overwritten by older versions installed by badly written installation procedures. If these unexpected problems are discovered too late, it is usually very difficult to trace back the real cause of the problem. On the other hand, both methods [2] and [3] make very easy to uninstall an application, because the user should simply delete the application directory and there is no risk to leave alien, no more useful, files in the system directories. However, method [2], if not forecast explicitly by application programmer(s), requires active actions by the user, and this means that unskilled users could find that it is difficult to apply. Method [3] removes these difficulties and is certainly the simplest choice. So, all these considerations seem to be in strong favour of method [3], but we will see in the next section that things are never so easy as we could like, and we must always pay something to get an advantage.

Please note that here I do not touch the delicate subject of preference files. Here the widest anarchy rules. There are programs that save their preference files in S: and others that use their own directory, programs that use ENVARC: and others that use their own icon, programs that use text files and others that use unreadable binary files. Even if the use of ENVARC: should be the preferred approach (according to the rules stated by Commodore), the subject needs a clarification that only the OS programmers could and should give once and for all.