[martinnormark]

This reminds me of how Microsoft added specific code to Windows 95 to ensure SimCity would run.

This is from Joel Spolsky's Strategy Letter II: Chicken and Egg Problems http://www.joelonsoftware.com/articles/fog0000000054.html

So Windows 3.x on Intel 80386s was the first version that could run multiple DOS programs respectably. (Technically, Windows 386 could too, but 80386s were rare and expensive until about the time that Windows 3.0 came out.) Windows 3.0 was the first version that could actually do a reasonable job running all your old software.

Windows 95? No problem. Nice new 32 bit API, but it still ran old 16 bit software perfectly. Microsoft obsessed about this, spending a big chunk of change testing every old program they could find with Windows 95. Jon Ross, who wrote the original version of SimCity for Windows 3.x, told me that he accidentally left a bug in SimCity where he read memory that he had just freed. Yep. It worked fine on Windows 3.x, because the memory never went anywhere. Here's the amazing part: On beta versions of Windows 95, SimCity wasn't working in testing. Microsoft tracked down the bug and added specific code to Windows 95 that looks for SimCity. If it finds SimCity running, it runs the memory allocator in a special mode that doesn't free memory right away. That's the kind of obsession with backward compatibility that made people willing to upgrade to Windows 95.

[scrabble]

My understanding is that Raymond Chen ( http://blogs.msdn.com/b/oldnewthing/ ) was a huge part of ensuring that everything was backwards compatible. If you like that kind of thing, he's got a book: http://www.amazon.com/The-Old-New-Thing-Development/dp/03214...

[martinnormark]

Amazing. Thanks, I didn't know of him specifically but I do remember seeing his book somewhere.

[Touche]

While a fascinating story, this is nothing like that.

[achivetta]

Amazingly, this sort of use-after-free causes compatibility problems for allocator writers even today. Imagine if you change the implementation of malloc() such that smaller allocations get their own mmap() region rather than being stuffed in with other allocations. Now any use-after-free bugs to allocations affected by the change will segfault instead of reading garbage, since the allocator would munmap the region upon free().

[keeperofdakeys]

That's why programs like valgrind are great, they check all your memory allocations, and ensure these kinds of bugs don't occur (though it can only test codepaths that run, and has an overhead for all the checks).

This is also why I'm so excited about Rust. Suddenly your compiler and language definition ensure these kinds of bugs can't occur.