What is the name of the 64 bit compatibility function?

[MinuteBracelet]

So a lot of you who have been using macs at latest since 2006 probably know what I'm talking about. Basically, back then during the 32 bit to 64 bit transitional period Apple was going through, many older x86 machines were upgrading to Leopard and Snow Leopard and thus Apple released OSX in both 64 bit and 32 bit flavors in the Intel distribution.
However if you either
1) Bought a computer that was higher than the floor model in terms of specs
or
2) Upgraded a floor model mac,
Then you probably noticed back then that even though your OS was in 32 bit, you almost never had to worry about finding the correct build of software aside from PPC/UB/x86. In fact you may have even been aware that your computer was mysteriously running 64 bit software looking at Activity Monitor.

This was basically a feature Apple introduced that let 32 bit macs with a 64-bit capable processor (like the then-new Core 2 series) to run 64 bit software even if the firmware and OS were 32 bit. More recently this feature has more or less become irrelevant as every new Macintosh is now 64 bit, but I wanted to look into how this feature worked and I can't seem to find the name of it.

Does anybody know what this is called? And if those anybodies are brainiacs could they also explain how it works?

TL;DR
Macs can run 64 bit software on 32 bit installations provided there's a 64 bit processor on board and I want to know what that is

 

[chown33]

It's not a "function" per se (or programmers wouldn't call it a function). It's a capability of the executable file.
https://en.wikipedia.org/wiki/Universal_binary

This capability is based on the fact that Mach-O binaries can hold code for multiple architectures, and each architecture is identified. Formats other than Mach-O can have that capability, so it's not unique to Mach-O. For example, FatELF can do it:
https://en.wikipedia.org/wiki/Fat_binary


As to how it's done, it's in the headers. Specifically, the header for each Mach-O segment and section identifies the type (e.g. symbols, executable, initialized data, etc.). Within the executable type, other header info identifies the CPU type and sub-type. The OS is responsible for loading and executing the correct executable section for the CPUs it knows about.

You can dig into the Mach-O format and how the headers identify CPU type and sub-type. Here's a starting point, with almost no detail:
https://en.wikipedia.org/wiki/Mach-O

It shouldn't be hard to find Mach-O's details, since it's a well-documented format, and plenty of development tools like linkers and debuggers need to know how to decode it.


At the command line (Terminal.app), the 'otool' command can tell you what a file's segments and sections are, what architectures they're for, etc. You might not have this command unless you've installed the command-line tools. You can google for its man page.

 

[Mrbobb]

Boy, that's so last decade. I guess 32bit emulation.

 

[MinuteBracelet]

Boy, that's so last decade. I guess 32bit emulation.

I'm fairly certain it's not 32 bit emulation. After all, the host system is 32 bit and the executables are 64 bit. It can't be 64 bit emulation either because otherwise why would it require a 64 bit processor?
[doublepost=1474515552][/doublepost]

-snip-

Haha, pardon my terminology. I should probably have said "functionality".
I don't think it's something packed in the executables though because I read somewhere a long time ago that the ability is actually inside the operating system itself to run 64 bit natively. Since UBs more often than not refer to dual packaging of x86 and PPC execs as opposed to x86 and x86_64, I think it's unlikely.
Unless I didn't catch your drift that is. I'll read those links.

 

[chown33]

Universal Binaries cover more than x86 + PPC.

The 'file' command in Terminal has some knowledge of Mach-O, though less detail than 'otool'. For example:

file /bin/ls

Output:

/bin/ls: Mach-O universal binary with 2 architectures
/bin/ls (for architecture x86_64):    Mach-O 64-bit executable x86_64
/bin/ls (for architecture i386):    Mach-O executable i386

Here's 'otool' command and output:

otool -h -arch all /bin/ls
/bin/ls (architecture x86_64):
Mach header
      magic cputype cpusubtype  caps    filetype ncmds sizeofcmds      flags
 0xfeedfacf 16777223          3  0x80          2    13       1928 0x00000085
/bin/ls (architecture i386):
Mach header
      magic cputype cpusubtype  caps    filetype ncmds sizeofcmds      flags
 0xfeedface       7          3  0x00          2    13       1516 0x00000085
duo:Pi gadmin$

This is on a 10.6.8 Snow Leopard OS, on a Core 2 Duo.

If there were a PPC executable in there, that would show up, too. And there could be versions compiled not just for PPC in general, but G3, G4, or G5, as those were settable compiler options when PPC Macs were the main model line.

 

[MinuteBracelet]

Universal Binaries cover more than x86 + PPC.

The 'file' command in Terminal has some knowledge of Mach-O, though less detail than 'otool'. For example:

file /bin/ls

Output:

/bin/ls: Mach-O universal binary with 2 architectures
/bin/ls (for architecture x86_64):    Mach-O 64-bit executable x86_64
/bin/ls (for architecture i386):    Mach-O executable i386

Here's 'otool' command and output:

otool -h -arch all /bin/ls
/bin/ls (architecture x86_64):
Mach header
      magic cputype cpusubtype  caps    filetype ncmds sizeofcmds      flags
 0xfeedfacf 16777223          3  0x80          2    13       1928 0x00000085
/bin/ls (architecture i386):
Mach header
      magic cputype cpusubtype  caps    filetype ncmds sizeofcmds      flags
 0xfeedface       7          3  0x00          2    13       1516 0x00000085
duo:Pi gadmin$

This is on a 10.6.8 Snow Leopard OS, on a Core 2 Duo.

If there were a PPC executable in there, that would show up, too. And there could be versions compiled not just for PPC in general, but G3, G4, or G5, as those were settable compiler options when PPC Macs were the main model line.

Hmm, interesting. But I don't think that's what's going on for the case I'm describing because in Activity Monitor it actually tells you which processes are 64 bit in parentheses.
Do you have snow leopard on a 32-bit machine like a 2006 mini/macbook? Try opening up Activity Monitor and see if the more "modern" apps show up as "Intel (64 bit)"
[doublepost=1474524832][/doublepost]

See, activity monitor tells me that I'm running the 64 bit versions of those processes, but the kernel being used is not the 64 bit one.

 

[chown33]

Hmm, interesting. But I don't think that's what's going on for the case I'm describing because in Activity Monitor it actually tells you which processes are 64 bit in parentheses.
...
See, activity monitor tells me that I'm running the 64 bit versions of those processes, but the kernel being used is not the 64 bit one.

A 32-bit kernel doesn't prevent the OS from running 64-bit user-space processes. The main restriction a 32-bit kernel has is on KEXT's or driver, which would need to be 32-bit.

The kernel can provide services to 64-bit user-space processes by providing a 64-bit library that interfaces to the 32-bit kernel. If you look at the fundamental libraries, they should all be dual architecture: i386 and x86_64.

The OS will certainly know which architecture is being used by each process. It would have to know this, because it loaded either the 32-bit or 64-bit executable from the Mach-O file in the first place.

 

[MinuteBracelet]

A 32-bit kernel doesn't prevent the OS from running 64-bit user-space processes. The main restriction a 32-bit kernel has is on KEXT's or driver, which would need to be 32-bit.

The kernel can provide services to 64-bit user-space processes by providing a 64-bit library that interfaces to the 32-bit kernel. If you look at the fundamental libraries, they should all be dual architecture: i386 and x86_64.

The OS will certainly know which architecture is being used by each process. It would have to know this, because it loaded either the 32-bit or 64-bit executable from the Mach-O file in the first place.

Ah I see. Thanks for the info!