Universal Binary

Quote:

Original post by Maega As the computing world moves more and more to 64 bit, the inconvenience of applications will just get worse. Any thoughts on why Microsoft or anyone else hasn't build functionality to have both x86 and x64 versions of the same software in the same executable? Apple does it with PowerPC and Intel, why can't Microsoft? Note: This is not a rant or anything. I'm just curious.

Apple did no such thing. They built a PPC emulator for their Intel-based machines. It's also far from fool-proof, high-performance apps like Photoshop don't work with it.

Additionally, 32b .NET applications should run on the .NET Framework on XP64.

Quote:

Original post by capn_midnight Apple did no such thing. They built a PPC emulator for their Intel-based machines. It's also far from fool-proof, high-performance apps like Photoshop don't work with it.

Somewhat inaccurate. Old PowerPC applications run under Rosetta, but new versions of Mac OS X can build a "Universal Binary" which contains both PPC and x86 machine code slapped together using a tool called lipo. GCC pretty much runs twice with different SDKs for each target, then stitches the binaries together and slaps some metadata at the head of the bundle. It's pretty easy from the developer's standpoint -- check off two things in Xcode and then cross your fingers that you know how to write endian-independent code.

It works for libraries as well as binaries. When running a lipo'd binary, the OS goes "what's all this then" and tries to run the PowerPC code if on PowerPC, and the i386 code if on i386. I would assume that in OS X 10.5, x86-64 and ppc64 paths will be added (since OS X 10.5 is the first OS X that really supports 64-bit properly). Okay, it turns out that Xcode supports 64-bit code paths for x86-64 and ppc64 right now and I have neglected to keep up to date with my Xcode updates.

Naturally there's a tradeoff -- Mac OS X prior to 10.4 has no idea what a universal binary is, and will throw up. However, you can build both sides of the application with different SDKs -- some of the Apple manuals tell you to build the PowerPC side with the OS X 10.2 SDK so it will run on 10.2 and up regardless of the Intel side of the equation. PowerPC binaries are lipo'd in first, so the OS X binary loader just goes "What's all this garbage at the end? Ah, fuck it. I've got my program already."

This "fat binary" comes from the old Mac OS, where we could ship 68k and PPC code together in the same executable, and later from NeXTStep, where it was common to see i386, Sparc, PA-RISC and other executables lipo'd together. Since Mac OS X is effectively a token gesture of Apple fanservice lushly spread on top of NeXTStep, the tradition continues.

I think NT actually had something like this a long time ago; but it'd take time for me to dig it up. Obviously, if Microsoft plans on moving most application development to .NET, this won't be much of a problem.

Also, Photoshop works fine under Rosetta; it does tend to chug during high-memory operations though. Photoshop CS3 is a Universal binary.

Quote:

Original post by capn_midnight Additionally, 32b .NET applications should run on the .NET Framework on XP64.

Washu was unable to run my 32b .NET app on 64b XP without running the CorFlags conversion tool on the executable. The culprit for this (alleged by Washu) was the Managed DirectX libraries being 32bit (they were not embedded, so it is strange it did not default to the 64b version). Thus, .NET developers may¹ still compile two versions of their executable, pre-assuming they want to use MDX or any other library that exhibits similar behavior.

¹ - Assembly.LoadLibrary() appears to be an alternative -- dynamically linking the 32b or 64b .NET assemblies respectively at runtime.