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.
It only takes one unintentional reliance on an implementation detail to make an application not run on another OS implementation...
A 1 bit framebuffer and a CPU gets you most of what the machine can do.
Most of the quirk abuse of 8-bit machines came from features that were provided with limitations. Sprites, but only 8 of them, colours but only 2 in any 8x8 cell. Multicolour but only in one of two palettes and you'll hate both.
Almost all of the hacks were to get around the limitations of the features.
I don't know if the decision apple made was specifically with future machines in mind. It certainly would have been a headache to make new machines 5 generations down the track if the first one had player missile graphics.
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!
Many hours were wasted on that game.
and yes:
https://github.com/jjuran/metamage_1/commit/30cb0e260d5ff478...
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.)
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.
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
make ams-x11
./build.pl -i exhibit graft skif minivx xv68k freemountd interact-x11
...
T=0.275s ERROR: OpenDF is unimplemented
You clipped the part that said "Starting VNC server on 127.0.0.1:5900". Did you try connecting a VNC client?
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.