coolest A/UX-related development

[ChristTrekker]

What would be the coolest development you can imagine happening regarding A/UX? What's on your A/UX wishlist?

[ClassicHasClass]

A good implementation of X11R6 (and Motif and/or Xaw) so that we can port more things to it. By good I mean easy to install and pre-built.

[johnklos]

Hmmm... A modern toolchain which could bootstrap modern software would be nice!

[Unknown_K]

Using Apple OS 7.1 instead of 7.01, DHCP support.

[johnklos]

Another thing which might be cool is if someone found a way to run A/UX services such as AppleShare and System 7.0.1 on top of other OSes such as NetBSD with COMPAT_SVR4...

[Unknown_K]

Finding $500+ under a couch cushion so I can buy this:

http://cgi.ebay.com/ws/eBayISAPI.dll?Vi ... 0470543090

[Gorgonops]

Another thing which might be cool is if someone found a way to run A/UX services such as AppleShare and System 7.0.1 on top of other OSes such as NetBSD with COMPAT_SVR4...

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.

Of course, it makes me sad that COMPAT_DARWIN just evaporated. Ironically now that Apple has gone Intel COMPAT_DARWIN would be a far more useful thing to have than it was at the time it died.

[ChristTrekker]

A good implementation of X11R6 (and Motif and/or Xaw) so that we can port more things to it. By good I mean easy to install and pre-built.

I've never tried the R6 that's floating around the 'net. I assume from your comment that it needs to be compiled and is not an easy process. Since we don't have shared memory, small widget toolkits are a must. I think I've said it before, but I'd love to see FLTK ported.

Hmmm... A modern toolchain which could bootstrap modern software would be nice!

Being stuck at gcc 2.7 stinks. Even 2.95 would be great. Someone once sent me a 3.x binary but I couldn't get it to work. A/UX support was dropped in 3.0 or 3.1, but I'd be thrilled with that.

Using Apple OS 7.1 instead of 7.01, DHCP support.

Yes! I'm not sure I've ever looked into why DHCP doesn't work.

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?

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?

I've occasionally thought implementing a "Commando"-like app for a different *nix would be pretty slick. It wouldn't be too hard, really. Would just need description files for every available command detailing options and what combinations they can/must be used in, an app that builds a GUI from those descriptions, and fires off the command when you're ready.

[ChristTrekker]

Anybody know of free C compatibility headers/libs for older (pre-1999) systems? Likely need that to build modern software.

[Gorgonops]

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.

[ChristTrekker]

My "goal" is to have a modern Unix environment capable of running my favorite old classic Mac OS apps "natively", not windowed or with a different UI like in an emulated environment. I don't think BasiliskII gets you there.

That's why I think you'd need the code for those "glue" APIs and the ROMs. I don't know if using a "binary blob" ROM would be possible, if Apple would even allow copies to be distributed gratis. You'd have to implement the Toolbox.

It's a pipe dream, I know…

[Gorgonops]

My "goal" is to have a modern Unix environment capable of running my favorite old classic Mac OS apps "natively", not windowed or with a different UI like in an emulated environment...

I guess I don't understand the distinction, because A/UX really was little more than a Mac OS emulator (ala native-CPU BasiliskII) running full screen on a UNIX box. (Again my memory is fuzzy, but I seem to recall actually being able to kill the MacOS process via a telnet window just like any other process.) If you hacked BasiliskII/SheepShaver/whatever so it ran full screen with your Classic Mac OS apps "natively" while letting UNIX programs poke through (either in Commando-style terminal windows or something more elaborate like my X11 composting suggestion) it seems to me like you've essentially achieved the same thing.

That's why I think you'd need the code for those "glue" APIs and the ROMs. I don't know if using a "binary blob" ROM would be possible, if Apple would even allow copies to be distributed gratis. You'd have to implement the Toolbox.

Being able to distributing the MacOS support pieces for free is a *whole other story*. (No, it's never going to happen. If you want a free OS then I guess your best approach would be to try to do something with the Executor code base and either integrate it more seamlessly with X11 or use the reverse-engineered Toolbox as your only GUI on a bare framebuffer.) I was just spitballing technical approaches you could try by harvesting pieces from the existing (dead and impossible to get a proper license for) binary code base.

[Bunsen]

Why reverse engineer the Toolbox? OK, I acknowledge that I'm in way over my head here, but if you're using a native CPU Basilisk on a real-deal 68k Mac, could you not make the necessary calls direct to the existing Toolbox?

[ChristTrekker]

As I said,

It's a pipe dream, I know…

My "goal" amounts to doing A/UX "one better". In it's day, it was Unix with a Mac face. Mac OS was the primary environment. Sure, you could run X apps with MacX, but they were always second-class citizens. If you stayed in the Mac environment, you could use it just like a Mac, but A/UX gave you the ability to keep your machine running if some bad app killed your Finder instead of rebooting the machine.

Now that a significant minority of people are using some Unix/X11 as their primary environment (be it KDE, GNOME, or whatever), the old Sys7-era Mac apps would be the second-class citizens. I'm not content with that! I want to run Word 5 and have full copy/paste functionality to the rest of my world (for example). I want the Mac apps to behave just like native apps. It would technically still be emulation, I believe, as you'd have several intermediate layers interpreting function calls to that of the native system, but it would be the best emulation ever. You'd be able to take a Sys7/m68k app and run it seamlessly on a Linux/x86 box.

Tall order, I know. I want to have my cake and eat it too! You gotta admit, that would be pretty cool.

[Gorgonops]

I want the Mac apps to behave just like native apps. It would technically still be emulation, I believe, as you'd have several intermediate layers interpreting function calls to that of the native system, but it would be the best emulation ever...

Aaah. Therein lies my confusion. I thought your goal was to have something that really was essentially "like A/UX but with more modern tinkertoys." A/UX *really* didn't integrate MacOS with UNIX in the way you're envisioning.

(If it had lived and been somehow transformed to be a real "Desktop OS" for mere mortals maybe that would of changed. Perhaps it would of evolved from having the GUI be what's essentially a complete emulation of MacOS with a few token message passing API's grafted on to having components of the Mac Toolbox reimplemented in UNIX-y ways that allowed real memory protection and multitasking in GUI apps. Of course, *that* opens up the same can of worms Copland did and we know how well that worked out.)

I think the closest you're ever going to get what you want is OS X's "Classic" environment. (Which of course is only for PPC OS X) It did allow cut-and-paste and was able to do seamless windowing, after all. But yeah, under that veneer it was still an emulator-in-a-box. To really go as far as you'd like what you'd need is essentially a really-well polished Mac Toolbox version of WINE. Which is sort of what Executor is, but it's a pretty incomplete version of it. Lacking any help from Apple the best shot you'd have would be to start with the Executor code base and make it *really* work. (First task, obviously, would be to add native windowing support so all your Mac programs aren't held hostage in a little penalty box...)

Come to think of it, another idea would be to figure out how seamless windowing works in OS X's Classic environment and implement the same thing using SheepShaver as the back end. That plus some clipboard integration magic (which you might be able to write an extension for with some more minor SheepShaver hacking, it already allows paste *from* X11) could give you a "Classic for UNIX" which works on Intel CPUs. It's a fairly tall order, but if you can live with having to run a (hidden) MacOS 9 emulator box for your Mac programs it might be more doable than the "re-implement the whole Mac Toolbox" approach.

[ChristTrekker]

Tinkertoys: Yeah...I don't think anybody today would really want to live within the limitations of the Sys7 desktop all the time.

Copland: If I understand correctly, Copland died of feature creep. If they had limited the first draft to exactly the same functionality as Mac OS then had, but implemented "right" to allow for future growth, maybe it would have succeeded. Unfortunately they tried to add more stuff in while they were at it, and you know the rest.

WINE: I've tried pondering before what "MINE" would take to realize. And I did correspond with Mr Matthews from ARDI some time ago when I began trying to package syn68k for pkgsrc. It looks like he is still working slowly toward cleaning up the build system to something modern, which is very cool.

SheepShaver: Hmmmm, that's an interesting idea, too!

[Gorgonops]

SheepShaver: Hmmmm, that's an interesting idea, too!

I've been surprised by the fact that no one's done much hacking with "Classic". I was reasonably sure, for instance, that within a few months some dedicated soul would devote themselves to reverse-engineering and forklifting Classic support from Tiger to work on PPC Leopard. (From what I know of how "Classic" is implemented it seems like it should be possible to do it.) Perhaps it was just so painfully obvious that Leopard on PPC sucked that it turned off anyone who might have the knowhow to bother.

It's my recollection that "Classic" actually installs several extensions in the 9.whatever System file in order to handle tasks like clipboard synchronization. (It wouldn't surprise me if there's also some helper code inserted to assist in creating seamless windows.) To make "Classic for UNIX" happen someone would need to either duplicate those extensions and add their own API to Sheepshaver or see if they can hack the Apple extensions to work on 9.0.4 (the best SheepShaver can run) and reverse-engineer the methods they use. It's pretty deep hacking but probably no worse than other things the SheepShaver (and BasiliskII) authors have done in the past.

One thing I'm reminded of thinking of this is how IBM implemented Windows 3.x compatibility in OS/2 2.0+. OS/2 basically added a special video driver and a clipboard manager to standard Microsoft Windows and ran it the background inside a DPMI-compliant DOS VM. An interesting option you could enable when creating an OS/2 alias for a Windows program was to run said program inside its own dedicated copy of Windows. Doing so would consume more RAM and system resources than running the program in a "shared" Windows session (as was the default when starting more than one Windows program), but in return it allowed the program to leverage OS/2's pre-emptive multitasking and would also make it impossible for another Windows program to crash it. If you could get intra-processes clipboard synchronization working in SheepShaver then with today's powerful computers an interesting option might be to run completely separate MacOS sessions for each program. (Essentially each program would run maximized in its own window... which would have the odd side effect of making the MacOS single menu bar functionally equivalent to other OS'es "separate bar for each program" paradigm.) At the cost of some memory overhead you'd likewise gain the underlying OS'es pre-emptive multitasking and process protection abilities, albeit in a strange ack-bassword way.

[ClassicHasClass]

I'm pretty sure, though I don't know, that 10.0-10.4 had some deep magic in the kernel to enable certain features of Classic, and that these were taken out in 10.5. There were arguments in security rags about that, IIRC.

It probably is possible to do something like that in userland, but it would probably not be anywhere near as seamless either.

[z180]

1. Getting some system 7.1 source into A/UX.
2. Running A/UX on MESS,emulation up to Mac IIcx or ci.
Every interested guy can help A/UX then.
3. NEXTSTEP being ported to mac68k
4.Improving A/UX,more HW support,better X11 support,speed optimisations.

[MidnightCommando]

Wouldn't it at this point be the better solution to simply have a modern linux or unix or BSD, sit a MacOS clone WM on top of X (mwm used to be a thing, but i don't expect it'll compile on anything approaching modern - that needs work, as would gtk and qt engines for sys7/Platinum window decoration) ...

...

... and then have Basilisk II sitting somewhere, essentially projecting the background and icons into an off-screen framebuffer (RAM is more than fast enough for this) and emulating a full 040? Obviously we'd need the user to supply the ROM (we need to keep it legal, or at least have plausible deniability) so that Basilisk could do its magic, but ... what you'd have after this is X11 apps looking like MacOS, GTK+ and Qt apps looking like MacOS, and MacOS apps able to run with a translation layer (Basilisk II and possibly SheepShaver) looking like MacOS.

That would ultimately be next-level A/UX - The power of a UNIX or Unix-like, a Classic MacOS lookalike, but not workalike except for when it comes to actual MacOS apps. Truly, the best of both worlds.

( Thoughts, this end would probably require technical modifications to BasiliskII - fork and call it BasiliskIIx because it's bigger, faster, and better? )