Welcome to Mac OS 9 Lives, jjuran! MacRelix is awesome! Glad to have you here

Sorry, I need to temporarily take down the downloads page on the main site. We're moving the website and the downloads to a new host. The downloads are up on the Hotline server though, so grab them from there (like aBc mentions).

My idea is centered around getting apps to work by providing an environment that is identical to the Macintosh Toolbox.

[discussion of the challenges of improving Mac OS 9 snipped]

This is why I went down a path of sandboxing on Linux. Linux is open source, it has a substantial amount of hardware support... You can install Linux on PowerPC hardware.

I thought it might be plausible that a sandbox could reimplement the Macintosh Toolbox to target system components in Linux (X Window, PulseAudio, networking, etc). I understand there would be an overhead because Macintosh Toolbox would require thunking/translating API calls to Linux and back again - however given hardware has improved over the journey the speed might outweigh the overhead.

The gain would be to run MacOS 9 classic apps on many facets of hardware, having graphic/audio/input/network support across the board.

Rethinking this strategy, the biggest hang up I have is how Extensions/Control Panels hook into MacOS, how that might affect the ability to change the behavior of a sandboxed MacOS at runtime.

Food for thought.

Hi, I'm the developer of Advanced Mac Substitute, which you referenced earlier.  I have a perspective that both intersects and diverges from yours.

Advanced Mac Substitute
https://www.v68k.org/ams/

Reimplementing the Mac OS and Toolbox is a sound idea — I'm hardly the first to do so.  But bear in mind what an enormous task it is.  The road to Carbon reimagined how windows, controls, and menus work, adding many new API calls (to say nothing of Carbon itself).  QuickTime alone has hundreds.

This is why I chose to start at the beginning and move forward chronologically, more or less — it's the shallow end of the pool.  (In practice, my current target is System 6 and I focus more on what features are needed vs. which version introduced them — which explains why I have Gestalt() (added in System 6.0.4) but no Disk Driver (since System 1).)

That implies focusing exclusively on 68K for now.  That, in turn, calls for emulation.

Which is just as well — virtualization involves more complexity in general, and in Mac-on-Linux's case, requires the host OS trusting the guest with privileged access (removed in Linux 2.6).  Whereas emulation is essentially just number crunching with a large array.

Every reduction in complexity or scope helps make the overall problem more tractable.

(Performance just isn't an issue, even on a 15-year-old x86_64 processor.)

I've taken a factored approach:  The 680x0 interpreter core and the reimplemented Mac OS form the back end of the system, while an an application that displays graphics and relays user input is the front end.  A front end is a much smaller body of code to manage than the back end.  I've written five implementations just for macOS alone.  Linux is supported via fbdev, X11, and most recently (thanks to a colleague), SDL2.

In addition to the front and back ends, there are one or more file servers and a optionally a sound server active.  The sound server is itself split into a library that implements the individual synth modes of the Sound Driver, and an API driver, either PortAudio or Sound Manager (for really old Mac OS X versions).  PortAudio works just fine on Linux; I have no intention of targeting PulseAudio directly.

(I don't have a way to run cdevs yet, but any 'INIT' resources placed in the System file will load and execute.  On a Mac, files of type 'INIT' in the bootstrap file area will also be opened and checked for 'INIT' resources.)

There's another drawback of continuing to use Mac OS 9, whether in emulation or on real hardware:  Many applications just don't work in it.  (I was going to use Déjà Vu as the initial demonstration of Legacynth's capability, but (a) if you forget to start Legacynth, it hangs trying to play sound, and (b) even with Legacynth running, the sound works fine but the application eventually crashes.  I ended up writing my own demo app.)  With emulation, you can run applications in different environments on the same host, simultaneously.

In summary, I agree that sandboxing is vital for the future.  (Though I'm also in favor of small system or application patches that improve quality of life for existing users.)  However, preservation of our culture and the ability to share it with younger generations is too important to limit it to one operating system or CPU architecture — especially one without the speed and economy of scale of modern microprocessors.

I hope this was useful. :-)

Very interesting history! Thanks for sharing. I also read the article on the history of MacRelix you shared. It's not everyone that would continue a project like that long after Mac OS X came out. But it sounds like you are a truly passionate developer. Both pursuing whatever catches your next interest and also seeing things through to the end.

You have an amazing body of work. How did you first get involved in building legacy Mac software?

When I started learning the Mac Toolbox, it wasn't legacy yet. :-)  My first foray into Mac retroprogramming was MacRelix, an effort to bring POSIX features to classic Mac OS beyond the sockets API provided by GUSI, about which I've written:

MacRelix Origins
https://www.metamage.com/text/relix/origins.html

In 2003, I wrote Port XTender, my first Mac OS X application and first classic Mac OS device driver (pair), to bridge the gap between the Blue Box environment and a Mac's internal modem.  (It was also my first (and so far, only) commercial product — there was a popular application called MacAuthorize that never got updated for Carbon, and its users were necessarily businesses, so they could afford to pay for a solution.)  The hack is that the driver worked by... (are you sitting down?) sending Apple events. :-O

In 2007, I finally started learning 68K (and some PPC) assembly language so I could generate stack traces and do those special 68K things you can only do from asm.  That led to teaching MacRelix new tricks (like installing its own hardware exception handlers), a 68K disassembler, the v68k interpreter core, a debugger, a threads library, and various trap-patching INITs.

You have an amazing body of work. How did you first get involved in building legacy Mac software?

Physical disks, yes, but there are also disk images.

For making MFS disk images you can use MinivMac:
% dd if=/dev/zero of=400kb.image count=800and drag that file into MinivMac, select single-sided.

not an issue these days with ZULUScisi, BlueSCSI, AppleSauce etc

Quote from: Jubadub on December 04, 2025, 11:51:11 AM

So to highlight one of the interesting features of e.g. System 7.1.2P, it is the latest version of the OS that is still able to format disks as MFS. Nearly all of the later System 7 versions can both read from and write to existing MFS disks, but not format one anew. (So a Mac mini G4 CD for 7.1.2P could, one day, be theoretically cool to have. It is also a relatively popular System 7 version choice by many.)

MFS floppy disks are formatted with Apple's proprietary GCR encoding, which can only be written or read on Apple floppy drives connected to an IWM or SWIM controller chip. No computer since the "Gossamer" G3 desktop or "PDQ" notebook is able to use these disks, since they are unreadable in all USB floppy drives. MFS was normally only used on single-sided double density (SSDD 400KB) floppy disks, but there were ways to prepare double-sided (DSDD 800KB) disks as MFS instead of HFS. Both use GCR encoding, not industry-standard MFM.

A Mac Mini G4 cannot read, write, or format 400/800KB disks at all. It is a hardware limitation, not a missing driver or software issue.

Physical disks, yes, but there are also disk images.

So to highlight one of the interesting features of e.g. System 7.1.2P, it is the latest version of the OS that is still able to format disks as MFS. Nearly all of the later System 7 versions can both read from and write to existing MFS disks, but not format one anew. (So a Mac mini G4 CD for 7.1.2P could, one day, be theoretically cool to have. It is also a relatively popular System 7 version choice by many.)

MFS floppy disks are formatted with Apple's proprietary GCR encoding, which can only be written or read on Apple floppy drives connected to an IWM or SWIM controller chip. No computer since the "Gossamer" G3 desktop or "PDQ" notebook is able to use these disks, since they are unreadable in all USB floppy drives. MFS was normally only used on single-sided double density (SSDD 400KB) floppy disks, but there were ways to prepare double-sided (DSDD 800KB) disks as MFS instead of HFS. Both use GCR encoding, not industry-standard MFM.

A Mac Mini G4 cannot read, write, or format 400/800KB disks at all. It is a hardware limitation, not a missing driver or software issue.