5 ms·

Building Classic Mac OS Apps in OS X

175 points by milen 12y ago

yuhong 12y ago
There is a big exception. They eventually removed Open Transport support.
nandhp 12y ago
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.
- yuhong 12y ago
  Yea, Win32s had many limitations, and was a joke compared to OS/2 2.0. I mentioned before that PX00307 pretty much ignored them.
- rpeden 12y ago
  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 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/ http://www.charlespetzold.com/etc/windows1/
mightykan 12y ago
Very impressive! It's so cool to see stuff like this. Great job.
frozenport 12y ago
Did the classic Mac OS 1 support things like threads? For example, how do you deal with a std::async?
- yuhong 12y ago
  Mac OS 9 had MP tasks, but the amount of things you can do from them was pretty limited.
  - kalleboo 12y ago
    IIRC the micro kernel which added MP support came in 8.6
    - kalleboo 12y ago
      *nanokernel http://en.wikipedia.org/wiki/Mac_OS_nanokernel http://en.wikipedia.org/wiki/Mac_OS_nanokernel
  - stroughtonsmith 12y ago
    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)
    - yuhong 12y ago
      No, all that it needs is the new nanokernel.
- morkfromork 12y ago
  http://en.wikipedia.org/wiki/MultiFinder http://en.wikipedia.org/wiki/MultiFinder
- robterrell 12y ago
  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.
deleted 12y ago
[deleted]
stuaxo 12y ago
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 https://github.com/ctm/executor
stuaxo 12y ago
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.
- thought_alarm 12y ago
  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.
  - yuhong 12y ago
    It is not a true VM, the virtualization is at the nanokernel level.

175 points by milen 12y ago

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

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.

yuhong 12y ago
Yea, Win32s had many limitations, and was a joke compared to OS/2 2.0. I mentioned before that PX00307 pretty much ignored them.
rpeden 12y ago
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 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/ http://www.charlespetzold.com/etc/windows1/

mightykan 12y ago

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

frozenport 12y ago

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

yuhong 12y ago
Mac OS 9 had MP tasks, but the amount of things you can do from them was pretty limited.
- kalleboo 12y ago
  IIRC the micro kernel which added MP support came in 8.6
  - kalleboo 12y ago
    *nanokernel http://en.wikipedia.org/wiki/Mac_OS_nanokernel http://en.wikipedia.org/wiki/Mac_OS_nanokernel
- stroughtonsmith 12y ago
  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)
  - yuhong 12y ago
    No, all that it needs is the new nanokernel.
morkfromork 12y ago
http://en.wikipedia.org/wiki/MultiFinder http://en.wikipedia.org/wiki/MultiFinder
robterrell 12y ago
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.

deleted 12y ago

[deleted]

stuaxo 12y ago

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 https://github.com/ctm/executor

stuaxo 12y ago

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.

thought_alarm 12y ago
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.
- yuhong 12y ago
  It is not a true VM, the virtualization is at the nanokernel level.