Universal binaries, and issues of endianness.

I discovered, entirely by accident, that *.dso files use platform-native endianness. How did I discover this? Another developer was kind enough to provide me with a Windows binary of my T2D code. I combined this with the *.dso files generated by the PowerPC Mac build, and when I ran it, it simply went nuts. Consumed tons of memory, and had to be killed. After much trial and error, it occurred to me to remove the *.dso files and leave the *.cs files in place. Like magic, the Windows build worked. x86 = little-endian, ppc=big-endian. Oops.

Ok, no big deal, you need a separate binary for Mac and for Windows, so why not separate .dso files too? Just one small problem: Universal binaries.

For those NOT following the Mac world, "Universal binaries" are binaries that support multiple distinct processor architectures -- specifically, PowerPC and x86. Apple just announced an Intel-based iMac at MacWorld today.

I now face three choices:

1) Ship Mac/Intel, Mac/PowerPC, and Windows/Intel versions of my game, or an installer that's smart enough to pick the appropriate combination of application binary and *.dso files.

2) Hack up the engine to use "network byte order" (a la Java) for disk-based representations such as *.dso files and serialized data.

3) Ship *.cs files with my game.

I'm unwilling to do #3, and even if I did, that would cause problems if someone installed on a PowerPC Mac, then backed up their HD and restored to an Intel Mac. Similar problem with #1. The smoothest solution for my users is #2. This will create some work for me, mostly in terms of keeping up to date with patches and updates from GG, but I consider it worth it if my users never have to worry about what CPU they have under the hood.