After reading a few threads regarding VCPI/EMS and DPMI, I am wondering that are these two interfaces really needed if the sole purpose for DOSBox is to run DOS-based games..... Here I provide some background about VCPI and DPMI, why they exist and hope that DOSBox developers will come back and brainstorming.....

Both interfaces provide a mean for DOS-extended software (a DOS-extended software is the software that runs in protected-mode) to gather system information and switch to protected-mode. VCPI gives ultimate control to VCPI client. A VCPI client is the DOS-extended software that request VCPI service from VCPI server. A VCPI server, most likely, is 386-based memory managers that provide all-in-one EMS, XMS, upper memory management, eg. 386MAX, QEMM386, EMM386.EXE etc. just to name a few. When a VCPI client request protected-mode switch, the VCPI server must surrender the machine to the VCPI client, and VCPI client runs in Ring-0, hence the ultimate control. Well, due to such "ultimate control" VCPI is not multitasking friendly. Microsoft, at the time VCPI was drafted, didn't quite like the idea as the Windows 3.x in development, which is also an protected-mode environment, cannot afford to give VCPI clients such priviledge.

Therefore, DPMI came in which still provide a mean for DOS-extended software to switch to protected mode, but retained ultimate machine control to the server side, which is the DPMI host. Unlike VCPI clients, DPMI clients run in Ring-3. This allows OS kernel protected space to be saved from misbehaving protected-mode software.

In essence, VCPI and DPMI are here to resolve the conflict of protected-mode software in competing for machine control. While protected-mode software are also available in 286, protected-mode conflict is non-existance in 286 world because 286-based memory manager does not run in protected-mode and EMS emulation is not really popular in 286. Most 286-based machines use hardware EMS. For 386, DPMI and VCPI is a must if memory manager is used, since 386 memory manager puts the machine into V86-mode, which is another form of protected-mode, while the memory manager running DOS in Ring-3. Without DPMI or VCPI, there is no way for DOS-extended software to switch into protected-mode because mode-switching instructions are priviledge instructions that can only be executed in Ring-0.

So since DOSBox emulates DOS environment, which is a real-mode environment, there isn't a need for VCPI and DPMI here to resolve protected-mode software conflicts. Since DOSBox is an emulated environment, the EMS emulation should emulate hardware EMS, not EMS based on 386 hardware paging. It will not make any difference without DPMI and VCPI in DOSBox as most protected-software can be characterized as below:

1. Ancient protected-mode software that don't recognized DPMI or VCPI. This group of software only know how to switch to protected-mode directly by writing to CR0 or MSW, and will only switch to protected mode if CPU is in real mode. Will output some error message or fault trap by 386 memory managers if any, if absolutely must live in protected-mode. Otherwise, resort to other real-mode tricks to access memory above 1MB (EMS, XMS, AH=87h, Int15h etc.

2. Protected-mode software that recognized VCPI. Even though the software recognized VCPI, this is not favoured. The software will only resort to VCPI if 386 control software (memory managers) is detected, ala V86 mode. Otherwise, directly write to CR0 or MSW to switch to protected-mode. This is normally known as RAW switching, which has less software overhead. If you have a copy of AutoCAD DOS R11/R12, it comes with a Pharlap utility that times how many mode switching per second of the environment. 386 RAW switch is always the fastest compared to VCPI or DPMI.

3. Latest and greatest protected mode software that recognize both DPMI and VCPI. Again, for most DOS-extenders that I come across, all of them favour 386 RAW switching. Only when raw switching is not possible, then only VCPI and DPMI will be chosen.

Most of the details are extracted from my old good advanced DOS reference "Extending DOS" by Ray Duncan. Unless, there is one DOS app/game that DOSBox absolutely must support, and absolutely requires VCPI/DPMI, I hope that DOSBox developers can put DPMI/VCPI-based development to a stop, and focus on perfecting other areas of DOSBox, eg. protected-mode instructions emulation, faster screen draw, enhanced sound emulation etc.