The Inquirer-Home

Why XP will never officially work on a Mac

EFI problems galore
Wed Feb 15 2006, 13:05
APPLE HAS SHINY new x86 based iMacs and the eloquently named MacBooks (yech) out on the market, and reviews, barring a few fawning toadies in the print media, are exceptionally rare. The usual Apple cooked benchmarks abound, but there is no real third party analysis, I think mainly because it is afraid of what will be found. The biggest bloomer is its tacit non-denials of the fact that the current C86 macs will never run XP in an approved or corporately acceptable fashion, and Vista is a long long long shot. Apple knows, is doing nothing to quell the rumours and speculation, and I think that's irresponsible.

Apple has long said it will do nothing to keep people from running XP on their machines, but this is sheer cynicism. It knows it can't be done, and just grin and feed the rumour mill when you ask about it, or at least when people they deign worthy to talk to ask. Either way, while nothing is impossible, the level of surgery required to make it happen, if it is indeed possible, will never be something that a corporation will undertake. Spyware, rootkits and viruses are bad enough, would you install a patch to your EFI from someone that has problems with capitalisation in their NIC? Yeah, I would too, but if I were doing it in a corporate setting, there is not a chance in hell that I would go near that code. Sadly, that is what it will take.

Why? Well, it is a long and technical story that Apple really does not want out. It knew, and made decisions to make it impossible, and it has everything to do with EFI. EFI as you all know, is a next-gen BIOS on steroids … or more appropriately a framework for implementing things that you wish the BIOS could do, but would take an army of coders to do, and be more or less locked to a single box type. EFI is the next big thing, and it is long overdue, mainly thanks to Intel/AMD squabbling, and Microsoft's backroom arm-twisting for power.

EFI as a technology is a very good thing caught up in the politics. There are several versions, revisions, and asterisks that you need to know about. The first main one is called EFI 1.10, basically the Intel Framework and TianoCore, look them up if you need to, but for this article, you just need the revision number. The successor to this is called UEFI 2.0, and it is shipping in nothing at all now, but (really) should be finalised soon. It will probably make its commercial product debut around the time Vista ships. So, two versions, EFI 1.10 and UEFI 2.0 … the former is shipping, the latter is imminent.

There are a bunch of things that plug into EFI and the Framework which allow you to do various neat tricks, from CD playing with the computer 'off' to reading file systems so the machine can boot. The two functions to be concerned about here are the FAT32 loader and the BIOS compatibility module. The FAT32 module is what allows EFI machines to read the aforementioned file system and do such wild and crazy things as initiate the OS, in this case usually Windows, boot process. You may see the process where EFI accesses the boot partition referred to as GPT. The other big one is the BIOS compatibility module, AKA Compatibility Support Module (CSM). It translates EFI calls to BIOS and the other way around, allowing legacy OSes like nearly everything MS has made (other than Itanium software) to boot on an EFI-based system.

I am not trying to pick on MS here, there are two good reasons why XP/iAMD64 will not boot using EFI, and why Vista 64 won't use it either, at least at first. The first is that EFI 1.10, remember this is mainly an Intel defined standard at this point, was born in the days when Intel was pretending that iAMD64 didn't exist. We knew better, and told them so ( 3. 2. and 3), but the denial seems to have carried over to the EFI spec. If you want iAMD64, no love for you here. All current MacIntelIntoshes don't have iAMD64 capable CPUs anyway, so the distinction is pretty academic.

The other problems are rather odd, and will probably be rectified in UEFI 2.1 or something, it will cause enough anguish that programmers will have to fix it. Basically, UEFI 2.0 can only do firmware callbacks in the mode of the OS. If you have an iAMD64 version of XP that needs BIOS to boot, not that you can buy a UEFI 2.0 board now anyway, it boots by going from Real Mode to IA32 to iAMD64. See a problem? This means that you are stuck with a BIOS, not a CSM in UEFI 2.0. Microsoft roadies seen by the Inq show that there is an UEFI iAMD64 variant of Vista coming, and by the time Vienna ships in 2013, it will probably be a moot point.

Summary to this point is basically this, if you want to boot XP on EFI, you need to do it on a 32 bit system with both a CSM and GPT support. XP will fall flat if either is not there. Win64 will make the system go down in a hurry due to inherent incompatibilities, like, well not supporting iAMD64 in 1.10, and not allowing mode changes with BIOS support in 2.0. It is an ugly scenario no matter which way you look at it. Vista will smooth things out a little, mainly in the UEFI 2.0 and Vista64 space. To their credit, MS wants to clear this situation up, and from what I hear is now working pretty hard to make it so. There was one, and as far as I am aware only one, demo of a test variant of EFI based Win32 booting at WinHEC, but I am told elves came out and took the code away to a deep dark place in the forest, possibly guarded by dragons, lobbyists and other creatures most foul. In short, don't look for it or beg friends who work in places that might have access, they don't and won't give it to you anyway.

If you recall from sometime in the last century, this article was about an albino fruit logo company called Apple, and its shenanigans. All shipping MacIntelIntoshes are based on Yonah, a strictly 32-bit CPU, so that shuts the door on all current and future versions of Win64, including the UEFI 2.0 one. Again, all shipping MacIntelintoshes have EFI 1.10. Yay you say, XP should boot right up. Well, no, not exactly, Apple left out the CSM on purpose. This means XP will never work on it now matter how hard you push the CD tray in.

Yup, it did it on purpose, and then sent the rumour mill spinning with strategically worded denials about 'not preventing' such things. Yeah, it isn't preventing me from walking outside flapping my arms and taking flight either, but both scenarios are about equally possible. Yes, they knew it could not happen, and did nothing to point this out. Not ethical, but legal, sadly typical Apple behaviour.

So, what if you are a hacker and want to do it anyway? You have three choices, hack a CSM into a MacIntelIntosh, hack the OS into a Yonah mobo, or just run the damn OS under a VM, either OSX under XP, or the other way around. All three can theoretically be made to work, but what are the fine points?

For hacking a CSM into a MacIntelintosh, you basically have to make or acquire a full blown CSM for the Apple mobo, hack it in without documentation, and make it work. There are no docs on the Apple side, probably little if anything on the MS side, that is their domain not yours after all, and no one will be overjoyed to answer technical questions on the subject in any case. Add in that such a beast might very well not exist, and you would quite possibly have to write it, and you get a hard lesson in the phrase 'it's going to be a royal bitch to do.'

That said, there are some brilliant hardware and software hackers out there, may of which are hard at work on this. There are reports of them bricking a few iMacIntelIntoshes while giving it their best shot. To their credit, Apple has been very good about returns and warranty claims here, good job there, minions of Jobs. That said, if you kill your machine doing things way outside the warranty, don't keep bringing it back, that isn't cool.

Then comes the more feasible plan, putting OSX on a non-Apple platform. This one seems to be much more do-able than XP on Apple, the hard part is legally acquiring the OS, but I will assume you have already done that. Intel is currently shipping some new desktops with EFI 1.10 and the Framework, but it isn't all there. It has CSM, so BIOS calls work just peachy, but it lacks the FAT32 loader, so no GPT, and therefore no XP.

Intel has some really nice documentation on the subject, and a lot of very smart people work there too. It would probably not be all that hard to figure out how to hack the FAT32 drivers into these boards, and you can probably figure out how to reflash them on your own before you brick the things. All hail openness and companies that document well. XP should be the hard one here, and then with some minor hacking, you should be able to boot OSX on it as well. Moral, Intel EFI boards are going to see an upswing in sales soon.

Last but not least is the tried and true method of VMs. Most security conscious companies haven't quite figured out yet that anything they need to do, anything they need to check, can be emulated. This is how the original release of OSX was spread, it was a VMWare image. With Xen and VMWare both being free, it stands to reason this methodology will be the first beachhead of the hardware hacker. It is *HINT* massively *HINT* easier and faster to muck around with the boot code and firmware of an emulated system, and just reload the image when things go pear-shaped than it is to send a machine in for warranty, more ethical too.

So, of the three methods, I pretty much posted them from hardest to easiest. It will be much easier to run OSX on non-MacIntelIntoshes than XP on them. Apple made damn sure it would be in the words of my friend, a 'big blue bitch' to do, and succeeded. That said, to its credit, it did not pull any LT based evil tricks to melt systems on purpose if you looked at them funny. I was honestly expecting it to, but it seems that it did right and left things open. You can jump all the way across the Atlantic Ocean too, nothing is preventing you, but again, good luck with either endeavour.

As I said earlier, if you want to make XP run on these new x86 Macs, you need basically a massive firmware upgrade, and I do mean massive. Since no one will provide this in an official way, and lawyer slinging Apple will probably make life miserable for anyone who tries, you will never see a supported patch to do this. There will most likely be a few solid efforts in the next few months that do this, but they will all remain in the hobbyist/hacker domain. If your CxO wants a pretty white Apple to sit on his desk unused with the XP screen saver running, ummm, don't go there, it will never work.

It may not meet the bounty requirements, but the converse is quite do-able, and you can probably buy a very nice laptop, a copy of OSX, and still end up with money left over. That is the way I would do it. In either case, it won't be easy.

In the end, Apple was technically correct, it did nothing to prevent you from loading XP yourself, you can. Until Apple decides to make XP an officially supported OS on MacIntelIntoshes, the idea is all but dead for any work environment. The funny part is, by doing this, and quite possibly making OSX unusable due to licensing on any non-official machines, it makes piracy the only way to dual boot the OSes, and you can bet that this will be rampant sooner rather than later. Didn't it learn anything from the RIAA? µ

Apple was contacted multiple times for this story, but never even bothered to call us back for a 'no comment'. We can only assume that what we say is true, it knows it, doesn't care.


Share this:

blog comments powered by Disqus
Subscribe to INQ newsletters

Sign up for INQbot – a weekly roundup of the best from the INQ

INQ Poll

Heartbleed bug discovered in OpenSSL

Have you reacted to Heartbleed?