One thing from A/UX that would be nice to add to the GUIs of current Unix/Linux systems is Commando. Commando was a nifty thing in the terminal program under the System 7 environment [1].
If you typed the name of a command, such as ls or sort or cc, and then typed an ellipsis (…) it invoked Commando which would put up a dialog box for constructing the command.
The dialog box would have check boxes or radio buttons for the various available flags, text boxes for arguments, buttons to invoke file choosers for stdin, stdout, and stderr, and probably more that I'm forgetting. These things would be organized into sensible groups.
For complex commands like cc, there would be buttons that invoked subdialogs such as a dialog for code generation settings, a dialog for warning/error settings, and so on.
The Commando dialog would show you the command being constructed, and if you accepted it that would be entered into your terminal.
[1] A/UX had three ways it could run. (1) Console only, which used your Mac display as one big terminal, (2) GUI using X, which used the Mac display as as an X server, and (3) System 7, which ran a modified Mac System 7 on top of Unix, with System 7 having control of the GUI, and had a Mac terminal program that could run Unix processes.
IBM i (previously called OS/400, the operating system of the IBM AS/400) has a similar feature. At the command prompt, you type a command name then press a function key and it brings up a (text-mode) fill-form UI you can use to specify command arguments.
Part of how it works – on Unix, command arguments are just a list of strings, and any option parsing (etc.) has to be done by the code of each command. By contrast, on IBM i, there is a declarative language used to define the syntax of the command (allowed options/arguments, what values are allowed for each, etc.) The declarative command definition is compiled into binary form and installed into the system. When you run a command, the operating system uses the installed command definition to parse and validate the parameters and marshal them into a memory block. If the parameters are invalid, then the OS produces the error and the command executable never even starts. If the parameters are valid, the memory block gets passed to the command's code. These same declarative command declarations are what gets used to generate the fill-in form UI.
That's an ingenious solution. Whoever thought of that was very, very smart, forward looking and insightful. We need to bring that into illumos, the runtime linker in illumos already has capability to do all sorts of things before the excutable even starts, so it would be the perfect place to plug into. It can easily be made optional, so programs which do not generate this declarative part will continue to function unmodified and nothing will be broken.
Just to set the record straight though, while the options in UNIX programs are very different from program to program, good UNIX programmers know to use getopt(3C) libc function and not invent their own custom parser. All programs which use getopt(3C) have a uniform, consistent option parser and command line behavior. https://illumos.org/man/3c/getopt
It just invokes your $EDITOR on the command you are typing/editing.
But the best environment ever is Acme under 9front/plan9, as a "shell/editor/mail client/music player/kitchen sink" powns both vi, ed and Emacs. It has structural regular expresions, full mouse support (and far better than gvim), an embedded terminal and a plumber, which is like xdg-open on steroids, crack and LSD at once.
Using plan9port is not the same, 9front/plan9 has a lot of additions on top of that.
That description reminds me a bit of Powershell's Show-Command. It doesn't seem as rich as you've described Commando to be and it's not the same as three "..." but it's something.
So much love! I worked on A/UX's original Unix port, wrote many of the drivers,the AppleTalk stack, made the thing field configurable so you could write your own drivers (at a time when kernels had drivers compiled in), and wrote the original event manager. I also got to debug the original Mac II hardware, and help fix it.
Our internal code name for the project was "Pigs in Space", Apple's was "Eagle", when theirs leaked to the press we were in the clear
Do you still have any of the relevant software or documentation?
I am looking for the Apple A/UX Device Driver Kit (APDA M8037/B), which should include a book titled “Building A/UX Device Drivers”. I am specifically interested in driver source code.
Here is an incomplete list of A/UX software and documentation of which I am aware. Helping preserve any of the missing items would be highly appreciated.
If we can't find the docs try the BSD 4.1/4.2 docs, A/UX is essentially UniPlus which was vanilla AT&T System V with Berkeley 4.1 networking added, the Apple team upgraded things to BSD 4.2 networking by A/UX 3.0
Cool project! Do you have any plans to make these cards available to hobbyists when you have the drivers worked out?
I've always thought it would be amazing if somebody developed an ethernet interface for the 100-series powerbooks. It would certainly make it easier to transfer files to and from my trusty Powerbook 180.
Yeah, the plan is to open-source everything including PCB designs, drivers and CPLD firmware.
I'm not sure if it would be possible to redesign the card to fit in a Powerbook 100-series though. The Powerbook 180 appears to have a modem expansion slot but that doesn't give access to the processor bus AFAICS.
Fun! A/UX was neat... I was always a big fan of System 7, and this was System 7 running on top of a real Unix environment. Many years ago I picked up an "Apple Workgroup Server 95", which was basically a Quadra 950, to try running A/UX on. It's definitely an old Unix, but it certainly worked. Perhaps the neatest thing Apple did with it was the "commando" interface... in the Unix shell, you could enter a command (say "ls") and hit a hotkey to pop up a Mac-style dialog box that had check marks for all of the flags, text entry boxes for all of the paramaters, etc. Perhaps one of the more usable Unix-derivatives ever! Even MacOS X doesn't have a similar capability. The only system I'm seen like that is IBM's AS/400, with the F4 prompting to help with all system commands. Nice to have a self-documenting command line interface.
One thing I'm curious about- was Commando "pre-baked" with dialogs for all of the pre-installed utility commands, or did it pull from some kind of user-extensible database? Metadata stashed in the resource fork of the commands, maybe?
On standard classic MacOS, Apple's Macintosh Programmer's Workbench (MPW) IDE also had commando, which is where I got familiar with it. I wonder in which direction it was ported.
Circa 2003 I found an old Quadra [forget which model, but with an MMU -- still have it powered off in a closet] on eBay for less than $20, and installed A/UX.
I got some old Mac software (some games, and an old release of Netscape), and some GNU ports (gcc 2.8 ish I believe?). It was interesting what could have been - there is a simplicity in System 7 UI that OS X doesn't have. But after a while it became kind of boring, another dated Unix machine that can't run a lot of recent things.
The most dated thing I remember from the time was it didn't support DHCP.
Do note that A/UX was not a "path forward" for Apple. Mac apps were all cooperatively multitasked in a single address space so all the same problems remained. macOS (neé OS X) finally delivered Carbon which made the transition to modern features possible. That was not a trivial transition though - there were simply a big chunk of APIs that could never be made to work in a world of separate address spaces and pre-emptive multitasking, let alone your own app's behavior with respect to (or likely lack of) locking / thread safety.
Microsoft definitely learned some lessons from classic Mac in that regard but they still weren't able to promise 100% compatibility with the switch to 32-bit without compromises. Windows NT could run 16-bit apps in a rock-solid way but not all apps would run: some APIs were just incompatible. Windows 95 could run just about anything but had infamous reliability problems.
IMHO the takeaways are:
1) Platform transitions can be difficult, especially if you haven't done one before and don't know what will bite you about your current platform
2) Compatibility is key. Where you can't maintain binary compatibility offer source compatibility. If you can't offer 100% source compatibility, then offer as much compatibility as you can. Every little bit helps.
Cool stuff. I've never had any of the old mac models A/UX supported. Seems like it would be fun to tinker with. I find System 7 very aesthetically appealing, but it would be nice to still have a CLI and old friends like grep close at hand.
Probably worth noting that this post is from 2018.
I always wanted to make an X window manager that looked like System 7, particularly because I quit using Macs when OS X came out due to a general sense of pique.*
I know people have made attempts as Mac-like interfaces, but it would be a huge task to make one with as much attention to detail and consistency as the original. And then you might be infringing anyway.
*Like, I'm not colorblind, but changing the traditional hieroglyphic window controls to bubbles distinguishable only by color signified an attitude/culture change that irritated me.
The black-and-white Macintosh look-and-feel is just wonderful. Simple, crisp, and reads well.
It's interesting to compare even MacOS 1.0 with contemporary imitators. Windows 1.0 looks horrific, and GEOS has an uncanny resemblance, but everything is clunkier and uglier in subtle ways. Susan Kare is a genius.
If I could use Linux with a pixel-perfect System 7-like window manager I'd be delighted. It would probably be necessary to rewrite a suite of everyday applications to really take advantage of the look-and-feel and have internal consistency, but that could be its own fun project.
That's cool. Any chance anyone's successfully built either of these? I eventually built mlvwm but it segfaults (in Xephyr on Ubuntu). I didn't get xap to build; after installing all the dependencies I get "/usr/bin/ld: final link failed: bad value" and I have no idea what that means. I might try mlvwm on FreeBSD next, since its home page implies that it was mostly tested there originally.
This might not be what you want since you've specified System 7, but if you like the Platinum theme used in Mac OS 8 and 9, I recommend the Platinum9 theme for XFCE, which is what I've been recently using whenever I use a Linux desktop:
I find this theme quite pleasing to use whenever I'm using a Linux desktop. However, it's not yet pixel-perfect, and this also doesn't address the fact that GTK and GNOME applications are written under a completely different set of UI guidelines than classic Mac apps were, and so it's still largely a Mac OS 8-like veneer over the Linux desktop.
Even so, this theme looks like an excellent foundation for a suite of GTK applications that employ the mid-1990s Apple Human Interface Guidelines. What would be tantalizing would be forks of AbiWord and GIMP that look and feel like Microsoft Word 5.1 and classic versions of Photoshop, respectively.
"if you like the Platinum theme used in Mac OS 8 and 9"
There were three iterations (that I recall) of the interface on color Macs - the first one had window controls that were black and white, the second had a subtle 3d effect, and the third (which I think you mean by "Platinum") had more depth and was mostly gray.
I personally preferred the second. Attempts at imitating grayish metal on screen don't appeal to me, and I thought OS X got even worse when they switched to the brushed metal look.
But I really liked the design theme for the physical cases that was also called "Platinum" even though I think it's generally considered an uninspired period for Apple. And I have nothing against the aluminium or titanium Mac cases either.
The one change I would make to a "neo-Mac" window manager would be to have handles on all sides of a window for resizing. Although I like the Mac approach of having scrollbars and a lower right resize control that are substantial and obvious, I also like the ability to resize from all sides like most other interfaces have. I know there were Mac programs for the classic OS that did implement something like that, but it was never universal.
Very true. In fact, aside from the big fridge-sized VAXes and some early Sun-3s, I'm pretty sure the Macintosh II of 1987 is the oldest commodity computer that can still run a mainstream and maintained UNIX-like OS. You can even stick 128 MB of RAM in one!
Brings back memories -- I had an SE/30 maxed out with 8MB of RAM, and ethernet with the D-shell connector, and A/UX. Still have it; it still booted, last time I tried.
I didn't find out until this year that I could have replaced the 1MB modules with 4MB ones, and have 32MB.
I just have to ask -- does A/UX use any type of software packaging format? Is it SVR4 pkgadd(1M) / pkgrm(1M) / installf(1M) / removef(1M) / pkginfo(4), or something else? Is there any documentation on how to make OS packages for it, and if so, where is it?
Is there a way to perform a completely automated, unattended installation of A/UX over the network, like Solaris' JumpStart(TM), redhat's Kickstart, SuSE's AutoYaST, or SGI's roboinst?
Cool.
In 1991 I built an ISP based on Macintosh hardware and A/UX. Especially the Newsgroups with uucp and nntp where fun.
We gradually added BSDi based routers and terminal servers but even this we initially did with A/UX and ARA modem banks (Appletalk over dialup 14.4K modems)
Wow, that takes me back. I ran it on a Quadra too (although I forget which model), and it was a great way to both talk to the VACxen and DECstations on campus and run/script a few things locally.
Personally, while I’m a fan of Mac OS X and its NeXT lineage, from a UI standpoint I prefer the simplicity of the classic Mac OS, and A/UX married the classic interface with a solid Unix foundation.
One of the major focuses of pre-OS X Apple was empowering the user not only with a well designed UI with a set of guidelines that third-party software consistently abided by, but also further empowering that user with programmability, with projects such as AppleScript and HyperCard. I feel that Apple has lost this particular focus, and while I personally find macOS more pleasant than Windows 10, I wish Apple had continued on its 1980s and 1990s quest of remaining “the computer for the rest of us.”
I think there’s demand for a “back-to-basics” desktop operating system that has a classic Mac OS-inspired interface and a suite of applications that complied with its guidelines.
> I wonder how an A/UX with memory protection and preemptive multitasking would fare today.
I believe A/UX had both of these things, although it ran all the System 7 applications inside a single address space. I suspect that without this measure, many native Mac apps would not have worked.
I think apps could also be ported (mostly just recompiled?) to run in separate address spaces. So you could have a Mac app that was its own A/UX process.
My understanding is that the old MacOS Classic "Blue box" dates back to making System 7 virtualizable on A/UX.
The issue at the time is the typical Unix/X11 graphical application was not really impressive compared to what you could get with native System 7. (Which is still mostly true with modern MacOS vs Linux.) So AU/X gave you some commandline stuff... Graphical apps you wanted Mac.
Also the story is that A/UX mostly existed because of government purchasing requirements that a computer had to be POSIX-capable. Often it was never removed from the shrinkwrap.
If you typed the name of a command, such as ls or sort or cc, and then typed an ellipsis (…) it invoked Commando which would put up a dialog box for constructing the command.
The dialog box would have check boxes or radio buttons for the various available flags, text boxes for arguments, buttons to invoke file choosers for stdin, stdout, and stderr, and probably more that I'm forgetting. These things would be organized into sensible groups.
For complex commands like cc, there would be buttons that invoked subdialogs such as a dialog for code generation settings, a dialog for warning/error settings, and so on.
The Commando dialog would show you the command being constructed, and if you accepted it that would be entered into your terminal.
[1] A/UX had three ways it could run. (1) Console only, which used your Mac display as one big terminal, (2) GUI using X, which used the Mac display as as an X server, and (3) System 7, which ran a modified Mac System 7 on top of Unix, with System 7 having control of the GUI, and had a Mac terminal program that could run Unix processes.