Advanced Mac Substitute is an API-level reimplementation of 1980s-era Mac OS • Hacker News Board

Re: Advanced Mac Substitute is an API-level reimplementation of 1980s-era Mac OS

#41

Post by jjuran » Sat, Apr 11, 2026, 9:28 PM UTC

andai wrote: post #31

Very cool. If it's built on SDL2, it should be straightforward to make it run in the browser via Emscripten, right?

Advanced Mac Substitute uses a factored approach. 68K emulation happens in the back end, which is a collection of processes connected by Unix-domain sockets, portable to basically any POSIX system.

The front end deals with displaying graphics and forwarding user input to the back end. Working front ends include SDL2 (by a contributor), X11, Linux fbdev, VNC, and five different macOS APIs (Cocoa/OpenGL, CGL, AGL, Quartz, and QuickDraw).

The front and back ends communicate using FIFOs and shared memory. I'm aware that certain platforms will require refactoring all of this to run in a single process. If Emscripten is one of them, then it won't be as simple as you suggest.

In any case, if I were the one doing the port, I might write a bare-bones front end just for this purpose, possibly using the fbdev one as a starting point.

Re: Advanced Mac Substitute is an API-level reimplementation of 1980s-era Mac OS

#42

Post by hagbard_c » Sat, Apr 11, 2026, 9:38 PM UTC

jjuran wrote: post #25

Someone wrote: post #14

Earlier quoted context omitted.

I think they mean FSpOpenDF ( https://dev.os9.ca/techpubs/mac/Files/Files-53.html#HEADING5... ), a (relatively) late addition to the Mac API.

The FSSpec calls added in System 7 are mostly new interfaces to existing File Manager functionality. There's an actual high-level `OpenDF()` call, which is like `FSOpen()` except that it won't try to open a driver when the name begins with `.`. Some applications call `OpenDF()` without checking its availability, but fall back to `FSOpen()` or equivalent if `OpenDF()` returns `paramErr`, which is what the parent is wi…

That, or add this information to the error message: OpenDF not implemented, falling back to FSOpen

Re: Advanced Mac Substitute is an API-level reimplementation of 1980s-era Mac OS

#43

Post by jjuran » Sat, Apr 11, 2026, 9:51 PM UTC

azinman2 wrote: post #2

This is quite the feat. I’d love to know more about the process to make this, the motivation, how much time was spent, etc.

My earliest recollection of what motivated me is a desire to resurrect The Fool's Errand.

The irony is not lost on me. :-)

Re: Advanced Mac Substitute is an API-level reimplementation of 1980s-era Mac OS

#44

Post by anthk » Sat, Apr 11, 2026, 10:23 PM UTC

Executor from autc04 was fine until I tried to open Nethack 3.6.7 for m68k Macs. It crashed, but it was a fun exercise.

AMS might work better, but it's a pain to setup.

Re: Advanced Mac Substitute is an API-level reimplementation of 1980s-era Mac OS

#45

Post by anthk » Sat, Apr 11, 2026, 10:25 PM UTC

jjuran wrote: post #25

Someone wrote: post #14

Earlier quoted context omitted.

I think they mean FSpOpenDF ( https://dev.os9.ca/techpubs/mac/Files/Files-53.html#HEADING5... ), a (relatively) late addition to the Mac API.

The FSSpec calls added in System 7 are mostly new interfaces to existing File Manager functionality. There's an actual high-level `OpenDF()` call, which is like `FSOpen()` except that it won't try to open a driver when the name begins with `.`. Some applications call `OpenDF()` without checking its availability, but fall back to `FSOpen()` or equivalent if `OpenDF()` returns `paramErr`, which is what the parent is wi…

I had that error with Nethack 3.6.7 for m68k.

Re: Advanced Mac Substitute is an API-level reimplementation of 1980s-era Mac OS

#46

Post by flomo » Sat, Apr 11, 2026, 10:27 PM UTC

eschaton wrote: post #39

icodestuff wrote: post #37

Earlier quoted context omitted.

Eh, there were plenty of games that were coded for a particular clock speed, and then once the SE came out, had an update that included a software version of a turbo button, let you select which of two speeds to run at. They run FAST on an SE/30 or Mac II and unusably fast on anything newer.

I didn’t encounter too many of those back in the day, I think because there was the VBL task mechanism for synchronizing with screen refresh that made it easy to avoid using instruction loops for timing. Much more common in my experience was the assumption that the framebuffer was 1-bit, but such games would still run on my IIci if I switched to black & white—they’d just use the upper left 3/4 of the screen since the…

Yeah, there were a bunch of floppy games which only ran on an original Mac or maybe a Plus. No go with even my Mac SE.

Re: Advanced Mac Substitute is an API-level reimplementation of 1980s-era Mac OS

#47

Post by flenserboy » Sat, Apr 11, 2026, 11:03 PM UTC

Efforts like this could be a nice way to get old apps to run "natively" on current hardware, as there are a ton of them out there which are perfectly good for work, but which cannot run today.

Re: Advanced Mac Substitute is an API-level reimplementation of 1980s-era Mac OS

#48

Post by WillAdams » Sat, Apr 11, 2026, 11:09 PM UTC

flenserboy wrote: post #47

Efforts like this could be a nice way to get old apps to run "natively" on current hardware, as there are a ton of them out there which are perfectly good for work, but which cannot run today.

I'd be glad of being able to run Macromedia Freehand/MX thus.

Re: Advanced Mac Substitute is an API-level reimplementation of 1980s-era Mac OS

#49

Post by WillAdams » Sat, Apr 11, 2026, 11:13 PM UTC

eschaton wrote: post #28

DavidSJ wrote: post #16

Earlier quoted context omitted.

The original Mac system software was written in Pascal and most Mac toolbox calls took Pascal-style (prefixed by length) rather than C-style (terminated with null character) strings. But you could write application code in either language keeping this caveat in mind.

It was actually mostly written in assembly, but used Pascal calling conventions and structure layouts since that was expected to be the primary language for application developers. As it had been for Lisa, as it was for “large” applications on Apple II, and as was the case for much of the rest of the microcomputer and minicomputer industry and even the nascent workstation industry (eg Apollo). It was the Lisa system…

A good example of this dichotomy is the Puzzle Desk Accessory --- originally written in Pascal (as an example of making a DA thus), it was too large to include on a 400KB micro-floppy disk, so was re-written in assembly language going from 6K Bytes to 600 Bytes:

https://www.folklore.org/Puzzle.html

Re: Advanced Mac Substitute is an API-level reimplementation of 1980s-era Mac OS

#50

Post by wk_end » Sat, Apr 11, 2026, 11:34 PM UTC

CharlesW wrote: post #36

wmf wrote: post #19

Earlier quoted context omitted.

There were plenty of apps that relied on implementation quirks.

Out of curiosity, what app are you thinking of? Of all of types of software used with classic Mac OS (INITs, CDEVs, FKEYs, Desk Accessories, Drivers, etc.), apps would be the least likely to rely on implemention quirks.

Macintosh Common Lisp - at least the versions floating around Mac Garden and such - seems to refuse to run on anything besides accurate emulators and real hardware.