I've been wondering to what degree it might be possible to have a freely-available, open-source, non-Apple implementation (or implementations) of the 68k MacOS, one that could be distributed freely to users, perhaps alongside one of the several, 68k Mac emulators.

I recall that Executor, in particular, used a reimplementation of 68k MacOS, one that wasn't "complete", but was able to run a number of games and apps. I know that its source code, or at least, a significant portion of it was posted to Github years ago (to https://github.com/ctm/executor).

Executor does not boot on actual Macs, that much its own documentation states. I do wonder how much work would be involved to get it to boot on other emulators, especially those that are more actively maintained.

I've done some bit of poking around within Basilisk II's source code, as well as some amount of 68k Mac code, but admittedly, my knowledge there is a bit lacking. By the time I picked up programming, first as a hobby, and later as a profession, 68k Macs were, arguably, obsolete, and I never took much time to study up or practice working with its internals.

I am curious, though:

1. to what degree might a reimplementation of 68k MacOS be possible, within existing emulators.2. might Executor, or some other MacOS reimplementation, be feasible.

Thoughts not his *definitely* welcomed. (I may be crazy on this, though. )

It's an interesting idea, as the problem with 68k Mac OS is that half of the stuff happens via toolbox calls in the ROM, some of which are then bootstrapped by the system kernel.

Executor side-steps all this in the same way WINE does for Windows: by implementing hooks to the toolbox calls itself and running the code natively using native CPU operations. This meant that Executor had to do endianness translation and other hackery on the input data to make it usable in an x86 world, which is something WINE never had to do (after all, it wasn't an emulator).

This means that the Executor method itself does not lend itself to being a System/ROM replacement on emulated 68k hardware. However, the places where Executor hooks the toolbox calls should be usable as a guide for doing something similar without the translation, as long as the hardware/emulator interface is also written from scratch (the part Executor never has to do).

In short, a lot of work, but also very intriguing. It seems like we now have most (but not all) of the parts needed to do this at our disposal to write a ReactOS equivalent for 68k hardware.

Executor side-steps all this in the same way WINE does for Windows: by implementing hooks to the toolbox calls itself and running the code natively using native CPU operations. This meant that Executor had to do endianness translation and other hackery on the input data to make it usable in an x86 world, which is something WINE never had to do (after all, it wasn't an emulator).

Executor's source does have references to a port running on 68k NeXT hardware. Assuming that this was a reasonably-working port, any thoughts on if this might help? I.e. Executor's reimplemented-Toolbox might already have been running on real, 68k processors.

Definitely worth chasing up... I think the first steps would be understanding the 68k port and verifying we can build and deploy for the target (or possibly for the Previous emulator if that supports 68k).

I like the idea of using HFVExplorer instead of trying to re-implement the Finder, but alas, the source code for HFVExplorer has yet to emerge. (As per viewtopic.php?f=7&t=9071 , even mini vMac will work without a Finder.)

But then, I suppose replacing the Finder is only a small part of what Executor does.

Only recreationally for me... but I'd love to be able to repackage classic software to run on modern OSes. Like WINE, it could also have a second mode where you could compile against it. Imagine writing some code in Turbo Pascal in BII, and then linking it against an XCode project....

This could be useful for doing things like compiling the VGA binary support code for qemu without having to boot into OS 9 in qemu (with the compiled VGA code) to do it....

Like WINE, it could also have a second mode where you could compile against it. Imagine writing some code in Turbo Pascal in BII, and then linking it against an XCode project....

I like this idea, although, it seems like it would expand the layer's target by quite a bit. My current thought was more along the lines of: create a replacement for 68k MacOS that, in tandem with modern, freely-available emulators, allowed classic Mac apps + games to run. It might not be quite as minimalistic as possible, but it would make for a smaller, while hopefully still-viable, goal.

What if such a system (replacement OS + emulator) existed, but also provided a means to 'boot' into a specific application, and perhaps to shut down when the app closed?

Jorpho wrote:

I'd like to think the lack of such a reimplementation is the major obstacle preventing heaps of classic MacOS software from being properly rereleased to new audiences.

This seems like a good reason to me. I guess I am thinking along the lines of, "If I/we build it, will they come?". Not to say that it isn't an interesting thought for a project, it's just, well, big-looking.

I'd like to think the lack of such a reimplementation is the major obstacle preventing heaps of classic MacOS software from being properly rereleased to new audiences.

This seems like a good reason to me. I guess I am thinking along the lines of, "If I/we build it, will they come?". Not to say that it isn't an interesting thought for a project, it's just, well, big-looking.

It does occur to me that to my knowledge, there's no Amiga software being distributed on Steam despite the existence of open source implementations of the necessary components. But then again, perhaps any Amiga games that people would want to pay for are already available in other forms.

The big pull of Amiga software back in the day was the audio hardware handling; graphics generally were on-par with PC graphics. Since the hardware side of things doesn't really get into emulators to a great degree, most software available for AmigaOS was also available for DOS and looked/played about the same.

So Amiga software would be competing against DOSBOX, which is an uphill battle.

Since the Video Toaster and Kitchen Sink are eclipsed by modern video editing tools, there's not much call in the non-gaming area either.

I've been doing a bit of digging into this. Here's what I've done, and/or figured out, and/or made mistakes with :

1. I tried getting Executor building in OPENSTEP/m68k, without any immediate luck. I was able to get a working, OPENSTEP/m68k system running, and with Developer Tools installed, however, when trying to build Executor's Nextstep/Openstep code, both 'make' and Project Builder failed. More work _could_ be done here, but I haven't gotten there. Executor's code and documentation do have a bunch of references to a 'native', m68k port. This isn't to say that it still works, or this was released on Github, but I was able to find some.

2. I was able to build and run Executor on 32-bit Linux. It was a virtualized system, run inside Vagrant + VirtualBox, on a minimal install of Ubuntu 16.04. The result displays an empty, Executor desktop, via an X11 window. I figure this might be useful for figuring out what a working copy of Executor does. If anyone is interested in the Vagrantfile and scripts for this, let me know, and I can post them somewhere. (In theory, they should allow a copy of Executor to be built via a 'vagrant up' command, if run from the right directory at a shell prompt, but this might be wishful thinking.)

3. I started toying around with m68k cross compilation, via gcc. I used the virtualized, 32-bit Linux system that I used to build Executor, and installed a gcc 5, m68k compiler (via "sudo apt install gcc-5-m68k-linux-gnu"). I've been able to use this to get a no-frills, no headers, no linked libraries file, that has some compiled, 68k code in it. For reference, here's the command I ran to build it:

romtest.c is just a main() function that returns an identifiable, non-zero value (such as 42).

4. I did some exploratory work into Basilisk II's rom-patching code. Yeah, wow, it's extensive. After looking at it, I am thinking that trying to target Basilisk II is probably a bad idea, given how much searching it does for specific, binary snippets. I'm thinking of looking at a different, Mac emulator, perhaps the one in MAME/MESS.

Good thought. I forgot that PCE had Mac emulation in it (despite having hack-ported it to another platform, at one point!)

I have PCE building + running now. I don't, yet, have source-level debugging enabled for it yet, despite it being compiled with both CFLAGS and CPPFLAGS having -g set for configure and make, but I'll give it some more shots.

I've been continuing to work on this, and have something pretty basic up and running, within PCE. It only displays a bitmap image, however it does so without the use of any Apple-copyrighted code. The program is loaded into PCE as a rom file.

Here is a screenshot:

This should load into a PCE-emulated Mac Plus with 4 MB of RAM. It also seems to work if PCE is setup to emulate either a Mac SE, or a Mac Classic.

The code for this is almost entirely C++, with a little bit of inline assembly mixed in.

A pretty recent copy of gcc was used to compile this, specifically g++ 7.2. I did so on a 32-bit Ubuntu 17.10 VM, which has 68k g++ cross compilers installable via apt. If anyone is interested in this, the apt package is, "g++-m68k-linux-gnu".

I'm thinking that if I do more work on this, I might try to get printf support running over a serial connection. That seems like it would be good to have, in terms of debugging other things.