6 ms·

> Certainly Steve has the luxury of not worrying as much about backwards compatibility Not all the time. Let's not forget about the Universal Binaries (a solut

> Certainly Steve has the luxury of not worrying as much about backwards compatibility Not all the time. Let's not forget about the Universal Binaries (a solution for the transition to Intel) and the Carbon API: Carbon provides backward compatibility for existing Mac OS X software, while serving as a stepping stone for developers porting procedural applications from other platforms. [1] [1] http://developer.apple.com/carbon/ http://developer.apple.com/carbon/

Zev 16y ago
Let's not forget about the Universal Binaries (a solution for the transition to Intel) And from 68k to PPC.
- jonah 16y ago
  Weren't those called "Fat Binaries"?
  - Zev 16y ago
    A "Universal Binary" is the exact same thing as a "Fat Binary," the only difference is that marketing gave it a new name. If you look at the mach-o header of a binary that contains multiple architectures (initially, ppc/68k or now, i386/x86_64/ppc), the first 8 bytes will be either 0xcafebabe or 0xbebafeca, depending on your endianness. These values are also #define'd as FAT_MAGIC or FAT_CIGAM in <arch/fat.h>. If you're on a Mac, you can check this by typing `open -h fat.h` into a Terminal and opening up the binary of a universal app in a hex editor.
    - jonah 16y ago
      Yep. But I don't believe the 68k/PPC ones were called "Universal Binary".
      - Zev 16y ago
        If it walks like a duck and quacks like a duck... Please see the end of the first line in my previous post: ...the only difference is that marketing gave it a new name.