DOS officially ended in 1995. Yet even during the Windows XP era, running DOS games wasn’t a problem. You could launch almost any game, and it would open in a DOS window and just work. That was thanks to built-in 16-bit support. Something changed between XP and Vista, and that support quietly disappeared.
By the time Vista came out, many older programs no longer worked. A developer named Raymond Chen, who had been on the Windows team since 1992, wrote extensively about this shift on his blog. In one post, he shared a story about SimCity.
The developer of SimCity contacted Microsoft to report a critical bug. The game was trying to access a block of memory immediately after releasing it. DOS didn’t mind, but Windows did. That memory was already in use by another program. The Microsoft testing team found the crash and escalated it. Developers examined it with a debugger, discovered the error, and wrote special logic into Windows. This allowed SimCity to run by handling memory in a forgiving mode, even when it violated normal rules.
This kind of effort wasn’t common. Technically, the problem belonged to the game, not the operating system. But from a user's point of view, the situation looked very different.
Imagine you have an older version of Windows and lots of programs running smoothly. Then a new version of Windows comes out. You install it, and suddenly some programs don’t work. Some even crash the system. The only thing you changed was the operating system, so that’s what you blame. You return the software because it broke what used to work.
Microsoft had a large and capable testing team. They worked hard to ensure most applications remained functional. Windows XP is proof of their success. Still, not every developer agreed with this approach. Many believed broken or unsafe programs should stop working with each upgrade. Developers for the Macintosh system were part of this mindset too.
For example, some Mac developers tried to improve performance by copying pointers directly from the interrupt table. Even though the official documentation said not to do this, they did it anyway. Their programs ran faster—until a system update arrived and nothing worked anymore. That’s why so few early Mac applications still run today. In contrast, DOS applications written in 1983 for IBM PCs continued to work for years without modification.
🧭 Microsoft Lost Its Backward Compatibility Philosophy
A major turning point was when Visual Basic .NET was released without compatibility for VB 6.0. For the first time, upgrading a Microsoft product meant your existing work might not carry over. Developers were left behind, and many switched to web development instead.
Later came IIS 6.0, which introduced a new channel model that broke older apps. .NET 1.1 wasn’t fully compatible with .NET 1.0. Filesystems moved from FAT to NTFS, and eventually the entire operating system architecture changed. This wasn’t just an upgrade—it was a break from the past.
Joel Spolsky, a former Microsoft engineer, wrote about this in 2004. He explained that Microsoft, aiming for growth, chose to reinvent everything. In the past, new systems would have been released as DLLs, compatible across versions. But with Longhorn, Microsoft needed a reason to convince users to upgrade. They wanted to recreate the shift that happened between DOS and Windows. The problem was that moving from XP to Longhorn wasn’t as significant. Users weren’t convinced. Microsoft, however, needed them to be.
History has shown that Joel was right.
🎮 Running DOS Games Today
Luckily, this part is easy. Just download DOSBox from dosbox.com and install it. After that, you can run most DOS games without trouble. You can even run Windows 3.1 inside it, since that too was a DOS-based program.