Steven Troughton-Smith:
Just to provide an example for this post, I put together a trivial drawing app called BitPaint. It isn’t very interesting, but it should illustrate a few things:
- What’s involved in bringing a trivial classic Mac app to Carbon
- How the Classic Mac OS build process works
- How much source compatibility exists between 1984’s Toolbox and Carbon today
The answer to the third question is surprising: a lot. In fact, Steven managed to build an application that runs on every version of Mac OS/OS X, all the way from System 1.0 to today’s OS X 10.10 Yosemite. I’ve been following Steven’s progress (and by following I mean ‘looked at pretty screenshots’ because I don’t understand the developer stuff), and it’s quite incredible to see a single codebase run on such a long string of Mac OS/OS X releases.
A crucial aspect in this whole endeavour has been mpw, “an m68k binary translator/emulator whose sole purpose is to try and emulate enough of Classic Mac OS to run MPW‘s [note the caps!] own tools directly on OS X”.
I am incredibly psyched about mpw. Its developer, ksherlock, has been very responsive to everything I’ve come up against as I stress test it against various tools and projects.
Right now it’s a fully usable tool that makes Classic Mac OS compilation possible and easy to do on modern versions of OS X, without requiring emulators or ancient IDEs or the like. To my knowledge, this is the first time this has been possible (excluding legacy versions of CodeWarrior).
This entire post is a must-read.
I’m all for this as a hobby project, but there’s no reason to produce Classic code except for the fun of doing it, and nothing involving OS X has ever been much fun.
Nothing I used to like about Apple has survived. I prefer to remember them the way they were rather than constantly be reminded of what they became.
I pretty much agree. Have to add that very little of NeXTStep has survived. IMO, NeXT was probably the high water mark of operating systems. UI wise, I still prefer OS 9 to OSX. With Mavericks, the UI was nice a clean, but was beaten with an ugly stick with Yosemite.
Performance wise, it has been a giant down hill slide.
Development wise, it was so clean a simple to make an app in NeXTStep project center, Xcode has just become so bloated and convoluted. I so detest this iOS-ification of OSX.
Just to be clear, this is about getting a single piece of source, with a pile of #ifdef’s, to compile and execute across releases.
It would still require a minimum of three binaries to span that time:
1. A 68k classic app for System 1-7 (carbonlib not present)
2. A ppc carbonized app for OS 8.1-10.4
3. An intel carbonized app for 10.4-current
Generally I haven’t found it hard to achieve version portability with #ifdef on any major platform. Binary compatibility is much less consistent.
Windows used to be an exception, but with Vista and up, my thunked 16 bit apps no longer worked, and a lot of compliant win32 apps from the late 90s effectively died in terms of binary compatibility.
I think mostly it’s “good riddance”, but it’s kinda nice to see my 1986 games still work in dosbox :p
Edited 2015-01-25 11:30 UTC
DOSBox is definitely the way to go for 16-bit stuff. It also has the benefit of not requiring Windows at all.
Four: PowerPC classic Mac, and PowerPC OS X are two different things. But I guess if the thing is a 68000 emulator/translator, it might just JIT to either x86 or PowerPC.
One of the advantages of Carbon is that a single binary can run across OS 8.1 through OS X. A shared library called CarbonLib performed the translation on OS 8.1-9.2 back to classic.
No, OS X PowerPC will either run Carbonised PEF or Mac OS X native exe files. Quite happily too.
While that is technically true at the compile level, it could be achieved in a single binary as the m68k slice is purely in the resource fork. PowerPC/Intel Universal OS X binary with an m68k slice would, in theory, run on everything from 1.0 to 10.10
I once wrote a terminal based version of tetris that used escape sequences to draw the squares with braces ‘[]’. I think I did this on a Dec Ultrix machine c. 1992.
Recently I found this code, kicked out to a command line and tried ‘cc testris.c’ as I had over 20 years ago. Sadly, no, it didn’t compile, but there were only a few minor changes required having to do with tightening up of the c standard – and bam! I had my a.out and could play a really crappy game of terminal based tetris.
I thought that was a rather amazing level of source code compatibility. Though granted this code uses almost zero serious system interfaces, and those are mostly related to terminal I/O, which hasn’t changed much in the last 20 years.
On a side note, running the 32-bit intel binary on my Yosemite Macbook Retina i5 spikes the CPU up to 94% and really makes the fan blow :/
Absolutely – Classic Mac OS apps were designed to take 100% of your CPU time (as for the first 6 releases there was no multitasking).
There are a bunch of things you’re supposed to do to be a good OS X citizen (i.e. not steal all the CPU for yourself), but the samples in the post don’t do that.
I maintain a codebase that has lived on various incarnations of the Mac since about 1988 and that is kept, for the largest part, backwards compatible. It’s a vertical market thing where, back in the days, people wanted to be super progressive with one of those new-fangled graphical interfaces. Windows was an insult back then, OS/2 a “WTF?” also-ran and Atari screwed it up themselves.
The Mac serves as frontend for rather big devices that are, let’s say, somewhat timeless, and thousands of them have been distributed around the world. How many still chug along with a IIci next to them, no one knows (though they should!). These days they ship Mac Minis. Some active installations still run the Classic version in 10.4, but lack of an interface device probably requires these to be lifted to native OSX.
I find the latest XCode 3.2(.6) on 10.6 to be well suited for targeting the PPC 10.4 to x86 10.9 span. I’ve read about hacks to get the 10.4u SDK and ppc-gcc into later XCodes, but for now we’d like to stick to a straight install.
For the Classic stuff we’ve first kept a G3 (Pismo) and then a G4 (Antimony) Powerbook with CodeWarrior Pro 5.3. It’s surprising how well one can still work with that – except for the regular reboots during debugging
. So far it’s been only used to port forward, but if hell breaks lose we’d be able to update the oldest systems out there.
Should that ever be needed, this new “mpw” (lower case) would be really nifty, because it could go into our automated build system!