RealTime IT News

Windows 7: From Beta to Final Code in One Year

LOS ANGELES -- On Oct. 28, 2008, Steven Sinofsky, then senior vice president of Windows and Windows Live, stood on stage at the Professional Developer's Conference to announce the first preview release of Windows 7, the operating system that would succeed the poorly received Windows Vista.

One year later, Windows 7 is out, earning excellent reviews, and Sinofsky has a earned a promotion to be president of the unit. How did his team manage this in one year?

Without highlighting the failures of the previous development team too much, Microsoft (NASDAQ: MSFT) said it kept its focus a lot sharper this time.

"We were very clear on where we were going, and our message at last year's show was 'this is what you will get,' and a year later, that exactly what they got," Mark Relph, senior director of the Windows ecosystem, told InternetNews.com.

Vista was plagued with more than a few changes in mid-development, which hadn't helped. "If you're an architect and you change the blueprints of a house after the foundation has been poured, the house is going to be a mess," Relph noted.

Also in Windows 7's favor was the fact that Microsoft didn't make drastic changes from a previous version, as it had with its predecessor: Its kernel and driver model came from Vista, which had been steadily evolving since the release. Vista, on the other hand, introduced a far more sweeping amount of change with which to contend.

The other commitment, as much of a cliché as it sounds, was for Microsoft to listen and test widely.

"There was a deep commitment to taking feedback and taking a scientific approach to taking in that feedback," Relph said. Microsoft had eight million testers for Windows 7 and multiple mechanisms for sending feedback and suggestions built into the operating system.

In his keynote earlier this week, Sinofsky highlighted just how much feedback Microsoft had taken in during the testing cycle.

He also pointed out that Windows 7's testing better took into account the fact that average users' systems tend to be lower-performance machines compared to the developers who typically do most of the testing. For instance, most Windows 7 testers used lower screen resolutions more in-line with average consumers -- a consideration that hadn't been as much of a factor in Vista's development.

Mass migration

Microsoft has two challenges ahead of it now that it has delivered on the operating system: building the 64-bit platform and helping custom, Windows XP applications written in-house at firms make the move to Windows 7.

The shift to 64-bit will be easier (despite some rough patches) since there is only one way for a hardware vendor to earn a Windows 7 certification logo -- and that is to have both 32-bit and 64-bit drivers for their hardware. Software products have to follow the same route as well.

"That's the first step ... making 64-bit mainstream," Relph said. "The drivers are there at a level of commitment like we've never seen before. For new, current hardware, we are at almost even parity of having both 32- and 64-bit drivers."

Moving apps is a bit more of a challenge. Some apps, like Microsoft Word, won't gain much by a 64-bit port. Others, such as Adobe's suite of content creation and editing tools, or AutoDesk's high-end computer-aided design (CAD) software, will benefit greatly from having more than 4GB of addressable memory, the primary benefit of 64-bit systems.

Relph figures the migration will vary from vendor to vendor. "In many cases, [moving to 64-bit] is just a recompile. Others may have to re-architect their apps for it. I think as they move through their own product cycles, they will do it by design."

"And we're assuming this is new territory for them. 64-bit has been around for a while, so for some developers, this will not be new," he added.

For in-house apps written by IT shops, Microsoft has prepared the Windows Developer Center on MSDN with assistance tips on app migration. But Relph said it likely won't be that difficult.

The only real deal-breakers for apps will be low-level hardware calls, driver, security and in the case of Vista, User Access Control (UAC) calls. Or it might be as simple as an installer that doesn't recognize the operating system version number.

"For a lot of developers, if they have ... made calls to the security system or drivers, calls that are no longer allowed for security reasons, then they need to re-engineer those calls," Relph said. "But the rest should be straightforward."