Deep within the intricate source code of Windows 95, a seemingly innocuous block of code resides, tasked with a peculiar mission: to inquire if the user is currently engaged in a game of SimCity. Should the answer be affirmative, Windows 95 seamlessly alters its memory management approach, all in service of addressing a bug—not one inherent to Windows itself, but rather a remnant of the game’s own programming history.
The bug that wasn’t supposed to matter
This intriguing tale is recounted by Joel Spolsky, a former Microsoft programmer and co-founder of Stack Overflow, who learned it directly from Jon Ross, the original developer of SimCity. During the creation of this iconic city-building game, Ross inadvertently introduced a “use-after-free” bug by freeing a segment of memory and then attempting to read from it again—a genuine programming error. In the context of Windows 3.x, this bug went unnoticed, as the operating system left the freed memory untouched, allowing the game to function without a hitch. Consequently, SimCity thrived, selling over five million copies while the bug remained hidden in plain sight.
When SimCity stopped working
With the launch of Windows 95, a significant transformation took place. The new operating system merged MS-DOS and Windows, transitioning from 16-bit to 32-bit software and fundamentally altering memory management. During beta testing, however, a critical issue emerged: SimCity crashed on Windows 95. Upon investigation, Microsoft engineers pinpointed the culprit—the same use-after-free bug that had previously gone unnoticed. Unlike Windows 3.x, Windows 95 reclaimed freed memory, leading to data loss or corruption when SimCity attempted to access it again.
Why Microsoft fixed someone else’s bug
Faced with this dilemma, Microsoft made a remarkable decision. Rather than contacting Maxis, the studio behind SimCity, to rectify their bug, the engineers embedded a specific code into Windows 95 that detected when the game was running. This code altered the memory allocation behavior, mimicking the older Windows 3.x functionality to ensure SimCity could operate smoothly. This strategic choice stemmed from a keen understanding of customer perception: if a beloved game failed to work on the new operating system, users would likely blame Windows 95, not the game itself. With millions of potential customers at stake, the cost of implementing a small patch was negligible compared to the risk of alienating users.
The hidden museum inside Windows
The fix for SimCity is not an isolated incident; it exemplifies a broader trend within Windows. The operating system is home to numerous “shims”—small code segments designed to accommodate older programs and games, ensuring their continued functionality. Some games are tricked into believing they are running on an earlier version of Windows, while others receive tailored adjustments to keep them operational. This hidden layer of compatibility serves as a testament to Microsoft’s commitment to preserving the legacy of software, allowing programs from decades past to thrive on modern systems.
Why this small story matters
While it may seem like a trivial anecdote, the story of the SimCity fix encapsulates a crucial aspect of Windows’ enduring dominance in the software landscape. It highlights a steadfast dedication to backward compatibility—a promise that the tools and applications users have invested in will continue to function over time. Jon Ross’s minor oversight in the early 1990s was effectively absorbed by Microsoft’s engineers, ensuring that it never disrupted the user experience. This legacy of accommodating even the smallest of errors continues to resonate within Windows today, illustrating a commitment to maintaining the past while embracing the future.
