Comment by mixmax
14 years ago
Much more than you would ever know..
The original version of Sim City was written for windows 3.x and included a bug that read memory that had been freed to the system. It worked in windows 3.x, even though it shouldn't, because that particular range of memory wasn't being used for anything else until the program was terminated.
In beta versions of windows 95 Sim City didn't work because the operating system allocated memory differently, and Sim City would crash as expected because of the bug in the program. Amazingly, in the final version of Win95 the original Sim City worked. Microsoft engineers had actually tested backwards compatibility with Sim city, located the bug, and worked around it in their sourcecode.
Now that's serious dedication to backwards compatibility.
Specifically, Windows actually checked whether SimCity was running and then allocated memory differently if it was.
Joel Spolsky talks about it in this old article: http://www.joelonsoftware.com/articles/fog0000000054.html
More about Microsoft and backward compatibility is here: http://www.joelonsoftware.com/articles/APIWar.html
There's a blog run by Raymond Chen, one of the engineers on the backwards compat team, which is about backwards compat and other arcane aspects of Windows:
http://blogs.msdn.com/b/oldnewthing/
The part about millions of people sending millions of checks to companies really hit me. Why are Americans still using checks? I haven't seen one in more than a decade.
Bank transfers basically aren't supported by anyone you'd like to give a large sum of money to, so you have to write them a check.
I also remember that there was a version of <unnamed product> that rather than sending LVM_GETITEMTEXT would just read the ansi characters corresponding to the selected item during LVN_ITEMCHANGED off of a random location in the stack frame that they had "noticed" held the value. Of course, this eventually changed to a unicode string internally and broke WinZip... so the code that fired off this event would convert the unicode string to ansi and store a pointer in the stack.
I recall being very confused when I encountered this code many years after it had been implemented and had to spend a lot of time tracking through bug databases before discovering why the listview implementation was doing that.
I found it amusing how you avoided to mention the name initially only to lapse (I'm assuming it wasn't intentional) and inadvertently say it was WinZip later on.
Whoops! Yeah, I'd had WinZip in there originally, then I couldn't remember if this particular story had already come out. I've been gone from MSFT for a long time, but it was generally considered bad form when I was there to call out specific products publicly for their bad code.
1 reply →
This isn't a fun choice for the OS folks to make.
Backward-compatibility for cases such as this can lead to arcane and more complex code within the OS, to difficulty with adding enhancements and creating fixes in the future, and creates larger target areas for folks that are attempting security attacks, and more complex testing.
Bug-for-bug application compatibility is not without costs.
Nitpick: the original version of SimCity was released for DOS before Windows 3.0 came out.
I never knew that MS went so far out of their way to fix a bug for a single game though - it seems that they were much more dedicated to backward-compatibility then than they are now.
Similar issues came up for a lot of apps in the move to XP, and they wound up implementing a 'shimming engine' that would modify behavior of system calls for different apps to provied bug-for-bug compatibility.