Visual cues and other hints show Vista under the hood
Much has been made, by Microsoft and others, of the significant changes to the Explorer UI under Windows 7. The M3 build provided at PDC lacks certain key features - such as the reengineered task bar - but clearly shows that Microsoft felt the need to do some housecleaning. Printers and other peripherals, including Bluetooth devices, are now managed through a single Control Panel applet, the Device Stage. Some Control Panel items have been eliminated entirely, while others have been shifted around or rolled into neighbouring categories (for example, Security and Maintenance).
Overall, the changes are mostly superficial. Even the new Task Bar is simply a twist on the existing Explorer UI model, not to mention a blatant rip-off of the Mac OS X dock. Moreover, none of Windows 7's UI goodness is the result of any architectural changes to the OS. The underpinnings are still clearly based on Vista, which explains why most Vista device drivers and services install without a hitch under Windows 7 M3. Not all Vista drivers behave, however; see the next section for some potential trouble spots.
Otherwise, Windows 7 operates much like Vista. There are subtle visual tweaks here and there, but nothing on the level of the dramatic XP-to-Vista transition. Ironically, Vista users may be more annoyed by the UI changes than users coming from XP. Because the Windows 7 and Vista Aero experiences are so similar, seasoned users of Vista will be more likely to look in the wrong places for common functions. By contrast, XP users won't be burdened with now-outdated Aero navigation skills.
Potential pitfalls: compatibility woes continues
One of the more surprising results of my Windows 7 M3 testing was the number of unexpected compatibility issues that plagued each stage of the process. For example, Daemon Tools, an ISO image-mounting utility that works great under Windows XP and Vista, refused to install under Windows 7. Worse still, when I tried to work around the problem - by using the Compatibility tab in the MSI file's properties dialog - I found myself stuck in an endless loop of failed installations and mandatory reboots.
The apparent source of the problem - an incompatibility between the low-level CD/DVD-ROM simulator driver (SPD version 1.56) and Windows 7 - was difficult to fathom, considering the kernel composition seemed so similar to Vista's. In fact, when I relayed my experience to some of the Microsoft people on the show floor of the PDC Partner Pavilion, they were equally puzzled. They also seemed alarmed that Windows 7 was incompatible with anything that ran properly under Vista, a reaction I interpreted as tacit endorsement of my understanding of the Windows 7 kernel.
Unfortunately, that wasn't the end of my compatibility headaches. Running under Windows 7 M3 on a Dell Precision M6400 mobile workstation, Skype 3.8 would randomly crash without warning. Skype showed no debug dialogs - it just disappeared. But the worst compatibility issue, and also the most alarming from an architectural standpoint, was with VMware Workstation 6.5.
After installing VMware Workstation on the Dell M6400, I was unable to launch any virtual machines. The VMware UI shell couldn't communicate with the VMware Authorization Service, a problem I eventually worked around by running the shell in Administrator Mode. But this "fix" came at a price: the loss of drag and drop between Windows 7 and the VMware guest OS.
Nor was this the only issue I encountered with VMware Workstation. It seems that the VMware Bridge Protocol - another of those Vista-compatible device drivers you would expect to work unmodified under Windows 7 - was nonfunctional, rendering VMware's bridged networking mode useless. (In VMware Workstation, bridged networking is the virtual network configuration that allows the guest OS to communicate with the host OS.)
As of writing, I have yet to confirm the exact nature of the VMware issues. I suspect the VMware Authorization Service bug had something to do with Windows 7's revamped UAC (User Account Control) system. An attempt to bolster system security by requiring the user to confirm certain common functions via a dialog prompt, the nettlesome UAC has been one of the more unpopular features of Vista.
In Windows 7, Microsoft has responded to the criticism by suppressing most UAC prompts by default. Because VMware Workstation 6.5 was designed to work seamlessly with the older, more intrusive Vista model, my guess is that Windows 7's attempts to suppress UAC breaks the VMware shell's UAC interaction logic; it's no longer able to traverse the various process privilege levels and speak to its Authorization Service component.
Just how many Vista-compatible applications will break in this manner is anybody's guess. But as a person charged with supporting a UAC-aware software product on Windows, I'm genuinely concerned. Even more disturbing are the unexplained driver compatibility issues. If Windows 7 really is Vista at its core - as the close similarity of their System process, memory, and performance profiles suggests - then the fact that Microsoft has still managed to break applications as popular as Daemon Tools and Skype (both have tens of millions of users) is disconcerting and perhaps even alarming. At the very least, it doesn't bode well for Microsoft's promises to make the Vista-to-Windows 7 transition truly seamless.