A Windows 95 Compatibility Call Ended With Instructions for a DOS Boot Disk
An old game could outlive its commercial window, leaving the operating-system team to absorb the repair work.
The person helping Windows 95 run old games called the people who made the games. One vendor’s answer was a disk that would let the user boot into DOS.
Chen’s 2003 retrospective describes vendors who had moved on once the sales window closed. Some could no longer track their shipped versions; some no longer had source code. He recalls the response as “They already got their money.”
That is Chen’s firsthand account of the calls, without named vendors or independently supplied call records. It explains the pressure on the Windows team, while leaving the identities and individual technical failures unstated.
The business example in Chen’s post starts with one essential program. If it won’t run on the new operating system, the buyer has to account for replacing or upgrading it too. Chen imagines a $150-per-copy application upgrade changing the economics of the Windows purchase. That is his illustrative scenario, rather than a price attached to one of the unnamed game vendors.
The remembered corporate survey had a more difficult version of the problem. Chen says companies commonly had at least one deal-breaker application, often something written internally in Visual Basic. Sometimes the author had left and the source was gone. Calling the original developer was then less a support strategy than a search for somebody who might remember where the installer lived.
Games put a shorter commercial clock on the same dependence. Chen describes vendors seeing a shelf life of a few months, after which another compatibility patch offered little new revenue. Slipstreamed changes could leave the vendor unsure which shipped versions contained which problems. A customer could still own and want to play the game long after that accounting had stopped encouraging repairs.
Windows therefore had several places to carry the workaround. Chen explains that some compatibility changes went into core components for all programs, while others targeted particular applications. In his account of Windows XP, many fixes could live in compatibility DLLs under AppPatch, reducing the amount of special handling inside core operating-system files. He explicitly notes that this separation couldn’t accommodate every class of workaround.
The post also points developers toward a verifier that watches API use and stops at mistakes such as mismatched allocation and release calls. That recommendation gives the story a second path besides waiting for the OS team to compensate: catch a program’s bad assumptions while its developer can still fix them.
Chen also explains that Windows compatibility fixes can live in core components or target specific programs. Chen does not identify a particular shim built for the DOS-boot-disk vendor; the account leaves that technical repair unspecified.
This creates a durable planning question for systems buyers: who can repair the indispensable tool after its original developer stops caring? An upgrade plan that depends on a future patch still needs an answer when the phone call ends with a boot disk.