Shall we call this article "The PPC-x86 transition of Apple Macintosh"? Apple is more than Macintosh. Intel is more than x86. And how about "migration"? -- Toytoy 07:22, Jun 14, 2005 (UTC)

"Macintosh x86 migration"? --Ihope127 22:44, 3 September 2005 (UTC)[reply]

I support renaming. It's the Macintosh, not Apple, that is moving to Intel. "Macintosh Intel migration". jamiemcc 19:23, 11 March 2006 (UTC)[reply]

I believe there's an insanely huge POV or RDF hidden inside this article:

Motorola and IBM failed to deliver a 3 GHz chip so Apple has to jump the boat.

This sounds non-sense and Apple-centric to me. If I am right, the Macintosh marketshare has been falling for the past few years. Anyway, Apple's marketshare has always been miserable. If you cannot let IBM or Motorola earn money, you don't get your chips. No one drinks Cool-Aid this time. This is exactly Apple's situation today. The money flow to nurish newer PPCs drained. That's why Jobs gets nothing. 68k failed. Now PPC, as a personal computer CPU, also fails.

Apple's marketshare has always been too small to support its hardware advancements. SCSI failed. ADB failed. NuBus failed. ADC failed. LocalTalk failed. The list goes on and on. There exists an established pattern of hardware standard failures. I think IBM and Motorola are Jobs' scapegoats.

Is there a foundmental problem with the PPC design? If PPC makes money, why don't IBM and Motorola spend more money on the R&D? Fact: Apple fails to keep them well fed. -- Toytoy 06:11, Jun 14, 2005 (UTC)

I wouldn't say any of those "failed" except maybe in the context of the greater PC world. Parallel SCSI in particular became an important standard because the Mac embraced it early on. The others got replaced mainly because something better came along; ADB begat USB, NuBus was replaced by PCI, LocalTalk was replaced by Ethernet. ADC is really the only non-starter on the list. The same thing applies to PowerPC, in this case; it's by no means an abject failure, but it's not the best tool for the job at the moment, and I think Apple is smart for realising that. -lee 05:52, 22 Jun 2005 (UTC)

That's completely false. Apple's marketshare has been rising for the last several years. Their revenues, unit sales, and profits are the highest they've ever been, and this isn't due exclusively or even mostly to the iPod and iTunes: those are simply publicity grabbers.

PowerPC most certainly did not "fail". Apple, IBM and Motorola created it together, and it's an extremely good performer in many categories. It has nothing to do with Apple keeping IBM and Freescale (formerly Motorola) "well fed". Apple buys millions of dollars worth of CPUs from both companies. However, IBM's (and Freescale's) focus is on an even bigger market for PowerPC: embedded communications, networking, vehicle controls, speciality devices, and so on, and now, all three of the major next generation gaming consoles. PowerPC powered all of Apple's products for over a decade, and continues to be heavily used by IBM in high-end servers and workstations. So while yes, I guess you could semantically argue that as a *desktop* processor, PowerPC "failed", I'd beg to differ. It's just time to move on. Did 80x86 "fail" because it was time to move to Pentium?

Further, yes, in the early days, the Apple hardware platform was very proprietary. However, I take great issue with the basis of some of your claims. Things like ADB and LocalTalk were around before there were any comparable standards to even do those jobs! The rest of the industry may not have picked them up (in part because of Apple's early closed systems), but things like LocalTalk and ADB, and even NuBus, were light years ahead of other competitors. At the time, SCSI was picked because it was the better technology: IDE/ATA was not a clear winner at the time, and SCSI was clearly better. Market dynamics and economics ended up meaning that when the PC industry at large picked IDE/ATA, it ended up being the winner because the market forced prices down, and PCs were, and continue to be, all about price and being a commodity. Even today, SCSI didn't "lose": it's still used in high performance applications where speed and other performance factors are key. Only today is SCSI being outmoded by other technologies. But I will concede that it lost *on the desktop*. But that's not the fault of Apple picking the arguably superior technologies, and where they didn't exist, creating their own. Moreover, Apple's inclusion of USB in the iMac, and the deletion of the floppy and all legacy ports, is viewed as one of the largest catalysts for USB in the entire industry. The PC industry never was so bold. ADC was a damned good idea: dual channel DVI and analog (you could use an ADC connector with DVI or VGA displays), integrated with power and USB and FireWire in one cable. It was completely open. But it never took off. Now, Apple has standardized on DVI.

Today's Macs are a virtual who's who of international and open standards in the hardware and software: ethernet (including the first mass market machines to ship with GigE), PCI, DVI, HD-15 VGA, USB, FireWire (IEEE-1394), Open Firmware (IEEE-1275), 802.11/WiFi, Bluetooth, PCI, PCI-X, ATA/SATA, etc., even implementing some standards before anyone in the PC industry has. You take WiFi for granted now; look where Apple was with AirPort two *years* before any comparably priced offerings were available in the PC marketplace, to say nothing of the additional two years it took to get remotely comparable ease of use with Windows XP SP2. The OS is based on completely open standards whenever possible, and while the whole OS itself is proprietary, the entire core OS is open source. Mac OS X is the single most desirable operating system in many scientific, life/bio-science, engineering, and even some IT marketplaces.

When Apple went to the G5 (IBM PowerPC 970), IBM promised 3GHz by 12 months from that date. Sure, no one can predict the future perfectly, but they missed that target by *over a year*. What was Apple to do? Now that Apple has removed the last vestige of what could even be remotely called non-mainstream hardware from their computers - namely, the CPU - and you still chastise them, while getting in factually incorrect jabs about how Apple's marketshare is decreasing; surely, Apple is around the corner from certain death! As it has been, apparently, for nigh on 30 years.

I'm not disagreeing that there wasn't POV garbage in the original article; what I'm saying is that your grossly overstated position is itself POV. Granted, it's not in the actual article, but neither is my reply. Apple absolutely switched from PowerPC because it was time. And it wasn't so much that they couldn't keep IBM and Motorola/Freescale "well fed", its that they couldn't keep them well fed at prices that would allow Apple to be more competitive in the general PC marketplace. This decision is nothing but a good one, and makes Macs essentially high-end, high-quality PCs. The ability to now run Mac OS X PLUS any x86 OS in a sure-to-exist virtual machine/vmware-like environment on a sleek Apple laptop (Apple hardware is consistently and continuously ranked #1, ahead of all other manufacturers, in quality, support, lack of need for repairs, and so on, by leading consumer organizations like Consumer Reports) will be a major coup for Apple.

In closing, your incorrect analysis is unfortunately somewhat common. I hope this helps to clear things up. - das@doit.wisc.edu

This article's problem isn't POV. The problem is the fact that it isn't an encyclopedia article; it's an essay full of opinion and analysis. It needs major work. Tverbeek 17:07, 19 Jun 2005 (UTC)

I just finished up some heavy editing of the important bits, and I went ahead and deleted the whole Future section since it's not really relevant to the article, being mostly off-topic analysis. The Hurdles section could still use some rearranging, but most of the POV problems should be fixed now, hopefully. Let me know if there's anything I missed. -lee 05:45, 22 Jun 2005 (UTC)

"Virtual PC, a Windows emulation solution for Apple PowerPC sold by Microsoft, could now enjoy much more success with performance improved through virtualisation rather than emulation. For those customers wishing to achieve a more conventional environment, a dual, triple, or even quadruple boot solution would likely be possible on an x86 Apple device."

Not sure if thisbelongs in the article or not, but it's a fair bet that as soon as the official animal is on the market, a version of WINE will be built for the platform, too (in much the same way as there's a version built for Solaris x86) enabling direct use of Windows applications in OSX.

Unless, of course, that's included and makes WINE totally unnecessary. But I'll also bet anything that Microsoft'll do everything in their power to prevent that from happening.

Dodger 07:55, 23 December 2005 (UTC)[reply]

I added a note about how Macs will be protected from Windows viruses because it doesn't give users admin access by default but it was reverted. It's cited in the Windows XP article in the criticisms section, so I'm going to put it back in. 24.166.150.105 22:04, 29 December 2005 (UTC)[reply]

It is also to note that even being an Administrator, to change something of the system, or install something with "System" privileges you MUST input the administrator password (unless you hack it, but you shouldn't do). However in Windows being an administrator allows any program you execute to get administrator or system privileges. — Claunia 22:34, 29 December 2005 (UTC)[reply]

That’s certainly one of the ways in which Mac OS X’s security is better than that of Windows, but it has nothing to do with the Intel transition. The fear that Intel-based Macs would somehow be vulnerable to Windows viruses is widespread enough to deserve mention, but it is also based completely on misunderstanding. Since the presumed ‘problem’ is actually impossible in the first place, there neither a need for anything else to protect against it, or way in which it could do so. David Arthur 15:07, 30 December 2005 (UTC)[reply]

Impossible? Why? Heck, it isn't even impossible today. The PowerPC bc (branch conditional, using the "branch always" encoding) instruction can be made to act as a big fat nop (do nothing) instruction on x86. With an x86 Mac, you'd only need to look around in memory a bit to determine that the machine is indeed not running Windows. You could even share much of the exploit binary. You can hit other operating systems too while you're at it, as long as they all run similarly buggy apps. 24.110.60.225 06:34, 2 January 2006 (UTC)[reply]

In other words, you’re saying that it would be theoretically possible to write a virus that affected both systems, provided that they had the same security flaws. That doesn’t mean that WIndows-only viruses would magically start affecting the Macintosh just because it has an x86 processor. David Arthur 17:41, 2 January 2006 (UTC)[reply]

First of all, I dearly hope Apple isn't messing with 32-bit. Even Intel supports x86-64 now, so there is no excuse. :-( Anyway, there are lots of ABIs to choose from:

• 32-bit pointers, or 64-bit pointers
• stack only, or N parameters in registers
• caller clean-up, or callee clean-up
• long double: 64-bit, 80-bit unpadded, 80-bit in 96 bits, 80-bit in 128 bits with 64-bit alignment, 80-bit in 128 bits with 128-bit alignment...
• 64-bit values with 64-bit alignment, or with 32-bit alignment
• sizeof(long)==sizeof(void*) like nearly every system, or sizeof(long)==4 like Win64
• if passing in registers, is it N total? Is it N int plus M float, etc.?
• executable stack?
• executable heap?
• position-independant executables?
• size of address space for user code?
• access to thread-local data is how?
• access to system calls is how?
• how are variable-argument functions handled?
• do K+R C functions work fine?
• is there a frame pointer?
• where in memory does executable stuff get mapped? (low 16 MB, low 4 GB, above 4 GB...)
• what about StackGuard, ProPolice, or other stack smashing protection?

24.110.60.225 06:24, 2 January 2006 (UTC)[reply]

If you're curious about the ABI, see the Application Binary Interface section of the Universal Binary Programming Guidelines. That section says it's like the System V ABI for x86, with some changes (although it fails to list changes such as "uses Mach-O rather than ELF" :-)).

"Access to system calls" is "through dynamically linked procedure calls to system libraries", just as is the case in the SV ABI (except for _exit(); I suspect the OS X ABI doesn't include that exception, and I'm not even sure why the heck it's in the SVR4 x86 ABI - at least when I was at Sun, the intent was that the ABI would be based entirely on procedure calls, that being why the mechanism for having an "interpreter" section for binaries, so the C startup code doesn't have to make system calls to load the run-time linker). Guy Harris 22:56, 11 March 2006 (UTC)[reply]

Even having BIOS currently in PCs doesn't allow boot sector viruses to be effective. They work in real mode, and as soon as the operating system switches the cpu to protected or long mode, the virus code has no effect at all, as its memory is reclamed by the supervisor (the protected mode OS) and it get overwritten. If you design a virus in protected mode, it will not allow a protected mode OS to load, so it cannot spread also. PC boot sector viruses are only useful while running DOS or another real mode OS. —Claunia 13:47, 4 January 2006 (UTC)[reply]

No, here is how: First be in real mode, and hook the BIOS calls to read from the disk. Start the normal boot loader (MacOS X, Windows 2003 Server, Linux...), letting it do it's thing. Watch as the boot loader loads in the OS. When the boot loader loads in the last bit of the OS, patch the OS image in memory. Let the OS switch to protected mode. The OS will call back to the virus, since it has been patched. As the system continues to boot, keep adding hooks. Eventually you'll have the system call table patched, etc. AlbertCahalan 08:02, 5 January 2006 (UTC)[reply]

We don't get boot sector viruses much anymore because we don't often trade and boot from removable rewritable physical media. The floppy is mostly dead, and the BIOS probably isn't set to boot from it anyway. AlbertCahalan 08:02, 5 January 2006 (UTC)[reply]

Most protected OSes (all but Windows 9x) clear all memory, don't call to real mode code at all and are somewhat closed source (most), making boot sector viruses unfeasible.

They will work if made as you described AlbertCahalan, but will be limited to ONE operating system ONE revision.

—Claunia 08:45, 5 January 2006 (UTC)[reply]

It's often easier to deal with closed-source, because a closed-source kernel is constrained to have a stable driver ABI. Data structures in the kernel are much more predictable. Linux data structures vary with the compiler version and about a zillion different compile-time config options. Being multi-OS means that you package up two versions of the OS-specific code. It's usually easy to avoid the memory-clearing problem, since an OS typically asks firmware (BIOS,OpenFirmware,etc.) for the memory layout. The tricky thing is to find the right moment to patch into the OS. Considering a Linux example (which is somewhat impractical because of the volatile ABI), you'd first use real-mode code to patch in around/after the kernel's decompression code. When the decompression is done, you get called in protected mode. Relocate yourself to some place reasonably safe, being sure that it will be mapped in the page tables. Then you might scan for the idle loop (via disassembly) and patch yourself in there. When that patch gets called, scan for symbol table data and hijack a built-in kernel task. MacOS X is probably fairly similar. AlbertCahalan 10:13, 5 January 2006 (UTC)[reply]

Now that it is confirmed that intel macs are using Extensible_Firmware_Interface, does this rule out the possibility of running Windows XP without any kind of virtual machine program? --Windsok 13:37, 11 January 2006 (UTC)[reply]

Confirmed where? —Claunia 13:40, 11 January 2006 (UTC)[reply]

http://developer.apple.com/documentation/MacOSX/Conceptual/universal_binary/universal_binary_diffs/chapter_3_section_10.html --Windsok 13:48, 11 January 2006 (UTC)[reply]

Thanks. —Claunia 13:54, 11 January 2006 (UTC)[reply]

Found some information of (future?) microsoft support of EFI http://www.microsoft.com/whdc/system/platform/firmware/default.mspx , Apparently Lornghorn/Vista beta already supports EFI on x86? --Windsok 14:06, 11 January 2006 (UTC)[reply]

Pretty much, but I don't see that it matters. (just writing your own Windows XP boot code should do the job -- I think it's HAL.SYS and NTLOADER.SYS you need to replace) Much more interesting and useful: Linux has EFI support. Normally this is only used for the Itanium systems, but using it for plain x86 should be doable. AlbertCahalan 05:38, 12 January 2006 (UTC)[reply]

Teorically taking the NTLDR of Windows IA-64 should just work, as EFI bootloaders are bytecode and not machine code.

Also making a mini boot loader that simulates a minimal BIOS to load the IA-32 NTLDR should be enough.

HAL doesn't need to be modified, because as soon as NTLDR has loaded the kernel and drivers (HAL inclusive), NT doesn't use BIOS at all, but directly accesses the hardware.

—Claunia 15:03, 12 January 2006 (UTC)[reply]

P.S.: Currently ELILO (Efi LInux LOader) is able to load Linux for both IA-64 and IA-32. Don't know about x86-64 (is there EFI for x86-64 currently?)

—Claunia 16:25, 12 January 2006 (UTC)[reply]

See Talk:Apple-Intel architecture#New article. —Ævar Arnfjörð Bjarmason 16:03, 12 January 2006 (UTC)[reply]

Ok, so what about the recent Apple/Intel commercials? Maybe some comment on the controversy about them would be appropriate? Or does it belong in another article?

Most of the work of the Advanced Computation Group has been directed toward high-end applications of PowerPCs. What will happen to them? I raised the question in the ACG article, but do not know if there is a publicly-known answer.

Does anyone have the video of Jobs announcing the Intel transition? McDonaldsGuy 01:12, 26 April 2006 (UTC)[reply]

Would that be the WWDC 2005 keynote? (Found with a Google for "video wwdc 2005 site:apple.com".) Guy Harris 08:56, 26 April 2006 (UTC)[reply]

This article mentions lack of registers as a drawback of x86. Is this still true in Core? Exactly how many registers do Conroe/Yonah/etc have compared to Pentiums or PPCs? Frankie

Intel Core Duo and Solo (Yonah) are IA-32 processors, with 8 count 'em 8 integer/pointer registers, the same as other 32-bit x86 processors; POWER/PowerPC has 32 integer/pointer registers (or 31 - I forget whether one of the registers is a hardwired zero). Intel Core 2 processors, such as Conroe and Merom, as well as the other upcoming Intel Core Microarchitecture processor, the Xeon Woodcrest, are EM64T processors, and, in 64-bit code, have integer/pointer 16 registers. 32-bit code on AMD64/EM64T processors can still only use the first 8 of them, however. Guy Harris 18:10, 1 June 2006 (UTC)[reply]

Aha, I see, it's a hardcoded legacy thing. Well, that's just plain craptacular. Frankie

Does this mean that macs are essentially going to become PCs? Other than an x86 compatible CPU, what qualifies a computer for being a PC? The QBasicJedi 04:17, 18 June 2006 (UTC)[reply]

Yes, in terms of hardware, all new Macs are now PCs with the exception of a couple of models still to be updated, and Apple has stated this will happen in 2006. The main difference at the moment is the start-up firmware. Apple adopted the latest Intel standard EFI, but Microsoft later decided not use it for 32-bit software, so some extra software (e.g. Boot Camp) is needed to install Windows on new Macs.--agr 17:29, 18 June 2006 (UTC)[reply]