re: Comment on Memory Management FAQ

Hi, my favourite topic again ;-).
Now, the thing is: XMS drivers do not put the CPU in constant v86 mode.
They only use protected mode in a quite """compatible""" way when they
copy memory areas around. The problem is that EMS drivers (emm386 ones,
not hardware EMS ones) need to KEEP the CPU in v86 mode.
It is not THAT hard for a program to turn protected mode on itself when
it starts out from REAL mode. But this is impossible from V86 mode, as
you only have limited privileges in v86 mode.
This is where VCPI comes into play: It is, as you figured out correctly,
meant as a lowlevel interface that allows protected mode programs to
share the powers of full privileges. A program "locked" in v86 mode can
ask the program that has locked it in there (for example emm386) to get
full privileges handed over from it. This requires VCPI.
As said, an XMS manager does not need to provide VCPI. For XMS, the problem
turns out to be the other way round: If an application uses protected mode,
it may block the XMS drivers ability to copy memory around by that. However,
applications can either help the XMS driver with its task or do the copying
completely themselves while they use protected mode. So unless you have a
TSR that uses XMS (like LBAcache!) The TSR will be unable to access XMS while
some application that does not provide that "helping hand" to the XMS driver
is using protected mode. However, as far as I know, many DOS protected mode
applications DO provide the needed "int 15 BIOS extended memory copying" API
(not that hard to do).
Would be interesting to know which programs do NOT. Those would cause hangs
or error messages from LBAcache while you use them, as without int 15 helper
cooperation problems between fdxxms and the protected mode program arise.

The funny thing about VCPI is that when you have DPMI, you sometimes do
not need VCPI. This is how DOSEMU offers protected mode to DOS programs:
It cannot offer them to take part in sharing the full privs (VCPI), but
most programs will be happy with protected mode services provided (DPMI)
and will no longer insist on setting up protected mode themselves (from
real mode or through VCPI sharing), because they are satisfied with the
"canned" protected mode stuff that DPMI offers. VCPI is very lowlevel and
meant to allow programs that want full control over protected mode to
share this power. DPMI is more for applications and offers more standard
things, such as "create a new protected mode task" or "call a DOS interrupt
from protected mode". DPMI is often confused with DOS EXTENDERS. DOS extenders
implement a protected mode version of the complete DOS API (roughly speaking),
and they often use DPMI services as helper functions. Many DOS EXTENDERS
contain their own DPMI "server" because you often need DPMI and DOS EXTENDERS
at the same time. This builtin DPMI module will stay unused when the other,
EXTENDER, part detects that DPMI is already present anyway.

So: In real mode, you can turn protected mode on yourself.
    With XMS, the XMS driver only needs a single "copy memory" function that
    makes use of protected mode, and the XMS driver only needs it while
    copying XMS memory.
    Many protected mode programs either access XMS memory directly (so the
    XMS driver does not need to copy it) or provide their own "copy memory"
    function to the XMS driver so that it can stay active.
    In v86 mode, you do not have enough power to turn yourself into a controler
    of protected mode, BUT many programs that activate v86 mode also offer the
    VCPI cooperation interface, which allows you to request more powers from
    within your "v86 mode jail".
    Many DOS EXTENDERS use the comfortable DPMI services to offer a "protected
    mode DOS" to the program using them. Often, they contain a builtin DPMI
    driver.
    If you offer DPMI services directly, many modern programs no longer insist
    on getting full power (through VCPI or by starting in real mode). They are
    happy to get the needed stuff from DPMI, even if it is not them who are in
    control over the full powers of protected mode.
    Protected mode programs that work in DOSEMU are the ones that are satisfied
    with DPMI. Protected mode programs that refuse to run even when only MS DOS
    emm386 is loaded fall into the category "we want full powers for everything
    that protected mode has". A category in between are protected mode
    programs that run with MS/DR emm386 but not with FD emm386: They have the
    knowledge to ask politely via VCPI, but still want full powers (they can
    not ask FD emm386 because it does not offer VCPI).

Many more recent protected mode programs have a big choice of options, e.g.:
- from real mode, start protected mode yourself, install DPMI and an extender.
- when DPMI is already present, only install the extender.
- when neither real mode nor DPMI can be reached, ask via VCPI to get enough
  privileges to install your own DPMI and extender.

I think this is a quite common case. And most of them allow XMS to keep
running, too.

Those "professional" protected mode programs only fail when you lock them
into v86 mode without providing either of DPMI or VCPI. Remember that DPMI
is only available in a DOS box of Windows or Linux, or alternative through
the DPMI=ON option of DR DOS emm386. So normal DOS users would take care to
either not load any emm386 or select one with VCPI. When they want to run
one of the "professional" protected mode programs, I mean. More daring DOS
users can try the DPMI=ON trick as well. Users of Linux/Windows will be
unable or unwilling to provide VCPI, so they would configure their DOS
windows/boxes to have DPMI enabled (you cannot configure a DOS window/box
to run in real mode: Only PC emulators like Bochs and VMware are at least
able to simulate real mode. Real mode is simply "what you do not have when
protected mode is on", so if you do need it, you must simulate it. Otherwise,
only v86 and normal protected mode tasks are possible in protected mode.)...

To add a comment to the paragraph at the end of Georges mail: Do not worry,
XMS drivers do not mess with your "mode" that much. Only multitasking operating
systems and EMS drivers tend to do that. So you should be generally fine with
what FDXMS and the like leave you of real mode, it is really quite real :-).

Your assumption that FDXMS runs in protected mode is too pessimistic:
FDXMS runs in real or v86 mode (whereever it happens to get loaded) and
the only protected mode thing that it uses is asking the BIOS to copy data
beyond the 1 MB boundary. For this, the BIOS turns on protected mode for a
short time, and turns it off again right after the copying. Programs that
use protected mode can offer a replacement for that BIOS service to FDXMS with
relatively small effort and often do so. Before anybody complains: Yes, FDXMS
can also use protected mode for a moment directly instead of asking the BIOS
to do so. But when in doubt, it will fall back to the BIOS method.

Eric