> A 'pure' DOS extender simply switches the CPU to 32-bit mode and takes over the system. That works fine in pure DOS, but not from a v86 environment. So, DPMI was invented as an interface for programs in a v86 environment to let the host

Hmm that was not my understanding, not saying you are wrong though. I did not see any conflict between v86 and dpmi....the first simply forced realmode programs through the mmu so they could map ems into xms...the second provided a way for 32 bit apps (including emm386 itself) make syscalls back to realmode dos in a standardized fashion.

kolderman wrote:

Hmm that was not my understanding, not saying you are wrong though. I did not see any conflict between v86 and dpmi....

That's not what I said.
I said there's a conflict between taking over the entire CPU and switching it into protected mode, and the CPU already being in v86 mode.
Basically 'there can be only one'. There has to be one central 'kernel' or whatever you call it, which switches the CPU into protected mode, and then creates a v86 environment.
No program can take full control of the CPU from v86 mode (after all, 'v' stands for virtual. It's not in realmode, it just appears that way, but some of the environment is virtualized, you are in someone else's sandbox). So there's your conflict.

Which means that if you want programs from v86-mode to switch into another mode (which usually is 32-bit pmode, because they want the 32-bit flat memory model), this has to be done from that 'kernel'.
DPMI is the standardized interface to communicate between a v86 environment and the 'kernel'.

kolderman wrote:

the first simply forced realmode programs through the mmu so they could map ems into xms..

I think you are confusing v86 with what it is that EMM386 does.
EMM386 uses the 386's virtualization capabilities to emulate EMS in software. In order to do that, it has to first switch the CPU to pmode, because the virtualization is only available in that mode.
Then it has to set up a v86 mode, so that the machine still appears to be in realmode to DOS and its applications, for backward compatibility.
But v86 is a CPU mode, it's not directly related to EMM386. Any DOS prompt in Windows or OS/2 will also run in v86 mode. 16-bit Windows applications will also run in v86 mode under a 32-bit Windows.
v86 basically means a virtual 16-bit environment running under a 32-bit pmode environment (the idea is that you can have multiple such environments side-by-side, so you can multitask your 16-bit programs).
See here for more info: https://en.wikipedia.org/wiki/Virtual_8086_mode

So technically EMM386 is a 32-bit pmode OS, which runs DOS as its only task, in a v86 sandbox. It's a huge hack to achieve what it does: make it look like there's EMS memory under a 16-bit DOS environment.
In the early days, EMM386 broke various 32-bit DOS programs because of that. Their DOS Extenders could only run from realmode, not from v86 mode. So you'd have to reboot with EMM386 disabled to run these programs (like various early 32-bit DOS demos).