Advanced Mac Substitute is an API-level reimplementation of 1980s-era Mac OS
124 points
by zdw
4 hours ago
| 12 comments
| v68k.org
| HN
rcarmo
31 minutes ago
[-]
This is pretty neat. I have been spending the past few months adding an ARM64 JIT to Basilisk II (https://github.com/rcarmo/macemu) and totally appreciate what's involved (I'm currently stuck patching a Quadra ROM to bypass NuBus hardware detection...)

Will definitely give it a try, since I would _love_ to have a Classic Mac environment with some modern creature comforts (like file sharing) in tiny machines.

reply
msephton
34 minutes ago
[-]
So has this beaten MACE to the finish line? Or are the goals different? https://mace.home.blog
reply
imoverclocked
2 hours ago
[-]
I can't imagine how fast this is compared to the original hardware that ran it. I remember using a Mac 512k with a single floppy drive (no hard drive support) and doing the insert-floppy-dance. Computers were far more mechanical then.

It would be fun to have a "slow it down" feature that also has the various floppy read/write noises paired with it. Bonus points for different generations of hardware and having the OG HD noises to pair with those too!

reply
jdwithit
32 minutes ago
[-]
"Fond" memories of playing King's Quest IV as a little kid on my parents' Apple IIe. You had to swap in a new 5.25" floppy almost every time you walked to another screen. I was fascinated by the game but my god was it tedious to constantly flip and swap the disks around. Google says it came on 8 double sided disks, I could have sworn it was a couple dozen.
reply
technothrasher
4 minutes ago
[-]
The game I played for hours on the Apple ][+ was "FantasyLand 2041". It came on six double sided disks, and I was bummed to find out after quite a lot of game time that disk six was corrupted. I then found out many years later that it wasn't corrupted, the game wasn't ever finished. I then further discovered that John Bell, who produced that and other popular games (Sand of Mars, Beneath the Pyramids, House of Usher), is utterly batty and has written a few "the government is hiding UFOs from us" books.
reply
drzaiusx11
1 hour ago
[-]
There was a show HN retro HW project somewhat recently that included sound emulation on board. Maybe that author is reading this, but their sound emulation was probably my favorite part (not to disregard the actual hard parts! I just found it charming)
reply
hyperhello
2 hours ago
[-]
I'd like to see something like Carbon for old apps so that they boot in modern window frames (without the missing Tahoe corners) and can save to files.
reply
eschaton
15 minutes ago
[-]
This is exactly the sort of project that can serve as the basis for such a system.
reply
londons_explore
1 hour ago
[-]
I am amazed that 1980's software works on binary API compatibility rather than relying on API quirks like timing, memory alignment quirks, memory layout from specific allocator behaviour, etc.

It only takes one unintentional reliance on an implementation detail to make an application not run on another OS implementation...

reply
wmf
49 minutes ago
[-]
There were plenty of apps that relied on implementation quirks.
reply
davidfstr
3 hours ago
[-]
Wine for classic Mac OS? Amazing. Well done.
reply
bsimpson
43 minutes ago
[-]
Sounds like Wine + FEX
reply
shermantanktop
2 hours ago
[-]
But will it run Dark Castle??

Many hours were wasted on that game.

reply
rvnx
2 hours ago
[-]
Still wondering why the main character looks like Sammy from Scooby Doo

and yes:

https://github.com/jjuran/metamage_1/commit/30cb0e260d5ff478...

reply
Chazprime
40 minutes ago
[-]
Hell, I’d go straight for Beyond Dark Castle… it really took the series to a whole different level.
reply
homarp
3 hours ago
[-]
how does it compare to executor? https://en.wikipedia.org/wiki/Executor_(software)
reply
Batbird
2 hours ago
[-]
This triggered flashbacks. I'm not sure if I'm remembering correctly, but I think we sometimes also used used Pascal, and it was optional for some toolboxes. It's been a long time though so I could be mistaken. That might have been pre-Mac? But good times, though. Boy, is the world a different place.
reply
DavidSJ
1 hour ago
[-]
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.
reply
eschaton
1 minute ago
[-]
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 software that was mostly implemented in Pascal and some blamed this for its largeness and its performance. Compilers and linkers weren’t great back then; most compiler code generation was pretty rigid, and most linkers didn’t even coalesce identical string literals across compilation unit boundaries!

Lisa Workshop C introduced the “pascal” keyword for function declarations and definitions to indicate they used Pascal calling conventions, and otherwise followed Lisa Pascal structure layout rules, so as to minimize the overhead of interoperating with the OS. (I’m not sure whether it introduced the “\p” Pascal string literal convention too or if that came later with Stanford or THINK Lightspeed C.)

reply
homarp
3 hours ago
[-]
reply
azinman2
3 hours ago
[-]
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.
reply
whartung
3 hours ago
[-]
I'm guessing they reimplemented the toolbox at the TRAP level (most MacOS calls at the time were accessed through the 68K TRAP instruction).

So, rather than emulating hardware to run native ROMs, they "simply" reimplemented the ROMs.

A friend of mine did this at another level. He basically rewrote the bulk of the toolbox as a C library so that the company, who had a Mac application, could port it to run on a PC, while sharing the source code.

This was before Windows, and it worked! Launched it from DOS, takes over the entire screen. He didn't copy the Mac look and feel. Instead he used OpenLook for his gadgets and what not (since it was, you know, "open").

But he rewrote the bulk of it: QuickDraw, Event Manager, Memory Manager, Window Manager, etc. Just ate it like an elephant. I don't think his regions were as clever as the Mac. Pretty sure he just stuck with rectangles.

reply
hagbard_c
2 hours ago
[-]

   make ams-vnc
   ./build.pl -i exhibit graft skif minivx xv68k freemountd listen vnc-interact

   ...

   Daemon starting up... done.
   T=0.037s  ERROR:    OpenDF is unimplemented

Hm, doesn't seem to work. Let's try the X11 version:

   make ams-x11
   ./build.pl -i exhibit graft skif minivx xv68k freemountd interact-x11

   ...

   T=0.275s  ERROR:    OpenDF is unimplemented
Nope, it seems to be missing something. OpenDF? All I find is this: https://github.com/PrjEnt/OpenDF, a long-abandoned project which seems to be a more compact version of another abandoned thing.
reply
Someone
2 hours ago
[-]
I think they mean FSpOpenDF (https://dev.os9.ca/techpubs/mac/Files/Files-53.html#HEADING5...), a (relatively) late addition to the Mac API.
reply
jjuran
15 minutes ago
[-]
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 witnessing. See `68k/modules/ams-fs/Files.cc` in the `metamage_1` repo.

If the error message is confusing people, maybe it's time to implement `OpenDF()` for real.

reply
ksherlock
2 hours ago
[-]
OpenDF is a MacOS toolbox call (which is apparently not implemented)
reply
hagbard_c
1 hour ago
[-]
Strange it errors out on given that I assume the thing does run elsewhere. The X11 version sometimes shows the opening screen but any attempt at interaction leads to the mentioned error. The VLC version shows the error directly.
reply