Classic Mac OS Software (Discussions on Applications) > Hacking the System, Mac OS 9.3, and Beyond !

Alternative Idea: MacOS 9 Subsystem for Linux

(1/4) > >>

cybernetix:
I'm a professional developer and have been dabbling with C and reverse engineering (I'm still learning this skill). All versions of MacOS prior to MacOS X have always been nostalgic and interesting to me despite being a Windows developer most of my life. Reviewing the forum has been a sea of knowledge and the work that has been done thus far is excellent and I commend everyone who is contributing.

I had an idea that might have some merit and thought to share to get some feedback.

What if we wrote a sandbox app for Linux that provided an emulated environment (for PPC/86k code) to execute MacOS 9 apps but the sandbox app acted as an abstraction layer between Macintosh Toolbox (all APIs within) and Linux (mapping API calls to the respective system components such as graphics, audio, networking, input, etc). Linux supports HFS+ as a file system so data/resource forks can be supported natively. I imagine you could mount a HFS+ volume in Linux, have it run the sandbox at boot time and then you're immediately in Finder accessing apps just like MacOS 9.2.2. Finder would be making calls to paint the screen via Macintosh Toolbox and in turn they would be translated to paint calls to X server (for example). The sandbox emulator would handle translating PPC/86k code into the host instruction set and in theory as long as Macintosh Toolbox was abstracted correctly the apps would run like normal.

Linux already has a breadth of hardware support even on old Apple hardware. By creating an abstraction layer we negate having to build support around a set hardware and focus purely on getting apps to work. It also opens doors to running MacOS 9 apps on other hardware (given how portable C/C++ is and leveraging Linux kernel).

I'm not suggesting this would be an easy endeavour or be 100% bullet proof as I know MacOS apps back in the day did all sorts of weird and wonderful things to run (self modifying code, code injection into the system, accessing hardware directly, etc). But perhaps this could be a great alternative to trying to rationalise Apple hardware to fix issues surrounding getting hardware to work in MacOS 9.2.2.

Food for thought, happy to hear any ideas/criticisms/feedback. Cheers everyone!

cybernetix:
On reflection this might be the method that Classic Environment (Blue Box) is using on MacOS X. Maybe decompiling/disassembling Classic Startup.app/TruBlueEnvironment could give some insight and direction.

cybernetix:
It seems I wasn't far off after all...

https://groups.google.com/g/comp.sys.mac.programmer.help/c/tO0iuTNETGc/m/oTwfHPfuqXoJ?pli=1

cybernetix:
Another project I just found which implements this approach for 68k apps.

https://github.com/jjuran/ams-68k-bin

DrNo7:
Hi cybernetix,

What you describe is in the ballpark of the Classic environment of OS X and Wine on Linux x86 (as you research highlighted).
The main limitations of such straregy are:

* the Linux hardware support for Apple PPC hardware is not as mature as other architectures, so there will be some sizeable effort to invest in it to get all the performance from our aging hardware
* despite the portability sirens song of C/C++, there is a hard reality that throws a wrench: endian-ness. Porting such layer would require endian-ness byte-swapping constantly making it more a VM than a translation layer. And for that, there is already projects like QEmu that are open to contributions and support OS 9
Don't get me wrong, your enthusiasm and skills are good. And the good news is that you have a selection of existing projects to contribute into saving you the effort of starting and promoting a new project (energy that can be spent coding away) ;)

Navigation

[0] Message Index

[#] Next page

Go to full version