Hacker News new | past | comments | ask | show | jobs | submit login
Emulate Mac OS 9 with QEMU (jamesbadger.ca)
166 points by arm on Dec 2, 2018 | hide | past | favorite | 64 comments

The magazine archives linked from the article really take me back. I like how colorful they are. I like the weird studio photography they would do with a bunch of hardware on weird pedestals.



This was how we knew what Apple was doing, how to keep computers running, etc.

There are some things I really miss about the classic Mac era. Computers were cool. The entire experience of using a computer was very consistent. Poking around in MacsBug or ResEdit was interesting. Install an app by dragging it to your hard drive, uninstall it by dragging it to the trash. Word 5.1a, a.k.a. the best version of Microsoft Word ever made. Still waiting for Google Docs to catch up in terms of feature parity, it’s not even close.

Plenty of things I don’t miss. No memory protection. Cooperative multitasking. Open Transport. As much as Unix is a bit of a mess, it doesn’t have any of these problems.

The only reason I still go back is for the games. A few of the old games can be played on new computers—if it ever got a PC port, there’s a chance you can run it in DOSBox, but the Mac exclusives got left behind, and a bunch of them were just cute little shareware pieces that never had a bunch of money behind them.

> As much as Unix is a bit of a mess, it doesn’t have any of these problems.

Unix was an option, even back then. An expensive option, sure, but you could even run it on some types of Mac:


Actually A/UX was a pretty amazing operating system. The GUI of a Macintosh with the underpinnings of UNIX. Just like OS X - only in 1988!

I always wondered why Apple didn't consider A/UX for the base of its future OS, rather than spending 5+ years on the obviously-in-retrospect-doomed Copland/Taligent stuff and then buying NeXT. Unix licensing costs maybe?

> Unix licensing costs maybe?

Unix licensing costs almost definitely.

A/UX was forked from UNIX System V Release 2.2, with "additional features from System V Releases 3 and 4 and BSD versions 4.2 and 4.3". It also had a TCP/IP stack, since before MacTCP (if I recall correctly).

I don't have any direct knowledge of Apple's licensing issues with AT&T, but I worked for SCO in the early 90s, back when it was a UNIX OEM, not a litigation zombie.

AT&T licensing fees for UNIX back in the late 80s/early 90s were fiendish; that's the whole reason for the ascendancy of Linux today. (Linus couldn't afford his own Intel UNIX shrinkwrap, so he began rolling his own kernel.) I heard a ballpark figure that SCO paid out $200 in royalties every time they sold a copy of Open Desktop 3.0, which included royalties on SVR3.2, a third-party TCP/IP stack, X11 (which was free), and OSF Motif (which wasn't) and IXI's X Desktop (the desktop and utility apps build with Motif/X11). This drove the price of a copy of ODT 3 up to the $1000-2000 mark depending on trim. SCO also paid royalties to Microsoft every time we sold the developer tools, because SCO had inherited the MS C compiler by way of their Xenix license in the late 80s, and SCO SVR3.2 was built using MS C.

The AU/X "additional" features from SVR 3 and SVR 4 was probably the result of a similar process to SCO's cloning of SVR4 features in the early 90s. SCO's UNIX license only covered SVR3.2. AT&T jacked their license prices for SVR 4 so much that going to true SRV 4 would have drastically raised the price of Open Desktop. It worked out cheaper to assign a couple of hundred developers to work for 3-4 years at cloning SVR 4.3 (needed to hit the standards compliance checkboxes required by customers), while keeping the AT&T SVR3.2 copyright declarations in the header files (and on the box).

My guess would be that Apple hit the same wall that SCO hit after 1995; AT&T licenses were too expensive and cloning features and bolting them on top of an ancient code base was also becoming expensive. (As I remember it, SCO bought a license for SVR 4.3 in the end and switched to that, some time in the mid-to-late 90s, too late to dodge the bullet of Linux gobbling up the Intel/Posix world.)

My take is that Apple didn’t just need a good kernel and a good UI, but a good API for making applications. NeXT had the whole Objective-C API which was, well, a lot easier to use than contemporary alternatives. It also had tools like Project Builder and Interface Builder. The only other OS people thought Apple would buy was BeOS.

It took a long time for Mac developers to really buy into Cocoa, many of them saw it as a less-capable version of existing APIs rather than the future of Mac development. That viewpoint wasn’t entirely without reason, at first, but the longer you spent with Cocoa, the more clear it became that Carbon was a second-class citizen.

My other thought is that Apple didn’t just want tech, but the experience to develop it. That’s why acquisitions were at the top of the list. Apple has certainly bought a few other companies just to access their engineering talent.

I think also retooling build systems to work with XCode took a while to do, or at least be worthwhile to do - especially if you're shipping a multi-platform beast like anything from Adobe. If I remember, the only real way to ship a Cocoa app was with Xcode.

I have ported applications to Mac OS X, including applications that other people wrote and ones that I wrote. Let's say that you're starting with a C or C++ application using the Macintosh Toolbox APIs, built with MPW or CodeWarrior. A common path is:

1. Switch to using the Carbon API, and create a "carbonized" application that works on both Mac OS 9 and Mac OS X (same executable for both platforms, basically a special executable format and some restrictions on how you used various APIs)

2. Once you don't care about Mac OS 9 support, migrate to Project Builder (or at least GCC)

3. Eventually, migrate to Cocoa

The path was set up so that you could stop at any point along the way and keep shipping your application. In my personal experience, steps #1 and #3 could be difficult and labor-intensive, but step #2 was usually easy.

My understanding is that Quark got stuck and took too long to complete step #1, long enough that their customers didn't want to keep Mac OS 9 around just so they could use QuarkXPress and switched to InDesign.

Step #2 mostly involved fixing the parts of your code which used weird, non-standard C extensions that GCC did not support. Things like:

    (long)*ptr = x;
Adobe got stuck on #3, which is understandable because it's an enormous amount of work with a relatively low payoff. The main drawback of not completing step #3 is that you're stuck with a 32-bit application until you complete it.

Xcode came later, it was Project Builder and Interface Builder. The NeXT tooling was amazing at the time.

> My take is that Apple didn’t just need a good kernel and a good UI, but a good API for making applications.

That's hard to side with, when preemptive multitasking and protected memory wasn't a thing in Classic Mac OS. Those were some big sticking points when trying to Get Shit Done on a Mac, especially in the late nineties.

I agree Cocoa was amazing tech, but I don't see the sluggish migration from Carbon being because people didn't buy into it. I think it's more that Carbon worked, and there's just other things to put the expensive engineer's time to good us on.

> I agree Cocoa was amazing tech, but I don't see the sluggish migration from Carbon being because people didn't buy into it. I think it's more that Carbon worked, and there's just other things to put the expensive engineer's time to good us on.

My experience with the Mac developer community at the time was that someone new would come to the mailing lists and ask whether they should use Cocoa or Carbon for developing. These are people who don't have any legacy code and don't have a bunch of skills they've built up, working on greenfield projects.

A common response was along the lines of, "Carbon is a Serious API for developing Serious Applications, and Cocoa is a kids tool for making toys."

NeXT failed because of its hardware strategy/cost of manufacturing, and very high hardware sales price which kept away 95% of the potential customers. By the time they were "done" with making hardware and ready to be acquired, NeXT's OS was quite solid and stable, representing a good base to develop MacOS 10.0 from. If you take a look at MacOS 10.0 server, the first release, it's incredibly close to NeXT.

They probably looked at projects like FreeBSD at the time (1997-2000 era) and decided that too much time would be required to re-implement what they wanted to do, vs buying NeXT.



You're partially correct... NeXT's refusal to fully implement Posix is what locked them out of many government contracts, as it was and may still be a requirement.

Only the NSA was exempt from this requirement, and they did buy a lot of NeXT's equipment.

Which is actually something that many that use OS X as pretty UNIX don't get.

NeXT was never about UNIX, the compatibility that it had was just to ease the porting into the platform, not to get away from it.

The Objective-C APIs were what mattered.

Likewise when it was reborn as OS X.

I attended an Apple session at CERN during the early OS X days, with the same idea being transmitted.

It's funny that you mention FreeBSD, because large portions of FreeBSD were incorporated into Mac OS X. If you look through the Mac OS X man pages you'll find references to various BSDs, mostly BSD and FreeBSD.

Of course, but not to the extent that they took a freebsd base (vs NeXT) and put an osx GUI on top of it. When I first used osx from a command line at v10.4 and saw macports, the freebsd heritage was obvious.

A/UX used the 68k microprocessors and would have needed to be ported to the PPC chip to be viable. A number of us A/UX hard-core fans really pushed Apple to do so, but instead, Apple decided to drop A/UX in favor of some sort of combined effort with IBM and their AIX system (which never panned out).

Do any hard-core A/UX fans happen to have a copy of the A/UX Device Drivers Kit, or the Building A/UX Device Drivers manual?

AmbrosiaSW was a successful business for over a decade off of games. Most of them hold up very well.

Their office was just down the street from me. It closed sometime last year although their website still seems to be active. From what I understand the company may just be Andrew Welch at this point.

It still hurts me that I no longer have access to the email address I used to buy the Escape Velocity series. One day I'll have to suck it up and repurchase them...

Unfortunately if you look around at Reddit and such it appears that they no longer actually sell liscenses, you need to badger the one remaining employee for a code, etc.

That's a shame. I actually reached out to them asking if there was any way to look up my license by name and they said no.

At this point, what would be the downside to open-sourcing the original code and putting it under GPL 3? Why hold onto IP that you aren't making any money off of?

A lot of it probably comes down to IP. A lot of their games contained graphical or sound (especially sound) assets that they licensed from outside sources; relicensing those to GPL would be impossible.

Additionally, some of the games distributed by Ambrosia were written partially or entirely by outside developers. It's not clear if Ambrosia even had the source to all of their games, let alone the rights to relicense it.

In that case I would say the same recursively to all of the different vendors and contractors involved, but that quickly becomes a much more complicated problem than someone just dumping the source online.

Yep, and it's massively complicated by the age of the software. Most of Ambrosia's catalog was released in the 90s -- most of the consulting groups involved have probably long since been acquired or dissolved, any contact information Ambrosia had for the developers is probably stale, and some of the developers may no longer even be alive to grant permission.

I don't think that any one person or group has all of the IP and they can't be persuaded to communicate enough to release it. I get the sense that it was pretty freewheeling back in the day.

So I guess I should hurry up and setup an emulator so I can get my fix. I’ll gladly pay (bribe) Andrew Welch a reasonable amount of money for codes.

I ripped and uploaded a few old MacFormat CDs, if that's useful.


Someone else is seeding the same data as a torrent:


If you're interested in the 32x32 icon style for graphic art reasons, I wrote IconPush to search my old Mac OS 9 icon collection:


> Word 5.1a, a.k.a. the best version of Microsoft Word ever made. Still waiting for Google Docs to catch up in terms of feature parity, it’s not even close.

What features are missing?

User defined styles, you can’t add new ones to Google Docs.

User-created templates are such a pain in Google Docs that I would almost consider it a missing feature.

Tab stops that align to the decimal point.

Does Google Docs even let you control kerning these days? Last time I used it, it was a toy.

Google Docs feels like using Word 2.0 for Windows 3.1.

You say that like that's a bad thing.

Feature wise Word 2.0 is miles ahead of gdocs. In fact I'd rather use office 95 than the bloatware that came after it.

It's also lightning fast, unlike Google Docs. It's seriously mind-boggling how far we've regressed that we're running Javascript word processors on eight core 3 GHz machines and yet are arguably worse off in terms of performance and UX than we would be on a 486/33 running Word 2.0.

Office 95 was a beautiful thing too. Oh how I miss the no BS interface and the UI consistency of Windows 95 and its applications.

I agree with you vehemently with you here.

Been doing this with SheepShaver for years. Audio works perfectly. Runs Mac OS 7, 8, or 9. Is able to share your Mac’s internet connection. It can run in full screen mode on your Mac, without a black border or anything. It’s fantastic. Best of all, you can create a shared folder with the host computer, so files you download through your modern browser from places like Macintosh Garden can be accessed immediate in the virtualized vintage OS. Works great the other way around too. SheepShaver + MacOS9 comes in really handy when I’m feeling nostalgic for SimCity 2000.

SheepShaver is kind of rough around the edges -- booting to the desktop and running some basic applications will work, but a lot of more advanced applications (games, development tools, Macsbug) will behave incorrectly or crash the emulator. More importantly, the codebase is an ancient mess, and has been essentially unmaintained for 10+ years. qemu is a much more viable approach going forward.

Particularly difficult is how the Office '98 apps all crash in SheepShaver.

SheepShaver segfaults in the CPU emulator before running anything for me -- no matter which configure options I pass to it. It's an absolute nonstarter.

Meanwhile, qemu works a treat.

Wrote a sheepshaver how-to recently because I always have trouble finding links to everything: http://blog.eamonnmr.com/2018/10/os9-on-ubuntu/

It’s interesting to see Infinite Loop completely covered in short grass, instead of the drought-tolerant variety that now blankets the area by Infinite Loop 5 in the bottom right of the picture. I wonder when the landscaping was changed.

2013, according to their environmental report - https://www.apple.com/environment/reports/docs/apple_environ...

If only we could somehow emulate IRIX. Seems to me that platform is doomed to vintage hardware only.

Which company ended up with the rights to IRIX?

According to https://en.wikipedia.org/wiki/IRIX and https://en.wikipedia.org/wiki/Silicon_Graphics#Final_bankrup...

"Rackable Systems, Inc" picked them up, and then got acquired by HP

Presumably HP now owns IRIX then? Though it seems to have been retired

The charm in using Silicon Graphics machines was the dedicated hardware and graphics pipelines that these machines had. In addition to that the awesome, no, supreme hardware design and cool boxes.

I maintain that emulating Irix, wouldnt bring all of that back. It would be like watching porn instead of doing it.

At the time? Of course. With modern hardware speeds and bandwidth, it ought to work just right. Maybe not the last of the lineup (Tezro), but it would get there. Just like it did with (less powerful) Amiga. Problem is that so much of the stuff was custom inside.

I recently acquired an old iMac running OS 9. I'd like to play around with interesting old software, but half my attempts to download things off e.g. Macintosh Garden have resulted in a file on my desktop the system can't seem to use. Are there any good guides for what to do and how to do it on a classic Mac? I've got Myst installed but that's been the extent of it.

To open those old archives you need to get StuffIt Expander [1]. Once you have that installed, you'll be able to extract any .sit archives (unless they're corrupted).

Edit: If you're looking for some interesting software to run on OS 9, Macintosh Garden has Photoshop 7 [2] as well as Illustrator 7 [3]. It's extremely cool that you can get this old software for free now. Those applications are still highly capable for serious editing and design work.

[1] http://macintoshgarden.org/apps/stuffit-expander-55

[2] http://macintoshgarden.org/apps/photoshop-7x

[3] http://macintoshgarden.org/apps/adobe-illustrator-7

You may also need to open the files from Stuffit, rather than just double-clicking, as they may have lost their type and creator codes.

You should also get Disk Copy to mount disk images.

Oh man Stuffit really takes me back....

.img -> disk image, open with built-in tools (Disk Copy), copy to hard drive, then unmount it

.bin -> MacBinary, uncompressed binary format containing one file, use MacBinary or Stuffit

.hqx -> BinHex, uncompressed ASCII format containing one file, use BinHex or Stuffit

.sit -> compressed Stuffit archive, use Stuffit

.sea -> self-extracting archive, must be wrapped (.bin or .hqx is common), run it as a program

.cpt -> compressed Compact Pro archive, use Compact Pro or Stuffit

You can drag a file onto the Stuffit application icon and it will open in Stuffit. This is a feature I sorely miss when I am using Windows or Linux.

> You can drag a file onto the Stuffit application icon and it will open in Stuffit. This is a feature I sorely miss when I am using Windows or Linux.

I thought dragging a file onto an executable in Windows did open the file with the executable? Dunno about *nix, though if it doesn't work it should be easy enough to implement.

I just went and tried, and apparently you need to shift-drag. So, on Windows, the default action for dragging an HTML file onto Google Chrome, in the taskbar, is “pin to Google Chrome,” and “open with Google Chrome” is what you get when you hold the shift key down. I think this might make sense in some kind of fantasy world.

My general expectation is that dragging and dropping is a great way to discover an easier way to do something on a Mac, at least if you have a mouse and not a trackpad. I can drag a file into a terminal and get its full path, with escapes as appropriate. I can drag a folder into a “save” dialogue box and the dialogue box will move to that folder. I can drag an application off the Dock and remove it.

My general experience on Windows is that if you try dragging and dropping something, it may perform some kind of action, and it may be consistent about how it performs that action, but it is rarely the action I want to perform. Drag a file into a save dialogue? Obviously, I wanted to move that file into the folder that the save box was browsing!

My general experience on Linux is that drag and drop is utterly broken and will never work so I might as well give up. Even copy and paste is hell on Linux.

a few years ago arstechnica tried using an OS9 computer as a 'daily driver' for fun, they detail some of the challenges encountered:



I've noticed that Mac OS 9 along with some of the other OSs/platforms that disappeared into obolescence have one thing in common: a filesystem that has a more fancy abstraction that just "stream of bytes". The resource fork/data fork system of classic Mac OS is an extra hurdle to sharing files with other systems which don't have such distinctions. It was technically superior in some ways, but also restrictive in others (one of my first experiences with it was "what do you mean I can't open any file in the text editor to see the bytes?") and I suspect the latter may have contributed to its demise, because the opaqueness was not conducive to creating a culture of power users and "semi-developers" unlike the PCs of the time. Early Macs were an even more isolated ecosystem than the ones today.

> …the opaqueness was not conducive to creating a culture of power users and "semi-developers" unlike the PCs of the time.

Utter nonsense, as anyone who has ever used ResEdit can tell.


Also, extended file attributes are alive and well.

...so you have to go get additional software in order to do that, instead of being able to use what comes with the OS? That's already going to turn off a bunch of users.

In those days, PC users were entering Asm code published in magazines into DEBUG (which came with MS-DOS), creating real application binaries.

Here is an 'easy way' that also provides simple transfer of files to / from the OS 9 VM: http://www.columbia.edu/~em36/macos9osx.html

> I recently got an urge to revisit old computer media from the late 90s and early 2000s.

Shit that makes me feel old. In my mind that “modern times.” It wasn’t long ago—I could my first SDSL connection around then. I had a Pentium II!

(Still the heyday of computing if you ask me.)

Love to see MacOS on new stuff. Have you looked at Basilisk?

Basilisk only emulates 68K Macs, not PowerMacs, and Mac OS 9 only ran on the PowerMacs like the G3 and G4. Mac OS 8.1 was the last version to run on 68K Macs like the Quadra, and it's the last version you can run under Basilisk as a result.

It works, at least on GNU/Linux. I can't figure out how to take a screenshot in OS 9 itself though.


Hold Cmd-shift-3

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