Swift on Mac OS 9
belkadan.com
belkadan.com
> Fun aside: I’ve always assumed this is why Core Foundation exists—to provide a common interface between Carbon and Cocoa. I don’t actually have a citation for this, though.
This (very enjoyable) blog post from 2006 confirms it: https://ridiculousfish.com/blog/posts/bridge.html. I believe ridiculous_fish was working at Apple at the time.
At one time, up to at least 1996 the fastest Mac for running Photoshop, was not a Macintosh at all, but an Amiga tricked out with a graphics card and a CPU upgraded from the standard 68020 or 68040 to Motorolas last entry in the 68k line, the 68060. (Roughly equivalent to a Pentium - a bit slower clock but slightly more powerful instructions.)
How could this be? Photoshop 4 used 68k instructions, and the fastest 68k based Mac was the Quadra with the 68040 CPU. The first PowerMac was released in 1994, but it had to emulate the 68k to run Photoshop, which had a serious performance hit. Once Photoshop was released for the PowerPC, this anomaly ended.
(And Photoshop on Windows must have been faster than both Amiga and Mac pretty much immediately, but if I recall correctly it wasn't as capable on Windows right then. Or maybe people used to working on Macs for magazines etc just weren't prepared to switch platforms on a whim.)
So, Amiga was the original Hackintosh. :-)
But the copyright situation was even thornier then - to start the emulator you'd have to copy ROM images from a real Mac, and the only legal way to do that was to buy a Mac.
(Not that anybody did that, they just copied the ROM onto a floppy.) I think the preferred emulator was Shapeshiter. It worked remarkably well because most Macintosh programs did not use any direct hardware access but used the Apple provided official APIs.
Another anomaly was that Amiga was dead as a commercial gaming target by then, and so did not receive a port of Doom - but you could run the Macintosh version of Doom:
https://www.youtube.com/watch?v=spHpv3NKQhI
Earlier, there was even an older Mac emulator for the Amiga which tried to go the legal route by having a little hardware board you could put Mac ROMs into. (And then of course people copied the original ROMs and put them on EPROMs.)
Edit:
the same CPU upgrade almost happened to 68030 based Macs:
That said, the first PowerPC Macs shipped in March of 1994 and Photoshop 3.0 for Mac in November. While the application was not native, a number of the filters were, so depending on what you did, they could be faster. Photoshop 4.0 was indeed fully native (November 1996).
Impress me further if you can do that with BeOS.
(For that matter, LLVM might well pick up a backend that has sufficient maintenance to keep up with internal code changes, regardless of "production" concerns. See RISC-V as an example - obviously it's not seeing a lot of production use, but LLVM does include it.)
https://lists.llvm.org/pipermail/llvm-dev/2020-March/140282....
m68k seems to be mostly a hobbyist interest rather than a commercial interest at this point. The problem is, if the person whose hobby it is gets busy and then either the whole project is getting held up by that backend, or it just gets removed.
At least in case of PPC and System z, IBM has a commercial interest in making LLVM work for them – and the former has some hobbyist/retrocomputing benefits as an unplanned side-effect. (System z, much less so – modern System z is 64-bit, whereas most of the mainframe hobbyist community focus is on the legacy pre-1980s 24-bit architecture.)
> and then either the whole project is getting held up by that backend, or it just gets removed.
LLVM has a notion of "experimental" backends that's precisely meant to avoid this. Unfortunately it's a bit misused at present, with backends that have little reason to be "experimental" being marked as such for historical reasons, while stuff like m68k (and perhaps this new PPC-based stuff) that could use it gets left out altogether. This should be fixed.
But how many people in that community have the skills to maintain the LLVM backend?
I agree it would be great if m68k made it in LLVM, I'm just trying to explain why the LLVM developers seem so hesitant about it.
A thought: if there is really enough interest in LLVM for m68k, those interested could set up a not-for-profit membership association with annual dues, and then the association could use those dues to hire a developer to work full-time (or even just part-time) on LLVM+m68k. I think if an arrangement like that existed, the LLVM development team would be far more likely to say "Yes". If 1000 people were all willing to pay $100/year to support this, that would make available $100,000 per annum to fund development.
As for WinNT and other non-ELF platforms systems, that's retro hobbyist territory, not very likely to end up in upstream LLVM. But you could always convert object files into the right format externally! e.g. for years building TianoCore EDK2 on non-Windows has involved conversions from ELF to PE (now there's also a CLANGPDB setting that produces PEs directly from LLVM)
https://github.com/zydeco/minivmac4ios
https://github.com/zydeco/macemu/tree/ios/BasiliskII/src/iOS
The first is more stable, and recently got the pointer support added, but doesn’t go up to MacOS 8 AFAIK. I copied a bit of the stuff from that to the MacEmu one to get the pointer working ok.
Thank you Zydeco!
Gonna give that a go!
This may have something to do with those being as objects of desire from my youth.