How to make sure your program doesn’t run on Windows 95

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…

This entry was posted in PC history. Bookmark the permalink.

10 Responses to How to make sure your program doesn’t run on Windows 95

  1. Yuhong Bao says:

    “I found the insistence on calling DOS extenders "MS-DOS extenders" jarring”
    There was likely a movement within MS to replace references to “DOS” with “MS-DOS” around 1991. History: Back in the pre-5.0 days, OEMs were allowed to call their adaptation of MS-DOS names like “Compaq DOS”. Then DR-DOS was created which was not based on MS-DOS code, hence references to “DOS” were substituted with MS-DOS at around the 5.0 timeframe.

  2. me says:

    Searching for “EMS driver is not VCPI compliant.” suggests that it’s Origin. The DOS versions of WC3, WC4, Privateer and Strike Commander all had precise requirements and wouldn’t work in Windows.

  3. michaln says:

    Oh yeah, that sounds right. I was never a big Wing Commander fan, but I very clearly remember that Ultima VII (otherwise a brilliant Origin title) used a homemade DOS extender which could not even tolerate VCPI (goodbye EMM386/QEMM/386MAX), yet the game required some insane amount of free conventional memory. Voodoo Memory Manager it was called, and it must have been by far the worst DOS extender ever used in a commercially successful game. The other Origin games may well have used variations of the aptly named Voodoo Memory Manager.

  4. Yuhong Bao says:

    In fact, from https://groups.google.com/group/alt.fan.bill-gates/msg/17c2f8873be131fc?hl=en :
    “I work in a group where you get fined a quarter if you say
    “dos” instead of “msdos””

  5. Yuhong Bao says:

    What is fun is that the continued prevalence of DOS and Windows 3.x probably helped this situation last as long as it did, and that of course was partly caused by MS itself turning OS/2 2.x into an entire fiasco.

  6. Alex Czarnowski says:

    I agree that Chen’s target of his ire is misplaced but to his defense I do understand his irritation considering that the IF flag management has been clearly described in DPMI document:
    http://www.tenberry.com/dpmi/02.html#03

    And let’s not forget applications that were using unreal mode – those always required “restart to dos “option.

  7. Alex Czarnowski says:

    I did some digging and apparently Voodoo Manager is in fact unreal mode stub and not DOS Extender: http://wiki.ultimacodex.com/wiki/Voodoo_Memory_Manager

    Unreal mode also called flat real mode or voodoo makes a lot more sense for the manager name. So the Chen comment isn’t about Ultima VII but the developer could be Origin anyway.

    Usage or unreal mode also explains why it was non compatible with memory managers and dos extenders and why it needed so much memory below 640kb.

  8. dosfan says:

    Usage of unreal mode doesn’t explain why it used so much conventional memory, only that it needed more than 640KB for data and for whatever reasons (probably performance) they didn’t want to use a more standard method to achieve this (EMS, XMS move block, VCPI or a DOS extender). I would guess they still used XMS to allocate the required extended memory so as to not step on other software and then just got the address of the extended memory block and directly accessed it.

    An aside: why was this more commonly called “unreal mode” instead of “big real mode” or “flat real mode” ? The latter two terms are more proper terms as you’re setting the big bit in the descriptor to enable flat 4GB access. The term “unreal mode” is kind of silly.

  9. Michal Necasek says:

    I agree that unreal mode does not (or should not) automatically imply high conventional usage. I suspect it was just lack of forward planning and the conventional memory usage slowly snowballed to dangerously close to 640K, and there was no easy way to move anything out (as there would be with a real DOS extender).

    The term “unreal mode” is both a pun and a nice expression of the fact that according to Intel, no such thing exists. It’s also shorter–always a plus.

  10. Alex Czarnowski says:

    I guess the reason for using interchangeably terms unreal mode, flat real mode and big real mode (and voodoo mode sometimes) comes from the fact that the same idea came from different people about the same time in pre internet days. So everyone came up with different name for the same invention. Unreal mode name has been pretty popular with demo coders, other names (except Voodoo) were popular with system/application programmers. On the other hand DOS 5 A Developer Guide book does not use any name for this mode when describing the idea (see chapter 18: Accessing 4 GB in real mode).

    However I agree that flat real mode makes a lot more sense form programmer perspective but since Intel never confirm officially this mode usage of “unreal” word makes sens and play nicely with real mode memory addressing concept.

    Last but not least I’m still interested who are the developers mentioned in the book.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.