Building Classic Mac OS Apps in OS X | Hacker News Reader

Building Classic Mac OS Apps in OS X

blog.steventroughtonsmith.com

175 pointsmilen20 comments

Windows should have a similar amount of compatibility. The API is basically the same at least as far back as Windows 3.1 (1992), and probably further (though I have no personal experience with programming for older versions of Windows).

Also, Windows 3.1 can be augmented with Win32s, which offers a subset of the 32-bit Windows API -- so it's possible for a single binary to run on Windows 3.1 all the way through Windows 10 (64-bit Windows does not support 16-bit executables). If you want to try this for yourself, Win32s is rather finicky, so executables produced by modern compilers won't run. I believe I used Borland C++ 5.5, which is now available as a free download.

Yea, Win32s had many limitations, and was a joke compared to OS/2 2.0. I mentioned before that PX00307 pretty much ignored them.

It's actually interesting how similar a pure Windows API app for Windows 8 looks to one created for Windows 1.0. A fun example of this is Charles Petzold's birthday cake app:

http://charlespetzold.com/etc/Windows1/CAKE.C

With relatively minor modifications, it'll run on Windows 7/8 and look exactly as it did on Windows 1.0 30 years ago.

The app was actually created for a fun presentation he gave in 2005:

http://www.charlespetzold.com/etc/windows1/

I wonder if someone could use carbon to make an emulator for old apps that ran them seamlessly in OSX ?

Originally I assumed this is what the classic support would do.

Classic support was simply Mac OS 9 running in a virtual machine.

Carbon is a modernization of the classic APIs. If an app was ported to Carbon then it could run in OS X natively without the VM. Older apps that weren't ported to Carbon need a VM running a classic version of Mac OS.

It is not a true VM, the virtualization is at the nanokernel level.

There is a big exception. They eventually removed Open Transport support.

Did the classic Mac OS 1 support things like threads? For example, how do you deal with a std::async?

Mac OS 9 had MP tasks, but the amount of things you can do from them was pretty limited.

IIRC the micro kernel which added MP support came in 8.6

*nanokernel http://en.wikipedia.org/wiki/Mac_OS_nanokernel

I could be wrong, but OS 9's Multiprocessing framework actually relies on multiple physical CPUs, from what I can tell - there's no way to use it or test in an emulator (I've tried in the past)

No, all that it needs is the new nanokernel.

http://en.wikipedia.org/wiki/MultiFinder

You mean, the original System 1.0 of the 1984 era? Did not support threads, no.

There was a thing called "Desk Accessories", sort of single-window mini apps (think Calculator), that were implemented as a special kind of device driver. But IIRC even these were serviced by periodic calls to SystemTask() which would make sure every running device got some time.

To get around this, we hacked the OS in crazy ways. For example, all of the system APIs were in a big address table. So if you had loaded some code and wanted to get a little slice of execution time to yourself, patching your function's address into the table in place of SystemTask() was a common technique (not forgetting to call to the original SystemTask() address before finishing, of course)! Since everyone did this (including Apple), you can imagine the long sequences of hacks patching on top of each other would lead to a really unstable system. Hence the classic Mac OS reputation.

I once wrote a driver for a custom-built hardware keyboard which plugged in via the serial port. The keyboard driver was basically a Control Panel (CDEV) with an INIT resource that patched something (I'm guessing SystemTask() but my memory is hazy...not sure why I didn't just make it a straight-up device driver) to check for bytes from the keyboard, which it would post into the event queue, and they'd show up in the running application.

Another common technique for getting time slices was to use the interrupt manager, although that was dicey because calling into system APIs at interrupt time wasn't safe.

Caveat: it's been a long time.

I, too, once wrote a driver for a hardware keyboard which plugged in via the serial port, and I did it the same way you describe. My recollection is that the keyboard/mouse driver system at the time assumed it would only be dealing with ADB devices. There was no abstraction for "a keyboard" or input device in general, there was just a system for interacting with ADB specifically and turning its input into events.

It didn't, and didn't even have the co-operative multitasking that was introduced later.

You could simulate threads like GUSI did, by passing control on (simulated) UNIX system calls.

Many of the OS calls had asynchronous versions (PBHOpenAsync, etc) which add it to a queue for later processing and call your completion pointer when done. That was documented in Inside Macintosh Volume 1 (1985), predating Multifinder.

For the compatibility layer, stuff it might be worth looking at the old, but open sourced emulator 'executor'.

He built a compatibility layer that can run a lot of binaries up to about system 6, but without a copy of the OS.

(The closest analogy I can think of is like wine, but also he has a CPU emulator underneath with neat tricks like dynamic recompilation).

https://github.com/ctm/executor

Very impressive! It's so cool to see stuff like this. Great job.

Reply on news.ycombinator.com