Compiling a Mac OS 8 Application on MacOS Sierra | Hacker News Reader

Compiling a Mac OS 8 Application on MacOS Sierra

cocoawithlove.com

139 pointsingve44 comments

Having been at Metrowerks during the launch of Project Builder, I can say that it wasn't just Motorola bungling things. Apple poached a lot of MW's talent and was trying to build a CodeWarrior-killer. They hated being reliant on an external company to make the best dev tools for their platform and actively worked to make CodeWarrior irrelevant. Motorola's interest in the tools was both for Mac support (as long as they used 68K and PPCs) but also to improve their embedded toolchains, and once they saw that desktop market dry up, all efforts were moved into the embedded space.

Agreed, I think the writing was on the wall for CodeWarrior from the day OS X came out.

Apple was vendor-neutral regarding development tools for the entire classic Mac era: yes they sold MPW, but Universal Interfaces, SDKs, documentation were all distributed separately. It was a level playing field for Apple, Lightspeed/Symantec, Metrowerks, and even Microsoft to compete and sell development environments (IDE, compiler, libraries).

But of course this all changed with OS X. The entire Mach-O world was just not intended to be targeted by anyone else's environment (each CodeWarrior release from that era is basically tied to a specific OS X version for Mach-O development because of header/library changes between versions). Objective-C was Apple's language, being evolved without any standards body. Cocoa was a fantastic framework, taking away much of the need for PowerPlant. And unlike the 68k->PPC transition, Apple didn't give tools vendors a heads-up on the PPC->Intel transition.

Although I miss Metrowerks and a competitive market, I think it's outweighed greatly by the benefits of having the best dev tools be free, something that was unheard of 15 years ago. I sometimes wonder if the software landscape on the classic Mac would have been different if the best dev environment (THINK C, later CodeWarrior) had been free. (although Metrowerks put a lot of effort here too: I remember CodeWarriorU, and also the Discover Programming Edition which was a full-featured 68k CodeWarrior + extra documentation for $100)

> Apple didn't give tools vendors a heads-up on the PPC->Intel transition.

In ~2005, were any of the third-party Mac dev tools vendors in a position to make good use of the heads-up? Who was good enough at staying current in the late PPC days that they could have spared resources to bring up an x86 toolchain as well?

Metrowerks/Code Warrior had an x86 compiler in the late 90s. CodeWarrior was the BeOS PPC compiler and it was also used for the x86 R3 release (1998). For R4, they switched to GCC 2.9 (and from PE to ELF) because it generated better code (perhaps there were financial and other considerations as well).

Be paid Cygnus for the gcc port, shortly before red hat bought up Cygnus.

Hey ben, those were fun days! For others, Metrowerks hit the wall that many Mac developers hit and continue to hit. The Mac market size simply isn't big enough for a 3rd party developer, so they tried other platforms. As Metrowerks tried many embedded markets, the Mac product suffered. Also, since only Metrowerks had a PowerPC compiler, Apple was very dependent on Metrowerks while Metrowerks was heading towards Chapter 11. The tension between the execs (give me more money/support or else) created a 'complicated' relationship.

Motorola rescued Metrowerks from the brink of Chapter 11 with the Apple/Metrowerks relationship already tense. Motorola also gave many long-time employees an excuse to leave (pre dotcom crash). PalmOS took so many people that lawyers were involved at the HR level between Motorola/PalmOS

BTW, Metrowerks was originally founded as "Metropolis Computer Networks" by Greg Galanos in 1985.

Metrowerks, like Borland, were a product of their time and suffered badly when those times changed.

Both made fantastic third-party compiler suites and both saw a tremendous amount of success because of that. Then the operating system vendors started to re-focus around building a first-class compiler environment for their developer base and it got very hard to compete.

Borland got ground down by Microsoft Visual Studio while Visual Basic killed any hope of Delphi taking over. Metroerks slid largely because of Apple's Xcode.

It's a shame that Borland and Metrowerks tanked like that, they did add their own flavor to the development world, but it's also a good thing. Back in the 1990s being a developer meant forking out hundreds if not thousands of dollars for good tools. The barrier to entry was awfully steep. Since that made app developers a rare breed, finding developer support was a lot harder.

Today anyone with a computer has access to top-quality tools without having to spend a dime more, and they're also able to access a knowledgable developer community that's easily engaged to help solve problems, provide advice, and recommend strategies.

When using Metrowerks you were on your own. If the book you had didn't solve the problem you could try your luck on USENET or a mailing list, but that would only work with the most trivial of problems.

Apple had a better track record of supporting third party compilers than Microsoft did BTW.

For fun, from http://www.nynaeve.net/?p=105 :

"This layering violation is not the most egregious in the x64 exception handling scene, however."

Fun fact: the US Social Security Administration still maintains and distributes a Mac PowerPlant app, built with CodeWarrior as a PPC binary (which of course doesn't work on 10.7+)!

https://www.ssa.gov/OACT/anypia/anypia.html

I ported it to Xcode, keep the code on GitHub, and maintain an Intel build. Haven't been able to get the attention of anyone at the SSA though.

http://bslabs.net/2015/07/18/porting-anypia-to-xcodeintel/

Looks like your screenshot links got broken in the second part of your series (maybe since they're TIFF they won't display inline on Windows Chrome?). I'd love to read the rest of the series when you write it, as well!

Thanks for the tip, 10.4 takes screenshots as TIFF (unless you use Grab.app) and didn't realize Chrome won't show them. Unfortunately I don't think I'll finish out the series with quite that many separate posts, but I want to do at least one more to finish it out and get the screenshots up.

That was a fun read. Just until recently, I also worked on a code base that originated in Think C/68k, albeit in the order of several hundred thousand lines of code. It was quite the effort when I had to take it through Apple's transitions, porting it to OS X/Carbon/Codewarrior, then to Xcode/gcc/UTF-8, then to Intel, finally lifting the whole thing to Cocoa/64 bit/clang. We even had prototypes on iOS.

The Windows version remained largely unchanged despite being ported to Unicode and 64 bits. Microsoft is doing a crazy good job at keeping APIs alive.

I remember those days, thinking to myself "why would anyone actually choose to use this junk of an OS, let alone actually develop for it", because: Think C/Metrowerks Codewarrior.

But now I sit here wrestling with merging Storyboards in Xcode and casting a green eye at my friends, doing React apps, in the background.

I sure do miss the simpler days, before all these great tools got in the way. You know, coding for X and POSIX .. /ducks.

The library computers all had Fetch (a disk-eating koala and FTP client

I can't tell if that's meant to be a joke or if the guy had never seen a dog before.

Yeah, seriously. Fetch's icon is a dog with a disk in its mouth.

Considering that later in the same sentence, he says, "Mosaic (a program written at the Andreessen Center for Supercomputing Champagne", I'm going to say dry humor.

It does look quite a lot like a koala.

Of course it's a dog...if you know up front that it's a dog. I take it as a dig about the "dogginess" of the icon. At the resolution of the time, hell, could be a koala for all I know.

That looks so much like a Koala to me.

This is a great story and it brought back a lot of classic Mac OS nostalgia for me.

Metrowerks for Mac may be nostalgia. Metrowerks for PalmOS was like trying to breed a duck with a platypus. I mean, they're both using Motorola 68K, so it should work...

The PalmOS API was heavily inspired by classic Mac OS. The similarities are striking -- a lot of the system traps even had the same names across both platforms.

I was the tech lead on CodeWarrior for Palm OS v7, v8, and v9... it was quite a mishmash, and the Windows version was a really big hack on a hack. I ended up rewriting the whole 68K toolchain and linker for the v9 version, but that ended up making something that we couldn't economically justify porting back to Mac OS (it was 2003, Macs weren't doing so well).

Since the Palm had a very screwy approach to memory in general, your team did a fine job.

I still have all my Sony Magic Cap [1] stuff which came out around CodeWarrior 6 I think. Some type of Metrowerks MPW environment and a software emulator which crashed if you breathed on it!

[1] https://en.wikipedia.org/wiki/Magic_Cap

Great article. I have a Carbon/Powerplant app that I stopped developing that I would live to get it working again. Perhaps this will help.

CodeWarrior is readily available from abandonware sites, and can be used inside 10.5/10.6 on VMware Fusion if you don't have any PPC hardware around. Older versions of Xcode (2.x) can then import CW projects, you can swap in open-powerplant, and do an Intel build. Let me know if you want any help/advice

This is actually what I was trying! Perhaps I can dump this all into a GitHub repo and we could collaborate. E-Mail in my profile if you are interested.

That wouldn't happen to be Pepper would it?

Indeed it would be. I had stopped with it when 10.7 came out, just continuing the Windows and Linux version.

You can still find Metrowerks macros and macro checks in parts of Darwin/XNU (like the Mach-O loader). It's pretty interesting to see how the development options of the time have shaped the kernel and userspace's code, even today.

I grew up on the opposite side of the Classic Mac learning-C++ camp. I had a copy of MPW, and a trial version of CodeWarrior from some CD in the front of a "...For Dummies" book I had checked out from the library. I was SO jealous of the people who got to use the professional version of CodeWarrior! They were obviously real programmers, and I was not, because my development environment was free and theirs was not.

Although at the time the extent of my C programming didn't go past a couple of XCMDs to make my HyperCard stacks more app-like, I had the same CodeWarrier complex...

Oh ResEdit, you were so much fun.

If you had a few bucks lying around at the time there was Resourcerer..

ResEdit was an incredibly cool tool, with a surprisingly good (and intuitive!) interface for what was clearly a developer tool. I started using it to poke around in games when I was around 9 years old -- admittedly I didn't understand everything I saw, but there was still a lot of interesting stuff to see.

ResEdit was one of the things that got me hooked on programming because it was (1) so accessible and (2) could be used on real executables.

A few months after discovering it, I had jammed little hand drawn icons onto the menu items of damn near every application on my tiny hard drive. It was awesome.

This, this, this!

I bet there's a whole slew of us who spent countless hours inspecting everything, trying to take it all apart... that formed the developers we are today.

Same here. Me and my friends would take shareware games and edit all of the text, graphic and audio resources to essentially make our own games.

>> By 1998, Think C 5 was woefully outdated

In school back in 1997 we were using Think C 3 or 4 on Mac LC II's, talk about a terrible environment for programming C

In Romania they are still using Borland C++ 3.1 for DOS, released in 1992 to teach programming.

StackOverflow has a lot of questions relating to bgi.h and conio.h, I wouldn't be surprised if other countries are still using it as well

A lot of programming courses in India still use course materials which rely on Turbo C++. It's really unfortunate -- means that students are learning "C++" without access to the STL.

Fun fact: the concept of handles that this article talks about is almost exactly the same as Windows 1.0's concept of handles. See for example https://blogs.msdn.microsoft.com/oldnewthing/20041104-00/?p=...

Reply on news.ycombinator.com