Uncategorized

Although Intel macs don’t support classic, SheepShaver may be a way to run older software. I’ve installed an x86 build and I finally found a working ROM image, but it won’t boot my 9.2 CD, which is the oldest one I can find. Tomorrow I’ll look for a 9.0 CD which it should be able to boot.

UPDATE: I was able to get it running using the Software Install CD from my old G4 minitower. I posted the full details here.

I found a pre-compiled binary of Wine for Intel Macs. It looks like they didn’t fix the problem in context_i386.c that I ran into, they just worked around it:

It looks like the inability to call PowerPC code from native code is going to be a big problem. I can’t run SourceOffsite because it isn’t native but the libraries it tries to dynamically load are native. The result is:

There’s one very big difference between the transition from PowerPC to Intel and the transition from 68K to PowerPC, which may make it more difficult for many people. With the first transition, it was possible for code to switch between architectures, so you can use 68K plug-ins in a PPC application & vice versa. The Code Fragment Manager was able to handle cross-architecture calls.

However that’s not the case with Rosetta. You can’t call code written in one architecture from the other, so you can’t use PPC plug-ins with a native x86 application. So even when a major application like PhotoShop goes native, anyone who still needs to use a non-native plug-in is stuck running it in Rosetta.

My new iMac arrived this morning! I’m using it now.

I should receive my new iMac tomorrow, so my tests were done on my DTK. Several sites have done performance tests showing the Intel iMac to be slower than a G5. However, anyone using a G4 (as I am) will see a big speedup with an Intel mac. I use a PowerBook as my primary system, so I’m forced to use a lower-performance G4. If and when I get a MacBook, it will outperform my PowerBook by a huge margin.

I did some very crude tests running a small command line program that writes some system information to a file and timing it using time. Even running in emulation, the DTK is faster than my PowerBook.

The latest version of XCode allows you to specify separate settings for x86 & PPC code, although it isn’t really obvious how to do it. After some digging I figured it out.

Some of the build settings such as SDKROOT & GCC_VERSION allow you to specify which architecture they apply to by appending _ppc or _i386 to the settings name. Here’s how I’m able to build a universal binary that will run on OS X 10.2 or later (which requires it to be built with GCC 3.3) as well as x86.

First, set up the project & target settings as required for building the x86 version. Then add the following variables to the build panel of the project or target settings window (hit the ‘+’ button to add a variable & edit the name).

MACOSX_DEPLOYMENT_TARGET_ppc  10.2
GCC_VERSION_ppc               3.3
SDKROOT_ppc                   /Developer/SDKs/MacOSX10.2.8.sdk

Those settings will override the defaults when building a PPC binary, while the defaults will be used when building x86.

I now have most of my code working on the Intel Mac. Once again, I need to reiterate this bit of advice: Never assume Macs are Big Endian.

We already have a cross platform product that works on both Macs & PCs. Since it deals with binary data read from a file, it needs to handle byte ordering issues. In our code we used #ifdef __MAC__ for pieces of code that are sensitive to byte ordering. We also used #ifdef __MAC__ for a lot of other Mac-dependent stuff that had nothing to do with byte ordering. This was the cause of almost all of the problems I had with the port.

I’m sure a lot of other developers are doing the same thing. If you ever plan to port to Intel, go through your code and change any such tests to use #ifdef __LITTLE_ENDIAN__ or #ifdef __BIG_ENDIAN__ instead. Those things will bite you badly when you port to Intel. Better yet, use any of the byte order utilities whenever possible.