Channel Insider content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.

If you’ve ever wondered why major software releases such as new operating systems take so long, one of the biggest contributing factors is backward compatibility. Microsoft is especially sensitive to this, and especially with its largest customers. It works very hard not to break old applications.

But with Windows XP Service Pack 2 (SP2), expected to be finalized in the next month, the standard has changed somewhat. The big point about XP SP2 is security, and toward that end, application compatibility must suffer. Some ISVs and other developers are mad. Others not only aren’t mad, they see it as a good sign.

Russ Cooper, senior scientist at TruSecure and moderator of the respected NTBugTraq Security mailing list, goes so far as to say, “I hope it breaks more things than it’s already broken.”

For insights on security coverage around the Web, check out eWEEK.com Security Center Editor Larry Seltzer’s Weblog.

If you look carefully at Microsoft’s guide to Windows XP SP2 for developers, you can see that the things it bans are generally things developers shouldn’t be doing anyway, such as automated download prompts and files with extensions that don’t match their content-type value. This is the point that Cooper is making.

Many vendors have already slipstreamed in upgrades to applications to comply with SP2. According to testers in Microsoft’s Application Compatibility Support newsgroup, for example, Symantec PCAnywhere works from version 10.5.1 up, including the 11.x versions.

Problems in the debugger in Borland’s Delphi in Release Candidate 1 were fixed quickly, although another tester reports that multiple applications under SP2 cannot access the Borland Database Engine.

And like all bug databases, problem reports on XP SP2 have a large share of inaccuracy and overstatement. There were, for example, reports that Apple’s iTunes for Windows 4.6 worked if present on a system onto which SP2 was installed, but would not install afresh on an SP2 system.

I tested this myself and had no trouble installing it on an SP2 system. It’s entirely possible that iTunes does fail on some SP2 systems, or perhaps the problems observed had nothing to do with SP2. We’ll know a lot more after the service pack goes final.

And some ISVs are publicly complaining about the problems. RealNetworks, for example, says, “The changes Microsoft is proposing for SP2 will have serious negative consequences on the consumer experience of many applications and Web sites.” Of course, it’s not surprising to hear Real complain about Microsoft, nor is it always a meaningful or accurate complaint.

Next page: The real problems.

Of course, there are real problems, and I’ve been a victim of one of them myself. A Web-based application I use regularly breaks under Windows XP SP2. The developers haven’t figured out the exact problem yet—I don’t have the source, so it would be difficult for me to figure out the problem—but I wouldn’t be at all surprised to find out that what it was choking on was something the developer really didn’t want to do, like overflowing a buffer.

Users of SP2 get a lot of warnings, especially early on in using it, when they try to run programs that break policy. Rarely are you actually prevented from doing anything, just warned and asked to make a conscious decision to engage in activity that could be insecure.

Microsoft has developed extensive tools for managing the deployment and management of SP2 on a managed network, and I agree with TruSecure’s Cooper that enterprises will likely use these tools to roll SP2 out in a relatively crippled state.

Consider this paper on managing the Windows firewall on a network. They can then turn on features as they are more thoroughly tested, or turn them off if they cause problems in the real-world deployment.

For all the whining Microsoft is getting now, there’s no serious argument to make that these changes aren’t necessary. The next year or so will be a busy one for Microsoft support, but things will get better thereafter.

And a willingness on Microsoft’s part to break these old, dangerous applications is more important than just cleaning up an existing mess. It’s also a break with the past and with Microsoft’s enthusiasm for letting developers make programs that do whatever they want. Security means that programs need to have bounds, and those bounds need to be enforced. It must be a scary thing for Microsoft, but it’s an important moment, and they need to move on with it.

Security Center Editor Larry Seltzer has worked in and written about the computer industry since 1983.

Check out eWEEK.com’s Security Center at http://security.eweek.com for security news, views and analysis.


Be sure to add our eWEEK.com security news feed to your RSS newsreader or My Yahoo page:  

More from Larry Seltzer