The Object-Oriented Nature of AmigaOS

Is the AmigaOS object-oriented? It was designed before OO became a buzzword, but I believe that in many ways it is indeed OO, and that it is as OO as an Operating System should be. I discuss AmigaOS Exec plus the various parts that work with it, up and including Intuition.

1. Objects.

That is, things rather than variables. This is the most fundamental concept in OO, though it is shared with things not called OO such as Frames in artificial intelligence. If we look at the data structures in AmigaOS, then each task, window, menory-chunk, etc. etc. is held as a 'thing' rather than a (complex) variable. That this is so becomes clearer when we consider the next characteristic of OO ...

1a. Flexible numbers of objects.

That is, no intrinsic limit. This means that, internally, the data structures that implement the objects must be held as linked lists or similar, rather than in tables. This is precisely what AmigaOS did, and what gives it much of its power and flexibility. Contrast with some OSs, which hold their OS-elements in arrays. Even though they might appear to be 'things' or objects, their real status is as complex variables since they are really parts of arrays. An array of this kind is of fixed size, and so there is a maximum number - as Windows people used to find!

1b. Ability to define new classes of object in future

A true OO system makes it easy to define new classes of object at future times, as need change. Thus extending the life of the product. In traditional OO this is achieved by some addition to a class hierarchy, but, however implemented, the main and most important benefit is this ability of the software to evolve according to needs. We find exactly that in Classic AmigaOS. With a few exceptions, AmigaOS has is so designed that new types of things and new features can be added at a later date - and not just bolted on, but integrated in a way that is very elegant. We think of datatypes, boopsi, SANA, etc. This occurs, not because of any cumbersome class hierarchy (see below) but rather because of its extremely elegant and appropriate design.

2. Flexible number of attributes per object.

That is, objects can have new attributes added during their life that were not thought of in the original design. In OO these are often called slots. Now, original AmigaOS did not have this very easily. Though there was usually an Expansion pointer and bit in each structure to allow for this, albeit in a clumsy way However, with the advent of TagItems it does have this. All one need do is define a new tag.

3. Message passing.

The activity mechanism defined for traditional OO is message passing. As opposed to procedure calling etc. AmigaOS has an excellent message passing activity (though it also has procedure calling where appropriate).

3a. Multitasking.

Inherent in the idea of message passing is that objects are active in parallel. That is, they multitask (if not actually multiprocess). It is the near-OO internal design of AmigaOS that has enabled it to do its multitasking so well.

4. Inheritance.

Traditional OO derives attributes of objects by an inheritance mechanism, by which if the object does not have that attribute then it climbs up the inheritance tree (class hierarchy) to see if classes above it have the attribute. Now, AmigaOS exec does not have this. (Or at least not explicitly: if you want to find for instance the number of colours of a Window, then you traverse the pointer to its RastPort and then to its BitMap, or via Screen, and such traversal can be seen as similar to climbing an inheritance hierarchy; but I do not name it as such.)

4a. Inheritance not for OSs

However I would argue that an exec should NOT have inheritance. Because inheritance is, by definition, a huge slow-down. Instead of one memory access to obtain an attribute value (or a very few) you have an indefinite number, depending on how long the inheritance tree is. Horses for courses: inheritance aids the human during knowledge representation and design; it hinders the efficiency and elegance of an OS. Therefore the fact that AmigaOS exec lacks inheritance is a plus point rather than a minus.

5. Encapsulation.

The above were the original OO concepts. Later concepts include encapsulation and polymorphism. Encapsulation means that the user or caller of an object should not know nor be able to access the insides of that object. The reason for this is to prevent programmers from messing up the inner workings of objects. Is this appropriate for an OS? Well, there will be much debate. But I think not. As conceived, encapsulation is a device aimed at making the process of programming less risky with low-grade programmers. If programmers were higher grade, more careful, more motivated to care, then encapsulation would be less important.

5a. Opening the bonnet.

Now, I remember some years ago somebody making a comparison between AmigaOS, MacOS and Windoes, likening them to looking under the bonnet of a car. In MacOS the bonnet was welded down so you could not look underneath. In Windoze you lifted up the bonnet and found a complete mess that nobody could understand. In AmigaOS you open up the bonnet and there is everything laid out neatly and cleanly. Encapsulation, when taken religiously, leads to the MacOS syndrome.

6. Polymorphism.

Each objects 'knows' how to respond to each message it receives. It is the object's responsibility to know this, not the caller's. In AmigaOS exec we find polymorphism in some places and not others. It is there in the message lists in that it is the responsbility of the receiver of the message to know how to deal with it. But it is not there in e.g. memory lists. However I would argue that it probably should *not* be there in memory lists because of the need for speed. Any attempt to check the type incurs a runtime penalty. Maybe AmigaOS could use a bit more polymorphism in some places (e.g. Intuition gadgets can have either a bitmap or a list of lines, but not a mixture - that is a pain.)


Therefore, I contend that AmigaOS exec is almost exactly as OO as an OS should be. That is, indeed, one reason I have delighted in it for so long, and it has seldom disappointed me.
Copyright (c) Andrew Basden 1998.