jjuran

> Classic MacOS remains proprietary. ... Pity. I'd hope that some day Apple might release whatever source it still has.

I highly doubt this will ever happen. It seems like Apple is trying to avoid any association at all with classic Mac OS, even to the point of declining to go after folks hosting system software or ROM images, or even leaked ROM source code... on GitHub!

Even in the case of QuickDraw, whose source was published by the Computer History Museum, it's under a non-free license — so it wasn't quite released, but merely exhibited. (If you're unclear on the difference, ask any resident of a zoo.)

In the meantime, my own work-in-progress reimplementation of Mac OS is dual-licensed AGPL/commercial. The goal is to run classic Mac applications on commodity hardware.

> The AI know this too,

An AI trained on leaked Apple ROM code?

> and that is a way to rework the OS.

What you do on your own machine is your business, so have fun with that. You can't legally share it, though.

"CarbonLib" implies Mac OS 9 (or 8) — it's the classic Mac OS implementation of the Carbon API. The OS X implementation is Carbon.framework (or more precisely, various frameworks under its umbrella).

RegisterEventHotKey() is available "in CarbonLib 1.3 and later" according to Universal Interfaces.

It's totally fair to disagree about whether Mac OS 9 meets the stated requirements. I just don't think it's reasonable to assert that GGGP (who may have made unwarranted claims about OS 9) was actually confusing OS 9 with OS X.

What do you find lacking in the emulators? I don't mean to suggest that they leave no room for improvement — I'm asking how to improve them.

My own emulator (Advanced Mac Substitute) can run Spectre Challenger, by the way.

NewPtr() and Delay() date back to System 1.0, and they're still present in macOS 14, at least.

UI-level Carbon is gone, but various low-level APIs persist.

> At this point, they could likely decompile MacOS classic and rework it to give it modern memory protection, virtual memory, preemptive multitasking, and networking.

You'd lose compatibility with the applications, though, so you'd have to decompile and rework those as well. And even if you did, you couldn't legally distribute any of it.

An alternative approach is high-level emulation. Running a separate instance per application gives you process isolation (via the host OS) for free.

> I assume booting an OS with a mere few megabytes of RAM footprint would only take milliseconds?

I haven't measured it as such, but yes.

One of my elementary school classmates brought printouts of Escher's Waterfall to share. I accepted one, took it home, and taped it to my bedroom wall. My father saw it and loaned me his copy of Gödel, Escher, Bach.

At first, I flipped through the book looking at the Escher prints. My second time through, I read the dialogues. Next I had a go at reading the chapters and got lost. Maybe on my fifth read-through (years later) I actually attained an understanding of Gödel's Theorem (at least for a brief moment before it vanished again).

I credit GEB (and its dialogues like Little Harmonic Labyrinth) for helping prepare me to deal with the kind of multi-level abstraction involved in developing a language interpreter or machine simulator. Especially that time I had to debug a crash that only occurred when running my simulator inside a simulated instance of itself (i.e. when three levels deep, but not two).

In my 68K Mac emulator running on modern (or even decade-old) hardware, performance in the traditional sense is less of a concern, but other issues arise. The big ones include CPU-burning loops that wait for a length of time or for an interrupt-decremented counter to reach zero, as well as invalid memory accesses (which I've made crash — no NULL deref for you).

> We considered creating a plugin that fixed all these things, it would have been hard to maintain, in the end we travelled around to the people who made these apps and talked them through their problems

Since talking to developers is no longer an option, I actually do write "Such-and-such Tune-up" extensions that patch applications dynamically to make them run better (or at all) in Advanced Mac Substitute, or even Mac OS itself.

I knew of Executor, but never saw it in action. Winning back performance lost to emulation was critical when competing with contemporary real hardware, and kudos to ctm and ARDI for their clever solution.

Decades later, though, emulation performance is mostly a non-issue (and even improves automatically with faster hosts). What matters now is portability (which requires ongoing maintenance) and renovation of programs designed around having the CPU to themselves (via dynamically applied patches).

A Mac 512K of sorts was already built before the Macintosh introduction at the 1984 shareholders meeting — the demo wouldn't run in 128K of RAM.

Funny you should bring up MacRelix — the very first front end for Advanced Mac Substitute was built in it.

The latter. There's only one heavy drinker in Dark Castle, and it's not the hero. ;-)

It's not you; it's me. My implementation of LoadScrap() (which is called at startup) is calling FSOpen(), and it turns out the glue code for that tries OpenDF() before falling back to PBOpen(). TIL.

The call is coming from within the OS!