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. :-)
Author
Topic: Alternative Idea: MacOS 9 Subsystem for Linux (Read 15758 times)