Windows 95는 Maxis에 수정을 요청하는 대신 SimCity의 해제된 메모리 버그를 특별 처리했다

Windows 95는 MS-DOS와 Windows 앱을 통합하고 API 집합을 16비트에서 32비트로 업그레이드했으며, Microsoft는 사람들이 업그레이드하지 않을 이유를 전혀 남기고 싶지 않았다. 그럴 뻔한 이유가 하나 있었는데, 바로 Windows 3.x용 SimCity였다. 이 게임의 제작자 Jon Ross가 방금 해제한 메모리를 읽는 버그를 실수로 남겨둔 것이다. Windows 3.x에서는 메모리가 어디로도 사라지지 않았기 때문에 잘 작동했지만, Windows 95 베타에서는 게임이 망가졌다. 500만 장 이상 팔린 SimCity는 문제없이 작동해야 했다.

Microsoft는 버그를 추적해 Windows 95에 SimCity를 찾는 코드를 추가했다. 게임이 실행 중인 것을 발견하면 메모리 할당자를 메모리를 즉시 해제하지 않는 특별 모드로 실행한다. SimCity만 그런 것은 아니었다. Windows ADK의 호환성 관리자는 앱별 수정 데이터베이스를 보여준다. Windows NT는 Final Fantasy VII와 함께 일반적으로 설치되는 파일을 감지하면 문자 그대로 “Win95VersionLie”라는 이름의 수정을 적용하는데, 이는 단순히 게임에게 Windows 95에서 실행 중이라고 알려주는 것이다. 반면 Dungeon Keeper는 “Horny.tif” 같은 파일을 기준으로 한 파일 경로 수정을 받는다.

이 집착은 제도적이었다. Raymond Chen은 2005년에 Windows 95의 개발 관리자가 픽업 트럭을 몰고 동네 Egghead Software 매장으로 가서 매장에 있는 모든 PC 프로그램을 하나씩 구매했다고 기록했다. 모든 개발자는 설치하고 실행하고 버그를 문서화할 프로그램을 최대 두 개씩 맡았고, 테스터는 끝낸 프로그램을 가질 수 있었다. Maxis의 전 크리에이티브 디렉터 Mike Perry는 나중에 Ross가 Maxis를 떠난 뒤 Microsoft에서 일하게 되었다고 언급했다.

호환성 심: 운영체제는 특정 앱을 인식하고 해제 지연, 버전 속임수처럼 자신의 동작을 조용히 굽힌다. 그래서 오래된 바이너리는 무엇이 바뀌었는지 전혀 알지 못한다.

운영체제 업그레이드는 앱 카탈로그에 달려 있다. 사용자는 이미 가지고 있는 게임과 도구를 망가뜨리는 운영체제를 사지 않는다.

모든 서드파티 공급업체를 고치는 것은 불가능했기에, 심을 통해 Microsoft는 다른 사람의 코드를 건드리지 않고 호환성을 복구할 수 있었다.

이름이나 설치된 파일로 앱을 감지함으로써 모든 것의 동작을 바꾸는 대신 각 수정을 외과적으로 유지했다.

실제 소매 소프트웨어를 대규모로 테스트함으로써 알려지지 않은 비호환성을 출시 전에 문서화되고 할당 가능한 체크리스트로 바꿨다.

하위 호환성은 앱별로 살 수 있다. 오래된 플랫폼의 버그, 심지어 메모리 실수까지 에뮬레이션하면 업그레이드하지 않을 모든 변명이 사라지고 소프트웨어의 닭과 달걀 문제가 깨진다.

2000년에 SimCity 이야기를 다시 들려준 Joel Spolsky는 이것이 운영체제의 닭과 달걀 문제를 깨는 방법이라고 불렀다. '어떻게 보느냐에 따라 트럭 한 대의 닭을 배달하든 트럭 한 대의 달걀을 배달하든, 하위 호환 모드를 제공하고 뒤에 앉아서 돈을 긁어모으는 것이다.' 앱별 심 데이터베이스는 Windows 95보다 오래 살아남았고 Windows Assessment and Deployment Kit에서 여전히 검사할 수 있다.