Could Apple make the x86 leap?

The calls to action began early this year when Apple software engineer Wilfredo Sanchez reported that he had successfully compiled the Darwin OS to run on a PC. Internet message boards lit up again in October when Apple (aapl) reported slower-than-expected fourth-quarter sales and saw its stock value plummet.

Darwin is only the foundation of Mac OS X, and does not include such elements as the Quartz imaging engine or the Aqua graphical user interface.

Nevertheless, developers told MacWEEK that Apple could port its next-generation OS to PC hardware with relative ease -- if it were willing to make trade-offs, such as abandoning Classic Mac applications or forcing them to run in a slow emulation environment. Apple -- and Mac developers -- would also face the challenge of managing dual hardware platforms because there would still be a huge base of Macs with PowerPCs.

"If Apple were to devote time and resources to this project, it could definitely be done," said Bob Murphy, chief technical officer for ShadeTree, whose business includes porting other companies' applications to Mac OS X.

Apple declined to comment for this article.

In April, at Apple's annual shareholders meeting, CEO Steve Jobs said that the company had no plans to port the Mac OS to Intel hardware. However, Murphy said that making the move would largely be a matter of rebuilding the Mach kernel -- the part of the OS that talks directly to the hardware -- and writing new device drivers.

"Rebuilding the kernel would not be too difficult because Mac OS X is built on the same Mach kernel that NeXT used," he said. NeXT Software Inc.'s OpenStep operating system ran on x86 hardware.

Sanchez's achievement with Darwin came on one specific PC configuration, and Apple still does not offer PC installers for download. To get Darwin -- and ultimately Mac OS X -- to run on different configurations, Apple would need to develop new drivers for the mouse, CD-ROM, memory controller, and other components. Manufacturers would have the option, as they do now, of making their hardware work with Apple's generic drivers -- if available -- or creating their own.

For Apple, developing the needed drivers would not be a big engineering challenge. "Drivers are straightforward -- I don't think that Apple is facing research problems here," Murphy said.

James Berry of Critical Path Software agreed that creating drivers is a well-understood task but said it would still require a significant allocation of resources. Critical Path offers driver development and Mac OS X porting services.

"Creating these drivers would not be so bad if Apple sanctions a specific hardware configuration for a new x86 Mac," Berry said. If Apple followed its tradition of designing systems from the ground up -- rather than simply porting the OS to generic PC hardware -- its engineers could drastically reduce the number of drivers needed, he said.

Scott Anguish of StepWise, a longtime OpenStep/Cocoa developer, said he believes that Apple would probably take this approach if it decided to embrace AMD (amd) or Intel (intc). "Apple would likely ship a proprietary box instead of going the PC clone route," he said.

Apple uses many off-the-shelf PC components, such as USB, PCI and ATA, and their requisite controllers are all capable of supporting an x86 CPU. However, Apple continues to make its own memory controller, which would have to be redesigned to work in an x86 system, said Chris Cooksey, director of engineering at XLR8.

Because it uses a different addressing scheme from the one used in PC systems, the Mac's current UniNorth memory controller would not provide data in a format that the new CPU would understand.

However, replacing the controller would be relatively simple, Cooksey said, noting that one of numerous off-the-shelf x86-based memory controllers could be used in a new Mac motherboard design.

Apple could conceivably get AMD or Intel to design a CPU that operates on the existing Mac motherboard, but it would be "much easier to change the memory controller than to redesign the CPU," Cooksey said.

Moreover, redesigning the x86 would defeat one of the goals of moving to that hardware -- taking advantage of an economy of scale.

The higher layers of Mac OS X would need some debugging and optimization for peak performance on an x86 CPU. However, developers said the code rests high enough above the Darwin kernel that this work would be relatively straightforward.

Applications written to the Cocoa and Carbon APIs should work fine in a hypothetical Mac OS x86 configuration. However, this wouldn't be the case for Classic Mac applications.

To support Classic, a future Mac OS x86 would require a PowerPC emulator, which would likely suffer the same performance drawbacks seen in SoftWindows or VirtualPC on the Mac. Applications would be stable, but they would run much more slowly than they do on their native processor--and in Mac OS X's Classic environment. (The PowerPC can successfully emulate 68K code because it is so much faster than a 68K processor.)

Moving to a new hardware platform would also create logistical challenges because Apple would still have to support the large base of PowerPC hardware. The Mac OS -- and Mac applications -- would have to be compiled for both processors. However, Berry noted that this could be made transparent to users thanks to Mac OS X's bundling capabilities, which allow developers to store executables for different processors in a bundle that appears as a single application.

How long would it take Apple to make the move? It all depends on resources, Berry said. But he added that "it would be easier to move Mac OS X to another processor that it was to move from Mac OS 9 to Mac OS X."