Lately posted on Slashdot, an article written by Joel Spolsky mentioned the trouble through which Microsoft went to make each version of Windows backwards compatible. In one case, for the game Simcity, they even changed the way memory handling was done when running that application. You can find additional stories of software tricks that recent versions of Windows have to perform in order to run these bug-dependant applications on the web. After reading the story, I discussed with a couple of friends how weird this was and how Free Software completely avoids this problem.I was still amazed that there are special hacks in Windows for certain applications. I saw the compatibility settings in the property dialogs of executable files when using Windows, but I never thought that the effects could run so deep. These hacks must introduce weaknesses into the system. The it came to me that in the case of SimCity there might even be a huge problem, here is my theory, be warned that I am unsure of the following.
If Simcity requires a “freed” pointer to be referenced (see Joel Spolsky’s previously mentionned article), you could code an application that exploits this fact and name the executable simcity.exe. There are hundreds (if not thousands) of applications supported by Windows XP dating back to Windows 95, and thus must have very special hacks for them to run. Does this mean that Windows XP is riddled with holes because of these applications? Will MS remove all the hacks, which cost them many hours of work, to make XP more secure and therefore breaking these applications? How would its customers react? Being used to backwards compatibility, customers will blame Windows for not running their favorite application.
Maybe I am wrong and there are no possible security breaches due to the compatibility hacks. It would be interesting to investigate this further. But if this is true…
What a security nightmare Microsoft created for itself by supporting bug-dependant software!
In the closed source world, this is a major unavoidable problem. When a bugfix in software A breaks a dependant application B the available options to solve this are few: either you hope the broken application B developers fix their bug or software A has to have a workaround added to support application B. Why couldn’t you simply rely on a fix from the developers of the broken applications? Well, there are many reasons:
– The company that created the application could be out of business;
– The company could ask for funds to fix the bug, after all their application worked with the previous version of your software;
– The company could not have the ressources to fix the bug, their developers could be busy developing some other software;
– The company could have abandonned the application and doesn’t want to put ressources into anymore.
The only thing left to do is to make workarounds in software A. However, all the time, money and work invested into the workarounds is also the source of security holes in software A!
Well, apparently SP2 for Windows XP will be removing support for some old applications to improve security. Kind of makes you wonder, Microsoft first spent an enormous amount of resources to build support for bug-dependant applications and now it finds itself to spend an enormous amount of resources to remove this support. Not only that, but this compatibility reduction doesn’t seem to be well received by Microsoft’s customers.
This is unimaginable in the Free Software world. Because of the availability of source code, it can be updated not only by the original authors of the software but also by others. This means that if the authors are unavailable for whatever reason, someone else could fix application B in order to make it work with a newer version of software A.
Let’s say that a program B which depends on A is broken by an update on A. I see two types of incompatibilities:
– binary incompatibility: this means that a simple recompile of B will fix the problem.
– source level incompatibility: the developers of B will be notified of the bug and could fix it. If the developers of B cannot, for some reason, fix the bug, someone else could pickup the source code and fix the problem.
If my company depended on software B and the bug fixed in A improves security, I wouldn’t be forced to sacrifice one or the other; I’d be *certain* that both could still work together, even if it meant I had to bounty a programmer for a couple of hours. As an example, instead of creating holes in Windows, Microsoft could have of spent all those resources on improving Simcity and the many other bug-dependant applications Windows has to support. You could say it’s not their reponsability to improve SimCity, but why should they spend time and money in making hacks into Windows, thus making it vulnerable, instead of improving the general state of software.
An additional reason to adopt Free Software: you can avoid creating security holes in order to be backwards compatible.
“Emulation” to the Rescue
Could emulation be the solution to support old bug-dependant applications without compromising security? Dosemu seems to be able to run SimCity, Wine does a a pretty good job of running most Windows application. I remember in the days of OS/2 that it ran Win3.x applications better than Win3.x. Do these applications introduce the same kind of weaknesses into the system as do the hacks in the latest Windows?
Of course, the best way to get rid of this compatibility nightmare is to write a Free version of the software you need.
About the Author
Stefan Michalowski is a computer enthusiast who likes to spread the Free Software word. Preaching by example, he has been using multiple flavours of GNU/Linux since 1995.
If you would like to see your thoughts or experiences with technology published, please consider writing an article for OSNews.