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?
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).
