Linked by Stefan Michalowski, M. Sc. on Thu 19th Aug 2004 08:27 UTC
Editorial 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.
Permalink for comment
To read all comments associated with this story, please click here.
A few opinions...
by Luke McCarthy on Thu 19th Aug 2004 17:43 UTC

When an application takes advantages of bugs, or undocumented behaviour, it is unfortunate but it deserves to break. Emulation is possible in the worst case, I guess, when the application can not be changed.

However, binary compatibility of say, C libraries should not ever be a problem. For starters, I can't find any reason you would need to change your ABI for linking and calling C code. It really is quite silly.

If you release a new version of a library which has a different (even slightly) API you could keep track of this with *interface versions* (distinct from normal versions which are dictated by development, which may or may not be backwards/forwards compatible). It may be necessary to have multiple versions of the same libraries but that is a small price to pay for having working software.

C++? I think that is a bad idea for shared code. It is always possible to create OOP interface classes to a C library, much harder the other way round. C++ (to my knowledge) does not have a widely agreed-upon ABI like C's cdecl and stdcall.