GUI Wonderland #5 – In a Beautifully Connected World – Apollo Aegis

Introduction:

Hello again, and welcome to Episode 5 of GUI Wonderland; time flies, and it’s insane to think that we’ve gotten this far in just 9 months (plus the development hell this series was originally stuck in, but you didn’t see that, so we’ll pretend it doesn’t exist)! Whilst it’s certainly enjoyable to reminisce, I’d prefer to leave this kind of talk to the Journal’s Introductions; thus let’s dive into today’s topic!

Apollo/Domain & AEGIS

A Few History Notes & Development

The company behind the Domain systems, called Apollo Computer Inc., was founded in 1980 (two years before Sun Microsystems, which will be covered in a future Episode) in Massachusetts by a man called William Poduska (who also worked on the Multics time-sharing operating system at MIT); whilst they might be less popular now among retro technology enthusiasts, they were still some of the first to sell graphical workstations in the 1980s, alongside the more popular Sun Microsystems.

In 1981, Apollo Computer Inc. released their first Domain model, which was originally known as the DN416 workstation; it was then renamed to DN100 once its green screen was swapped with a black and white screen. Whilst I haven’t found much about its development, we do know that one of the very first customers who purchased an Apollo was Harvard University, which acquired two Domain systems on March 27, 1981.

Software & GUI

As we saw with the previous systems, instead of paying to use a third-party OS, Apollo also used its own operating system, called Aegis (apparently, this was done to avoid facing the excessive cost of a single-CPU Unix license); it was released in 1981 alongside the DN416, only for it to be successively revamped and renamed to Domain/OS in 1988. Aegis was full of useful features, some of which were still groundbreaking at the time, such as having an object-oriented file system (similarly to the Apple Lisa^{[ep 3]}), network transparency^[1], and diskless booting; starting from Domain/OS, it also allowed interoperability with BSD, Unix System V, and POSIX-compliant^[2] systems.

Aegis & Display Manager

Let’s first cover the earlier iterations of the Apollo Domain’s operating system; Aegis, similarly to Unix, was inspired by the Multics time-sharing OS, plus, it was a distributed operating system. This meant that any computer running this OS performed at its best when connected to a network, and unlike other systems which simply had additional network features (such as the Xerox Star^{[ep 2]}, the PERQ^{[ep 4]}, or the Apple Lisa^{[ep 3]}), Aegis considered networking as an essential part of the experience; primarily, each component had both a local and a remote part, plus, the file system residing on each machine was considered to be the same as the ones found in the same network, unlike in Unix (which also allowed diskless booting), and many important administration settings were solely network-based. Lastly, if the systems didn’t already seem network-oriented enough, let me add one final piece to the puzzle; you literally couldn’t configure a node without a network card inside!

Moving on, this wouldn’t be a GUI Wonderland Episode if we weren’t going to talk about some GUI; just like the other systems we have seen, Aegis has its own high-resolution graphics-based GUI, called Display Manager (DM), which works alongside another deeper-level window manager, known as “Window Manager” (yes), shortened to wmgr. The way this collaboration works is that DM will offer a built-in text editor and a “transcript”, which acts as the Terminal program, whilst on the other hand, wmgr will allow all windowing functions to work properly; in case you wanted to extend DM’s functionalities, you can add more programs, and DM will take care of them.

Now, as we’ve often been accustomed to doing in the previous Episodes, let’s talk about how wmgr conceptually sees windowing; according to the documentation, windows are seen as openings on the screen, through which you see information contained in the so-called “pads”. What are pads, you might be wondering; you see, they are what we could refer to as containers, which keep the information that you display in a window, and they hold this data inside a temporary file. Whenever something needs to be shown in a window, that same window will call part or all of this data to show it to the user, and can go back to retrieve more of it, or put away some. It sounds confusing in theory, but it makes sense; imagine that you are looking out of a window, and there is a nice forest outside, however, you don’t see all of it right away. If you were to move to the side, you’d now see some new scenery, though part of what you could see before is now hidden; of course, what you can’t observe doesn’t simply disappear (at least, this is what science implies, but let’s not jump into the existential rabbit hole), and if you move again, you’ll see it.

Now, going back to wmgr, and with this example out of the way, we can see that, similarly to the other systems we covered before, a user can have as many windows as they want on the screen, and resize as well as overlap them in any way they desire (by dragging them with the mouse), just like papers on a desk^{[ep 2]}; the inactive windows’ contents will be darkened, and to make a window visible again, you can simply click on it (or you can use a special key named POP). However, the only “issue” with this otherwise intriguing GUI is that, in a similar fashion to the PERQ^{[ep 4]}, you need to use the command line for everything, so novice users would have had a hard time learning how to operate the system.

DomainOS

As we have seen before, at some point Aegis was renamed to Domain/OS (which stood for Distributed On-line Multi-access Interactive Network/Operating System, which was internally numbered as SR10), and alongside the new name, it also got new features; unlike what we might have expected, at the beginning, Domain/OS was just a layer placed on top of Aegis, and wasn’t built on any Unix kernel.

So, what are these improvements that Domain/OS introduced? The most fascinating one, at least to our GUI Wonderland series, is that it turned Aegis into a core OS that could support not only the Aegis environment itself, but also System V Unix, and BSD Unix’s; this allowed it to be more compatible with other Unix systems, which were common in universities and similar locations. Alongside these other environments, Domain/OS also provided an improved version of the X Window System and its VUE (HP’s predecessor to CDE, which is a perfect topic for a future article), though it had poor performance; we will certainly be covering the X Windowing System in a future episode, as it deserves to be explored on its own. Moving on, whilst Domain/OS was technically compatible with POSIX-compliant systems, it was not compliant on its own, and Apollo was working on making that a reality; although, as far as I’ve understood, they were bought by HP before that could happen.

Now that we have seen what it offered, it’s time to see whether this upgrade was ultimately worth it; first of all, whilst on one hand, you had all the new Unix features, the system still needed to be backward compatible with Aegis, which meant that the system was slower as a result, and it needed more disk space as well. Moreover, as it often goes with new system releases, SR10 was quite buggy, and managed to complicate things that were initially easier; as you can easily imagine, this made people put off updating to SR10, and whilst it became better later on, users still didn’t want to get Domain/OS unless it was the only option available (in fact, the later systems could only run SR10). Thus, we could say that Domain/OS wasn’t exactly popular, despite all the new and exciting environments it offered; as a fan of intriguing GUIs, it is certainly sad, yet, if the rest of the software was buggy or not adequate, there wasn’t much they could do. Did it ever get any better? Well, not really, as after Apollo was bought by HP, support for Domain/OS went on for a while, until it eventually ended on January 1, 2001.

Graphics-related Libraries

If, by any chance, you wanted to use your Apollo workstation to create some impressive graphics, be it in 2D or 3D, then you will need a regular compiler (C, Pascal, or Fortran), alongside access to the Apollo’s graphics libraries (some of which are to be paid separately, although I bet that’s impossible right now). Here are some examples:

1. GPR (Graphics Primitives Resource): It is an in-built library, which is provided with the main OS; it is a 2D library that can be used to draw various shapes, and you can edit the color, style, and other aspects of the figures. It is regarded as a really important library, considering that it’s the one that was used to write the Display Manager itself! It’s also the best one for “beginners”;
2. PHIGS (Programmer’s Hierarchical Interactive Graphics System): This is an optional 3D product, which was an industry standard when it came to 3D graphics. If you’re curious about what you could do with something like this, feel free to check the Additional Information box below.

Hardware & Network

Memory	1 MB (expandable to 4 MB) (Earlier systems) – from 2 MB to 32 MB (Later systems)
CPU	Motorola 68k series of processors
Storage	68, 158, or 300 MB hard disk (optional) (Earlier systems) – 76, 150, 330, or 660 MB hard disk (optional) + 5.25” floppy disk drive or QIC-type cartridge tape drive (optional) (Later systems)
Display	19”, 1024×800, bitmapped
Graphics	Bit-sliced, 16 bit, dedicated
Input	keyboard, mouse, graphics tablet

Let’s now have a look at how an Apollo Domain System worked. When you bought an Apollo Domain system, you got a number of machines, called nodes, each of them running a complete and highly configurable set of standard programs, such as some for file storage purposes and more; additionally, there was another kind of systems, which was to be used as a “server”, and it would provide all kinds of designated network functions to the other nodes connected to it, as well as accessing their stored data, all thanks to the Apollo Token Ring (ATR) functionality. Something admittedly fascinating about these nodes is that, assuming they were connected to a server, they could be booted even without a hard disk inside, virtually turning them into “dumb terminals”; however, if you wanted to take advantage of diskless booting, you’d have to accommodate a server for about a maximum of 4 machines.

In case you had a node without a display or a graphics card (a server, perhaps), it would have been called a DSP (which means Domain Service Processor), and it could also be accessed with those dumb terminals we have just mentioned; for quite some time, these needed to be part of an older line of devices, as the later units (such as the DN300 and the DN330) were designed as all-in-one devices meant to fit on a desk, and had their own in-built screen (similarly to the Apple Lisa^{[ep 3]}) (I am not sure whether you could actually simply turn the new ones’ screen off and use them as servers, or if that was impossible or economically not viable). Later on, Apollo also produced machines that were housed in IBM PC-style cases, without an in-built monitor, which made them easy to service.

Are Distributed Systems Ideal?

As we have seen throughout the article, networking was undeniably crucial to the Apollo workstations and, for this reason, they are called Distributed Systems; let’s now have a look at whether they could be considered ideal or not.
The advantages of such a system included:

• They were able to run even when one node failed (if the correct precautions were taken);
• They allowed you to improve your internal network easily, as you simply needed more nodes;
• You could split difficulty tasks between multiple machines;
• File sharing was easy given that internal and external disks were treated in the same way.

However, there were some issues:

• Even if the other nodes could run whilst one had failed, what if it was a crucial one?
• You needed to purchase several of them for them to be convenient;
• You would have hated to have to go back to an inferior system 🙂

As the advantages outweighed the disadvantages, it was decided to turn the Apollo Domain workstations into a Distributed System.

File Naming

Alongside the problems we have seen before, there was also a tricky choice that had to be made; in a system that would treat all disks connected to it in the same way, even if they were in another location, how would you go about file naming?
The developers had two choices:

• UID: it’s a string that uniquely identifies a file, and it’s valid throughout the network; it doesn’t say where the file is, and must never be reused. Both Aegis and the Xerox Alto^{[ep 1]} chose this one.
• “Structured Name”: made up of various components that describe the object, also telling the computer where to retrieve them. You can reuse them.

Whilst I’m sure Structured Names sound more appealing, in the end, they weren’t chosen; why was that? You see, if they had gone with the second option, once the location of a certain object changed, its name would have needed to be changed as well; this means that if you had any direct references to that object, you would have to change those references in order to connect to the file’s new location. Thus, it was decided to save users this hassle, and go with the first option.

Now, even if it doesn’t really have anything to do with GUIs, I would still like to bring Aegis’ intriguing naming process to your attention; this process used time as a basis, and on Aegis, time was calculated thanks to a 36-bit system (starting since 1/1/1980) which gave them an impressive 34.8 years of unique names… which ended in 2014, so I guess it sadly doesn’t work anymore.

Still, UIDs still created some problems which had to be solved:

• The system needed to be able to understand which UIDs were already taken, not only on local media, but all over the network (which was luckily possible, given that the time on each node was synchronized);
• If there was no indication of the location of an object in its name, you needed other ways to find where it was;
• What about multiple versions of objects?
• A scary one, losing objects: A lost object is a file that still exists, but can’t be accessed as it has no references anywhere. It will still take up disk space, and it may become lost due to a crash, or if every item that leads to it gets somehow deleted; you can still recover it with a volume scan, but it’s not always possible.

The trickiest of them all, however, was time itself; Aegis was able to create unique UIDs only if the internal clock kept advancing, and only if they were all synchronized. Thus, on startup, each node would check the time and compare it with the other nodes thanks to the Account Registry, and complain if the time it had internally stored was different; the problem would arise in case the clock had to be moved forward to a point of time which was a bit too distant from the previous one the machine remembered, as some of the UIDs it had generated up until that point may now be in use on other machines. For this reason, it was crucial to make sure your clock was always on point, and in case your internal battery died, you’d have to set the right time manually on each startup; I bet you can easily see how, despite looking more convenient, that method still hid many issues.

Marketing & Reception

Domain Systems were easy to use and administer, though they started to become less convenient as, funnily enough, whilst Aegis was initially made so that Apollo could save money and avoid paying for Unix, it eventually became more expensive for users to buy Aegis software than to buy the Unix equivalents. Plus, the processors found in the nodes were slower than the ones found in Sun Microsystems and Hewlett-Packard’s machines, and whilst Apollo did introduce a faster machine (the DN10000) it was still extremely expensive, and Domain/OS wasn’t stable enough. Eventually, the rise of cheaper PCs meant that Apollo machines weren’t desirable anymore; even so, from 1980 to 1987, Apollo was still the largest manufacturer of network workstations, and it had a bigger market share than Sun Microsystems (Apollo’s customers were companies such as Mentor Graphics, General Motors, Ford, Chrysler, Chicago Research and Trading, and Boeing).

What Happened to Apollo?

Unfortunately, Apollo incurred in large losses first in 1987 due to speculation, and in 1988 as the demand for their workstations was in decline; thus, in 1989, Hewlett-Packard bought Apollo for US$476 million, and gradually closed it down in the following 8 years. Still, they integrated some of the Apollo technology in their own HP 9000 workstations, and some of their workstations could now run either HP-UX or Domain/OS; at the time of purchase, you could choose between either of them, and you’d receive the necessary compatible hardware.

Sadly, support for older Apollo machines wasn’t as good as one could have hoped, as we have seen with the 1997 Time Bug, and the brand eventually died, only to be resurrected in 2014 as “HP Apollo”, for a series of high-performance machines; it’s really sad to see yet another intriguing system go, and as always, we can only do our best to preserve its legacy.

Conclusion:

We have finally reached the end of our 5th Episode; we saw how, once again, GUIs didn’t necessarily mean user-friendliness, and how they were used in a unique Distributed System that was almost resembling to Time-Sharing, right when Three Rivers was trying to abandon it. As I mentioned before, we’ll have a look at the X Windowing System later on, though for now, our next stop in this magical journey will be with VisiOn, and we’ll see how the Apple Lisa’s rival was faring!

Now that you’re done reading this, don’t forget to have a look at the References and the Further Reading sections below, where you’ll find more materials to read!

As always, thank you for reading, and I hope I’ll see you in the next Episode, in the next Journal Page, or anywhere around the site.