The Long View
A/UX
In 1988, Apple released the first version of their Unix-based operating system. It was a complete multi-user Unix kernel with preemptive multitasking and memory protection. It could run regular Unix programs and X-windows1 programs like other Unix boxes, but it could also run Macintosh programs. Practically all existing Macintosh programs could run in a kind of classic environment. But you could write a special kind of program that lived in the Unix environment, had Unix virtual memory and memory protection, and used the Macintosh toolbox to create its user interface. It was pretty easy for a programmer to recompile a regular Macintosh program to take advantage of this new environment. Sounds a little like OS X? Yes, Apple had all that available as a product, from February 1988 (version 1) through 1995 (version 3). During the same time period there was a lot happening at Apple and elsewhere. NeXT introduced their unix-based operating system in September, 1990. The famous meeting in which pink and blue cards were used to plan the future of the Macintosh operating system were held in 1988. Apple gave up developing their own home-grown multitasking, memory protected operating system (that was to be called OS 8), in 1996, and purchased NeXT, to acquire their working Unix-based operating system, in February, 1997. What gives? Why didn’t Apple, some time between 1989 and 1995, realize that they already had the operating system they needed for the future, and it was A/UX?
Why A/UX?
If Apple didn’t develop A/UX to become their modern full-featured but backward compatible operating system of the future, why did they make it at all? At the time A/UX was released, most people thought they knew what it was for. Apple representatives at Mac user groups were quick to explain that the purpose of A/UX was to gain access to the US Government market. The US government is one of the largest computer purchasers in the world, maybe the largest. In 1988, after about 5 years of work trying to get the warring factions in the Unix world to all just get along, the IEEE approved a standard set of features that should be available on all (Unix) computer systems, with the goal of making them interoperable and making software portable. The standard, called POSIX, was important to the US Government, who wanted to be able to buy computers from various sources (the lowest bidder) and have them all be basically the same. Everybody who wanted to sell computers to the biggest customer out there was supposedly going to have to be POSIX compliant. POSIX was really a standard for Unix systems. Unix vendors thought that getting Uncle Sam to adopt POSIX was going to be a windfall for them, and bad news for Microsoft and Apple. To make a non-Unix system compliant was a big job (Microsoft did it with Windows NT, but not till 1993). The best way to make a POSIX compliant computer was to make it run Unix. Apple hired UniSoft, a company that did Unix ports to new hardware, to port standard Unix (SVR2.2) to the Macintosh. Apple had to write a Macintosh environment that could run in Unix. It looked like the government was going to force their hapless employees to use Unix, which was technically a great operating system, but it had a terrible user interface and no user-oriented set of productivity software. Unix vendors had no sense of human factors engineering whatsoever, but there was a class of computer users who didn’t mind. Lots of Unix users thought that emacs was a great word processor. Many of the rest advocated vi. Most had never even seen the kind of software that most office workers wanted to use. Apple must have thought that this offered a huge opportunity. Any government worker would jump at the chance to buy a Macintosh, run word processors like Microsoft Word, page layout programs like Pagemaker, and graphics programs like Canvas, and still call it Unix. When I heard that, I thought it was certainly true and A/UX would sell a zillion Macintosh II’s to Uncle Sam. Did it work? No.
Anybody Else Interested?
Silly me. I thought that if the government adopted the POSIX standard, government workers would actually have to use POSIX-compliant computers. In reality, I don’t think anybody in government ever had to buy a POSIX compliant computer. I don’t know how they got out of it. I think they all ran DOS and then Windows 3, and then Windows 95, etc. There’s always a way around that kind of government standards stuff. You just have to fill out some standard form explaining why you should be able to use some non-standard thing. But A/UX was a big hit among some Unix users, especially ones that used Macintoshes already. At that time I had two computers on my desk: a Sun workstation for running some scientific software that needed Unix, and a Macintosh for doing everything else. A/UX meant I could reduce the number of computers on my desk by 50%. I bought it. I think it cost about $500, and that was an academic discount from the $700 or so list price. This was a lot of money. Remember, at that time we didn’t pay anything for the Macintosh OS. It came with your computer, and upgrades were free. The first time we had to pay for a Macintosh OS was System 7.1, and I think that cost $100. But a Sun workstation cost thousands, so it was a bargain for me. I ran A/UX on a Macintosh IIfx for several years, in fact, long after the IIfx was obsolete. I delayed switching to the new computers, based on the PowerPC chip, which started shipping in 1994. They were faster computers in some ways, but to me they were teh sux, because they could not run A/UX. Apple never ever ported A/UX to PowerPC. Instead they offered file servers running IBM’s totally vanilla and intensely uninteresting Unix, called AIX. By that time, Apple had been colonized by IBM. By 1994, nothing Apple did made any sense any more.
Was A/UX Good Unix?
One of the surprising things about A/UX was its reception in the Unix workstation world. It got great reviews. Of course, the motorola 68k processor was an old favorite in the Unix world, but was past its prime. Sun introduced their line of workstations based on the SPARC processor in 1989, and Silicon Graphics started switching to the MIPS processor at about the same time. Macintosh computers running A/UX could not match the high end workstations for performance. However, the difference in performance was not huge, and Apple’s line of computers was priced for the personal computer market. A Macintosh running A/UX was way cheaper than a SPARCstation 1 from Sun or an IRIS 4D workstation from SGI. And from a software perspective, the Macintosh was at least as good, maybe better. Macintoshes had fast graphics subsystems by the standards of the time, and UniSoft had done a good job on the Unix port. Most Unixons expected a lot of things to be lacking in an Apple Unix box, and were surprised when everything they liked was there. And then there was the thing about printing. Apple at that time had great printers. Better than anybody else. Apple took out the first license for PostScript in 1983, and introduced the first PostScript laser printer in 1985. Sun’s first PostScript printer was an Apple LaserWriter with Sun’s logo on it. In 1989, Apple was still a major player in laser printers, and Apple’s AppleTalk network had dynamic addressing and resource discovery. You just hooked your printer on the network and then looked for it in the chooser....and it was there. Like Bonjour in OS X. In contrast, printing was a hassle in Unix. To solve the problem for Unix, Adobe created a package called Enscript that could interpret the output of the archaic Unix printer software into PostScript and send it to a PostScript printer. Look up Enscript on the internet today and all your hits will be about the GNU knockoff that the GNU/linux guys cooked up so they could have this capability without paying for it. Apparently linux still needs this, even now. It was there in A/UX and just about no other Unix vendor included it standard. And A/UX supported AppleTalk, as well as all the Unix networking stuff. Just having an A/UX machine on my network meant that all my Unix boxes could finally print on my PostScript printers, with practically no configuration. For years after I had to give up my Macintosh IIfx running A/UX on my desktop, I kept it running in a closet so I could print from my Unix boxes.
Unfortunately, I no longer have my wicked fast Macintosh IIfx. But I still have my A/UX 3.0.1 distribution disks and a Quadra 950 handy, so I installed A/UX on it to remember what it looked and worked like.
Was A/UX a Good Mac?
There are three kinds of A/UX session: console, X11, and Macintosh Finder. There’s no reason at all to pick anything other than the Finder. Like OS X and other Unix systems today, a shell session is always available by opening a terminal window. 
And A/UX came with Apple’s X-server program, MacX, which allows you to run X11 programs rootless, which means in a Macintosh window, the same way the OS X program X11 does. In these ways, as in many others, A/UX works just like today’s Macintosh operating system.
Once you have logged in, your desktop looks like the regular System 7 desktop, except for one thing. There is an alias on the desktop to your home folder. This is an alias to a directory in /users that has the same name as the user. It also has icons representing two partitions that were part of the obligatory A/UX setup. One is a Macintosh HFS partition called MacPartition and one is a Unix UFS (Unix file system) partition called... /. The system boots using MacPartition, and that partition has a program on it called A/UX Startup. But when A/UX Startup runs, it launches the A/UX operating system, which mounts the / partition. Although A/UX doesn’t use the HFS file system for the root partition, it can read it, and mounts MacPartition and any other Macintosh volumes you have, and can 
read and write to them, and even run programs on them.
The A/UX Finder is basically the same finder that System 7 users were used to seeing. There were just a few small differences to get used to. One was file permissions. Users had permission to read and write and execute programs in their home directories (er, I mean folders). Just about everything else was off limits. Your permission to make changes in a directory was indicated in the upper left of the window, in the form of a pencil that had a line in it if you were not allowed to make changes. This is something like the convention used by AppleShare, and lots of Macintosh users were already used to it.
Directories that really belong to you also have an extra dark line on the tab on the top. Folders that you are sharing (using the regular System 7 sharing interface) are drawn as in System 7. In your home directory, there is a System Folder, with all the stuff you normally would have in there (although you can see you are not its owner). It’s a real Macintosh in all ways that matter. I never encountered a System 7 Macintosh program that didn’t work in A/UX. I know there were some, but all the ones I used worked great.
How Did They Do it?
Unix programs at that time all occupied a 32 bit memory addressing space. This required memory management hardware that could remap memory rapidly. In A/UX, as in most Unix versions of its time, the programs code was loaded starting at the bottom of the addressing space. The end of the code region for a program can be obtained from the global system etext, whose address (&etext) gives the end of the code memory space. Above the code is where initialized data (i.e. global and static variables with initial values coded in) resides, and above that is the home of uninitialized data. The boundary between these is marked by &edata, and the address at end of the uninitialized data is available in &end. The heap (used for dynamic memory allocation using malloc and the like) grows up from the end of the uninitialized data. The current high limit of the heap is available using the sbrk() system call. The stack starts at the high point of memory, 0xFFFFFFFF, and grows down from there. Of course, this space might be sparsely mapped to physical memory. Very little of this space it would be mapped to physical memory at any one time. Few programs would use the entire 4 GByte memory space to begin with, and of course computers at that time didn’t have that much memory. The Quadra 950, which runs A/UX just fine, can only accommodate 256 MBytes of physical memory.
Despite this, every program runs in this large addressing space. When switching between programs, the entire memory space is remapped. This provides memory protection, because the entire addressing space of the computer is occupied by each program. There is no way that a program could accidentally mess up another by writing into its memory space using a valid address. All of them map to its own space.
A regular Macintosh program runs in the The Macintosh System 7 environment, which does not try to occupy the entire 32 bit memory space. System 7 stacks all programs into a single memory space, all of which is resident all the time, unless virtual memory is turned on. And even if virtual memory is running, a big piece of each program is resident all the time, and shares its addressing space with all the other programs, as well as with the low memory globals, the trap dispatch table, the system heap, and the toolbox ROM. The Macintosh environment in A/UX is a implemented by program, called startMac. It maps the lowest 1/16 of the memory space (about 260 MByte) as the memory of a virtual regular Macintosh. This entire space is not necessarily available to the Macintosh operating system. It depends on how much memory the user has allocated for the Macintosh environment in the Memory Control Panel. By default, something like 16 MBytes are used for this, so System 7 thinks it is running in a space of that size. The memory allocated by the Macintosh environment can be set in the Memory control panel. The rest of the addressing space allocated for the Macintosh Environment goes unused.
For the third (and most interesting) kind of program, the Macintosh Environment is mapped into that first part of memory, and the rest is used in the typical fashion for a Unix program. This kind of program was called an A/UX Toolbox program. There is just one Macintosh Environment, and it is mapped into every A/UX Toolbox program. Regular Macintosh programs also live into this space, so an A/UX Toolbox program shares its Macintosh world with all the others, just like Macintosh programs always do. But an A/UX Toolbox program doesn’t use the Macintosh Environment for some things that a regular program does. For example, it doesn’t need to have a stack in the Macintosh world. Its stack is in the place where A/UX programs have theirs. Its code doesn’t have to be in its Macintosh Environment heap. It has two heaps, the Unix heap, and the Macintosh heap, and two places to keep global variables, one in the Unix data area, and one in the Macintosh A5 World. This becomes a little subtle. For example, if you allocate space using the Unix malloc() function or its kin, that space will be in the Unix heap. If you allocate space using the Macintosh NewPtr() function, it will go into the Macintosh heap. If you declare a global variable, it goes into the Unix data region, but your Quickdraw Globals will be in the Macintosh A5 world.
If you use the Macintosh process manager to list your Macintosh programs, your A/UX toolbox program will be there. If you use the Unix ps command to list your Unix programs, your A/UX Toolbox program will be there. If you terminate the program using the Macintosh process manager, it will terminate in the Unix world, and visa versa.
The bad news is that your program still shares the Macintosh Environment with all the other A/UX Toolbox programs and regular System 7 Macintosh programs. Your program runs in a cooperative multitasking way with all of them. The Macintosh environment is one single Unix process. That process runs at very high priority (nice 0), I guess to speed up the user interface. If the Macintosh Environment crashes, it crashes all the regular System 7 programs and also all the A/UX Toolbox programs. The Finder crashes when that happens, and so you are effectively logged out, and have to log back in. Not as bad as a full reboot, but all running Macintosh interface programs are killed without saving changes. This was the thing about the Macintosh operating system we really wanted fixed. And the worst Macintosh program crashes happen in the Toolbox calls. These always kill the Macintosh environment.
What If?
A/UX made it to version 3.1 over 6 years. If it had been pursued, it seems to me the next step would have been to give each A/UX program access to the Macintosh Toolbox without having to share it with everybody else. This would have made A/UX almost exactly the same thing as Carbon in OS X. Maybe A/UX was started life as a part of the US Government POSIX maneuver in 1988, but in 1994 that was over because Microsoft Windows NT was POSIX compliant. Why did the Apple leadership not see that A/UX was the best hope for the next generation Macintosh OS? Why did they not even bother to port it to PowerPC when they changed processors? It is obvious from the existence of the A/UX Toolbox application in A/UX, that at least some Apple engineers working on the project recognized its potential. Apple decision makers at that point were apparently clueless. Who knows what they were thinking?
A second but related question. If Apple had promoted A/UX to Macintosh users as the wave of the future, would they have taken to it? The response to Carbon and OS X in 2000-2002 was pretty positive. Most Macintosh users were very excited to transition to a Unix-based operating system, with all of the benefits of that, and still have the Macintosh interface. Macintosh programmers were at first not very excited by Cocoa, but they were very happy to port their programs to Carbon, which turned out to be very easy. So why wouldn’t have Macintosh users responded the same way in 1995, to an A/UX version 4 with the same capabilities? I sorta doubt it. For one thing, A/UX could not be free, or even cheap. It was not fully an Apple product. In fact, it was mostly AT&T System V Unix. Although AT&T had not originally seen the value of Unix, by this time they had. Licensing Unix must not have been cheap for Apple, and they were going to have to pay for every copy distributed. Even the port to the Macintosh was done by another company. Apple was by this time badly entangled with IBM, but they were not dependent on IBM for permission to sell the very basis of the operating system.
Also, Macintosh users were not excited about multi-user operating systems. Nobody was worried about security at that time. The idea of having to log on to your own computer was not attractive. File permissions were even worse. I know lots of Windows users who rejected Windows NT at first (and stuck with Windows 95), just because they didn’t want to bother with file permissions. Finally, there was the problem of performance. A multitasking operating system sounds good to say, but it means that your computer is going to be doing a bunch of things in the background. There is no way that you can accomplish that without a performance hit. We don’t notice it now because our computers are so fast. In the late 1980s and 1990s, computers were not as fast and computer users were very sensitive to the responsiveness of their computer’s user interface. Some applications, like video, could barely work on the most responsive systems. The performance loss from a true multitasking system could make them fail. Systems 6 and 7 were single-tasking, rarely changed contexts (never if you wanted it that way), and were written in assembly language. They were really lean and fast. A good example of this is the Avid video editor. Avid founder Bill Warner had originally worked for Apollo, a prominent maker of then-popular high end workstations with multitasking, multiuser, Unix-like operating system. Warner had originally implemented his first-ever non linear video editor on a very expensive Apollo system. Only months before the scheduled launch of the Avid software on the Apollo in 1988, he tried out implementing it on a Macintosh II. Frame rate was the most important metric for a program like that, and the Apollo was doing 9 frames a second. The Macintosh went 45. And the rest, as they say, is history. Warner switched Avid to Macintosh. Apollo workstations were build on Motorola 68k processors, the same as the one used in the Macintosh. In a time where performance was still at a premium, the original Macintosh OS, with all of its flaws, could do things a modern multitasking operation system could not do.
-- BG (basalgangster@macGUI.com)
1 I know it drives you crazy when I call it X-windows. Too bad. That’s what you called it at the time. Now you want to call it X11. What’s the difference?
Saturday, September 25, 2010
