MacRelix: a Unix-like environment that runs in classic Mac OS

MacRelix is a Unix-like environment that runs in classic Mac OS.

MacRelix natively supports classic 68K and PPC Mac OS, as well as Mac OS X on PPC via Carbon.

MacRelix website

The creator of MacRelix, Josh Juran, published an article in 2019 detailing the origins of the project. As a Mac OS developer, he was so unhappy with both CodeWarrior and Apple's Macintosh Programmer's Workshop (MPW), that he set out to create what would become MacRelix in 1999. Reading through the limitations and roadblocks he experienced with CodeWarrior and MPW, it's not hard to see why he got frustrated - CodeWarrior's targets were apparently a mess and a half to deal with.

Then came target multiplication. Whereas the initial CodeWarrior developer releases shipped with each combination of language (C and Pascal) and architecture (68K and PPC) supported in a separate application, a later version of the IDE unified these, allowing the developer to have a single project file per project. To allow the same project to be built for both 68K and PPC architectures, the project data model included targets: One target would compile for 68K and link against 68K libraries, another would do the same for PPC. Targets could also be used to select an optimized build versus one for debugging. Combining both dichotomies yields four targets: 68K debug, 68K optimized, PPC debug, and PPC optimized. Then if your project involves multiple executables, like a code resource or shared library in addition to an application, you now have eight targets. Or, if you support one of, say, 68020 optimization, profiling, or a third executable, make that twelve. Or, for all of them, twenty-seven.

Josh Juran

Changing an option in your application required you to change it in every single target, too, which I can easily see is incredibly frustrating. MPW, for its part, was a massive improvement, he argues, but while it was clearly inspired by UNIX, it didn't seem to actually implement any of the features and characteristics of UNIX.

However, very much unlike Unix, the MPW Shell had only a single thread of execution - only one program could be running at once. Not only that, but there was no way for MPW's compiled plugins (called tools) to invoke other tools or scripts - not even via system() (which blocks the calling program until the called program exits). Therefore, Make couldn't actually do anything, but only printed out the commands for the user to run manually. You could code in Perl instead of the built-in language, but then your scripts couldn't run other programs - only MPW shell scripts could do that.

Josh Juran

The limitations Juran was experiencing with these two tools pushed him to create his own solution, which went well beyond what MPW offered, even in 2019 when this article was published.

Nowadays, MacRelix has pipes, signals, system calls, TCP sockets, and more. It works on both 68K and PowerPC Mac systems and builds as Carbon to run natively in OS X. It can be used on any Mac OS version from System 7 to Mac OS X 10.6 Snow Leopard" (after which Apple removed the Rosetta PowerPC emulator). I haven't implemented fork() yet, but I know how to do it. In addition to a Unix-like file system interface (which even handles long names by storing them in Desktop database comment fields)), MacRelix has a /proc filesystem (with human readable stack crawls) and also maps various parts of Mac OS (e.g. the ROM image in /sys/mac/rom).

Josh Juran

I had never heard of MacRelix, but it seems like an amazing tool Juran put a lot of thought, effort, and love into. Sadly, with the number of PowerPC Mac OS X users being vanishingly small, and the number of classic Mac OS users even smaller so, the future of MacRelix seems uncertain. I wonder what parts of it can be salvaged and upgraded to work on ARM macOS or even Intel macOS, because I think the ideas and concepts are incredibly cool.

A related project by Juran is something called FORGE, a portable windowing API that used a virtual file system, meaning that instead of using functions as objects, it uses files. Juran mentions the example of a window title - which is a file, and if you want to change the title of that window you just change the file, which will be instantly reflected in the GUI. Here's a Hello World example:

cd $FORGE/gui/port/hello # select a window port named "hello"exec 9> lock # exclusively retain the port for our useln new/caption view # add a caption as the window's viewecho Hello world > v/text # set the caption texttouch window # create the window

Even though I'm not a programmer, this little tidbit of code makes perfect sense to me, and I understood it instantly. Of course, anything more complex will quickly leave my wheelhouse, but intuitively, I really like this. FORGE exists as a prototype inside MacRelix, so you can play with this concept while using MacRelix.