MPW, Carbon and building Classic Mac OS apps in OS X
Jan 13, 2016.SSH – SSH might be the single most important feature. Interact with your cluster from any machine (Mac OS, Raspberry PI, Windows, smart phones, tablets). You are not required to use an SDK to submit a job. With your SSH connection, you can establish multiple sessions (for a single user), or have a multi-user collaborative session.
- Jan 09, 2020 Either way, Win kicked Mac in the networking jimmies, really, really hard, and Mac would not do any different until OS X. Back when Mac OS 8 was released, Apple took out a two page magazine ad to.
- Find 9 ways to say HINDSIGHT, along with antonyms, related words, and example sentences at Thesaurus.com, the world's most trusted free thesaurus.
- Nov 12, 2020 Rebuild the Spotlight index on your Mac. If you get unexpected results when searching your Mac, rebuilding the Spotlight index might help.
- Experience a giant leap in performance with the all-new, 13-inch MacBook Air. Designed with the new M1 chip that is also found in the 13-inch MacBook Pro and Mac mini, this laptop delivers exceptional performance, custom.
MPW
In 2014 I came across a project on Github described as 'Macintosh Programmer's Workshop (mpw) compatibility layer'.
There has never been a good way to compile Classic Mac OS apps on modern OS X — for the most part, you were stuck using ancient tools, either Apple's MPW or CodeWarrior, running in a VM of some sort. CodeWarrior, of course, is not free, and MPW only runs on Classic Mac OS, which is unstable at the best of times and downright nightmarish when trying to use it for development in an emulator like SheepShaver.
Enter ‘mpw' (which I will refer to in lowercase throughout as something distinct from Apple's MPW toolset).
mpw is an m68k binary translator/emulator whose sole purpose is to try and emulate enough of Classic Mac OS to run MPW's own tools directly on OS X. MPW is unique in that it provided a shell and set of commandline tools on Classic Mac OS (an OS which itself has no notion of shells or commandlines) — this makes it particularly suited to an emulation process like mpw attempts to provide, as emulating a commandline app is a lot easier than one built for UI.
At the time I came across the project, the author himself had never attempted using mpw to build a Classic MacOS app — only commandline tools and Apple II-related stuff. Naturally, building a UI app was the first thing I'd try.
The Experiment
I started off by writing code just to see how well mpw emulated the MPW compilers, and over time managed to write a working shim of an app that could run on System 1.1g. This in itself was a learning process, not only in code but in piecing together the build process. All the sample code and documentation of the time was in Pascal, so I had to translate that to C — not so difficult, it turns out (technically, first I had to transcribe it from a PDF…).
Eventually I had something that worked, built a few sample projects, uploaded some to Github and left the classic Mac stuff for a while.
More recently, towards the end of 2014, mpw added support for the PowerPC tools, so I immediately set out to update my build processes to support that — a trivial effort.
However, now that it was possible, I really wanted to try Carbonization.
Why Carbon?
I vaguely knew what Carbon was from having lived through the OS 9 -> OS X transition, and that knowledge came with a certain amount of bias. 'Carbon is that thing that badly ported OS 9 apps used, right?' It always felt 'off' in OS X, in the same way that cross-platform UI toolkits invariably feel off.
I knew I wanted to understand the process better, however, and see what would be involved in porting my sample projects to Carbon (and thusly, OS X). I read some books, and set to work. Ouroboros (itch) (raccoon_js) mac os.
The actual porting process didn't take much time at all, and for the most part I ended up with fewer lines of code than where I started. Most of the changes involved #ifdef-ing out lines of code that weren't necessary anymore, and changing anything that directly accessed system structs to using accessor functions — a trivial amount of work (for an admittedly trivial set of projects). Super cardboard box raiser mac os.
What interested me the most is how so much of the API remained identical — I was still using only functions that existed on System 1.0 in my app, but they were working just the same as ever in a Carbonized version. The single built binary ran on OS 8.1 all the way to 10.6 (care of Rosetta).
My mind wandered to Carbon as it exists in 10.10. While Apple decided not to port it to 64-bit (for all the right reasons), the 32-bit version of Carbon is still here in the latest release of OS X — I wondered how much of it was intact.
Turns out the answer is: all of it.
The only change I had to make was to point my header includes at the right place, but after that the whole app came to life exactly as it did on Classic Mac OS.
With the same source file, and only a handful of #ifdefs, I could build the same app for 1984's System 1.0 all the way up to the current release of OS X, Yosemite.
The Sample Project
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
Carbon, redux
The more I dug into it, the more I came to the conclusion that Carbon was probably one of the most important things Apple did in building OS X. Even today it provides source compatibility for a huge chunk of the classic Mac OS software base. It kept the big companies from ditching Apple outright when they were needed the most, and gave them a huge runway — 16 years to port perhaps millions of lines of code to OS X while still being able to iterate and improve without spending thousands of man-years upfront starting from scratch. Over time, of course, Carbon has improved a lot and you can mix/match Carbon & Cocoa views/code to the point where you can't realistically tell which is which. I appreciate what a monumental effort Carbon was, from a technical standpoint. That Cocoa apps always felt 'better' is more to Cocoa's credit than Carbon being a bad thing — it's a lot easier to see that in hindsight.
Final Thoughts
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).
I have used this toolset to build all kinds of things, including fun ports of my own apps. I'm sure I'll be coming back to it for a long time to come.
I'm hoping I'm not the only person who'll ever get to use it 🙂
Misc Gotchas
I ran into a few things along the way that are worth noting, mostly because information about them either doesn't exist or is difficult to find on the web — check BitPaint's makefile for context on any of these:
Pascal Strings
You want to tell clang to enable Pascal-style strings (-fpascal-strings).
-mmacosx-version-min=10.4
If you specify -mmacosx-version-min=10.4, your Intel binary will work all the way back to 10.4, otherwise it will crash on launch trying to use invalid instructions.
PICTv1
Systems 1–6 support only one picture format for resources, and that's PICTv1. Helpfully, it seems like nothing on Earth supports the creation of PICTv1 files anymore, so I wrote a very suboptimal one (but it works well): https://github.com/steventroughtonsmith/image2pict1
OS X Packages
When you package a Carbon binary into a .app folder structure, as necessary for OS X, you'll find it won't be able to find its resource fork anymore, despite the fact that running it from the commandline will work fine. Instead, you can put the resource fork into a data file inside the bundle's Resources folder and it will work as expected.
'SIZE'
If you accidentally your SIZE resource, your app will launch on OS X but appear to hang, unresponsive, in the background. I ran into this more than once.
'carb'
From what I can tell, including a 'carb' resource in your binary will stop it from launching on System-7.x, but be fine on System 1–6 and 8–9.2.2. Not sure if this is an MPW problem or a me problem, but I lost quite a bit of time to 'This version of MPW is not compatible with your system' alerts from my apps before realizing this.
Packaging!
Those who knew Classic Mac OS will be well accustomed to type/creator codes and resource forks; those who did not will be absolutely baffled by trying to figure out why they can't open their files/disk images/binaries. I run SetFile on my disk images after creation so that DiskCopy will be able to see/open them, and I binhex encode the disk images so I can safely transfer them to a real Mac using Internet Explorer without losing the resource fork. Neither Samba (as used in VMWare's Shared Folders) or FAT32 support resource forks, so they will get stripped and render your files unusable. SheepShaver's external folder support does indeed support resource forks, so you're totally fine there.
Rez
MPW includes a version of the Rez tool (which compiles your resource forks for you), but currently mpw is unable to emulate it successfully. Fortunately, Xcode still ships with Rez and today's Rez seems almost unchanged from the version included with MPW all those years ago. Pass it the Classic Mac OS set of includes and it's happy to spit out resource forks compatible with System 1.0.
Editor's Note: Our ongoing preview of the announced features in OS X 10.5 continues, with this profile of Leopard's enhanced support for 64-bit computing.
Full 64-bit support got top billing in Steve Jobs' Worldwide Developers Conference keynote —it was first on the list of Leopard enhancements he previewed, ahead even of Apple's striking Time Machine backup-and-restore technology. Even at a developer conference, however, 64-bit support was an odd choice for the lead-off position, because it's an option even Apple admits doesn't yet make sense for most applications.
How it works
If you're writing an application that requires truly huge amounts of memory (more than 4GB) or needs random access within data sets larger than 2GB (as opposed to, for example, video-editing apps that read and write very large files but work with only a subset at any one time), it's convenient to deal with 64 bits of data at time, rather than the 32-bit chunks that most of today's Mac (and Windows) applications use. Apple has for years offered developers some ways to work with 64-bit data, but those involved working around the fact that the Mac OS and most of the hardware it ran on were basically a 32-bit environment
In Hindsight Mac Os Catalina
In recent years, however, the company has gradually added some direct 64-bit support to its products: the PowerPC G5 processor, for example, was designed to handle 64-as well as 32-bit code, and Mac OS X 10.4 (Tiger) allows developers to create fully 64-bit command-line or background applications, though not 64-bit programs with their own graphical interface.
What's changed
Sammy the snake mac os. Things will be different in Leopard: Developers can now build full-fledged Mac apps that are 64-bit-capable. But developers converting existing Mac programs will face a fair bit of work. Not only their own code, but every library, framework, and plug-in their programs use will have to be modified and recompiled.
Even then, there's not always a clear-cut case to move to 64 bits. First, 64-bit code will work only on G5 or Core 2 processors—developers will still have to deliver 32-bit versions for users with Macs based on G3 and G4 PowerPCs or even with Intel's first-generation Core Duo and Core Solo CPUs (in other words, the current MacBook, MacBook Pro, iMac and Mac mini product lines).
Second, some 64-bit programs will actually perform more slowly than 32-bit equivalents, particularly on G5 Macs. Although most applications are likely to pick up some performance by going 64-bit, the benefits are not likely to be overwhelming, even on the new Mac Pro and future models with Core 2 processors. The main problem is that going from 32- to 64-bits results in inflated code, which means less of it fits in the processor's L1 and L2 caches, and more relatively slow calls to memory are required.
Who's it for
Developers of certain types of programs that work with huge amounts of data—some scientific computing applications, large database and data-mining systems, large-scale CAD/CAM apps, and specialized image processing programs, to name a few—will appreciate Leopard's full, native support for 64-bit computing, especially if they are creating new applications from scratch and if they are targeting only future Core 2 CPUs, leaving PowerPC and first-generation Core users behind.
Mac Os Mojave
What it means
How it works
If you're writing an application that requires truly huge amounts of memory (more than 4GB) or needs random access within data sets larger than 2GB (as opposed to, for example, video-editing apps that read and write very large files but work with only a subset at any one time), it's convenient to deal with 64 bits of data at time, rather than the 32-bit chunks that most of today's Mac (and Windows) applications use. Apple has for years offered developers some ways to work with 64-bit data, but those involved working around the fact that the Mac OS and most of the hardware it ran on were basically a 32-bit environment
In Hindsight Mac Os Catalina
In recent years, however, the company has gradually added some direct 64-bit support to its products: the PowerPC G5 processor, for example, was designed to handle 64-as well as 32-bit code, and Mac OS X 10.4 (Tiger) allows developers to create fully 64-bit command-line or background applications, though not 64-bit programs with their own graphical interface.
What's changed
Sammy the snake mac os. Things will be different in Leopard: Developers can now build full-fledged Mac apps that are 64-bit-capable. But developers converting existing Mac programs will face a fair bit of work. Not only their own code, but every library, framework, and plug-in their programs use will have to be modified and recompiled.
Even then, there's not always a clear-cut case to move to 64 bits. First, 64-bit code will work only on G5 or Core 2 processors—developers will still have to deliver 32-bit versions for users with Macs based on G3 and G4 PowerPCs or even with Intel's first-generation Core Duo and Core Solo CPUs (in other words, the current MacBook, MacBook Pro, iMac and Mac mini product lines).
Second, some 64-bit programs will actually perform more slowly than 32-bit equivalents, particularly on G5 Macs. Although most applications are likely to pick up some performance by going 64-bit, the benefits are not likely to be overwhelming, even on the new Mac Pro and future models with Core 2 processors. The main problem is that going from 32- to 64-bits results in inflated code, which means less of it fits in the processor's L1 and L2 caches, and more relatively slow calls to memory are required.
Who's it for
Developers of certain types of programs that work with huge amounts of data—some scientific computing applications, large database and data-mining systems, large-scale CAD/CAM apps, and specialized image processing programs, to name a few—will appreciate Leopard's full, native support for 64-bit computing, especially if they are creating new applications from scratch and if they are targeting only future Core 2 CPUs, leaving PowerPC and first-generation Core users behind.
Mac Os Mojave
What it means
In Hindsight Mac Os 11
In a decade or two, 32-bit computing may only be a distant memory, and the Mac OS (or whatever succeeds it) and the hardware it runs on will be fully optimized for 64-bit operation. By then, in hindsight, the addition of 64-bit application support in Leopard will look like a milestone on an important evolutionary path. But in the near term, it's mostly of interest to developers of specialized technical applications. For most Mac fans—even graphics professionals and other power users—this is one leap forward that's not likely to produce much of a splash when Leopard is unleashed next spring.
Mac Os Versions
[ Henry Norr is a former editor of MacWeek and a former technology columnist for the San Francisco Chronicle .]
