Okay, let's do stuff:

Well, starting out... what do you know, Netscape 3.0 runs on it! Unfortunately, there's a little problem... I can see my internal network, but I can't get to the outside world. Turns out I don't have a gateway set. The A/UX documentation is fuzzy enough that I haven't deduced the 'proper' way to set that at boot. I may cheat and just stick it in a custom init script. But for now, let's fix it:

I haven't been too motivated to fix this gateway problem, because this is really the killer demo that proves that A/UX is Mac OS running on top of UNIX, not a UNIX-wannabe running inside the Finder, like Minux or MachTen. It never fails to get a double take out of UNIX people to see 'netstat' and 'route' running on a Macintosh.

That detour into networking aside, there's not very much remarkable to say about Mac software running on A/UX. In theory, most everything that runs on regular System 7 should run on A/UX. The primary exceptions would be things like disk utilities that demand direct access to certain parts of the Mac's hardware. The dark side of all this is the fact that being Macintosh programs, there's not much A/UX can do to get around their limitations. You still need to allocate memory to a program, memory can get fragmented from opening and closing software, etc. The memory fragmentation doesn't effect UNIX processes running in the background, but it can eventually lead to having to log out and log in again to regain sanity on the Mac side. (Achieving the same result as rebooting would in normal Mac OS.)

I do have to give the A/UX Finder brownie points for stability. I managed to crash it once under 3.0.1, but it hasn't done it under 3.1 yet. Even if you do crash it, the UNIX underneith should survive. I haven't succeeded in crashing that yet. (I kernel panicked OS X within an hour of installing it on my iMac, a record of which I'm quite proud.)

What about UNIX programs? Well, on the command line there's not much to say again, assuming you mean running them by typing their name in a command shell as you would on any UNIX. However, here A/UX does offer some unique features:

This facility is really pretty unique in my experience. It would have great potential in helping newbies learn their way around UNIX. Using it, someone could use the menus to select what it is they want to do and observe the command line that Commando builds. I would of killed for a learning tool like this a few years ago, when taking to plunge into Linux. In addition to using the Finder, you can also access cmdo by typing the name of a command in the CommandShell and selecting 'Commando' from a menu, or hitting Command+K.

What about graphical UNIX programs? Well, for most practical purposes, that's going to mean 'X-Windows' software. Here's a complex screen shot showing some X Windows programs running alongside Macintosh equivalents:

Religious wars have been waged about where the 'right' place to display a menu bar is, inside the window or shared at the top. X11, like most of the computing world, has generally gone for in-window. There's actually nothing stopping someone from implementing Mac-style menuing on X; the primarily difficulty is that existing X11 programs would have to be rewritten to use a shared menu-bar resource. That would make them somewhat less portable, since you'd have to run them inside a window manager which accommodated that shared resource. (It'd be possible to piggy-back it into most, actually, but you'd still have the inconsistency problem when mixing with non-modified X programs.)

When an X program is in the foreground, the Mac menu displays various option settings for the MacX X-Server. Further, it lets you manipulate the window manager settings for various windows; for instance, selecting whether a window is grow-able or not.

MacX has one Achilles heel, and that's memory. MacX works like a normal Macintosh program, in that it's assigned a block of memory at startup, which isn't dynamically adjustable as it runs. If MacX runs out of memory, then Bad Things start to happen. If you look at the memory usage dialog box in the screen shot, you'll notice that nearly all of MacX's resources have been gobbled up by starting Mozilla. (Mozilla has an extremely gadgety and complex UI, including colorful shaded dialog boxes and whatnot. All of which suck up a great deal of memory.) MacX of course holds up much better under the Spartan interfaces you'd find in X programs of a decade ago, so to some extent it can be forgiven. Stand-alone X terminals can sometimes run out of memory and crash if pushed hard enough as well.

Anyway. Enough X. If you're a little confused by any terms I mentioned above, feel free to read the footnote below.

There's one more kind of program I'd like to be able to show you, which is UNIX programs that use the A/UX Toolbox to display their UI, but sadly, there just really aren't any to show you. CommandShell and Commando are about the best examples there are. Sad, really. There was real untapped potential there.

Anyway. Let's really get weird and try installing some UNIX software

Footnote:

If you're still fuzzy about how X11 and X-Windows software work, here's that explanation I promised you earlier. I might help clear up some of the fundamental differences in mind set between it and Macintosh-type GUIs.

X11 is essentially a low-level graphics display protocol. You could compare it vaguely to the Postscript printer language. (Postscript is considerably more sophisticated, actually.) A UNIX program using X11, which is called the 'client', sends a stream of X11 data to a 'server', which runs on the machine with the graphics hardware and generates the actual display. The X server in turn sends back things like mouse activity, key-presses, etc. The interesting twist here is that the X11 client and server can be running on different machines. Thus, it's perfectly natural to log into your Unix account on another server, start an X11 client program, and display it using the X server running on your client machine. Understand?

Another thing that's different about X Windows from the way Mac OS or Windows does things is there's a disconnect between what we might call the 'display layer' and the 'presentation layer'. All X servers know to do natively is display areas (windows) for the client program, draw certain graphic primitives, place bitmaps and rendered fonts, etc. The other functions you expect from a windowing system, like moving windows around, opening and closing programs, etc, are all outside the scope of X11 itself. Those functions are the job of the 'Window Manager'. And UNIX has an incredible array of Window Managers available to it. Some of them are plain, lightweight and simple, like the 'twm' window manager you'll see a shot of later. Others are complete GUI environments that load file managers, menu bars, control panels, etc. Examples of those would include KDE and GNOME. If you run a modern Linux distribution, this is how you'll see X, most likely. When all those bells and whistles are piled on, it's easy to mistake it for a Mac Finder / MS Windows type environment.

Finally, because of the low level at which X11 operates, there are no look-and-feel standards that an OS like Mac OS naturally pushes a program to comply with. Generally X11 programs are compiled against 'widget sets', roughly comparable to the Mac Toolbox or the Windows APIs, which provide primitives to make dialog boxes, menus, etc. Programs compiled against a given widget set usually look similar, but a given program could use any number of widget sets. Or if the programmer is really a glutton for pain he can write in pure Xlib and not use a widget set at all.

There's this move in the UNIX world today to standardize on (ideally just one, but that's probably unlikely) universal sets of widgets and function libraries for X. Doing so would make the GUI less intimidating for new users, and facilitate the adoption of UNIX as a desktop operating system for non-technical users. But when A/UX was current, X was pretty hard core technical, and the roughness of the user interfaces tends to show it.

So how does this all relate to A/UX? Well, when you're running in the Finder interface, MacX acts as both the X server and the window manager for X11 programs. That's enough to run programs linked against whatever widget set they want in most cases, although they might look weird inside MacX's window manager.

As an aside, OS X doesn't use X11. Its GUI is based heavily on on the 'Display Postscript' system used by the NeXT Computer NeXTStep and OpenStep operating systems. (Sun Microsystems also offered a GUI based upon similar technology once, called 'NeWS' but it lost out to X11 in the long run.) Technically, it's a superior system, as it includes far more graphic and text manipulation functionality in the 'display engine' portion of the standard then X11 does. Thus, it depends less on third-party libraries and workarounds to generate complex displays, and enforces a consistent programming interface. The dark side of course is that it's proprietary technology, and thus not freely applicable to the vast pool of other UNIX-running machines out there.

While it is possible to run X11 software under OS X, it requires the installation of an X server, and the programs won't be any better integrated into the Aqua environment then they are under the A/UX Finder with MacX.