Converting Enumerations to User Readable Strings in .NET

Suppose you have the following scenario: You have a function that can return multiple return types codes via an enum value. For each of those enum values, you want to inform the user the result of the operation by some user friendly string.

A common implementation I see is some sort of switch statement that resolves enumerations to a string by way of a switch statement or hash table or something. And whenever that string is needed, call into said method.

And although this is viable, this creates a disconnect between the enum and it’s actual string literal definition. In addition, for each new enumeration value, that giant switch statement needs to be updated with a new string value. If there were only a clean way to map an enum to a string value automatically… and there is! With clever usage of attributes, reflection, and extension methods, one can do something like this:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Linq.Expressions;

namespace EnumString
class EnumStringAttribute : Attribute
string myValue;
public EnumStringAttribute(string value)
myValue = value;

public override string ToString()
return myValue.ToString();

static class ExtensionMethods
public static string ToUserString(this Enum enumeration)
var type = enumeration.GetType();
var field = type.GetField(enumeration.ToString());
var enumString = (from attribute in field.GetCustomAttributes(true) where attribute is EnumStringAttribute select attribute).FirstOrDefault();
if (enumString != null)
return enumString.ToString();
return enumeration.ToString();

enum AuthenticationResult
[EnumString("This username is not registered.")]
[EnumString("Incorrect password.")]
[EnumString("Logging in...")]

class Program
static void Main(string[] args)

Delaring string values can simply be done inline, and the usage is simple as well! Just call the new extension method to get your user friendly string!

(Of course, for localization, you may want to map the enum to a string resource rather than a hard coded string value; but a similar approach can be used.)

Language Mavens, Tool Mavens


Recently, a fellow coworker referred me to an article by Oliver Steele about Language Mavens and Tool Mavens. The synopsis is that there are two types of deveopers:

  • Language Mavens are those that leverage a features of the best language to complete the task at hand; the IDEs/tools used do not matter so much.
  • And conversely, Tool Mavens leverage the power of mature, full featured development tools to complete their tasks: an integrated editor, debugger, code refactoring, etc. The language itself does not matter because, it is just the same old set of classes and methods with slightly different names.

Naturally, this led to a bit of introspection, which resulted in the diagram that you can see above: I think I am somewhat between both camps, in that I choose and tend to use a variety of languages on a frequent basis to get my work done. But I find myself more so gravitating towards the languages with the richer tools, because they make suit my programming habits better.


The tool I require a language to have before I even consider touching it is an integrated debugger. Well, to qualify that statement, I require that for applications with complex execution paths and sustained runtimes. That means for bash, Ruby, Perl, and JavaScript, it doesn’t matter, because printf debugging will suffice. [1] However, if you follow this blog, you may have read about my work on porting Mono to Android. Although Mono has a great integrated x86_64 debugger, none exists for the ARM platform. Doing development using Mono on Android is not really a viable option to me until the debugger exists (or I get around to implementing it myself).

The other tool I prefer a language have is auto complete (aka content assist). It’s purpose is two-fold:

  1. When learning a new language/API/platform, content assist severely lowers the learning curve. Instead of hunting down method signatures, class names, and descriptions on Google, it is built into my editor. This ultimately saves me a significant amount of time.
  2. Eventually, when I master the language, auto complete serves a different purpose: it reduces the amount I need to type by a little under 50%. [0] This is interesting, because a language without code completion would need to be able to complete a task in half the lines over a language that does support it before it actually becomes a more efficient use of my time.


As Steele’s article states, C# and Visual Studio, as with everything with Microsoft, is an exception to the rule. The new languages (and features) are released at the same time as the tools. And generally, I find myself getting more excited about the languages aspects, than the tools. For example, with VS 2010 (which should be in beta very shortly I hear), we will get: F#, Dynamic Language Runtime (Iron*!), and full expression tree support in C# (to support the DLR and the new dynamic keyword). [2]

Lately, in various projects, I find myself wanting to do more in the way of code generation. Be it code being generated from a model or modifying/creating new code at run time. So that is what spurred my desire to learn Ruby and Python (of which I currently favor Ruby). Though I don’t think this is something I can not live without.

As for language features that are to-die-for, I find it hard to cope without closures and generics, of which Java has neither. [3] The lack of generics is why I also did not really adopt C# over C++ (templates) until version 2.


Where do you fall as a language/tool maven, and why?





[0] I did this by recording my keystroke count using a free Windows application, and disregarded keystrokes for any navigation or correction keys: backspace, delete, and arrows. Then I compared the results versus the character count of the code written.

[1] Incidentally, I realized I have learned around 5 new languages in the past year. Though I can only claim proficiency in one, the language with the best tools: Java.

[2] Using expression trees in C# to Frankenstein together some new code at runtime seems like there could be infinite Lisp-ish possibilities. Though you can dynamically create new code at runtime using Ruby/JavaScript, you can’t modify or access the expression trees themselves like Lisp. C# doesn’t allow you to look at any expression tree at runtime either, but it does provide language integrated support for building expression trees (and has in a primitive form since C# 3), which can have a similar effect.

[3] Type erasure is not what I would call a real implementation of generics. Anonymous inner classes are not closures.

Gitweb Line Highlighting


I made a few more changes today to support line highlighting of gitweb blobs. Like SyntaxHighlighter, the line highlighting is also completely JavaScript driven. When you highlight a line, it updates the fragment portion of the URL in your browser. Then when you send the URL (with the fragment) to someone, they will see the same highlighted code.

Click here for a sample of code highlighting.

Fun exercise in my quest to catch up and learn JavaScript, CSS, et al.

I couldn’t do this by modifying the query string, because that causes a browser reload when changing window.location. I could perhaps have made a “create hyperlink” button that puts the hyperlink with a modified query string into your paste buffer, but that isn’t as easy as just copying the address out of your browser address bar.

Gitweb Support for SyntaxHighlighter

After getting Gitosis set up on my Hackintosh, I set up gitweb as well. But vanilla gitweb is really ugly; it’s almost as bad as sitting at a console typing the git commands manually. So I spent a good day or so trying to tweak gitweb to work with SyntaxHighlighter. For the longest time, SyntaxHighlighter simply would not work on any page at all. After prodding for a while, I finally figured out that it was due to gitweb.cgi returning the content-type as “application/xhtml+xml” instead of “text/html”.

Click here to see a sample gitweb repository with SyntaxHighlighter enabled. Navigate around the projects, and click any of the language specific blob links (.c, .cs, etc) to see the new highlighting.

// This is SyntaxHighlighter, and
// it now works in gitweb!
if (true)

Head over to my GitHub repository to get my git fork with the tweaked gitweb and instructions!

P.S. This was my first time hacking at Perl. I feel violated.

P.P.S. The Perl brush is intentionally disabled. It is a little buggy.

Setting up a Gitosis Server on OS X

I currently run a Team Foundation Server as my source control management for my Windows based projects, but I found that nigh unusable when doing anything related to Linux and Mac development; as the only way to check in is to have a shared directory on the Mac/Linux system that Visual Studio maps to a project in TFS. Rather clumsy.

Since I started working Android, I slowly became git fanboy. The GUI tools are still unbelievably primitive (as is the case with Linux in general it seems…), but the speed, flexibility, and ease of use of the command line tools and the SCM itself more than make up for that aspect. When I set up a Hackintosh last week, I also purged my computers of all Linux VMs and I forgot to take into account that I might want one running for dedicated SCM and other Linux-ish work. But, I figured, I might as well try installing gitosis and see if it works: gitosis is just a Python script that runs in an SSH session. And, it turns out it does!

These steps already assume you have git and Python installed by way of MacPorts.

As I mentioned before, gitosis is actually run in a restricted SSH session to provide the repository access, and RemoteLogin is Apple’s implementation of an SSH daemon/server. So, the first step is to make sure you have Remote Login and Remote Management enabled on OS X:


I prefer to keep my git repository in a case sensitive partition/image. I recommend you do the same, as there may be issues otherwise. But, OS X can’t be installed on a case sensitive partition, so you might need to repartition your hard drive to include a case sensitive partition:

WDC WD3000GLFS-01F8U0 Media

Now, let’s add a “git” account that will own the repository and provide repository access via SSH. This can be a standard user account. You should not run gitosis under your account, because it restricts shell access to the SSH session, limiting it to gitosis-serve. (You should also verify that the git account has remote login access in the Sharing section, although it should available by default.)


Now, let’s set up gitosis. The steps are very similar to the ones found at the site I referenced. Let’s drop to a Terminal. If you do not have an SSH key yet, generate one now with ssh-keygen.


Download and install gitosis:

mkdir ~/src
cd ~/src
git clone git://
cd gitosis
sudo python install

By default, gitosis creates repositories in the ~/repositories directory of the “git” user account. And OS X by default places user HOME directories on the case-insensitive partition. Let’s create the repository directory on the case sensitive partition, and create a ~/repositories symlink to it:

sudo mkdir /Volumes/PartitionName/repositories
sudo ln -s /Volumes/PartitionName/repositories /Users/git/repositories
sudo chown git /Volumes/PartitionName/repositories
sudo chown git /Users/git/repositories

Next we need to make sure the git user has the proper directories in its PATH variable (or you may get a gitosis-serve not found error). We add them by modifying the ~/.bashrc file located at /Users/git/.bashrc:

vi /Users/git/.bashrc

Insert the following into the file:


And make the owner “git”:

sudo chown git /Users/git/.bashrc

The last step is to initialize gitosis and give yourself access to it by adding your public key:

sudo -H -u git gitosis-init < ~/.ssh/

This should give you a working gitosis installation! Administration of the git repository is done by checking out the gitosis-admin repository from git, making changes to the config, and checking back in. That is incestuously cool! So, if you can check out the gitosis-admin directory, that means everything is working great:

git clone git@your-host-name:gitosis-admin.git


Hopefully that worked. If so, you can begin editing the gitosis.conf file to create more repositories and add users. More information about how to set up repositories and access can be found here.

Building a Hackintosh from A to Z


Before we resume this tutorial, let’s take a moment of silence in memory of PirateBay.
*Half Second Pause*

Continuing On – Boot 132 Installation

One of the weird things about the tools available to get OS X running properly on x86 hardware is that they are all written for the OS X. A bit a of a chicken and the egg problem: how do you exactly use those tools if you can’t install in the first place? This was also one of the first oddities I encountered in the primary guide I used for my installation: the guide calls for you to install a hacked installation disc of OS X prior to doing a Boot-132 installation. And in retrospect; it makes sense: the hacked discs are easy to install are just used as a bootstrap/failsafe/utility in case your actual Boot-132 installation goes awry. The reason I am bringing this up, is so that the prerequisites to the installation make more sense.

Step 0: Prerequisites

  • Two hard drives – It must be two hard drives, not two partitions. The installation will involve installing both the hacked install CD as well as a Boot-132 installation. Boot-132 involves creating and tweaking the aforementioned modified EFI boot partition. So if something goes wrong with the boot partition, using two partitions to do the installation would just result in two busted installations. So, that is why you should have two hard drives for this process; one hard drive will contain a backup installation and boot partition. Use the slower/cheaper/crappier hard drive for your hacked CD installation, and the good one as the target of the Boot-132 installation.
  • Patience – You will need a lot of this later on in this guide.

Step 1: Hardware Setup

Make sure both of your hard drives are connected to your PC. Have your crappier hard drive as the second one in the boot order. Remember that there will be be two OS X installations, and we are starting out by installing the hacked installation, which goes on the crappier drive. We don’t want to boot into this one automatically because once everything is said and done, this will not be the primary installation.

Step 2: Installing iDeneb v1.4 (OS X 10.5.6) [3]

Here is the guide I used to do my iDeneb installation. Much of my information came from here. I recommend also reading through that as it comes with pretty helpful pictures and such. But be mindful to follow the instructions regarding partitioning on this section of the blog, as the final setup will be different from the linked guide.

Download iDeneb 1.4 torrent off of PirateBay (if it is still around) and make a CD from the ISO.

Boot off the iDeneb CD. Hopefully you will not see the “waiting for root device” problem during boot that some people get. I personally ran into it on one installation. The issue resolution varies from computer to computer. For me, I resolved it after much hair pulling by hooking up my CD-ROM to the SATA-0 connector.

Once iDeneb is loaded, keep hitting Continue/Agree until you get to the point where you choose an installation disk. From the menu, choose Disk Utility. Verify both of your hard drives are visible in the list. Partition both drives with the following:

GUID Partition Table (this can be found under Options). The first/installation partition of each drive should be Mac OS Extended (Journaled). [0]

Name the crappy partition “Recovery”. Name the good partition that will have your retail installation “System”. Well, you can name them what you want, but that is what I called them and how I will refer to them in this guide.

After partitioning both disks, choose the crappier disk as the installation target, and continue. You should now see a OS X disk with an arrow pointing to a hard drive. Don’t press Continue yet! First press customize. At this step, you need to choose the .kexts that you will add in as part of the installation process. Make sure you choose the appropriate ones for your motherboard, video card, and network card. Don’t worry about sound and any other random peripherals; it doesn’t matter if those do not work. Keep in mind that this step is just to get a booting OS X installation, preferably with working internet access (if not, a USB drive to transfer stuff over from another computer works too).

My Personal Computer Setup [1]:

  • Core i7 920 Processor
  • Gigabyte EX58-UD3R Motherboard
  • NVidia 9800GT Video Card
  • 6GB RAM
  • 2 SATA Hard Drives

In my case, I chose the following from Customize:

  • JMicron ATA (motherboard)
  • Realtek R1000 (network)
  • NVInject 512MB (video)
  • Voodoo Kernel
  • Fonts
  • Applications

Once you have chosen the proper setup for your machine, press continue to finish up the installation. At the end of this, you should a working OS X installation that will be used to bootstrap the actual installation. Do not ever run the Apple Update software on this installation. It will break it.

Step 3: Installing from the Mac OS X Retail Disc

As I mentioned in the previous post, you must have a retail disc. You probably can’t install off an OEM disc because that is a stripped down version of the installation tailored to a MacBook/MacPro.

Insert the disc into your Hackintosh running iDeneb. It might automatically start up the Installation Menu. Close that out. You don’t want to run that as it will try to restart your computer and install, which will fail miserably. Instead we will install retail OS X on a separate disk from under the current running OS X installation. To do this, open Terminal from Applications and type the following [2]:

cd ‘/Volumes/Mac OS X Install DVD/System/Installation/Packages’

Now type:

open OSInstall.mpkg

The menus should look familiar, as they will be very similar to the previous iDeneb installation. Choose the good hard drive for the retail installation. Don’t worry about formatting/partitioning it, as you already did that during the iDeneb installation. And once again, choose customize before starting the installation. But this time, you will not be presented a list of drivers and tweaks for your computer like you were with iDeneb. Instead you will see the list of OS X installation options. I recommend unselecting all the printer drivers (they are all selected by default and total to an extra 3GB). This will make the installation go much faster. Now continue on with the installation.

Boot-132 on your EFI partition

You might be tempted to reboot now into your OS X installation on your main hard disk. But don’t! It won’t even boot, because there is no boot loader set up on that disk yet!

Download the EFI Boot Installer. Credits to Wolfienuke for writing this; don’t download the v3 version from his post though: there were several bugs that made the scripts not work properly for me. I ended up patching them, notifying him of the fixes, and then uploading the fixed/linked version to my site.

When you unzip the EFI Boot Installer, there are two things of interest:

  • Extensions – This folder contains the .kexts for your machine. The download currently contains the .kexts I use for my setup. They probably won’t work for you unless you have the exact same hardware. Typically you will want to download the .kexts that work for your hardware.
  • install.command – Run this to set up your EFI boot partition. Don’t do this yet though.

Step 4: Extensions

First, delete or move all the Extensions that I provided. You will probably want to start from scratch, unless you are using my motherboard.

Ok, above I mentioned that installing OS X requires patience. And that is because finding the .kexts that work for you can be very tedious and induce insanity.

Basically, first start off by googling and downloading the .kexts for your motherboard, video card, and network card. Don’t worry about peripherals at first; let’s just get a working retail installation. That’s all the advice I have for you: Google wisely and dig through the search results on the InsanelyMac forums.

Step 5: Using the EFI Boot Installer Tool

Now that you have the proper .kexts, it’s time to set up your boot partition.

  1. Double click the install.command, and you will be asked for your administrator password.
  2. It will ask you which disk your OS X installation is on. Choose your “System” partition.
  3. When prompted whether you are choosing Installing or Updating, always choose Install. There seem to be bugs in the script with the Update, which I did not bother to fix.
  4. When asked if you would like to edit, once again, always choose yes and select the following:
    • mach_kernel
    • Press enter for boot flags, but you may want to tweak this if you don’t have an i7 920 processor. If you don’t have an i7, simply use “-v”. If you have an i7 better than the 920 or are overclocking, you will need “-v busratio=X” where X is the clock multiplier you are using for your processor. You can look this up in the BIOS.
    • Press enter for timeout.
    • Press enter for EFI String. More on this later.
  5. Press enter (no) for increasing version numbers. I have tried this, and this just caused problems. Not sure what it is for.
  6. Press “y” to continue.
  7. Before rebooting, first peruse through the install.log and see if there are any glaring errors. There generally shouldn’t be.
  8. Now confirm the reboot.

Up until now, you have been choosing your second hard drive from the boot menu. You can now finally choose your first hard drive. If you have the proper .kexts, your retail installation will boot properly.

Step 6: More on Extensions

Hopefully your retail installation is working (somewhat). In which case, you will want to set up the rest of your connected devices. Navigate to your Recovery disk, and find your EFI Boot Installer folder. You will need to go searching for .kexts for your Sound card, power/sleep fixes (maybe), and whatever else you may have. Rerun the EFI Installer in the same fashion after updating your Extensions directory with the new .kexts, and reboot. Keep doing this until you have a working system. :) [4]

If at any time your retail installation stops working, simply reboot into your Recovery disk and undo whatever change you made to the EFI Boot Installer, and rerun it to recover it! (Now you should understand why you need that second install, haha.)

Extra Credit:

EFI Strings

Another method discussed on InsanelyMac for getting OS X to recognize your hardware is the usage of EFI strings. I’m not really sure how it works beyond that. Although my video card (NVidia 9800 GT) worked for the most part when my retail install, dragging windows left some strange transparency related artifacting. I fixed this by using this guide to find the EFI string for my video card. Once I got the EFI string, I placed it into the efistring.txt found in the EFI Boot Installer and reran the tool.

Using VMWare and Parallels

If you want to run VMWare and Parallels to run Windows, it will probably cause your system to kernel panic due to using a custom kernel which is found in the EFI boot partition, and not at the usual /mach_kernel in normal installs. I fixed this by copying the custom kernel to the expected location by doing the following:

  • cd /
  • sudo mv mach_kernel mach_kernel.old
  • sudo cp /path/to/efi/installer/Kernels/mach_kernel .
  • sudo chmod 644 mach_kernel
  • sudo chown root mach_kernel

This got Parallels working for me I haven’t tried VMWare, but that should work for it too. If not, you can also try running:

  • sudo /Library/Application\ Support/VMware\ Fusion/ –restart


Well, that’s it. I realize the guide probably won’t give you an exact set of steps that will for-sure get OS X running on your PC hardware. There’s no magical way to get a retail OS X install without some blood sweat and tears towards finding your perfect .kext combination. But hopefully the information found in these two posts helped you understand how things work, so you aren’t just poking in the dark twiddling random settings praying something works. :)

And, feel free to run Apple Update on your retail install; unlike the hacked installation, it will continue working properly and not break because your critical system files are on a partition that Apple does not touch.



[0] You can not install OS X on a case sensitive partition.

[1] The .kext files I will provide at the end of this tutorial will apply to only my computer. Though if you have similar setup, you can probably scavenge some of them.

[2] The blog is munging my quotes. Both quotes are single quotes, the button to the left of Enter.

[3] If you have problems installing iDeneb, you can also try iPC, iAtkos, or Kalyway. One of those is bound to work well enough. You only need it to be able to boot and read your CD-ROM and ideally have network access.

[4] I still have not managed to get sound working on my motherboard, Gigabyte EX58-UD3R. I don’t really care though, as my headphones are hooked up to my laptop anyways.

Have Your Cupcake and Eat It Too


Google released the Android 1.5 SDK today. They also pushed their internal Cupcake branch upstream to the main Android project! I sync’d up my repository and started the build. I ran into an issue with not being found, so I patched the build process to pull it off the device. I’m not sure if that is the right solution; but it builds and runs!

The immediate differences I noticed: the UI scheme has changed significantly. It looks considerably better than before. The soft keyboard seems to be out of the prototype stages and is fairly usable as well.

Click here for a zip file containing the Cupcake images. I recommend also downloading the cupcake scripts I wrote up to flash to a phone or run in an emulator.

To flash to a phone using my scripts on a Windows system, extract both zip files into the same directory and simply run while your phone is in fastboot mode [0]:


To run the emulator, you must have the Android SDK:


The directions are similar for Mac/Linux (,

[0] To start up in fastboot mode, you must have a rooted/dev phone and the engineering bootloader. Turn your phone off, hold camera, and press power. Then connect your phone to you computer and press the Back button.

Building a Hackintosh from A to Z

I’ve been slacking on this blog. I guess you can say my computing life has been in a state of turmoil recently. A mid-life crisis per se. After much soul searching, I decided to write my first check to the embodiment of all that is evil, the reincarnation of Skeletor, Steve Jobs. For a long standing zealot of the Microsoft Windows camp, this is perhaps the highest form of treason.

skeletor jobs

Anyhow, this post isn’t really to talk about why I switched; my Windows machine didn’t go anywhere. It is just sitting in a VM in my Mac now. All said and done, I am now a somewhat proud owner of a MacBook, iPhone, and… a Hackintosh?

Building the Hackintosh has been one of the most frustrating experience of my life. This was mostly due to the combination of my utter lack of knowledge of the subject matter and the abysmal quality of the guides that are available. Speaking of the OSx86 guides. They are perhaps the most poorly written, ill-explained walkthroughs ever written. They are only somewhat useful if you have read every last one, and have been failing at your OS X installation for 4 weeks. Those 4 weeks consist mostly of copying and deleting .kexts and twiddling various settings randomly. Consider it the bar to entry.

So, I made a commitment, that if I ever managed to get OS X working properly on my desktop, I would write a guide that did not suck. So here I am today.

As a precursor, the files on this guide apply specifically to my computer setup. Although the general information about the topic should help others understand what is going on, so they just aren’t poking blindly in the dark when trying to get OS X working.


Installing OS X: Two Methods

You can install OS X on Pentium 4, AMD, Core2 and i7 processors, with generally no problems (though I would recommend Intel chips for better support). However, there tend to be some issues with chipsets. For the most part, Intel based motherboards seem to work fine. However, non-standard motherboards, in my case the NVidia nForce 790i SLI, may have issues. (There are currently no working SATA drivers for this board.)

Hardware compatibility is obviously the major hurdle for OS X installations. Macs roll off the assembly line, with mostly the same set of hardware from machine to machine. As such, there’s a very limited set of drivers available for the platform. To work around this, hackers have spent significant time porting and implementing drivers to OS X. The annoying part is finding that special combination of .kexts that work for you and your machine.

Putting the driver issue to the side for now; there are two methods to install OS X:

  • Hacked Installation Disc – There are currently four popular hacked/custom OS X discs: Kalyway, iDeneb, iAtkos, and iPC. These discs come prepackaged a custom installer, sometimes a custom kernel (voodoo), and a variety of drivers. These installation disc torrents can be found on everyone’s favorite torrent site. Because the discs come with basically everything you need on them, and the hard work done, you can more or less just pop it in and get a running system fairly easily. The downside to this method is that since various system files and drivers are modified, Apple Software Update can easily break this installation, turning your computer into a paperweight until the files are restored. This makes it a very brittle installation.
  • Boot-132 – This is a fairly new installation method, and as such, the tools and guide regarding this are not very well developed or explained. But, this method is not as brittle as the aforementioned. Updates from Apple are very unlikely to break your installation.

Boot-132 Explained

Boot-132 works by storing the modified kernel and kernel extensions (aka .kext files aka drivers) on a boot disk. This boot disk starts up and then loads OS X under its modified system environment that is compatible with non Mac hardware. Since the modified environment is contained in the boot loader, this allows users to install OS X from directly from the retail CD [0] and without any modification to the installation itself! This boot disc is commonly a CD or a USB drive. [1]

Recently, a technique has been developed that allows users to store the Boot-132 boot loader and system files in a special partition of a GPT format disk.

Partition Tables (and GPT) Explained

When you partition a hard disk, the disk uses a partition table to contain the disk layout/volume information. The primary partition format found on Windows is Master Boot Record. However, Master Boot record is getting a bit long in the tooth, and the new standard is GUID Partition Table (GPT). This is interesting because GPT partitioned disks must have a 200MB EFI System Partition. This partition contains the disk’s boot loader, and is generally hidden from the user, and currently unused and untouched by most operating systems; as is the case on Mac OS X. This means that system updates will not meddle with and patch your critical system files.

Thus, the EFI partition is the perfect place to store the Boot-132 modified system files.


Stay tuned… Building a Hackintosh from L to Z coming soon.

[0] The Boot-132 install must be from a Retail CD. The OEM CDs that ship with MacPro or MacBook are stripped down versions of the OS tailored specifically to that hardware. They will most likely not work if trying to install off of them.

[1] There is a product called EFI-X that claims to magically turn your computer into a Mac by plugging their “BPU” or “Boot Processing Unit” (wow, what a joke) into your USB drive. This, in reality, is simply a USB drive with a Boot-132 loader. Boot-132 is free. A small USB drive goes for around $10. The company sells their BPU to uninformed masses for $340. And it generally doesn’t even work. Thanks to Karma, EFI-X got into some legal hot water and had to shut down their US office.

Continue on to Part 2 of Building a Hackintosh from A to Z.