|
|
|
|
|
|
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 |
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
to activate the "p" bit for pure commands that can be made resident.
Assign HDIMOSVOL: DH0:
Execute MorphOSBoot:hdinstall.fixc
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?
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:
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 ... |
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.
|
|
|
|
|
|