The first release candidate version of EMM386 with VCPI support is
available at ftp://ftp.devoresoftware.com/downloads in the files
EMM386.ZIP and EMM386SR.ZIP, as executable and ASM+C source. Note
well: the uncompressed executable name is now EMM386.EXE, and not the
previous test release name of EMM38664.EXE

This version of EMM386 corrects an incompatibility with Duke3D using
the high resolution 800x600 mode, and potentially with similar DOS
extended programs.  The NOEMS option of EMM386 has been corrected to
allocate more memory for larger memory machines (>192M), as well as
allocate additional memory to VCPI.  EMM386 parsing has been slightly
improved.  It also has a (completely untested) check for VMware with
auto exclusion of UMB's in the range 0E800-0EFFF.

Please bang on this version of EMM386 as hard as you can to uncover
any problems affecting maximum compatibility with all known extenders
and DOS extended programs, as well as various memory setups.  This
version is a candidate for next official release of EMM386 (except for
any additional fixes, tweaks, and enhancements that Tom Ehlert may add
to it).

As always, further details follow:

Fixed a problem where EMM386 did not always clear the high word of the
ESP register when necessary depending on how the VCPI handler was
entered, leading to problems with Duke3D in high resolution mode.
Theoretically this could fix other compatibility issues.

With NOEMS EMM386 dynamically allocates more memory for its page
tables than the previous static amount which caused problems when
extended memory was more than 192M.

NOEMS now allocates 1/16th of free XMS memory to reserve for VCPI at
startup.  This is to accommodate accursed DOS extended applications
which fail to allocate from the XMS memory pool as is standard for
extended environments, and consequently generate out of memory errors.
If you want more or less of an allocation to VCPI, you will need to
use the EMM= setting to explicitly set an EMS amount -- which directly
goes to the VCPI available since the memory pool is shared between the
two.

EMM= was moved to internally parse before NOEMS so that NOEMS could
properly shut off any allocation EMM= wanted to make.

If zero UMB's are available at startup (for example with an
X=C000-EFFF) it no longer breaks EMM386 by virtue of EMM386 trying to
allocate zero bytes of XMS memory and manipulate that (non)amount.

EMM386 was internally rejiggered to work with the 386SWAT protected
mode debugger.

Code was added to detect a session running under VMware via the
unofficial method of accessing port 5856h and checking a return value.
If VMware is detected, memory from e800-efff is automatically eXcluded
from UMB's, per VMware's official documentation to avoid VMware
failure.  This code is absolutely untested.

Aside from bugfixes, the remaining TO-DO list of EMM386 is merging the
EMS/VCPI and XMS memory pools into a single shared pool and VDS
support.  As it stands now, I don't anticipate either of those tasks
being started in the near future, at least by me.