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

EMM386 Version 2.02 is a stable release with small bug fixes over
version 2.01 and compatibility enhancements.  It is a generally
recommended upgrade, but not critical.

EMM386 fixes an error which causes a tiny memory leak when allocating
VCPI/EMS.  It fixes a more serious bug where -- under rare
circumstance -- EMM386 incorrectly believed it was out of memory.
This was only known to happen with the Deskwork RAMdisk utility
present, but it could possibly happen for other applications or
environments.  EMM386 will also warn if an old or out-dated HIMEM
version is used which does not allow XMS/EMS/VCPI common pool sharing.

Version 2.02 adds the new MAX= option to limit amount of available
VCPI, and EMS if <32M.  Use this with versions of DOS/32A which fail
if more than 256M of VCPI is available.  2.02 also adds emulation
support for the CPU RDTSC instruction in early Pentium and AMD chips.

Blathering on...

The memory leak bug would lead to temporary loss of 0-2% of allocated
memory as unavailable for use due to invalid memory alignment skipping
past 0-3 available pages of memory per block.

The bug with DeskWork RAMdisk was due to an error where small free XMS
blocks of <4K could, under certain circumstances of memory alignment,
lead the EMS/VCPI allocator to believe there was no more free XMS to
use, despite whatever free XMS blocks may exist.

The RDTSC emulation is as described.  Not much more to say about it.
It appears to be an Intel faulty design in Pentium chips, aped by
comparable AMD processors.  Pentium Pro, II, and later chips do not
have the problem.  As a consequence of my not having an old chip, the
modification is untested.

If someone should decide on a whim, through curiosity, by mistake, or
via basic stupidity, to use an out-dated or substandard XMS memory
manager which does not support INT 2Fh function 4309h, thereby forcing
EMM386 to turn off common pool-sharing, EMM386 will provide a startup
warning message to the effect that the user should upgrade or use an
explicit EMM= option sized allocation.

EMM386 supports the MAX=#### option which allows limiting the
available VCPI to the MAX setting.  If less than 32M, it will also
limit EMS.  EMM386 is smart enough to throttle its doubling of XMS
block allocations (currently 1.5M, 1.5M, 3M, 6M, 12M, etc) back down
to a value under MAX.  MAX usage will be accurate to within
approximately 1.5M.  As a vaguely amusing side-note, given the
separate EMS and VPCI allocator, using up VCPI to MAX limits still
allows EMS to separately use memory up to the MAX setting.

The MAX option is mostly for extenders or programs which inexplicably
throw a tantrum if allowed too much free VCPI memory.  At least some
versions of DOS/32A act this way.

The RSX DOS extender used by RAR32 throws a tantrum in a slightly
different way.  If EMM386 is loaded, and more than 429M of memory is
available EVEN IF almost all of memory is either left as XMS or taken
from XMS to VCPI, then RSX will give an out of memory error.  It will
not do that if EMM386 is not loaded.  This includes any EMM386 MAX
setting or use of a fixed pool via the EMM= option (as far as I could
test, anyway).  You must use the /MAX=### option of HIMEM, not EMM386,
to limit total memory to get around the problem.  RAR32 sobs quietly
to itself over such bizarre behavior in its forced coupling with RSX.

This version is considered stable.  No more than the normal complement
of bugs are expected to exist.  I will be available to fix those and
answer the occasional inquiry, but otherwise am taking the summer off
from anything that involves EMM386 and HIMEM.  Should anyone desire
new features or a novelization on the perils of VCPI, they need look
towards another EMM386 related/interested developer type of person,
place or thing.