68kMLA Classic Interface
This is a version of the 68kMLA forums for viewing on your favorite old mac. Visitors on modern platforms may prefer the main site.
| Click here to select a new forum. | | Short rant - MAE is *cursed* | Posted by: rfc6919 on 2026-07-20 01:40:49
Some thoughts from my onjoing poking at Apple's late 90s un*x efforts.
The A/UX Mac environment is a reasonable implementation, with a few rough edges but overall understandable. In addition to normal unix processes, the kernel has support for 24 and 32 bit Mac processes. 24 is basically the same as 32, but does extra page table tomfoolery to make the process's memory map wrap at the 16MB mark. Mac processes get their userland memory set up to look basically like a Mac - RAM at low addresses (including the low-memory globals at page 0) and a chunk of RAM assigned as the pagebuffer, the hardware ROM mapped in where the ROM lives, etc. /mac/bin/startmac launches into one of these address maps and the system just runs entirely in userland, with modified System files making A/UX system calls instead of talking to the hardware. Any other Mac processes get the same RAM mapped in, so they run with the exact same backing store as every other Mac process. The only real wrinkle is the /dev/uinter0 kernel driver which implements the event manager so that these multiple Mac-personality processes can do cooperative multitasking and not stomp all over everybody's data by running at the same time on the same RAM. And there's a bit more complexity around reflecting A-traps back into the Mac userland and dealing with supervisor-mode instructions, but that's just mechanics.
I sorta assumed that MAE would be the same Mac environment but with the Event Manager folded back in (since no need to support multiple unix processes), wrapped in a m68k emulator. The mae process itself sets up the GUI, makes sure the user has a System Folder and whatever other host-side setup is required, makes some sysv shared memory to be the mac environment's RAM, then forks off an emulator process to be the Mac environment. The Mac environment uses the same A/UX syscalls it used to in A/UX, emulator translates them to host syscalls, job done.
But no.
MAE's heritage in A/UX is jut allthere. The mae binary itself, if you rename it to midnight, is a synthetic 68k and an A/UX syscall translator for running A/UX binaries on solaris/hpux/whatever hosts. It's basically the model I was thinking of above - a synthetic CPU that catches guest syscalls and translates them to host syscalls.
Running it as mae it just sets up some RAM, loads lib/engine as if it was the ROM, and starts the synthetic CPU. So where does the GUI come from? How do we ensure the user has a System Folder? How does all this work?
Turns out lib/engine isn't just a Mac ROM. It's that plus "support code", and the support code is straight A/UX COFF binaries that do all that extra stuff. Where does the Mac's display window on the host come from? A/UX code linked with Xlib, running inside the cooperative Mac environment, connects to the host's X display server and talks X protocol to create a window shm-backed by the framebuffer RAM. How do we make sure the user has a system folder? A/UX code running in the Mac environment looks for it and if it's not there issues system("/bin/cp -r <srcpath> <destpath>"). Where does the rest of the GUI come from? Code running in the Mac environment calls a special other kind of service trap, not an A/UX syscall, that forks out the maed process (main GUI and some other stuff) as a child of the emulator. There's even code running inside the Mac that calls out to let the license manager know it's running.
There's just *so* *much* running inside the Mac environment that should by rights be all on the unix side. I mean, I assume there were real engineering or organisation constraints that made it go this way, but looking at it as an implementation it's just baffling.
Aside: But wait, how can Xlib code in the virtual 68k pass pointers to the framebuffer to the X server? The guest code sees virtual 68k addresses, and the X server sees real host memory addresses. Well yes, but the emulated CPU runs with a 1:1 RAM mapping - address 0xdeadbeef in the 68k world is address 0xdeadbeef in the host world too. Which is fine, it helps the JIT go faster, but it means the Mac low-memory globals need to be mapped at process address 0. I suspect this is why MAE no longer works on modern Solaris - null-dereference protection preventing the required memory map from being set up.
Also aside: Huh? Mac code under emulation calls system("/bin/cp -r <srcpath> <destpath>")? Yeah... A/UX libc system(3) first calls the host solaris fork(2), creating another full copy of the emulated Mac, which then runs more emulated A/UX code, before finally calling back into the host world for exec(2) and becoming the macd process. | Posted by: rfc6919 on 2026-07-20 01:51:46
CPU emulator plus syscall translation isn't difficult in principle, but implementing all those syscalls and porting the uinter driver is going to be a tedious process...
debian@box:/srv/jeaux2$ uname -a
Linux box 7.0.12+deb13-amd64 #1 SMP PREEMPT_DYNAMIC Debian 7.0.12-2~bpo13+1 (2026-06-21) x86_64 GNU/Linux
debian@box:/srv/jeaux2$ file aux-root/bin/sh
aux-root/bin/sh: mc68k COFF object (demand paged)
debian@box:/srv/jeaux2$ ./venv/bin/jeaux2 run --root aux-root/ /bin/sh
# uname -a
A/UX jeaux2 2.0.1 SVR2 mc68040
# file /bin/uname
/bin/uname: COFF object paged executable
# /mac/bin/startmac
WW: pid 4: unimplemented utssys type 33
WW: pid 4: no driver for character device 4/0
Can't open user interface device
/dev/uinter0: No such device or address
# echo ":'("
:'(
# exit
debian@box:/srv/jeaux2$ | Posted by: uyjulian on 2026-07-20 02:42:53
It would be interesting to see how audio is implemented. IIRC it only worked on HP-UX with its audio server. | Posted by: cheesestraws on 2026-07-20 02:43:28
That's absolutely hilarious.
Yeah the uinter driver is pretty hairy. It doesn't just do the event manager, it is basically a big steaming pile of "misc". Chunks of things like the display manager also live there, as well as (probably obviously) memory management. I ended up having to take quite a lot of it to bits for the A/UX VNC project but I don't think I even scratched the surface of what batshit madness lurks in the depths.
Mind you, now that more A/UX source is out there, it might be easier to work out what is going on... | Posted by: robin-fo on 2026-07-20 03:24:02
now that more A/UX source is out there Is there now some more A/UX source code available apart from the leaked pre-1.0 stuff? | Posted by: cheesestraws on 2026-07-20 03:34:44
Is there now some more A/UX source code available apart from the leaked pre-1.0 stuff?
Yes, kernel source for 1.0 and 2 are out there now. I think I got my copy from https://github.com/neozeed/aux1 / https://github.com/neozeed/aux2 | Posted by: robin-fo on 2026-07-20 04:45:52
Nice! | Posted by: rfc6919 on 2026-07-20 05:40:27
It would be interesting to see how audio is implemented. IIRC it only worked on HP-UX with its audio server. that other "special other kind of service trap", 0xFFxx instructions operating a bit like A-line traps, includes a bunch of Sound Manager and QuickDraw stuff among everything else. I haven't looked at any of that yet though, not sure if there's io or if it's just native code acceleration.
Yes, kernel source for 1.0 and 2 are out there now. I think I got my copy from https://github.com/neozeed/aux1 / https://github.com/neozeed/aux2 yeah, the toy whose output I pasted above is based on the the leaked A/UX 2 source. (I think it's 2.0.1 or thereabouts based on a comparison to the headers on 2 and 2.0.1 media). my git origin says I got them from the same place you did. | Posted by: cheesestraws on 2026-07-20 07:19:16
yeah, the toy whose output I pasted above is based on the the leaked A/UX 2 source. (I think it's 2.0.1 or thereabouts based on a comparison to the headers on 2 and 2.0.1 media). my git origin says I got them from the same place you did.
Ah, excellent. You are likely to have a much easier ride of understanding uinter than I did, then! And will probably understand it better. | | 1 |
|