Mac x86

MacBook Pro – Day 1

by

After my first full day with my MacBook Pro, I love it. I was concerned about the “whine” some people report, but this one is absolutely silent. On the rare occasions when the fan starts up, it’s still much quieter than the PowerBook. I haven’t seen any of the other problems people mentioned and the screen is flawless. PhotoShop CS2 isn’t too bad. It doesn’t feel much slower than it did on my old PowerBook G4. The screen is much brighter and a lot nicer than the PowerBook. It does get noticeably warmer than the PowerBook, though.

MacBook Pro

by

My MacBook Pro arrived this afternoon. The first thing that struck me was how small the box is. It’s about half as thin as the box from my PowerBook G4. The MacBook Pro itself is slightly slimmer than the PowerBook.

MacBook Pro

Classic on Intel

by

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.

Ha!

by

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:

[mike: 7]$ winecfg
wine: Unhandled page fault on write access to 0x00000000 at address 0xffff0857 (thread 0009), starting debugger…
FIXME : get_thread_context_ptrace unimplemented
FIXME : get_thread_context_ptrace unimplemented
Can’t attach process 8: error 5

MacIntel hacking

by

CAUTION: extreme geekiness ahead…

I’ve been attempting to build WINE on my iMac Core Duo. I’m just using the raw wine source code, although someone has Mac patches for it. I ran into difficulty with context_i386.c, which contains functions that obtain the register contents from a process using ptrace. Unfortunately the register structure & PT_GETREGS isn’t defined, so I’ve been looking through the system headers to find some clues.

Reading the Darwine mailing list archive, I found a pointer to this very interesting article which tells how to access the EFI command mode on Intel macs. That article gave some clues about the Mac’s startup process.

[mike: 182]$ file /usr/standalone/i386/boot.efi
/usr/standalone/i386/boot.efi: MS Windows PE 32-bit Intel 80386 executable

hmmmm…. This is the boot image that starts up the OS.

Intel Incompatibility

by

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:

[mike: 655] $ sos
dyld: Library not loaded: /opt/local/lib/libexpat.0.dylib
Referenced from: /usr/local/bin/sos
Reason: no suitable image found. Did find:
/opt/local/lib/libexpat.0.dylib: mach-o, but wrong architecture
Trace/BPT trap

Intel Transition

by

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.