For Christmas, I bought myself the book The Old New Thing by Raymond Chen, a long-time Microsoft programmer. The purchase was spurred by discovering, through Google Books, an excerpt of a riveting description of how various software titles abused the DPMI specification (and often common sense, too) in ways that made it difficult to run such software under Windows 95.
When I was nearly done reading my copy of the book, I realized that the protected mode programming treatise wasn’t there. Back to Google, I checked that my memory wasn’t deceiving me—yep, still there on Google Books. But for some odd reason, there are no page numbers in the excerpts of The Old New Thing that show up on Google Books, so I could not cross check with my printed copy. After a few more searches, I concluded that there are two appendixes which were probably never printed and only exist in electronic form.
Luckily, once I knew what to search for, Google found PDF versions of both: Tales of Application Compatibility and How to Ensure That Your Program Does Not Run Under Windows 95. The latter is what I’d been looking for, but I’m not sorry that I bought the book. It’s worth reading.
Now, on to Appendix B: How to ensure a DOS program isn’t Windows 95 compatible. I found the insistence on calling DOS extenders “MS-DOS extenders” jarring—they were never limited to MS-DOS and worked just fine with PC DOS as well as DR-DOS/Novell DOS. No one called them MS-DOS extenders except apparently Microsoft (and even then only sometimes).
The author’s surprise that game vendors didn’t care that their games didn’t run under Windows 95 was a surprise (and a source of amusement) to me. I remember that era well. A gamer with a 4MB system could either run Windows 95 or a game requiring 4MB RAM, but not both. Same for 8MB systems and games requiring 8MB. Furthermore, games were essentially real-time software and any intrusion from a multitasking OS such as Windows 95 was highly unwelcome. Game companies didn’t want users to run their DOS games under Windows 95 because that just created problems. That’s why so many games came with utilities to create game-specific DOS boot disks. Yes, it was a cop-out, but it was a sensible solution.
Chen’s discussion of interrupt flag mismanagement is fascinating, but the target of his ire is misplaced. Sure, application developers were amazingly creative in breaking DPMI rules, but whose fault is it that POPF (and IRET) in some situations doesn’t restore the interrupt flag and cannot be trapped? Hint: The perpetrator’s name is five letters long, starts with I. The apps were intended to run under DOS, and they did. It’s silly that they wouldn’t run under protected-mode operating systems due to minor and easily preventable issues, but that was the reality of the marketplace.
The description of memory mismanagement is quite scary. The code in certain applications (especially games) was anywhere between misguided, broken, and outright insane. Clearly, many of the early 1990s games had been written by kids who didn’t quite know what they were doing.
The code snippet on page 39 immediately caught my attention because using RETF 2 to return from an interrupt handler is scary. It’s not necessarily wrong, just scary—because the programmer must be very very sure that only the flags which the caller expects to be modified may change, and the rest must stay the same. Unexpectedly changing e.g. the caller’s direction flag is great fun and leads to hard to find bugs.
While most of the appendix is specific to moving DOS programs into the Windows 95 environment, the section dealing with interrupts and timing is relevant for virtualization as well. “Jerky” time and back to back interrupts are typical in virtualized environments. That also applies to unnaturally fast keyboard input and device drivers which assume that interrupts from their device will always arrive after some finite period of time.
The epilogue of the appendix is lovely. And I do wonder who Publisher 3 was…