Windows 7: The 'Dog Food' Tastes Bad

Not wanting to rag on something publicly that I hadn't experienced intimately myself, I decided to take the plunge (called "eating your own dog food" in developer parlance) and see if I could move over full-time to the new Windows 7 M3 pre-beta. After all, with an essentially unmodified kernel and no major changes to the security model, how bad could it be?

Apparently, a lot worse than I thought. After successfully backing up my notebook (Complete PC Backup in Vista is perhaps its single best feature), I fired up the Windows 7 DVD and had the new OS installed in about 25 minutes. Then the fun began.

[ Also read Randall C. Kennedy's earlier blog post "Windows 7: Oops! Microsoft did it again." ]

My first compatibility roadblock involved Daemon Tools. One of the most widely used ISO-mounting utilities, Daemon Tools is a core part of my day-to-day compute stack. It's how I install software into any new system (physical CDs and DVDs are so yesterday), and as such, one of the first things I add to a new installation.

And it broke. Not in any minor, cosmetic way, either. It broke big time. The core "SPD" driver -- kernel-mode component used to simulate a physical CD/DVD drive -- refused to install. This came after I had forced the installer to continue by enabling the "Windows Vista RTM" option in the compatibility tab for its disk file (otherwise, Daemon would refuse to even attempt an install).

In the end, I was able to work around this by installing a competing utility -- Virtual Clone drive. However, that sour taste of a failed transition was already building in my mouth. So when Skype 3.8 started freaking out (randomly crashing a few minutes after initial program load) I knew I was in trouble. The solution here was to download the Skype 4.0 beta. But since like most people I hate what Skype has done with version 4.0 (we're all praying it changes course away from that awful new UI), this was far from an ideal solution. Still, not a show-stopper.

What was a show-stopper was VMware Workstation 6.5. As a software developer and reviewer, I live and die by my ability to create and deploy virtual machines. It's how I review most software packages and also how I test my own code before moving it to a physical machine. So when VMware got all flaky under Windows 7 M3, I started reaching for my portable USB drive -- the one with the Windows Image Backup folder on it.

You see, VMware didn't just get quirky under Windows 7. It became unusable. First, it wouldn't start any of my existing VMs, ostensibly because its privilege requirements or security model was incompatible with the new "neutered" UAC (fewer prompts but more confusion as to what's actually going on behind the scenes). But what really got me steamed was the inability to use the bridged networking option. Though the bridging protocol was present and installed on the desired target adapter, VMware Workstation couldn't see the adapter -- there was no entry for it in the Virtual Network Editor screen, leaving me with NAT and Host Only as my only network options.

In the end, this was the straw that broke the camel's back. I can tolerate a lot of things, but breaking VMware isn't one of them. And since each new version of Windows seems to do exactly that -- break VMware's networking stack -- I'm starting to wonder if there isn't something malicious going on here, sort of like how Microsoft would deliberately break QEMM with each new version of DOS-based Windows.

Regardless, my real takeaway from all of this is that, despite leaving the core Vista kernel and driver model intact, Microsoft is still finding ways to break applications. So much for the whole "seamless transition" promise to Vista users. I can only hope that things get better before RTM or even the official beta launch. But, frankly, even at an M3 revision level, this sort of incompatibility nuttiness simply shouldn't exist -- not for an OS that is just a lipstick tube away from its piggish predecessor.

Subscribe to the Best of TechHive Newsletter

Comments