man gcc gives me:
I guess I should have tried it but the above suggested to me that gcc would not produce x64 binaries, probably, I thought, because they would not run anyway.
Compile for the specified target architecture arch. The allowable
values are i386, ppc and ppc64. Multiple options work, and direct
the compiler to produce ``universal'' binaries including object
code for each architecture specified with -arch. This option only
works if assembler and libraries are available for each architec-
ture specified. (APPLE ONLY)
I repeated our experiment on my iMac and the program ran and checked out as a 64 bit binary.
I also compiled it for PowerPC:
Just for completeness' sake I also compiled it for 32 bit PowerPC and Intel. As expected both PowerPC binaries ran on the G5, while both Intel binaries ran on the Intel. The 32 bit PowerPC binary also ran on the Intel (Rosetta), while the 64 bit PowerPC binary did not. That's exactly as should.
hokem:~ ajbrehm$ testapp
Steve Balmer belongs in a zoo.
hokem:~ ajbrehm$ file testapp
testapp: Mach-O 64-bit executable ppc64
This means that we are running in long mode, although our kernel is 32 bit:
In that case it is probably safe to assume that Parallels already emulated real mode and all 16 bit code where necessary.
xerxes:/ ajbrehm$ file mach_kernel
mach_kernel: Mach-O universal binary with 2 architectures
mach_kernel (for architecture ppc): Mach-O executable ppc
mach_kernel (for architecture i386): Mach-O executable i386
hokem:/ ajbrehm$ file mach_kernel
mach_kernel: Mach-O executable ppc
UNLESS Parallels runs in protected mode somehow while Mac OS runs in long mode, but I have obviously no idea how this works. And what about Parallels on Windows and Linux? Both hosts run in protected mode I am sure.
Seems like Parallels Desktop is a bit more advanced than I thought.
Or what am I missing here?
(This would mean that 16 bit programs running under Parallels would be faster on Parallels Workstation running on Windows, wouldn't it? Can anybody confirm the assumption?)