An old article on Windows 3.0 from PC Magazine (June 11, 1991, page 348) said that:

Using standard mode, the Windows DOS extender and DOS Protected Mode Interface (DPMI) are available to Windows programs, but not to DOS programs

Using 386 enhanced mode, the Windows DOS extender and DPMI are available to Windows programs and DOS programs

Why the same trick David Weise and Murray Sargent used to get Windows running in 80286 protected mode couldn't apply to other DOS programs?

  • 1
    For background, this is what the OP is taking about: blogs.msdn.microsoft.com/murrays/2006/12/07/… Jun 5, 2019 at 5:00
  • IIRC, on a Windows 3.x machine you could boot into plain DOS, which was also the first phase of booting Windows. So, basically if you booted DOS and avoided launching Windows, a DOS program that needed the DOS extender could still run.
    – RichF
    Jun 5, 2019 at 5:07
  • It’s not critical for answering the question, but to make the question better: would you be able to clarify exactly what portions are an exact quote from the article, and what portions are being paraphrased? Also, it would be a good idea to indicate the issue number (and page if possible) where you saw the article. Thanks! Jun 5, 2019 at 19:38
  • @Euro it’s not a review, it’s from Windows 3.0: All That Memory, All Those Modes. Jun 6, 2019 at 17:01

1 Answer 1


TL;DR: on 286s in standard-mode Windows, DOS programs run one at a time in real mode, with Windows suspended, so the restrictions of enhanced mode which rendered DPMI necessary don’t apply.

The “trick” used to allow unmodified Windows 2 programs to run in protected mode on a 286 relies largely on the fact that Windows provides a full operating system API to programs running on it, and that that API defines memory allocation rules precisely. In particular, memory allocation returns handles, not pointers, and pointers are only available when a memory block is locked (which is supposed to be a short-lived state); and segment arithmetic isn’t allowed in general, and where it is allowed, the allowable calculations are pre-determined. (The use of handles for memory allocation is, as far as I can determine, what the linked article is referring to with “Steve Wood's original memory-allocation design”.)

All this means that for Windows programs the Windows kernel could be modified in such a way that it continued to provide valid segments (descriptors now, and no longer memory offsets) to programs, since it can know ahead of time all the values that a running program is liable to load into a segment register, and the sizes of the corresponding memory blocks. Modifying the kernel and supporting DLLs in this way was itself a feat of engineering, and took quite a while; but it didn’t involve modifying Windows programs.

Under DOS, there are no such rules; memory is allocated as effectively pointers into physical memory, pointer arithmetic is standard practice, including with segment registers, and most DOS programs expect to be able to read and write from anywhere in memory. This means that there is no general way to adapt a program to run in protected mode while protecting it from other programs (and the operating system from running programs), in software. (SST uses this sort of approach to debug real mode programs in protected mode, but it’s only trying to run a single program.)

This has two consequences, on 286s: you can’t write a general-purpose protected-mode DOS extender (or replacement DOS) capable of running all existing DOS programs in protected mode; and you can’t even write a protected-mode operating system capable of running all existing DOS programs in real mode either without suspending most of the protected-mode side of things.

So Windows 3 in standard mode (and OS/2 1.x) is capable of running DOS programs, one at a time, but when a DOS program is running, everything else is mostly suspended, and the CPU is in real mode. Thus there is no need for a DOS extender; it might be useful for the operating system to provide one, if everyone could agree on a standard API, but since protected-mode DOS programs need to provide their own DOS extender anyway, there wasn’t much use for one in the early Windows 3 days. (This isn’t the full story with standard-mode Windows on 386s, where VCPI plays a role, but I’m mostly considering 286 constraints since that’s the scope of the question.)

Enhanced mode on 386s is a different matter. Here, the CPU provides additional features which allow real-mode DOS programs to run in parallel with a protected-mode operating system and protected-mode tasks (and other real-mode DOS programs), thanks to paging and V86 mode. However, protected-mode DOS programs still require special handling: there can only be one protected-mode “master”, and if that’s Windows — or rather, its 32-bit virtual machine manager — or any other protected-mode environment, a protected-mode DOS program can’t set up its own extender and will fail to run. This is where DPMI comes in: it’s an API which allows programs to enter and leave protected mode, allocate memory, call real-mode services etc., in the same way, regardless of what is implementing the extender. So Windows provides a DPMI implementation, DOS extenders also provide DPMI implementations (and typically, clients), and protected-mode programs can be written using DPMI and the world is again a happy place (so says anyone who has never actually tried to write a protected-mode program).

  • 1
    Related is that (Minix I think had it?) you could run a Unix with full memory protection between processes on the 80286. Something which was not otherwise generally available until the 80386. But the Unix programs had to use the 64kbyte data model, if I recall correctly. So I think only Minix used it. Minix could run on the 8088 too, but it didn't have true memory protection in that case, but it had multitasking. Jan 30, 2020 at 9:32
  • Microsoft Xenix ran on a 286. You were limited to 64K code + 64K data (IIRC), and there was no hope of DOS compatibility. There were other (non-DOS) OSes that ran on a 286; if my fading memory doesn't fail me, there was some sort of Ada-based OS for hard-realtime embedded systems, as well.
    – Eric Brown
    Aug 12, 2021 at 0:21
  • @Eric yes, see this Q&A for a discussion of some 286 OSs. Xenix allowed more than 128K per process. Aug 12, 2021 at 5:54

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .