Hacker News new | past | comments | ask | show | jobs | submit login
Swift on Mac OS 9 (belkadan.com)
272 points by bdash on April 1, 2020 | hide | past | favorite | 44 comments

In response to:

> 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.

Of course, while toll-free bridging is still around, its implementation details are somewhat different these days.

I suddenly felt the old Amiga fanboi inside of me pop up... :-)

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:


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


the same CPU upgrade almost happened to 68030 based Macs:


Remarkable. Today the fastest Mac is also a hackintosh, so some things have not changed so much.

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

You'd have to go through a lot of hoops like LLVM, compiler, etc CPU support just to get a Mac OS app written in Swift visible on the screen on OS9. Very interesting technical read on CPU support, compiler support, no matter the usefulness.

Impress me further if you can do that with BeOS.

There was some early work to get Swift running in Haiku: https://github.com/return/swift/commit/afca67566b0ed82f80ded...

Well it seems that the same guy has actually also upstreamed it https://github.com/apple/swift/pull/11583

It would be interesting to upstream the LLVM-related work. And I do wonder how much work would it take to support other PPC32-based platforms - not just Apple and BeOS but AmigaOne, GameCube/Wii, *NIX and WinNT 3.51/4.0 systems etc.

FreeBSD recently switched PPC32 to Clang and LLD https://github.com/freebsd/freebsd/commit/684fed6e06cc3d3cff... :)

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)

AFAIK LLVM only picks up backends that are production-maintained.

See also the debate about adding m68k backend to LLVM.


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

m68k isn't just one person's hobby however - there's a sizeable retrocomputing community around it.

> 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.

> m68k isn't just one person's hobby however - there's a sizeable retrocomputing community around it.

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.

IBM is doing most of the work wrt. this backend to support their AIX systems. Support for other platforms mostly comes along for the ride.

(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.)

This is the coolest, awesome most useless thing I’ve read in awhile. I can’t wait to see where this goes.

Far from being useless, this sort of work could ultimately make it easier to preserve existing Classic Mac OS-based apps and code, and run them on modern systems. Just as having FreeDOS around and even in active development makes it easier to support the DosBox platform.

Uh, how does making Swift compile new code to Mac OS 9 help with preserving old code?

It ensures that toolchains for the system continue to work on modern computers.

Why? You can already run the original toolchains used to write classic software using emulators.

In addition, there is a modern GCC-based toolchain for classic MacOS:


No, it does the opposite: it ensures that toolchains for the modern system work on retro systems. Which is a neat hack, but doesn’t help with preserving anything.

I recently have been getting into making a lot of small swift apps for personal use AND now have MacOS 7 and 8 running on my iPad since they’ve added mouse pointer support. Excited to dig into this article!

Okay, I'll bite: How are you running Classic Mac OS on an iPad?

These two projects:



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!

Haven't looked, but gotta ask: does it run HyperCard?

If it is like mini vmac for other platforms, and I don't see why it wouldn't be, yes.

I don't know if this is the way, but ~20 years ago I was curious about running emulators for 68k Macs on PCs.. there was vMac which emulated black&white Mac Plus, and basilisk II which emulated a macII. They could both run system 7. That was true circa 1998. I imagine the hardware needs are not that high.

Mini vMac can now also emulate a mac II and do color and higher resolutions. Basilisk II can do an 040 now as well.

Amazing. Would love to have classic Mac on the iPad. What a cool project.

System 7, Mac OS after 7.6

Awesome project and a great read! (Is it weird for anyone else to see such a nostalgic meme?)

The big takeaway for me is the MPW emulator that lets you run the tools from MPW.

Gonna give that a go!

This article encouraged me to finally buy the iMac G4 I've always dreamed about.

This post is obviously written with sarcasm. However, I've been enamoured with the G4 Cube and 12" PowerBooks since they first came out and haven't been able to find a device that's been as aesthetically pleasing since.

This may have something to do with those being as objects of desire from my youth.

No, I was absolutely serious! Bought one on ebay tonight. :-)

Mine is one of my most treasured possessions and is in daily use.

What are you running on it? Latest macOS or Linux…?

This is so wonderfully utterly useless. I love it.

Cool! Is there a copy of the Swift BitPaint code anywhere? I couldn't see it. Just trying to gauge how much this could support.

Now, let’s run Swift on the original Macintosh.

I wonder if this was inspired by the person who compiled .NET for Windows 3.11?

I would be happy already if the swift>3.x would run on my osx sierra machine

OS X was released 19 years (+ 1 week) ago...

Applications are open for YC Winter 2022

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact