From the unofficial comp.unix.aux FAQ: NouveAUX was an idea proposed on comp.unix.aux in early 2003 to resurrect A/UX, in spirit, if
not in fact. This would be done by integrating a MacOS emulator (such as Basilisk II) tightly with an open-source
Unix (such as NetBSD). By doing this, "A/UX" could run on newer machines, such as PowerMacs. The idea never got any
further than discussion, mostly because of a lack of clear direction and programmers interested in doing the
work.
This document is an attempt at providing that direction. I will discount the arguments that running a System 7 style desktop on a Unix is no longer "really A/UX" or is "boring". Unless you have access to Apple's source repositories, you'll never have a true updated version of A/UX, so something like it is better than nothing at all.
Essentially, the goal of this project is to build an A/UX workalike. A blend of Unix stability and classic Mac user-friendliness that OS X has forgotten somewhat.
The product of the NouveAUX Project will be the "NouveAUX Desktop Environment", or simply "NouveAUX".
That's it. I believe that by starting small, with realistic goals, this project might actually gain traction. Besides, with two major architecture transitions (and over 10 years) since A/UX was left to die, I believe it's naïve to think that many people are interested in integrated 68k Mac emulation or running System 7 apps, and Nickster (7/jan/2003) seems to agree. Besides, boon (16/feb/2003) and Nickster (5/mar/2003, 7/mar/2003) make some very good points regarding the difficulties of implementing a "true" Mac environment. Thus, this is Nickster's #5 (14/feb/2003) approach. Even calling it an "alternative OS" is a bit of a stretch.
Nickster's fourth (3/jan/2003) and Rimas' first (3/feb/2003) points are satisfied by selecting virtually any Unix kernel. Since we are not forking a new OS, but only developing a more Mac-like GUI, this is obvious.
If we were developing a new OS, the only two serious contenders to start from are NetBSD and Linux, due to Rimas' second point (3/feb/2003), which I interpret to mean we should support 68k Macs even if for no other reason than nostalgia. OpenBSD/mac68k exists, but I don't think it receives even the small level of attention that the others do. Additionally, more software exists in binary form for these platforms. We can't expect users (yes, I know it's unlikely we'll get many mainstream users, but shouldn't we endeavor to think like Apple engineers?) to compile everything from source.
Rimas' seventh (3/feb/2003) point is satisfied by going with NetBSD, which Karsten supports (15/jul/2003). The base NetBSD is very lean, and far less bloated than Linux. This should be our "target platform", though since we're essentially limiting ourselves to developing a Mac-like window manager/file manager/desktop environment, that work ought to be quite portable to any Unix. It would be awesome if it could be run on A/UX itself!
I don't think we need to go so far into supporting Classic Mac functionality/compatibility as the renaming (or parallel recreation) of directory structure like OS X has done, and Rimas considers (15/feb/2003). Perhaps we could provide a patch that would create "long name" symlinks, but what's the point? Like him, I reject the need for supporting ":" as the filepath separator — but we're not writing a new OS, are we? I disagree that users should have to use the command line sometimes (though I think it's good to have the option), but the goal of NouveAUX (at this time) doesn't extend so far as to eliminate its necessity.
I agree with Antoni (14/jan/2003) and Rimas (6/feb/2003) that we can begin our work by forking from an existing window manager. Here we leverage the power of open source, by standing on the shoulders of those who came before us. I don't know if MLVWM is the best starting point, as it hasn't been actively developed in years. I also don't know if gtk2 is the best toolkit to base it on just because it supports UTF8, though supporting UTF8 is probably a good idea. For one thing, it is very large—gtk1 and fltk are smaller. I have successfully built all three on NetBSD/mac68k though. I've heard/read good things about fltk and wxWidgets. However, I'm not sure that wxWidgets would work for this purpose. Maybe GNUstep would be a good option. Maybe a completely new toolkit is needed.
Actually, the problem isn't so much the window manager or the toolkit. The problem is the fundamental design of how X apps interact with the window manager. In X, it is assumed that the application handles all it's own details, including menus. "Handing off" that duty to something outside the application area is a challenge. What might actually be required is a library that could be compiled into applications to make them able to send/receive the menu information and events to the window manager. This means that for the wm to run correctly, one would need special builds of the apps used. I have no idea if this could be done and maintain the network transparency feature of X, since the client (where the application runs) and server (where the wm runs) could be in different places. It may well be that the decision to support network transparency drove the UI model. But keep in mind I really don't have any idea what I'm talking about here...
There are other "nice to have" things that, while not central to the success of NouveAUX as defined, I'd be willing to extend the NouveAUX project umbrella over if someone was willing to work on them. Sort of like making this project the "A/UX revival central clearinghouse". A short (and incomplete) list:
NouveAUX Desktop shall consist of two primary components: a window manager (NouveAUXwm) and a file manager (NouveAUXfm, our "Finder"). Though usable separately, I suggest they be designed for solid integration, and released in such a way that the versions always correspond — i.e. "NouveAUX" is what is released, not each of the components separately. Furthermore, I suggest that the first "production" release not be a 1.0 target, but 4.0, in homage to our inspiration. "Development" and "beta" releases could start at 3.2, for the same reason.
An additional component is a location for "dockapps" to reside (NouveAUXcs). This is analogous to the old Control Strip in many ways, so we'll refer to it by that name.
One big difficulty is that in the MacOS, the menu bar pulls double-duty by providing both application-specific menus as well as system-wide menus. So this has to be designed as a component (NouveAUXmb) shared by the wm and the fm: distributed by both, maintained by both, and not terminated unless both parents do.
Another difficulty is that in the MacOS, "dockapps" can go in two different places: the Control Strip (for system environment controls), and toward the right end of the menu bar (for other things like clocks, eyeballs, notifiers, and some controls). How to deal with this?
Ideally, NouveAUX would be themeable. I see the default appearance resembling System 7, with an OS 8/9 Platinum-like theme included. If we could support Kaleidoscope schemes somehow (extract the resources into image files?) that would provide hundreds more. However, we would do well to support somewhat more customization (such as menu/title bar font sizes), which may result in degraded theme appearance depending on how they are designed. We're stuck with the menu structure used by individual apps; I don't see any way we can adjust them to conform to the standard File/Edit/… we'd prefer. But we can control where system-wide menus appear relative to app-specific relative to dockapps, etc.
TBD
Just a few thoughts here...suggestions welcome!
Ha ha ha ha ha! Oh, I crack me up.
The goals would be:
- Run the A/UX interface on top of Darwin
- Run System 7 and OS 8/9 apps transparently
- Run A/UX apps transparently
- Good performance with old and new hardware
A much simpler and far more easily attainable goal would be AU/X integration in an opensource 68x00 emulator, such as basilisk II.
Then if you were to run Linux on a PPC, you would get X, a unix like interface, and with MOL, MacOS 8, 9 and X. You could then run system 7, and A/UX in 68x00 boxes.
Loose integration would just be a "bare metal" emulator with file and device sharing, tight integration would be a "system call traper" that would intercept A/UX kernel or MAC ROM calls and after adapting them pass them on to the linux kernel.
I only suggest linux because everything already exists to the loose integration level. BSD, (as in MacOS X) would also do, but some work would be necessary for the MOL (virtual machine support).
That's true, but wouldn't the only advantage to that be the ability to run A/UX and System 7 apps? Certainly it would be slow...
The advantages to creating a Darwin-based PPC clone include full speed PPC system code, modern hardware support, and most importantly Apple would not control the source code. The reason A/UX died on the vine was because it was not open-sourced and Apple chose to cease development.
For me, the issues with that approach are:
- I like using the A/UX interface. I hate Linux with GNOME, KDE etc.
- I'd still have to have a copy of A/UX. Why not just keep running it on my Quadra?
Maybe an A/UX-style environment for Linux is a preferable goal.
I think the big advantages of A/UX were the easy-to-use interface to UNIX and the ability to run then-current Mac apps. The need for running System 7 apps has probably diminished to almost zero... I'd like to keep the benefits of an A/UX style interface while running modern PPC apps.
[How would we start?] Documentation. Pick a target by comparing what's available with what's not.
Ideally, I would like a Linux or Darwin distribution that behaves just as if A/UX would had it been released for PPC. Bonus points if it doesn't require any proprietary packages (A/UX, OS X) to run.
MOL makes this a good choice, but it's still running the Mac desktop "in a box." It would be nice to have the ability to run the Mac OS apps transparently with the A/UX desktop replacing XFree/Gnome/KDE. With binary compatibility, since a lot of Mac apps are proprietary and we can't recompile them for Great Aux.
It could be just possible to use Linux/BSD kernel and GNU applications configured in a way similar to A/UX.
The only thing you'll be missing is the Finder. We can start of MLVWM. IMO it would be possible to make it reasonable close to real Finder and useable.
It's a moot point to me whether such a project would "really be A/UX." Of course it wouldn't. My main interest is to preserve the good points of A/UX-- Apple seems to have forgotten them.
I can imagine several project possibilites of varying levels of difficulty:
- Work-alike clone of A/UX that implements every feature; runs A/UX and Mac apps on PPC
- Distribution of alternative OS that is configurable like A/UX, and runs A/UX and Mac apps in emulation
- Distribution of alternative OS that is configurable like A/UX but *doesn't* run A/UX and Mac apps
- A/UX Finder-like emulation environment for alternative OS (Linux, BSD, Darwin) that runs A/UX and Mac apps
- A/UX Finder-like window manager for alternative OS with no emulation environment.
I want to be clear that I would be most interested in option 2, but I would not mind options 3, 4 or 5. I think option 1 is something only Apple could provide, and would be way too ambitious for an open-source project. It would pretty much mean re-writing SVR2 *and* System 7!
But i want to have unix. I want it to be new and I want to be able to build some unix apps and i think A/UX could do that. So, for me the ideal Great Aux should be something like this:
- Fast and reliable. Actually i think it's mainly be an alternative for those *OLD* boxes, not for the new G4 etc. ;] I don't want to buy more RAM or a new CPU for my box. I just want to use what I already have without investing money into the box as it may become cheaper to buy a new one.
- it MUST support old hardware (especially my AppleTalk printer mentioned above ;P).
- it should have a possibility to run MacOS apps. I'm actually unsure about A/UX ones cause there's a bunch of opensource software which covers those A/UX apps, i think.
- MacOS Look'n'Feel. Skinnable optionally (it's becoming a standard anyways :P).
- POSIX compatibility. I think it would be cool to be able to compile and use GTK+ on it for example.
- Internal UTF8 and i18n maybe. Would that add much weight to the system? 'Cause i live in Lithuania and it's not cool to have the latest M$IE still not supporting my codepage. :/ I believe it's much easier to use it from the start than to migrate to it later as seems like it needs some rewrites later.
- the basic system should be as small as possible. Will anybody mesure the space A/UX ocupies now? the Great Aux could be slightly bigger maybe. But it shouldn't take ALL the 500megz i have. I hope you won't laugh at me if i say 200MB is the limit...
- add anything i could have missed
well, what we do have, is:
- a few kernels of different OS'es, that we could use as a basis for our system,
- a few window managers, that we could also use after some adaption,
- some Mac emulators (or whatever they are).
Actually, I think, we could treat our OS as a simple version of Linux/BSD/whatever with some special requirements. It has to understand Macintosh apps and to have some kind of emulation of apple-toolbox (or is it not needed?). So, we could just have that same good Linux/BSD kernel with a few patches (like an image onboot instead of that usual STDOUT output etc), window, desktop and login managers (GNOME looks like MacOS, but is it not too huge? We could strip it off and make a smaller version of it, or simply write another wm based on GTK+2 (it uses UTF8 internally), for example), and tweaked or rewritten basilisk (or whatever) that would autostart with the OS globally and handle all the Mac`ish stuff, and also use global preferences for look'n'feel. Also, if you want to have Finder, we'll need some file manager that would look like finder. Or do you want that finder to be the copy of one on MacOS, and to handle desktop?
And the main problem is:
- DRIVERS for all that old stuff.
And still i think it will be the same Linux/BSD/whatever.
What is the functioanlity of A/UX now? Cause I see it as simple UNIX (read as: Linux) with built-in support for MacOS apps and that finder interface. And i believe that this finder is simply taken from MacOS7.0. So, we would run X server, window manager, login manager when needed, finder-styled desktop manager and a MacOS emulator plus apple toolbox call handler. isn't that all?
Well if our NouveAUX would be UNIX, you *should* use commandline sometimes. Cause these programs need arguments or so, also, when you type simple "make" in a particular directory, it uses *that* dir as a working dir, and makes a program from the sources it finds in *that* dir.
On the other side, names are OK, I could use both "Libraries" and "lib", cause I know anyway what that means. Finally, if something would not work for me, i'd make a symlink lib > Libraries. :) I don't think long names are bad. It's just not-unix-like then and people could be experiencing some problems. Well OK, it could be "Libraries". I just don't want the level separator to be ":" like in Mac, i want the traditional "/" like in UNIX.
The ROM contains operating system routines and Toolbox routines, which are the main programming interface to the Mac OS. Quickdraw is the most obvious piece-- all the graphics on your screen are put there by Quickdraw functions.
A/UX had its own set of Toolbox routines, which (alas) is not identical to the MacOS version. If we took the same approach as MOL and Basilisk, then you would need a copy of Mac OS to run Mac software. That's not such a big deal, but A/UX apps that rely on the A/UX toolbox would not run. Because of licensing issues, you can't break the ROM apart and use parts of it. It has to stay whole.
Another issue is the operating system environment. Mac apps expect to be running on Mac OS, where they have a set of global variables that the Toolbox uses... and its graphics world is self-contained. That means it's easy to run it in a window, hard to integrate with another windowing environment like X/KDE or X/Gnome. Plus, Macs always run in "supervisor" mode, meaning that apps can use privileged instructions which wouldn't be available under A/UX or Linux. Those would have to be trapped and re-directed.
It is a true can of worms!
It's the Mac-app Toolbox stuff that we really want-- QuickDraw etc. The Unix functionality is already cheap and plentiful! :-)
- 68k Mac apps run in an emulator that traps OS functions, it is a PPC app like Classic
- PPC Mac apps run natively with a Toolbox-compatible support layer
- The 68k emulator ties into the support layer, which provides a "virtual 68k Mac" like Basilisk
- The support layer could be based on X-Window, Quartz, or both
- The support layer is the only part that talks directly to the kernel
It's a big job. "Changing the toolbox to be compatible with the PowerPC platform" means re-writing the Toolbox for PPC.
- learn more about Unix and Mac OS in general to understand the system structure
- start documenting the differences between A/UX, Linux, and Darwin/OS X
- talk to programmers in the local Linux and Mac user groups about the possibilities
- put together a preliminary design and project plan for "NouveAUX"
- "go live" with a project web page on SourceForge
- ???
- profit!!!
[Mac app compatibility through MOL] So, it's already implemented (partially atm). Of course, if we want MacOS classic apps to run in separate windows (like WINE does with windoze apps), we should have to duplicate apple toolbox, and then, again, there's no much difference about the platform/UNIX version. You simply code it from scratch.
[MacOS look-n-feel] that would only require to create a nice window/desktop manager. Or modify an existing onw to suit our needs. There's no big problem in implementing that on Linux/BSD/anything else, that uses X11.
If you ask me i would recommend to start with NetBSD. they have a really portable and clean code. Also they did some "emu-work", you can for example run native binaries from Solaris, Ultrix, HP/UX, Linux, Irix, FreeBSD and more. Add compat_A/UX and you are done (well, mostly).