Saturday, May 16, 2009

The real story behind Windows 7 compatibility

Usually, when Microsoft talks about compatibility with Windows 7, it's either impressively big numbers - Senior VP Bill Veghte claiming Microsoft has logged 10 million device installs on Windows 7 between the beta and release client and that over 10,000 hardware and software vendors are developing for Windows 7 - or broad generalisations, like corporate VP Mike Nash saying that "by and large apps that worked on Vista should work on Windows 7 as well, if not a little bit better".




The exceptions Microsoft usually mentions are 'low level software' like anti-virus, firewall, VPN and disk imaging software which interact with the computer system at the kernel level.

But that's not the whole story about application compatibility with Windows 7 and Chris Jackson of the App Compat SWAT team revealed the nitty-gritty details at Microsoft's TechEd conference this week.

Jackson says application compatibility was what Microsoft calls a "tenet" for Windows 7 – a key principle during development: "We are putting in quality gates so that before you even check in code you have to make sure you have measured its compatibility impact. The goal in short is, don't break everything. Did we make it all of the way there? No. Some things are still broken."

The changes that Microsoft made in Vista for security are still there, which means apps still face the same problems, he concedes. "In the end there is no new special sauce that makes all the software we broke on Vista start working again. There are some one-off solutions - we added more shims, we fixed some additional apps - but there is no systematic change."

Working on 7

There are some programs that would not run on Vista that do work with Windows 7 because of the way they implement version number checking. Windows XP is version 5.1, Vista is version 6.0 and – purely to improve compatibility – Windows 7 is 6.1. Some apps make the mistake of checking for a major version number of 5 or greater and a minor version number of .1 or greater, which means they fail on Vista (6.0) but work on Windows 7 (6.1). Many apps that had problems running as a standard user on Vista have already been fixed.

There are changes in Windows 7 that do affect applications, many of them very low level. As with Vista, Jackson says there were good reasons to make them. "We wanted to take what was getting to be pretty much spaghetti and make sense of it. We reorganised things again in Windows 7 trying to get to what we call MinWin [a base kernel without the complicated interdependencies of Windows]."

He admits that may cause problems for developers. "The kind of stuff we broke isn't easy stuff. With Windows 7 if you don't work and you did work on Vista you're into some pretty hard engineering."

Zune had a particular problem: "If you were using private undocumented IOCTL codes to communicate, you're going to break," says Jackson.

ZUNE FAIL: Using undocumented features meant Zune needed work to connect under Windows 7

Not as many applications as Jackson expected were affected by the removal of Windows Mail (only three in total); although it had an API you could use to integrate it, it only worked if you renamed your own application WINMAIL.EXE.

The parallel registry in the 64-bit version of Windows is gone, but the only place it was actually used was Window's own COM interface.

Data Execution Protection (DEP) is enabled in IE by default (and to turn it off you have to run the browser as an administrator). That means ActiveX controls have to work with DEP (because they're hosted by IE), and that used to be harder than it needed to be because Microsoft's ActiveX template library framework was incompatible with DEP. That's now fixed so it will be easier for developers to create compatible plug-ins.

The new file libraries in Windows 7 can confuse applications that don't use the Windows file dialogues, because technically a library is a file rather than a folder.

And then there are changes that shouldn't affect applications but do, because developers have made assumptions they shouldn't have. The way to guarantee that apps will break, says Jackson, is to "assume we'll never change Windows". Version 3 of Skype won't run on Windows 7.

"They take an internal dependency on how we implement structured exception handling in Windows," he explains. "Any change in that would break them but we cannot just freeze exception handling for all time just for Skype." Instead, Microsoft helped the Skype team to make sure version 4 was compatible in time for the Windows 7 beta.

Putting the bug back

Microsoft Money wouldn't run on the Windows 7 beta, for a similar reason. "They had taken a dependency on the fact that a buffer in use in the internet control panel would allow you to over-run it by two bytes; that's been a bug since Windows 95." Effectively, says Jackson, "we put the bug back; we over allocate the buffer by two bytes and everything is okay."

BUGGED OUT: To make Money work in the RC of Windows 7 Microsoft "put the bug back"

Things are usually simpler for business applications says Jackson - they're usually written in Visual Basic and the commonest problem is writing files to a place that's no longer allowed when you're not running as admin.

Vista tried to fix that by providing virtual folders, but Windows 7 can virtualise the root of the drive (C:) as well as folders, so again, more apps will run on 7. "Commercial software tends to be more sophisticated: it's written in C, it's more low level and it takes dependencies on the operating system," says Jackson.

Businesses are usually conservative about moving to a new version of Windows because of those internal apps - if they're not a significant problem for Windows 7, we might see much faster adoption.



source :
techradar.com

0 comments: