ddress.  Conceivably, clients always set the proper CR3 before calling
the entry point, but nothing in the VCPI spec says this is necessary.
The entry stack, however, remains unchanged because a) I couldn't get
stack changes to work (see below) and b) the most common use of the
protected mode entry point does require the stack to be in shared low
memory and this may propagate to the other functions.

The undocumented function ENDALLOC was added and any critical 24-bit
loads were changed to 32-bit so that EMM386 non-VCPI routines can
function within the full 4G address space, rather than the first 16M.
ENDALLOC forces EMM386 to load and allocate memory at the end of XMS
rather than at the beginning, for dumb programs which might need lower
address XMS blocks.  HOWEVER, use of VCPI requires that the EMM386
VCPI server routines be mapped into the first 4M of memory for VCPI
client sharing (EMM386 itself only maps the required 1M low
memory+optional 1M ).  Due to this VCPI requirement, the ENDALLOC
option causes any program which uses VCPI to crash horribly under
EMM386, because the server routines are loaded too high in memory for
VCPI interaction.  Which leads me to my final point/rant.

I tried.  I really did.  I wanted to make EMM386 work as a VCPI server
and still be loadable anywhere within the full 4G extended memory
address space.  This would allow people to place drivers between HIMEM
and EMM386 in CONFIG.SYS, moving EMM386's load address above its
normal location, and still have EMM386 work as a VCPI server.  After
three false starts, I figured that if I stuck a VCPI server entry
point routine in low memory code aliased by the pre-existing low
memory data used by EMM386, then I could reload the descriptor tables
with EMM386's high memory address, rejigger selectors, jump to main
server routines, and everybody would be happy.

Doesn't work.  The client entry condition refuses to allow me to
switch back to my own stack originally passed to the client as one of
the three GDT entries available to the server.  No matter where, no
matter how valid, not matter if verified, stack changes puke blood and
die.  And then it crashes on my jump to high memory attempt.  Blew a
lot of free time on it, no luck.  So screw it, I'm done.  Any hotshot
young hacker wants to make it work, be my guest.  It's not like there
is a pack of VCPI groupies out there waiting to reward success.  And
if they are, they're twenty years and one marriage too late.  In the
meantime, don't load drivers which use XMS between HIMEM and EMM386 if
you want VCPI to work.

Consequently, ENDALLOC will remain an undocumented test option of
limited usefulness outside the EMM386 development sphere.

On a final note, all this work has made the chance of EMS/XMS pool
sharing feature appearing by the end of February far less likely.  I
hereby exercise the option to change my mind and say it probably will
arrive before March 31, 2005.