Uploaded to ftp://ftp.devoresoftware.com/downloads/emm386 are the
files emmx20.zip, EMM386/HIMEM mostly executable package, and
emms20.zip, EMM386/HIMEM mostly source package.

Version 2.0 of EMM386 supports sharing of extended memory between EMS,
XMS, and VCPI from a common pool.  For most users this means no more
need to specify EMM=xxxx in your EMM386 command, because the full
amount of memory is available to all memory classes, more or less.
Should you wish to limit memory for EMS/VCPI, you can still use the
EMM= setting.  Some programs may require this due to their failure to
work with too much free memory.

Additionally, HIMEM supports the /X2MAX32 option which limits XMS 2.0
memory reported to 32767K, to work around a dumb bug in Disney's
Aladdin game, and possibly others.  Full XMS memory is still present.
EMM386 also has a couple of bug-fixes that will affect almost nobody.

Be aware that some 1500 lines of assembly language code were added in
this version of EMM386, with another few hundred lines replaced or
deleted.  The actual code changes exceed that made for earlier VCPI
support.  Unnoticed (hopefully small) errors are virtually
guaranteed.  Please test applications and report any problems.

Various particulars ensue:

With the /X2MAX32 option of HIMEM, full XMS memory is still available
for both XMS 2.0 and 3.0 functions, and is fully reported on XMS 3.0
functions, eliminating the previous need to literally reduce all
available memory to <32M via HIMEM's MAX option get Aladdin to run.

The /? option is supported for HIMEM and EMM386.  Running HIMEM and
EMM386 at the command line will continue listing commands, as before,
but will not complain if /? is present.  Use of /? will henceforth be
known as the Arkady gambit.

The EMS system handle 0 name is preset to SYSTEM.  Also, memory for
UMBs are allocated to that handle, rather than in a separate handle as
before.

Since the EMS and VCPI allocators are now decoupled, I reduced maximum
available EMS to "industry-standard" 32M.  Mostly this was done
because silly EMS-using programs became confused if more than 32M was
available.  Pumping it back up to 512M would be a small change, but
probably unnecessary for anyone.  VCPI can go to 4G, theoretically.

There is a fix to INT 15h, function 87 in EMM386, but I have forgotten
the details.  Eric Auer can supply them in exhaustive detail, should
one wish.

EMS unmap page function 44h, bx = -1, has been broken for about a
thousand years.  It would map in garbage memory rather than original
page frame memory, possibly leading to a crash.  Apparently it's not
very critical since nobody has noticed going back to the original
EMM386 code.

On a very trivial note, EMM386 now supports common memory pool-sharing
between EMS, XMS, and VCPI, if a HIMEM version which supports INT 2fh
function 4309 is present (like recent FreeDOS versions).  No more
EMM=, usually.  As a consequence, the former VCPI reserve was
removed.  As a further consequence, should you wish to use a
nonstandard HIMEM without function 4309 support and do not specify an
EMM= setting, there will be approximately zero memory available for
EMS and VCPI.  If you do that, you are 100% on your own.

EMM386's pool-sharing feature is a bit more sophisticated than
originally planned.  It will search out the closest match to 1.5M
available in XMS free handles and use a matching handle to grow its
memory allocations.  If there is -- as is typical in a vanilla FreeDOS
environment -- only one monolithic XMS handle containing all free
memory, it will dynamically carve off a 1.5M slice as needed.  If
there are a litter of small amount of XMS handles of at least 32K
size, EMM386 will vacuum them up before carving up bigger pieces.

Nor will EMM386 voraciously consume precious XMS handles, given how
limited they are in number.  After the first couple of 1.5M
allocations, EMM386 starts doubling the allocation amount, assuming
that an application is after big memory game.  With the doubling
feature used against a single XMS handle holding all free memory, no
more than 13 handles need be consumed before the entire 4G address
space is covered.

EMM386 will also return XMS blocks to the pool when they are no longer
used by any EMS/VCPI allocation, where they may be used again by EMS
or VCPI, or allocated via XMS API functions.

You should be aware that there is no free lunch and pool-sharing may
increase memory allocation timing overhead by microseconds.  This
would be most noticeable when large blocks of EMS/VCPI are allocated,
then freed, since EMM386 will be dipping into and out of the common
memory pool as blocks come in and then go out of scope.

Hundreds of other small details and comments preempted in interest of
time, space, and sanity...

Questions, comments, problems, let me know.  I'll be around for a
while as this settles down, then after a suitable break, may take a
look at fixing CWSDPMI's faults or something entirely different.

-Micheal Devore