After months of speculation, Windows 7 was finally unveiled last month at Microsoft's Professional Developers Conference (PDC).
Through a series of well-orchestrated keynote presentations and supporting breakout sessions, Microsoft walked conference attendees through the highlights of its new desktop OS: better performance, an improved user experience, and some nifty media-sharing features. Overall, Microsoft's pitch was quite compelling, and the PDC crowd was practically salivating at the chance to play with Microsoft's latest and greatest.
But after the stage props came down, and after the projectors finally went cold, attendees were left with a pre-beta copy of something that looked less like a new OS than the repackaging of an old one. At least that was my impression after I started exploring the Windows 7 M3 (Milestone 3) bits that came on my shiny new 160GB Western Digital USB hard disk.
The more I dug into Windows 7, the more I saw an OS that looked and felt like a slightly tweaked version of Windows Vista.
Just what was so new about Microsoft's next Windows, apart from a rejuggled UI? Windows 7 appeared to suck memory like Vista, to consume CPU like Vista, and to have the same consumer focus. How would this product be received by enterprise customers, the vast majority of whom had soundly rejected its predecessor? After all, if Vista wasn't good enough for big business, then surely a Vista-derived encore would meet with a similarly chilly reception.
If any pre-beta software ever called for a close look and benchmark testing, Windows 7 M3 was it. With so many questions to answer, and the fate of Windows hanging in the balance, I rolled up my sleeves and dove in. I started by examining Windows 7's innards - the kernel and other low-level structures - then slowly worked my way out to subsystem behaviour and application runtime characteristics. Because one of the focal points of Microsoft's keynote presentation was improved performance, I looked for signs that Windows 7 would be faster, more responsive, and less resource-intensive than the bloated Windows Vista.
The view from inside: a minor tweak to Vista
I began my exploration of Windows 7 by poking around the OS's innards. Using a combination of the Windows Performance Monitor utility and some reference data I'd gathered from Windows Vista and XP, I began comparing the runtime structure and composition of various OS processes and services.
First up was the Windows 7 kernel - a.k.a. the System process. When comparing Windows versions, it's always good to start with the kernel because this is where the most fundamental changes take place. For example, when Microsoft went from Windows 2000 to Windows XP, the System process gained 21 execution threads in its default configuration. Likewise, when Microsoft introduced Windows Vista, the kernel gained 39 execution threads.
In fact, the kernel in each major new version of the Windows OS has spawned a different, typically higher number of threads. So when I examined Windows 7 and found a nearly identical thread count (97 to 100) for the System process, I knew right away that I was dealing with a minor point-type of release, as opposed to a major update or rewrite. This was not 'MinWin,' the mythical, streamlined new Windows kernel that promised a clean break with the bloated Vista.
Next up: the memory footprint for the kernel. Like the System process, memory footprint tends to vary widely from version to version, with successive releases showing an ever-expanding kernel working set. Based on the thread count values I observed in my previous example, I anticipated that the working set would be similar to Vista's. And in keeping with my initial suspicions, Windows 7 M3's System process indeed consumed a similar amount of memory (3.5MB to 4.5MB). So far, the new OS was looking a lot like Vista.
In fact, as I worked my way through the process lists of the two operating systems, I was struck by the extent of the similarities. Key subsystems, including the Desktop Window Manager (dwm) and Client/Server Runtime (csrss), sported similar thread counts and working set sizes. When viewed side by side in Performance Monitor, Vista and Windows 7 were virtually indistinguishable.
Two of Microsoft's selling points for Windows 7 have been improved performance and lower resource requirements when compared to Vista. However, these sorts of gains traditionally have been difficult to realise without significantly modifying the OS at a kernel level, and the telltale signs were showing that the changes were minor. What would happen if I threw some test workloads at this OS?
Benchmarking Windows 7 Milestone 3
To test Windows 7, I employed the DMS Clarity Studio tools suite - the same tools I used in March to show that Vista was 40 percent slower than Windows XP. Using a combination of the Clarity Studio's ADO (ActiveX Data Objects), MAPI (Messaging Application Programming Interface), and WMP (Windows Media Player) Stress workload objects, I was able to simulate a complex, multiprocess workload under Windows 7 consisting of client/server database, workflow, and streaming media playback tasks. I used the DMS Clarity Tracker agent to record system and process metrics during the test scenarios.
All tests were conducted against a 2GB Core 2 Duo (T7200) laptop PC (the Dell XPS M1710) configured to dual-boot between Windows 7 Ultimate M3 and Windows Vista Ultimate SP1.
A nine-way test scenario, involving three concurrent instances of each workload object, turned in nearly identical average transaction times under Windows 7 M3 and Windows Vista. In fact, the scores were so close - less than a 5 percent delta (in favour of Vista) on the database tasks, and a roughly 2 percent delta (in favour of Windows 7) on the workflow tasks - that they fell within what I'd typically consider the margin of error for this sort of test.
An analysis of system and process metrics collected during testing showed both operating systems consuming a similar amount of RAM - 637MB for Vista and 658MB for Windows 7 - across all active processes, while the overall thread count showed a modest reduction under Windows 7 (712 versus 810 for Vista). Interestingly, Clarity Studio's process objects for the database workloads (ADO Stress) spent significantly less time (61 percent less) executing in kernel mode under Windows 7 than under Vista, perhaps indicating that some of the code paths related to Jet 4.0 database access have been moved into user mode.
This could conceivably explain the modest, 5 percent slowdown of these same workloads under Windows 7. The additional Local Procedure Call overhead of moving portions of MDAC (Microsoft Data Access Components) out of the kernel would most certainly be felt by a time-sensitive, looping transactional workload like ADO Stress.
In a nutshell, Windows 7 M3 is a virtual twin of Vista when it comes to performance. The few minor variations I observed during comparative testing are easily explained away by slight tweaks to the kernel (such as the aforementioned MDAC changes); they certainly don't indicate a significant performance overhaul. More important, these variations pale in comparison with the 40 percent gap in performance I've observed between Vista and Windows XP SP3.
From a raw throughput perspective, Windows 7 promises to perform as poorly as its predecessor. 'Pre-beta' notwithstanding, the reality is that any hope for closing of the performance gap with Windows XP is unlikely to materialise in Windows 7.
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.
Lipstick on the pig
So where does this leave us? For starters, we can now say with some certainty that Windows 7 is in fact just a repackaging of Windows Vista - an "R2" release, to use Microsoft's nomenclature on the Windows Server side of the house. Key processes look and work much like they do under Vista, and preliminary benchmark testing shows that Windows 7 performs right on a par with its predecessor. Frankly, Windows 7 is Vista, at least under the hood; if nothing else, this should translate into excellent backward compatibility with Vista-certified applications and drivers.
Except that it might not. The M3 build of Windows 7 breaks all sorts of things that, frankly, it shouldn't be breaking. Worse still, the suspected source of a major compatibility bump - the neutered UAC prompts - is in fact architectural in nature, one of the few truly new features of Windows 7's secure computing stack.
So far, Windows 7 looks and behaves almost exactly like Windows Vista. It performs almost exactly like Vista. And it breaks all sorts of things that used to work just fine under Vista. In other words, Microsoft's follow-up to its most unpopular OS release since Windows Me threatens to deliver zero measurable performance benefits while introducing new and potentially crippling compatibility issues.
IT organizations rejected Windows Vista en masse, and Windows 7 is Microsoft's response. Simply put, it's not enough. Slapping an upgraded UI onto an already discredited OS platform fools nobody and serves only to further alienate the very enterprise customers whom Microsoft claims to be wooing. What the company needs to do is listen to its corporate customers and implement the features that IT shops have been requesting: lower resource requirements, better backward compatibility, and a clear migration strategy from Windows XP. The window for lowering resource requirements in Windows 7 has undoubtedly closed. But it's not too late to fix Vista's spotty support for legacy Windows applications.
Application virtualisation technology is an ideal way to isolate troublesome applications. If Microsoft were to include its App-V bits in Windows 7 - as part of a legacy-compatibility subsystem that could take over when a problem application is detected - I'd take its claims of targeting the enterprise more seriously. As it stands, there's little in Windows 7 that IT shops will find compelling. Most of the new features are targeted squarely at consumers, which is the same formula that got Microsoft into trouble with Vista.
The larger question is what all those Vista refuseniks will do when their hopes for Windows 7 are crushed. Some will undoubtedly give in. After all, you can prop up Windows XP only for so long. However, for many shops, this may be the perfect opportunity to seriously explore the alternatives outside Microsoft. Ubuntu Linux gets more polished each quarter, while Apple hardware and Mac OS X continue to impress technical and nontechnical users alike.
One thing's for sure: Microsoft's once unassailable dominance of the enterprise desktop is wobbling on a precipice. Windows Vista has permanently eroded the company's reputation among IT decision makers, and from what we've seen of Windows 7 so far, Microsoft still does not "get IT".