What an eventful week. As I sit here waiting for countless installs on my VM to get MCMS up and running, I thought I'd take the time to blog about my beloved MacBook Pro.

As some of you already know, I tried really hard when I got my second MBP to like MacOS. I ran exclusively on it for a while, and was running everything under Parallel, and then on Fusion.

The combination of lack of Aero, my mostly windows exclusive world, and with all its bad things the comparatively fantastic outlook (albeit I didn't try entourage), I switched back to full time bootcamp on vista.

After a while though, I realized that no amount of uninstall would reduce my Mac OS partition size, and keeping gigs and gigs of used space around just for the occasional firmware update got me thinking, why am I keeping Mac OS around at all? And as I installed on my main OS way too many beta and alpha of different products, it was time for a big cleanup.

So here's the steps I followed to be running a Vista only MacBook Pro.

1. Install Bootcamp 2.0 from the Leopard DVD. Follow the steps to burn the drivers CD and let it repartition your drive.
2. Reboot with the Vista install CD.
3. Don't install anything, go to the recovery console (on the first screen, instead of Install now use the repair bit.
4. When you're in the console type diskpart to start the disk management utility.
5. Wipe the whole drive completely, removing every volume and partition (yes that includes the EFI partition, but so far I've not seen any benefits in keeping it around, considering the very poor EFI use being done on the Mac).
   You do this by either select drive 0 and clear, or select partition n and delete override until none is left.
6. Once all the partitions are removed, convert your drive to MBR by doing a select drive 0 and convert mbr
7. Restart the machine and go through the installation screen. When asked to select your drive, do not create anything on it, just select the unreserved space and let Vista do the rest.

Bootcamp is actually several components:

• An update to provide a legacy BIOS for non EFI-aware OSs.
• A partition manager with dynamic resizing of HFS+ partitions and NTFS / FAT partition creation capability, with a dual GPT / MBR partition synchronization.
• An install applet that runs the previous two
• A set of drivers packaged by Apple, and containing Apple and other vendros drivers in one big install.

Now I think there's one point that's not been explained much. The reason why you convert your disk to MBR in my earlier point is because GPT is not supported as the boot partition for windows. It's a bit of a pain point to figure it out, and when you switch to MBR you won't be able to install Mac OS on that drive again. The way to make both coexist is to provide both a GPT and an MBR on the drive. The mac partitioning utility supports that, and if you run another tool like Partition Magic you may be able to make everything coexist.

As for me, I don't need or use Mac OS, and finally got all my software installed.

I wonder if using hacks I've seen published here and there, I could run Mac OS in MS Virtual PC? Or maybe install it on an external USB Hard drive?

I just wanted to point people to Joel's Evidence Based Scheduling. A lot of people often misinterpret my rant about estimates being an impossible dark art as going against tracking like the one developed by FogCreek (damn I wish I was attending their talk in London). The reality is that what I'm saying is reflected in the model:

The mythical perfect estimator, who exists only in your imagination, always gets every estimate exactly right.

Most estimators get the scale wrong but the relative estimates right.

And the one I'm the most in tune with.

When the project begins, the technical managers go off, meet with the business people, and come up with a list of features they think would take about three months, but which would really take twelve. When you think of writing code without thinking about all the steps you have to take, it always seems like it will take n time, when in reality it will probably take more like 4n time. When you do a real schedule, you add up all the tasks and realize that the project is going to take much longer than originally thought. The business people are unhappy.

Inept managers try to address this by figuring out how to get people to work faster. This is not very realistic. You might be able to hire more people, but they need to get up to speed and will probably be working at 50% efficiency for several months (and dragging down the efficiency of the people who have to mentor them).

You might be able to get 10% more raw code out of people temporarily at the cost of having them burn out 100% in a year. Not a big gain, and it’s a bit like eating your seed corn. Of course, when you overwork people, debugging time doubles and a late project becomes later. Splendid karma.

This all comes down to estimating a release date, certainly not thinking that your original estimate will be any accurate, because it won't. What do you end up doing?

If you do make a schedule, even before you start working, you’ll realize that you have to cut something, so you’ll cut the easy/fun feature and just do the useful/important feature. By forcing yourself to chose some features to cut, you wind up making a more powerful, better product with a better mix of good features that ships sooner.

I'm feeling happier today. Now go and read Joel, I don't agree with his prose all the time but his articles are deep and show a level of understanding of the writing software process that never ceases to amaze me.

While at TechEd I had lunch with IanG and the discussion around the blurry text in WPF came around. I mentionned that this was due to sub-pixel positioning: fonts are now positioned based on where the font designer intended to put it rather than at the pixel boundary. You gain in accuracy but you loose in sharpness. I also mentioned that fonts were rendered fatter on mac to account for this blurriness, and spent a couple of days wondering if I said somehting very stupid.

So I googled a bit and found where I got some of these ideas. Let me direct you to Joel on Software for the beginning of your cyber journey towards font understanding. I am lead to believe by all I've read that at small font sizes ClearType doesn't respect the font weight and spacing properly in GDI ClearType, while it's respected much better on the WPF ClearType, making it much closer to MacOS X sub-pixel rendering.

The problem, as Joel points out, is that users don't like change. They end up considering WPF text as blurry, when a mac user would find them absolutely appropriate. Should Microsoft backtrack on their ClearType WPF work? The problem would be that to respect the pixel grid, you need a pixel grid, and in WPF you don't have one. Ouch.

One thing I forgot to mention as well is that some of your blurry text comes from using Menus and other windows with transparency. This will disable ClearType altogether and switch to gray-scale rendering. When you wonder which mode each window is, make a screen capture and zoom, you'll see the red and green artifacts. And that includes every menu you use in your application (how's that for a hidden gem).

[Update]

While browsing wikipedia I stumbled on the following text.

Increasingly, new approaches to screen rendering have reduced the importance of extensive TrueType hinting. Apple's rendering approach on Mac OS X ignores almost all the hints in a TrueType font, while Microsoft's ClearType ignores many hints, and works best with "lightly hinted" fonts.

One additional potential explanation of the difference between GDI and quartz sub-pixel rendering.