Crisis Averted!

Just when I was on a virtualization roll using VirtualBox for testing IE on my Mac, Microsoft stopped me dead in my tracks. The latest version of Internet Explorer Application Compatibility VPC Images now have the anti-piracy features of Windows Genuine Advantage enabled.

The hardware signature detected when a VPC image first boots in a non-VPC host is different from the signature present when the image was first created, presumably in VPC. This difference triggers WGA's re-activation requirement to make sure you're not a dirty pirate. Of course you're not a dirty pirate, but if you wish to re-activate Windows you're going to need the original Windows Product Key which isn't provided with the VPC images. Microsoft has effectively blocked end users from hosting the VPC images with anything but Virtual PC.

To their credit, Microsoft has done a great thing by providing these VPC images free of charge, and it makes sense they would use their own virtual disk format for distribution. But it doesn't make sense for them to deny non-Windows (thus, non-VPC users) the ability to use the images.

One of the largest complaints I hear from web developers who work in a non-Windows environment is the difficulty of testing in IE. Until recently, VirtualBox was working quite nicely for me in this regard. Microsoft would be doing another great thing by loosening the reigns a bit. Alternatively, they could release Virtual PC for other operating systems.

Update: Microsoft has added WGA to their IE App Compat images rendering them mostly useless in VirtualBox.

Recently at work I've switched from Parallels to VirtualBox for my virtualization needs. VirtualBox has come a long way recently, and I'm very pleased with its performance and ease of use. Parallels was starting to become noticeably slow, and was generally not working well for me anymore.

At first, I tried to convert my Parallels (.hdd) images to VM Ware (.vmdk) format, which is natively supported in VirtualBox. Virtual PC (.vhd) format is also natively supported. Since my Parallels images are fully licensed versions of Windows XP, I didn't want them to go to waste. Sadly, the 'converted' images were corrupt and weren't recognized by VirtualBox, and I ended up wasting several hours.

I decided to ignore Parallels completely and simply use the free Internet Explorer Application Compatibility VPC Images from Microsoft. I should have done this in the first place, because setting them up was a breeze with the help of the internet and a few helpful how-to articles I found. I could link to those how-to's here but instead I wanted to post my own condensed version of the steps I took setting everything up. Mainly for myself for future reference.

Step 1

Download and install VirtualBox and Stuffit Expander. You can skip Stuffit Expander if you already have a tool for opening self-extracting .exe files.

Step 2

Download the free Windows XP IE App Compat VPC images that you'll need and extract the .vhd images with Stuffit Expander (or your tool of choice).

Using Finder, navigate to /Library/VirtualBox and create a new folder for each image. Move the extracted .vhd files into these new folders.

Step 3

In Terminal, run the following for each image:

cd /Library/VirtualBox/<image>
VBoxManage internalcommands sethduuid <image>.vhd

This undocumented command will avoid UUID conflicts when creating multiple VMs. If you're only setting up one VM, you can skip this.

Step 4

In VirtualBox, create a new Windows XP VM and follow the prompts. When asked, choose Use existing hard disk. Click the folder icon to open the Virtual Media Manager. Click Add and navigate to a .vhd file you extracted and relocated in step 2. Click Select to choose the new virtual disk. Finally, click Next then Finish.

Step 5

Start your new VM. Close/cancel any Windows popups or dialogs that appear. There will be quite a few.

From the VirtualBox VM menu bar in OS X select Devices > Install Guest Additions... and follow the Windows prompts. Reboot Windows when asked.

Step 6

Now it's time to install the network drivers. Why this isn't covered by the VirtualBox Guest Additions is beyond me.

In Windows go to Start > Run... and run the following:

D:\VBoxWindowsAdditions-x86.exe /extract /D=C:\Drivers

Back to Start > Run... and run:

devmgmt.msc

In Device Manager, find Network adapters > Ethernet controller. Right click it, and select Update Driver....

In the Hardware Update Wizard choose No, not this time and click Next. Select Install from a list or specific location and click Next. Check the option Include this location in the search and paste the following into the Location box:

C:\Drivers\x86\Network\AMD

Alternatively, you can choose Don't search ... and navigate to the location manually. Click Finish and you should have a working network connection.

Step 7

In Device Manager, find Batteries > Unknown device. In my case, there were two. Right click each and select Disable and confirm. These appear to be VirtualPC specific. In any case, they aren't really necessary anyway.

Next find Universal Serial Bus controllers > Universal Serial Bus (USB) Controller. Again, there were two. Disable them as well.

Finally, find Sound, video and game controllers > Multimedia Audio Controller and disable it.

Repeat steps 4-7 to set up additional VMs, and enjoy your new VirtualBox goodness.

Coda, the new all-in-one web development tool from Panic is truly a great app. It has tons of useful web development features within reach: text editor (complete with optional fancy CSS editor, syntax highlighting and code completion, and more), FTP client, live preview, terminal and code references (books) all wrapped up into one very slick, very Mac UI.

Despite all these good things, I feel that version control is sorely lacking. Users of TextMate, or other tools with version control integration (Eclipse, etc.), will find Coda's lack of version control a slight setback. Of course, command line access to version control is still possible, and power users won't mind. But, if Coda were to have support for this built right in, I think there are a lot of folks that wouldn't mind that, either.

DisplayConfigX is one of two or three decent tools for making OS X play nice with televisions, with powerful overscan correction settings. However, the documentation is sorely lacking a single sentence that could have saved about 4 hours of my life:

After installing new resolutions and rebooting, you may need to open Display Preferences and re-select the desired resolution.

For whatever reason, the changes I made took hold immediately after rebooting, but the overall display geometry didn't correct itself to compensate. I just couldn't seem to get the settings to do what I expected based on the documented behavior. Switching down to 800x600 and back forced the display geometry to recalibrate.

After about 4 hours of tweaking porches, rebooting, RTFMing, and googling for other folks' run-ins with DisplayConfigX, I figured I should try something different. In hindsight, I feel pretty foolish for not doing it sooner.

At any rate, here are the settings I finally landed on for my Philips 32PF7320A/37 32" LCD TV:

In preparing the recent releases of Jabber::Bot, I had my first OS X experience with using tar to produce a tarball; I had previously only been a consumer of tarballs, at least in OS X.

Using OS X on the command line means dealing with resource forks. Especially when doing things like copying or archiving files for public distribution. Of course, most OS X folks are familiar with .DS_STORE files. They are a nuisance, but generally can be dealt with without much fuss. Resource forks, on the other hand, can be a whole different animal.

Which brings me to my point. In order to create a public tarball, it's a good idea to exclude resource forks. They serve no purpose to anyone but you or another OS X user, who likely doesn't really care anyway. But, tar on OS X (Tiger) likely won't exclude them, even if you specify a proper exclude pattern. Like, say, --exclude='._*'. It took a few attempts, but I finally was able to prod all-knowing Google for a solution. On the command line (that's Terminal, folks):

export COPY_EXTENDED_ATTRIBUTES_DISABLE=true

Then, run tar as you normally would. Maybe tar -cf foo.tar ./foo, or so? Yeah, now you're talking.