Location: GUIs >
Okay, let's do stuff:
Let's continue our tour by looking some of the unique aspects of how A/UX
handles running different combinations of Mac and UNIX software.
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:
The TCP/IP control panel in A/UX is read-only. Real changes to the networking
configuration are made the UNIX way. That means using 'route', putting
your name servers in resolv.conf, etc. Hey, it's not that bad, really.
At least it's fairly standard. That 'route' command would work on just
about any UNIX out there. It is somewhat weird in one sense, in that it
lacks the 'ifconfig' command that other *NIX's use to set their IP numbers
and netmasks. That's set using the kernel configuration program.
There, now it works. As a side note, I think I've decided to make that
opossum my totem spirit, or something. It seems to have the proper attitude
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
Here, I've used the finder to navigate to '/bin', and double-clicked on
the 'ls' command. (This is the UNIX equivalent to 'dir', for those of you
out there who've used DOS.) Doing so runs the 'Commando' program, which
checks its database of UNIX commands for a GUI command script matching
the command you selected. If it finds one, it pops up a window like this.
Using it, you can build a command-line with all the options you might want.
When you're done, it opens a CommandShell and runs the program.
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:
Here we have Mozilla running on a remote server, and 'xcalc' and 'xlogo'
running locally on A/UX's UNIX backend. You can see how Mozilla displays
its menu bar and such inside its own window, rather then using the shared
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
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
Anyway. Let's really get weird and try installing some UNIX software
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.