It will go down in history as one of the more anti-climactic “surprise” announcements. Microsoft’s Windows XP Mode, which was billed as an eleventh hour killer feature for Windows 7, arrived with a thud, thanks in large part to its curious need for Hardware Assisted Virtualization (HAV) support.
The company’s media apologists quickly scrambled to defend the decision, pointing out that most new business-class PCs were shipping with HAV-enabled CPUs anyway. However, this argument did nothing to stem the tide of complaints, both from consumers - who purchased seemingly state-of-the-art, multi-core PCs only to learn that they were incapable of running XP Mode – and from small business customers who wished to leverage the capability on existing, non-HAV-supporting PCs.
A year later, and Microsoft has finally caved to the pressure. Just this week the company released an update to XP Mode’s underlying virtual machine engine – Windows Virtual PC 7 – that allows it to run on non-HAV-supporting PCs. All of which begs the question: Why the bizarro requirement in the first place?
Microsoft’s official line has always been that HAV was necessary in order to ensure an “optimal” end-user experience. However, I suspect a more sinister motive. Specifically, I believe that the “Great XP Mode Boondoggle” was in fact a concession to Intel Corporation – a kind of apology for royally screwing-up with the whole Windows Vista “too fat to fit” debacle
By tying VPC 7 to HAV, Microsoft was helping Intel to discourage small business users from buying low-cost PCs sporting “consumer” versions of its powerful dual and quad-core CPUs – parts that were intentionally neutered in order to create differentiation among the company’s myriad SKUs.
Of course, the whole exercise backfired. Savvy users balked at the restrictions (some even built workarounds using VirtualBox or VMware Player), while small business owners and consumers were left dazed and confused by the various XP Mode “compatibility matrices” that cropped up on the Internet
And then there was the matter of Microsoft’s Enterprise Desktop Virtualization (MED-V). A forerunner to VPC 7 and XP Mode, MED-V does not – and thanks to the aforementioned VPC 7 update, never will – require HAV, ostensibly because enterprise customers would never put up with these sorts of “marketecture” shenanigans in the first place
In fact, XP Mode users can likely thank Early Adopter Program (EAP) customers – many of whom have no doubt been evaluating the VPC 7-based MED-V 2.0 in pre-release form – for this reprieve. Now the only question is whether or not Microsoft will provide updated integration components that allow XP Mode VMs to run with good performance and functionality under the non-HAV update
As of right now, the plan is to not release an optimized integration solution for users of VPC 7/XP Mode on non-HAV PCs. But you can be sure that MED-V customers will get them, and this provides hope that somehow they’ll trickle-down: Either unofficially, through some end-user hack; or officially, as part of yet another “mea culpa” update
Regardless, it’s a good day for Microsoft’s small business customers and end-user consumers. The “Wintel” duopoly tried to foist another bogus restriction on its customer base, and the base fought back.
You balked. They blinked. Chock one up for the little guy!
Figure 1 – Get This and Similar Charts at www.xpnet.com
Posts
12 comments:
I thought that with the exception of Semprons all currently shipping AMD CPUs at the time of Win7's release supported hardware virtualization while at the same time not all of Intel's CPUs (even excluding Atom & Celeron) did.
I would see the situation as an advantage to AMD as apposed to this forcing Intel upgrades.
Maybe this had nothing to do with Intel but it simplified the code.
Obviously this is a good thing. Still, I wonder why AMD didn't get more mention through this whole debacle, for the fact that their entire lineup includes AMD-V support. It just works.
I still found XP Mode to be useless because it wouldn't pass USB devices like transcription pedals and the like. This was not noted in the documentation, so I ended up paying extra to have XP Mode and had to use Virtualbox anyway.
LC808, David, et al:
You're missing the point. Intel disables functionality in order to create stratification within its product lines. So a quad core chip that's targeted at the consumer space (and thus costs less to OEMs) might have identical specs to a similarly configured processor targeted at the business segment, with the only difference being the artificial (literally - they might as well hit it with a hammer) disabling of HAV support.
AMD, for the most part, doesn't pursue such an aggressive stratification program (they simply don't have that many SKUs to differentiate), so the impact to them was minimal either way. However, for Intel, the ability to justify their higher margin parts (by tying them to a popular Windows 7 feature) was a godsend. It allowed them and their OEM partners to steer small businesses away from that el-cheapo quad-core box at Costo (the one with 4-8GB of RAM and seemingly endless disk space) and towards a comparably-equipped (in terms of clock speed/core count) "business-class" PC from an HP or Dell.
It's the worst kind of "marketecture" collusion, and I'm glad to see it finally coming to an end - albeit for all the wrong reasons (i.e. saving face vs. actually giving a damn about customer needs).
RCK
shawnek,
A lot of people have run into these types of limitations, especially with specific USB devices. Not everything is compatible with emulation, and both Sun (now Oracle) and VMware have more experience in this department than Microsoft. Which is ironic since it was Microsoft, and not the other guys, who was more influential in the creation of the USB spec in the first place.
Go figure! :-(
RCK
One of the big problems with running XP mode with hardware-assisted virtualization is that it requires BIOS support and many manufacturers intentionally disable it for marketing reasons. Therefore, even if your CPU supports virtualization, your system vendor has to intentionally turn it on or it won't work. For security reasons, the Intel processors don't allow the feature to be enabled once it has been disabled, so you can't turn it on yourself by writing a register. It's the BIOS or nothing, so you are really at the mercy of the vendor.
I have one Gateway computer that I specifically bought for Windows 7 running Virtual PC. I did all my due diligence on the processor and the motherboard (Intel G33). However, when the system arrived, I discovered that Gateway had crippled the virtualization support and had no plans to fix the problem since it was a "consumer computer."
I have an Intel Q8200 @ 2.33 GHz in my box. After doing some research in Intel's very own documentation it appears that the chip itself is capable of HAV, but HAV is disabled via CPU microcode that is of course illegal now in the USA to reverse engineer (thanks DMCA!).
I can only hope at some point Intel would release an update that would turn the feature on. Mind you, this machine is a business-class Lenovo box, and was advertised as being able to perform excellent virtualization :)
I'm not very upset though, because since I've installed Windows 7, I haven't even given a 2nd thought to going back and using XP for anything.
Jim, thejynxed, et al,
I rest my case. :-)
RCK
@LC808:
The problem was never really with the lower-end processors, after all, there aren't many people lookign to spring for Windows 7, but attempting to run it on a single-core Sempron, and trying to get their XP fix. Most consumers will use what they're given, and won't worry about upgrades, and not only that, most consumers will rather buy something new, than wait/whine until a company updates support, they'll assume it's common practice to obsolete something everything two months.
The real problem was with the fact they required virtualisation, when there are likely plenty of people out there with computers that are powerful enough to run VPC or similar (for example, I have a friend that recently bought an old dual-Opteron workstation, from the Socket 940 period, which doesn't provide AMD-V), and can't use the built-in XP mode.
Randall, Filipe: I strongly agree with you guys for the most part. Except for one point of Randall's...
The point of my post is, my guess is MS was trying to simplify their codebase by chopping out the things hardware virtualization could do for them ignoring home users entirely.
You know, "Don't prescribe to malice what can be explained by incompetence."
Then again you'd think they'd have realized enterprise users wouldn't want to deploy new hardware. So maybe you're right. I could flip a coin on validity of either scenario myself.
Either way it was stupid decision period.
LC808,
I wish I shared your optimism regarding Microsoft's motives. Sadly, I'v seen far too many examples of the company making technical decisions in the name of protecting market share/turf vs. addressing customer needs.
Remember: "DOS ain't done til Lotus don't run!"
RCK
MS should have been backed on this, to force Intel's hand. That was MS's intent, but sadly Intel hasn't backed down, giving MS little choice.
Intel's market segmentation is absurd, extremely poorly communicated, and absolutely detrimental to consumers.
MS's only mistake here was not shipping XP Mode for every version, to make Intel's profiteering even more apparent.
Let's be clear: we should be demanding that all our processors have VT-x, and all our I/O controllers (whether processor-integrated or in a discrete chipset) have VT-d. VT-d in particular can't be faked. It's gotta be done in hardware.
VT-x is desirable because it substantially simplifies VM software (no more need for binary translation), but at least it can be worked around if absent.
Post a Comment