Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[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)

[IIO]

what i currently fail to see is the reasoning/use case for such a software.

what could it be good for? that you could run OS9 on a PPC? hm, that is what it does natively already. or under OSX, in bluebox. emulation exists, too.

more interesting (but of course also 100 times more difficult) would be a classic enviroment for 64 bit (powermac G5? IBM power9 and power10?) but i am sure that wont happen.
 
 
we had a development wishlist here some time ago. it contains things like USB 2 support, firewire 800 support, new graphics cards drivers for MacOS9. a new extensive HID driver with controlpanel. new device drivers for certain outboard gear. a new finder with more options, support for UTF and long names. a solution for formatting 16 TB HDDs by raising the blocksize. H264 for quicktime. exceeding the 1.5 GB RAM limit. blueray driver.

those should be much more realistic than dream projects such as AHCI support, 64 bit support, or a linux classic enviroment, where probably the whole OS has to be rewritten for or where you even might end up with unsolvable hardware problems.

however, an idea is an idea and an offer is an offer.

[teroyk]

support for UTF and long names. a solution for formatting 16 TB HDDs by raising the blocksize.

Actually UTF-16 support is already in Mac OS 9.2.1 and up.
Just check non US installation CD or DVD what came with machine,
there is Unicode folder that has extension and Worldtext folder that has Writing-app.
Starting MacOS 8.1 there is support up to 512 byte long filenames in HFS+, but
problem is that somobody has to write software that read filenames as they are on the disk.

But I am just guy that think opposite direction Linux subsystem for MacOS 9:
http://macos9lives.com/smforum/index.php?topic=5481
that Connectix already made, but it is lost in history.

[Mat]

I have to agree with IIO.
Hardware really is our last problem. We have tons of good machines going up to 2GHz. What we need first for our real daily work are some basic programs. A modern PDF reader (going on with Ghostscript for example), TLS 1.3 what might be done by porting Mbed TLS, or a xml (.odt/.docx) reader.
Later we should care about bigger more complicated projects like USB 2.0 driver, WPA2 and such stuff.

If a team would care about a recent webbrowser (e.g. porting netsurf) lives also would be a lot easier for us. Also some "driver" for an recent "media decoder chip", like done for MPG2 with the Wired 4DVD back than, would bring us foreward a lot.

68k is in general served well with existing emulation at PPC CPUs built into MacOS and all the software emulators at different plattforms. A PPC emulated environment that you suggest will be slower than our existing hardware. And it will never bee what MacOS 9 is about. Just see what "Classic" did to us, and what problems it still is creating all the time.

What might be a better aim is to create a kind of JIT compiler so that one of the real beasts like Power9 can act compatible to our E600 cores and serve as a much faster replacement CPU. But I doubt that it can be done by a single developer (and still someone would have to produce Upgradecards with such new CPUs).

[robespierre]

If you're going to shoot for the moon with talk about Power9, maybe the right way to think about it is how you would get MacOS 9 running under a hypervisor. Then it would be possible to run it "natively" on modern Power9 hardware like the Talos workstations.

[Mat]

Mac OS 9 under a hypervisor at a Talos would open a can of worms to my underdstanding. It would mean to need to care about any peripherial (like RAM, Timers, I/O, PCI etc. etc. etc.), an all that without the possibility to manipulate the OS itselve as we have no Mac OS 9 sources (just Mac OS 7 sources are around), ... how should that become possible without coming down to simple emulation again?

That was why I suggested to "just" care about the CPU. But as said, I do not really see any point in "new" and faster hardware without any software that would need modern computing power.

[IIO]

"hypervisor" reminds me on a recent talk with a friend about options for distributed processing from an OS9 client.

[GaryN]

If you're going to shoot for the moon with talk about Power9, maybe the right way to think about it is how you would get MacOS 9 running under a hypervisor. Then it would be possible to run it "natively" on modern Power9 hardware like the Talos workstations.

You know, if anyone could actually DO that it would be Cameron Kaiser, who's fast becoming "Mr. Talos".

I doubt however, he'd be interested in doing all that work for the 2 or 3 obsessives who would / could actually buy a Raptor…

[IIO]

hard to imagine that whatever new form of processor would allow a much faster classic enviroment operation than G4 and G5.

[teroyk]

hard to imagine that whatever new form of processor would allow a much faster classic enviroment operation than G4 and G5.

And end of the day classic enviroment is just classic enviroment.
So it might be good really try first G5 models to boot to MacOS9:
http://macos9lives.com/smforum/index.php/topic,5531.0.html
we doesn't even know where boot actually stop.
And people worried about 1.5GB memory limit...why not just
make ram-disk from all memory after that limit?

[cybernetix]

My idea is centered around getting apps to work by providing an environment that is identical to the Macintosh Toolbox. In the eyes of the app it looks and smells like a Mac because the API doesn't change, only it's implementation. An app doesn't care what's under the hood of the OS, as long as the API behaves the same and returns the same result despite being on different hardware.

I'm of the opinion (and feel free to correct me if I'm wrong) is in order to change things in MacOS 9.2.2 to support more memory, improve date time limitations, hardware support; It would require modification to MacOS ROM, System, Finder, Extensions and other binaries that make up the OS. Not only that, it would be up to the developer to build an implementation of respective fix.

This is why I went down a path of sandboxing on Linux. Linux is open source, it has a substantial amount of hardware support and many critical system components are implemented. You can install Linux on PowerPC hardware. The kernel can be compiled to be low footprint.

In light of that thinking, 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.

[IIO]

the use case of classic enviroment in 10.4.11 is mostly to run a few specific apps only and not to permanently use it like an emulation or virtualisation, so there is not too much experience about third party extensions.

however, i had tried quite a few third party extensions (including ones which are actual INITs) and it generally works.

what does not work is extensions in that area where the apple stuff has been removed in the "classic enviroment" install, hardware I/O or however it is called. for example you cant use the mouse controlpanel or OMS.

[teroyk]

In light of that thinking, 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.

You mean little like they have did for run Atari TOS/GEM with AFROS:
https://aranym.github.io/afros.html

It's not bad idea, but with MacOS 9 there will be same problems that with Atari virtualization...Linux is not so good for MIDI or Audio than original Mac OS 9 or Atari hardware.
I haven't seen any Linux drivers for DSP-cards.

EDIT: somehow end of my answer missing so:
Although I said bad points, it is not bad idea! I think you know good points already...I might even beta test if somebody start making it. Good emulation making adds also our knowledge how to make new hardware.

btw. there is already Mac On Linux and we have even talked it in this forum:
http://macos9lives.com/smforum/index.php/topic,2519

[cybernetix]

This is fantastic, I was not aware of the Mac-on-Linux project. I will take a look at it this weekend with my observations.

Thank you for sharing!