Tuesday, October 14, 2008

OSX Community Part 2

Shortly after Apple announced the transition to the Intel platform development kits were provided to select Apple developers. It didn't take long for the disk image to emerge into the wild. It a matter of weeks it was possible to run OSX on commodity hardware although device driver support was severely limited. I built my first Hackintosh based off nearly the identical hardware found in the Intel Developer Kit. 915 chipset, GMA graphics -- nothing fancy. Before Intel Macs had shipped I was using OSX86. Stability was fantastic from day one. OSX is a rock solid platform. As long as your hardware was supported it worked more or less flawlessly however the process of installation & maintenance was, and still is, a major factor to consider.

Initially the major challenge for the OSX86 community was to circumvent Apple's basic copy protection scheme. A kernel extension, called "Do Not Steal MacOS.kext" was responsible for providing a level of hardware lock-in. It did not take long to overcome this. Apple did not put any serious effort into locking OSX to Apple specific hardware. The futility of trying to stay one step ahead of the hacker community was wisely recognized by Apple as a waste of resources. Instead, they opted for maybe the best type of copy protection. A polite request. I believe in retrospect this was the first sign from Apple that OSX86 would be a reality they could accept.

After the initial circumvention of copy protection the next major technical challenges of the OSX86 project was to expand hardware support. Darwin, the open source core of OSX, provided a core set of device drivers (kexts in the OSX world) Interestingly Apple decided not to make any major changes to the OSX kernel to prevent these kexts from working. Darwin provided a limited but flexible core of device drivers that included many popular NICs, audio chipsets, and some limited support for graphics devices.

The design of the Darwin kernel is as elegant as Apple's best hardware designs. The IOKit framework allows drivers to be portable between different kernel versions. The driver is written to IOKit, not direct kernel level calls as you would find in most operating systems. This has allowed the OSX86 community incredible flexibility and freedom. We do not typically live in fear of all our drivers ceasing to work as the IOKit framework provides a stable reference. What happens behind the scenes in the kernel doesn't directly effect the code. Apple made another choice in the design of OSX that aided the OSX86 community -- use of standardized XML based configuration files. It is possible to look inside a kext and quickly identify and edit configuration parameters. Amateur hackers were able to explore and expand the hardware support provided by Darwin simply by plugging in their device-IDs into the proper driver. Quickly hardware support grew from an extreme niche to a relatively robust coverage of most common commodity hardware. The sticking point then and now is support for graphics drivers.

As the two major challenges of OSX were met the need for a better installation method was also in the works. Previously the only viable method to install OSX86 was to dump the raw disk image from the developer kit. This process required a fair amount of work and was quite destructive if instructions were not carefully followed. It clearly was not a viable method if OSX86 was going to interest anyone outside of the hardcore hacker/geek scene.

It didn't take long to get a bootable install CD. Building on the Darwin boot loader, it was possible to mount and execute the OSX installer. From there the challenges were simply to customize the install process. Again, this was made possible by Apple's use of standardized XML configuration files and a well documented packaging format. Over time these install disks have evolved by leaps and bounds -- customized for specific platforms, bundled support for more exotic hardware, and most importantly large community peer support groups. The developers behind JaS, ToH, Kalaway, and iATKOS have built the OSX86 community. Once the EFI nut was cracked it then became possible to use a legitimate OSX install DVD -- the holy grail of OSX86. Work is still underway however we're nearing the point where little or no hacking will be required to the core installer.

The EFI issue started as a source of frustration for the OSX86 community. Apple was the first company outside of Intel with their IA64 platform to embrace EFI -- a modern replacement for the archaic BIOS system still used in PCs today. Apple was used to a robust pre-boot environment on the PPC platform (OpenFirmware) When the choice was made to switch to Intel Apple needed something to bridge the gap. While EFI is not as user friendly as OpenFirmware it provides many of the same abilities. The challenge for the OSX community was the relative obscurity of EFI. Microsoft, a major supporter of EFI, fell out of favor with it when Intel's IA64 platform crashed and burned. Intel offered some resources for EFI however very few people had practical experience with it. The real core of the problem stems from the lack of EFI software on commodity PC boards. Hackintosh users continue to use BIOS as the pre-boot environment for EFI. EFI is loaded as a second stage pre-boot environment and then the Darwin kernel is executed. From OSX86's perspective, it is running on a legitimate EFI platform. There are however drawbacks. OSX uses low level EFI calls instead of BIOS calls. However the intermediary EFI solution does not provide a true 100% replacement for BIOS -- and in fact hardware such as disk controllers and graphics cards themselves rely on BIOS. Without going into too much detail this still remains a challenge for the OSX community.

Eventually the long term goal is to move to a 100% native EFI solution. This would require hardware makers to embrace EFI in a way they have not yet done (and realistically have very little reason to do so) The other alternative is for end-users to replace the firmware of their hardware with EFI software if it exists as an option. (again, not very common) Microsoft has recently begun to show more interest in EFI so it is possible in the next couple years we could see hardware makers begin to support EFI.

The OSX86 community should be proud of the progress they've made in a few short years. There only remain a few major roadblocks in the way of a nearly flawless OSX experience. In the next installment I want to focus on what work remains, possible solutions, and the practical design & construction of a OSX86 system.

No comments: