Gorgonops wrote:I've always wondered why no one has at least made a token crack at running A/UX binaries on NetBSD. A/UX is obscure, sure, but no worse than any number of other things NetBSD developers have fiddled with.
What is required to do this sort of thing? Just implement A/UX versions of system calls? Even if you did this, only the Unix apps would work, not the Mac/hybrid ones. Right?
The Mac environment itself as I recall (do keep in mind that I may be on crack, it's been the better part of a decade since I fiddled with A/UX) ran as a UNIX app on A/UX. It undoubtedly had some special kernel support that might be non-trivial to duplicate, but you need to walk before you can run. If you could get support for A/UX command-line binaries working then you'd at least have a start.
My own wish is that Steve J would suffer a whack to his head that made him think opening the Sys 7.1, ROM, and A/UX glue code to be a great idea.
Then we could implement "NouveAUX" on top of NetBSD. With a m68k emul layer, you could run it on modern processors, even. Wouldn't apps from the early 90s just scream running at today's speeds?
Not to be a buzzkill, but... there was so little "hybrid" software written for A/UX it gets a bit difficult to see what the advantage of "NouveAUX" would really be over just running BasiliskII on top of the modern UNIXoid of your choice. Was A/UX ever used for anything much "unique" beyond Appleshare serving on Ethernet networks? (In this day and age running NetaTalk would be a far better choice than running ancient unobtanium A/UX Appleshare Pro binaries.)
That said, I've always figured there were two "obvious" routes to recreate in a quick-and-dirty way the A/UX experience: (Note that "quick-and-dirty" is a euphemism for "A lot of really tedious reverse engineering".)
1) A complete clone:
Get A/UX binary support working on NetBSD, and get it working so well that it's able to run A/UX's MacOS "virtual machine" binaries unmodified. However, to *really* make this work in addition to getting A/UX binary support and figuring out how to run the 7.0.1 emulator you'll have to figure how to handle whatever messages are passed to the UNIX side when running a "hybrid" application. I've never really looked into it... does anyone here actually have any idea how A/UX hybrid apps handle the intraprocess communication? Does documentation for the A/UX extensions to the Mac API actually exist? I have no idea how big of a can of worms this would really be.
The end result would be an OS that would run on 68k machines supported by NetBSD (I see no reason in principle why it would be limited to Macs assuming a "Mac ROM" of some sort is available as part of the 7.0.1 virtual machine) and could behave just like A/UX while having a more up-to-date UNIX underpinning it. Frankly it seems like a lot of work just to be able to run Commando and some out-of-date server binaries. (Again, really, are there any significant A/UX-specific Mac-GUI-ed hybrid applications out there? And of course Commando itself would need to have its database updated to reflect the NetBSD syntax of the supported commands unless you just wanted to run a transplanted A/UX binary instead of the native one, which in most cases wouldn't be particularly useful.)
2) Fake it:
Forget about binary compatibility for A/UX UNIX binaries, and just provide a Macintosh application environment with better "generic" UNIX integration than a simple emulator... like the Macintosh Application Environment
. BasiliskII/Sheepshaver can already do some of the things MAE did, like integrating UNIX filesystems onto the Mac desktop, but MAE had extensions that allowed the user to do things like double-click on UNIX apps to run them in a terminal window. (It also had the "Launcher", which can sort of be thought of as "Commando Light".) Honestly unless someone can point to something besides Commando that made use of A/UX's "Hybrid App" capability then in practice being able to start a UNIX shell inside a Mac terminal program is really about all it takes to emulate A/UX from a user perspective. (Well, that and being able to run MacX. If you want to be snide you can say you can already accomplish much of the A/UX experience by running NCSA telnet and MacX on unmodified BasiliskII on a host machine set up to accept telnet connections from the VM.) Anyway, along these lines here's three possible suggestions:
A: Hack BasiliskII so it can run the MacOS 7.5.3 image included with MAE 3.0, including reverse-engineering the mechanism used by the Launcher to run UNIX applications. (MAE seems to be fairly system-agnostic so it probably wouldn't be that hard to make this work.) Find the newest version of MacX (or NetManage's Xoftware) to use as your X server, launch your modified BasiliskII full screen on the UNIX of your choice, and viola, you've got an A/UX wannabe. (Which is *slightly* more sophisticated than the "telnet as a command line" suggestion.)
B: Hack BasiliskII so it can run the MacOS 7.0.1 used in A/UX, this time extending BasiliskII so it can emulate the API extensions used by "hybrid" programs like Commando and for any given hybrid craft a backend that's able to translate any calls made by the Mac GUI portion into some sensible action. (In other words, recreate the UNIX portion of any hybrid you want to run.) Again, run this full screen with MacX, it'll look just like A/UX, and it'll continue to suffer from all of A/UX's warts. (Such as running your X11 server inside a cooperatively multitasked emulated environment with no memory protection.) But the backend will be more modern at least and the integration is tighter than option A.
(Note that this approach of using BasiliskII for the MacOS environment could be combined with the "A/UX binary support on NetBSD" path described in category 1 if it turned out to be too difficult to get the original virtual machine code from A/UX working on NetBSD 68k.)
C: Discard any vestiges of the original A/UX or MAE and instead modify SheepShaver so it allows UNIX shells to be spawned from within it and (here's the tricky part) have an API extension that allows the combination of SheepShaver and a MacOS program (you get to write) to act as a window manager. The way I envision this is that you'd have a Linux or BSD machine start X11 and launch your modified SheepShaver with MacOS 9.0.4 instead of a WM. An extension started as MacOS boots would act on window management requests, drawing blank frames on the Mac desktop (which is on the root window) and sizing the child windows to fit over the blank spaces. (Getting windows to stack/overlap properly with emulated MacOS programs would a bear, but I never said this would be easy. I could see some utility in using compositing techniques for this.) With this setup you get native X11 support for your UNIX programs so they're not held hostage in some out-of-date MacOS X11 server, yet you still get the effect of having a "unified" desktop. By adding a generic message-passing mechanism to "SheepshaverWM" you could even write your own "hybrid apps" if you wanted... imagine for instance a trivially hacked version of Firefox that uses the UNIX X11 rendering engine and can run "real" Flash (on i386/x86_64, of course) but displays its menus on the MacOS 9 top-of-screen menu bar. (Of course you'd want to use some Mac-look-and-feel-ing widget set inside the X11 portions of the display to really pull off the illusion.)
Option C: here is probably the easiest of all since it involves the least amount of reverse engineering (It "merely" requires a lot of grunt from-scratch programming work.), and it also has the potential of being the most stable (at least for UNIX apps... MacOS 9.0.4 is what it is.) and modern of any of the options.
Anyway. I don't see *anyone* wanting an A/UX clone badly enough to make any of these happen, but you never know.