Backward compatibility is a good thing. It keeps users happy and ensures
that files they've created in a particular application will still work
with a future generation of that application. I have a PowerPoint
presentation from close to 10 years ago that I haven't opened in, well,
nearly 10 years. But it's good to know that PowerPoint 97, 2000, XP, and
2003 can all open those files.
Windows itself had the old DOS Compatibility Box. It didn't work very
well, and who knows, may have even been designed to get people so riled
up, they'd upgrade, purely out of disgust.
It may be time to get disgusted again.
The Service Pack 2 release for Windows XP is coming. Geared mainly
toward enhancing Windows' meager security capabilities, some of these
fortifications are probably going to cause headaches for older
applications. In other words, they won't work.
This is a big deal and Microsoft knows it. The company has developed an
online training course dealing with SP2. It examines the impact on
existing applications and even includes code samples.
Here's how Microsoft sees it: "With Windows XP Service Pack 2 (SP2),
Microsoft is introducing a set of security technologies that will help
improve Windows XP-based computers' ability to withstand malicious
attacks from viruses and worms." The technologies include network
protection, memory protection, improved e-mail security, and safer
"Together, these security technologies will help make it more difficult
to attack Windows XP, even if the latest patches or updates aren't
applied. These security technologies together are particularly useful
mitigation against worms and viruses. To developers these technologies
will have impacts on the applications that they create and the tools
Here are just three of the many things you need to know.
The Alerter and Messenger service components of Windows are going to be
disabled by default. Any application or service that uses the Alerter or
Messenger services to communicate with a user will not be successful. In
other words, they won't work.
These services allow simple messages to be communicated between
computers on a network. The Messenger service relays messages from
different applications and services and the Alerter service is intended
specifically for administrative alerts.
Currently, the Messenger service is configured to start automatically
and the Alerter service is set to manual start. In Service Pack 2 for
Windows XP, both of these services are going to be set to Disabled. No
other changes are made to these services. They'll still be there and
So what do you do if you have an app that relies on these services?
According to Microsoft, two avenues of resolution exist. The recommended
technique is to revise the software to use another method to communicate
with the user. This will allow communication with the user to occur in a
more secure way, without having to use the Alerter or Messenger
services. Probably easier said than done. The second way is to have the
application invoke the Alerter or Messenger service before making use of
its services. That would seem to be the easier solution to implement.
Look for changes in the Windows Firewall feature, too.
Previously called Internet Connection Firewall, Windows Firewall is a
stateful filtering firewall for Microsoft Windows XP and Microsoft
Windows Server 2003. Windows Firewall provides protection for PCs
connected to a network by preventing unsolicited inbound connections
through TCP/IP version 4 (IPv4) and TCP/IP version 6 (IPv6).
For some reason known only to Microsoft, this feature has always been
off by default. In Service Pack 2 for Windows XP, the firewall will be
on by default. This applies to both IPv4 and IPv6 traffic, and is
enabled even if there is another firewall already present on the system.
According to Microsoft, had the firewall been on by default, the recent
MSBlaster attack would have been greatly reduced in impact, regardless
of whether users were up-to-date with patches.
After installing Service Pack 2 for Windows XP, the Windows Firewall is
enabled by default. This might break application compatibility if the
application does not work with stateful filtering by default. It may
also conflict with other active software and hardware firewalls. If
that's the case, you'll need to do some reprogramming, or chase whoever
developed that application. If they're out of business, you're out of
And finally, there is the issue of multiple profile support in Windows
Firewall. This feature will allow creation of two firewall policies: one
for when the computer is connected to the corporate network and one for
when it is not. The idea is that you can specify a less-restrictive
policy when the computer is connected to the corporate network and be
more aggressive when that system is being used, say, in a hotel room.
A configuration that is safe on a trusted network may be more
susceptible to attack on the Internet. Therefore, being able to have
ports opened on the trusted network and not on the Internet is critical
to ensuring that only the necessary ports are exposed at any given time.
Multiple profiles for Windows Firewall applies only to computers that
are joined to a domain. Computers that are in a workgroup only have one
According to Microsoft, if an application needs to be listed in the
Windows Firewall exceptions list to work correctly, it might not work on
both networks as the two profiles might not have the same set of
policies. For an application to work on all networks, it must be listed
in both profiles. The fix is simple: If the computer is joined to a
domain, you must ensure that the application is listed in both profiles.
There is a whole lot more than what I've identified here. If you're into
some lengthy reading, visit
http://msdn.microsoft.com/security/productinfo/XPSP2/. And the training
course is located at