One of Windows 7’s most publicised new features (announced in the Release Candidate) has been XP Mode, which allows users to stream virtual legacy applications to the Windows 7 desktop. We interviewed Jeff Alexander, an IT pro evangelist with Microsoft Australia, to get some extra information about how this feature will benefit businesses and IT pros. We also spoke about how Microsoft has changed its internal development structure to produce a better, more stable operating system and to avoid the nightmare of bad publicity and perception which surrounded Windows Vista from RTM.
James Bannan: Looking at Windows 7 RC from an IT pro perspective, what are the features which excite you most and why?
Jeff Alexander: Well, the biggest one is XP Mode, and the reason for that is because we now have an easier way to get people across to the new operating system, but be able to still run their old XP applications which might not be compatible with Vista or Windows 7. XP Mode is essentially Windows Virtual PC with a pre-configured XP virtual image, and it’s very tightly integrated into the operating system.
When you look back on the issues which probably caused people to resist going to Vista, it’s clear that there was such a big architectural change (especially from a compatibility point of view), so that even though we provided a lot of free tools to assist customers, there was still a lot of work that had to be done to move to Windows Vista. With XP Mode, they have more options and don’t have to replace old applications.
Of course, ultimately we do want applications to be fully compatible with Windows 7, but this gives them a stop-gap solution. Many customers have applications in their organization which aren’t being developed or supported anymore, and XP Mode lets them seamlessly integrate into the new operating system, which is great for both IT pros and end users.
James Bannan: Given that this functionality is already available to software assurance customers via MED-V, was there an argument that this technology should be made available to all businesses rather than limited to software assurance customers?
Jeff Alexander: Well, we’ve got to be very clear about where we position XP Mode and where we position MED-V. MED-V is targeted squarely at the enterprise consumers as part of the Microsoft Desktop Optimization pack, whereas XP Mode is targeted at small to medium businesses that might not have software assurance or access to MDOP.
XP Mode is very similar to MED-V—you get a Type-2 hypervisor, but you don’t get the management layer that you get with MED-V. So XP Mode doesn’t replace MED-V, it’s just targeted at a different IT professional who might be in a small to medium business.
James Bannan: Given that XP Mode is essentially a VHD running on top of Windows Virtual PC, is there anything to stop an organization from creating a Vista-based VHD and using that the same way as the XP-based VHD?
Jeff Alexander: Nope. The Virtual PC integration components support XP SP3, Windows Vista, and Windows 7, so that you get the same seamless integration across all those operating systems. So far, I’ve done three machines on my system, and the only limitation is that it doesn’t support x64, so they are all 32-bit clients.
James Bannan: Will there ever be integration components available for non-Windows platforms?
Jeff Alexander: I haven’t heard anything about that yet. At this stage it looks like we’re just concentrating on those three operating systems for integration component support. The other thing to consider is that MED-V is currently in Version 1, but there will be a beta of Version 2 available 90 days after the general availability of Windows 7. Version 2 of MED-V will use Windows Virtual PC, compared with the current version of MED-V which uses Virtual PC 2007.
James Bannan: Do you think that there’s a risk that some businesses won’t do any compatibility testing at all and simply move their apps across onto the Windows XP VHD and run it in XP Mode?
Jeff Alexander: Some might, but we don’t think this is a long-term solution. The thing about XP Mode is that it’s a bridging technology allowing them to be able to get access to that application, but we are really going to be encouraging them to continue to do their application compatibility work for those applications. There obviously is a danger for them doing that, but we figured it was better for us to have a solution in place to help people to be able to move towards the new operating system. I think that was probably the number one piece of feedback that we got, that moving applications over to Windows 7 or Windows Vista is just too hard. So we’re giving them an option.
James Bannan: Given that it is seen as a bridging tool to encourage people to migrate, presumably it’s not an offering that Microsoft would choose to simply remove at a later stage?
Jeff Alexander: No, there hasn’t been any word on that at this point in time. Of course XP Mode is simply installed via a KB so it’s easy to remove, but there’s no talk of removing the product once Windows 7 is firmly established.
Jeff Alexander: Another thing of interest for IT pros is that BitLocker is far easier to use. One of the things that people didn’t do when moving to Windows Vista was implement BitLocker, because it was simply too hard. With Windows 7 it hasn’t changed much from the beta to the release candidate, except reduce the size of the BitLocker partition to 100MB, and it’s far easier for IT pros to set up because it’s simply a case of ticking a checkbox. The 100MB partition is set up automatically, regardless of whether the system has a compatible TPM chip.
James Bannan: Is there any noticeable performance drop with BitLocker enabled?
Jeff Alexander: No, none. That’s been the case since Vista. Steve Reilly has commented on that many times. BitLocker impacts performance when it’s physically encrypting the drive, but after the drive is encrypted, there’s no impact.
James Bannan: What were some of the internal pressures to change the development model from Vista to Windows 7?
Jeff Alexander: Regardless of the reality of Windows Vista, customers weren’t satisfied with the product. With regards to development, you have to go back to Windows XP, which was the last major milestone release, and that was when we came up with the Software Development Lifecycle. Of course, we had a major security change around that time. Vista was developed with that model in mind, but the product was so complex that the structure of the internal product teams couldn’t cope. Additionally, we over-promised and under-delivered with Windows Vista—features were simply pushed out regardless of whether they were ready.
With Windows 7, we did almost the exact opposite. If features weren’t up to the required standards of quality they were pulled, and indeed we’ve done that from the beta to the Release Candidate, rather than have a feature which isn’t ready hold up the overall product. And this has reflected in the fact that the public beta was good enough to run as a live operating system. When I ran up the Windows Vista beta there were loads of problems with hardware devices and there was no way you could use it as your everyday operating system. Compare that to Windows 7—I have every machine in my house running Windows 7 RC, and I can because the product teams have hit all the quality milestones.
We also received huge amounts of telemetry data from customers who opted into the Customer Experience Improvement Program with Windows Vista, and all the data went in to determining how Windows 7 took shape. There’s a myth out there that people think that when they send us feedback it all goes into some black hole, but if you go back and look at the Windows 7 Engineering Blog you’ll see that we really do use that data.
Feature teams are a major new development approach which we’ve implemented for Windows 7. While senior management are still involved in the decision-making process, the features teams have a lot more independence, so the right people are making the decisions about product features. That’s not to say that the senior people don’t make the right decisions, but in many ways it’s a role which they shouldn’t have to play and by taking this approach they are empowering the feature teams to make the right decisions about what they want to have in the product, making sure the quality standards are met and ensuring that a features is complete before we openly state that this feature will be available in the product.
When I think back to Windows Vista with features like WinFS (which had a lot of hype surrounding it), we created a lot of dissatisfaction when we simply pulled it. This hasn’t happened with Windows 7. Although you will also have seen that there’s a lot more secrecy around Windows 7, and this is quite deliberate—we want to make sure that features which we say are going to be part of the operating system really are going to be there. Without the backend processes and structures in place which ensure that products are feature-complete, we couldn’t do that.
The last time I remember being able to run daily builds as an everyday operating system because the quality was so good was with Windows 95, and with Windows 7 we’re back to spending lots of time making sure that we reached all the quality milestones so that we can avoid those perception problems which we had with Windows Vista, as well as the genuine compatibility problems which were present at RTM. Although we fixed most of these with Service Pack 1, it still left a nasty perception in peoples’ minds which was fuelled by bloggers and online media so that perception never went away. As for comments that Windows 7 is just Vista Version 2, it’s clear to see that Windows 7 hasn’t been engineered anything like Windows Vista, even though it’s built on Vista’s foundations.
We engaged hardware manufacturers, partners, and ISVs long before there was even a line of code. That’s the main reason why Windows 7 users are seeing so many device drivers available via Windows Update—most systems just need one online update and they’re good to go. To have that at this stage in the development cycle is a first. That’s also why users are seeing lots of test updates come through—we’re gathering telemetry data and testing the robustness of Windows Update to make sure that patch and driver delivery will work as well as possible.
James Bannan: So this isn’t just an exercise in PR? Windows 7 really is being powered by genuine backend changes at Microsoft?
Jeff Alexander: Absolutely. A lot of it comes down to Steven Sinofsky being in charge of the Windows team, but also disclosure has changed a lot too. We’re being a lot more stringent about what information gets out there. The Windows 7 Engineering Blog was created as a conduit for Windows 7 information, but there are other official online resources like the blog run by Brendan LeBlanc and the Talking About Windows site which is run by the Springboard team and has videos from some major players like Mark Russinovich, explaining the decisions behind various Windows 7 features.
Given that, I think that the path to RTM should be very smooth with no major disturbances, so then we can concentrate on deployment. People resisted deploying Windows Vista when it first came out—there were a few bits of broken functionality in Vista when it first came out and we were so busy fixing them that we didn’t offer particularly good deployment guidance at the time. But with Windows 7 we’ve been discussing the technical aspects of deployment very early with IT pros. The product quality is good enough now for our U.S. teams to be producing content on deployment guidance so we’re compelled to get it out there as early as possible.
The thing which I think people don’t understand about Vista was that it was such a big engineering change—drivers, TCP/IP stack and the security model, and all these things which customers asked us to change. But in some ways we went too far away from usability—the level of UAC prompting is a good example of that.
James Bannan: Would it be fair to say that one of Vista’s problems was that it introduced so many new changes on the back of a ten-year old development process?
Jeff Alexander: Possibly. That process was fine with Windows XP but there was five years between releases—it was a very long development process for Longhorn, whereas the Windows 7 process is around two years. It’s a shortened cycle, but that’s also because we’re not re-engineering as much, not making so many sweeping changes across such an array of features, but rather building on the core kernel code.
Some people say that moving to Windows 7 is like moving to a service pack, but I disagree. It’s a new operating system in its own right, but I can understand why that perception is there. The move from Vista to Windows 7 isn’t as fundamental as the move to Vista from Windows XP.
What we’re seeing with Windows 7 is that it just works. In some ways this can be a bit of a let-down to users who get excited about setting up a new operating system and tinkering with it, but with Windows 7 you really don’t need to do that. Of course you can customise it as much as you want to, but if you leave it alone it will just sit there quietly and work and you won’t have to spend ages trying to get it up and running. I’ve haven’t run a machine with Windows Vista for ages—I’ve been running Windows 7 and Server 2008 R2 in production since the betas were released, because the products are just that stable and reliable.
For more on Windows 7:
More interviews with Microsoft: