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

This version of EMM386 has a number of compatibility changes to
enhance operability with a variety of DOS applications and
environments without the need for advanced option tweaking.  As a
result of the seven changes to EMM386 and two changes to HIMEM, this
is a recommended released.

Briefly, besides various fixes and compatibility modifications, the
VDS option now defaults to on, with a new NOVDS option to turn it off
(NOVDS possibly required for some SCSI disk drivers); the XMS memory
manager supports growing memory blocks on resize for the Graphics
Vision text editor; and a limited MEMCHECK default of 3-4G is present
for MMIO-based devices such as USBASPI.SYS, with the ability to turn
it all off by use of the new NOCHECK option.

Particulars ponderously proceed post-paragraph:

The HMAMIN setting of HIMEM never up-converted its K setting to actual
bytes as required internally, plus it allowed 64K instead of a maximum
of 63K.  Bad HMAMIN, bad boy.  Fixed.

The NOVCPI option was blocking allocation of UMBs.  This was overly
aggressive, even for a severe option like NOVCPI, and it was chastised
back to proper behavior.  Regardless of that whoopsie, friends don't
let friends use NOVCPI, as it is almost never a good idea.  Unless you
know exactly why you are using NOVCPI, don't.

There was an error when parsing EMS, such that an EMS page frame was
marked present even if there was insufficient upper memory (i.e. no
64K contiguous block) to place it properly.  The problem would not be
present if you specified NOEMS and even without NOEMS it would not
cause misbehavior unless you used an application which depended on EMS
and a page frame.  Admittedly, it was an error with a nasty bite, but
one had to wander far into the hinterlands of nontypical environments
to get bitten.  Such is how developers rationalize away crippling
guilt.  And minor bugs.

The EMM386 driver saves the full 32-bit part of all general registers
it uses, as well as segment registers.  This may or may not clear up
problems with 386-optimized kernels.  I can't test.  It consumes an
additional 22 bytes of stack, which I'm thinking probably shouldn't be
a problem.  Of course, I used to think an incompetent buffoon probably
wouldn't make a second term as President, and now look what the USA is
stuck with, so counting on me to tell you whether a particular kernel
version is safe seems chancy.

HIMEM's XMS API supports growing a block on resize; previously only
shrinking was supported.  Sufficient contiguous memory must be
available to simultaneously hold the old block and the new block or
else it will fail.  This feature was added because the Graphics Vision
text editor did not gracefully handle a failed XMS growing resize,
although resizing is never guaranteed.  I don't know whether it's a
bound-in extender fault or an application fault, but something is
acting goofy in there and we're stuck writing the work-around for it.
Not that I feel crabby about it.

EMM386's VDS option had a bug in the scatter/gather function and made
various setups, such as Bernd's VMWare and Mark Bailey's laptop, cry
in grief and frustration at the unfairness of it all.  The evil error
was corrected to help better balance Universal Justice towards the
Good Guys.

While on the topics of VDS, the VDS option is now on by default.  Too
many environments require this to leave it as optional, plus a default
on condition matches Microsoft EMM386.  There exist SCSI setups which
will REQUIRE you to turn off VDS support via the new NOVDS option.
Unfortunately for those SCSI-ites, the people who need VDS outnumber
the people who need to not have VDS, so they lost out.  Or maybe the
people who need VDS just yell louder.  Ahh well, same difference to
me.  I like quiet.

EMM386 internally defaults its MAX setting to 256M, so that unless you
explicitly specify a MAX= setting more than 256M, available VCPI will
not exceed this amount.  This change was made solely to accommodate
the DOS/32A extender complaining when large amounts of free VCPI
memory are available.  Applications which used the extender would fail
with a fatal error in such cases, including MPXPLAY -- an otherwise
extremely impressive DOS program that deserves major kudos.  It
appears that DOS/32A is dumb as a leaf of lettuce about the whole lots
of VCPI available thing, which kind of sours me on those rabid
endorsements of it.

The final change is to ensure better compatibility with device drivers
that use MMIO (memory-mapped I/O) to high addresses outside of normal
RAM, such as USBASPI.SYS.  Previously, the MEMCHECK option was
required.  EMM386 now defaults to operating as if MEMCHECK was present
IF the source or destination address range starts (not ends) within
the 3G-4G address space.  Should you require MEMCHECK type operation
below 3G for a doofus program or whatever, MEMCHECK is still available
to cover all 0-4G.  If you want it to act like it used to (that is,
without MEMCHECK capability), use the new NOCHECK option.  That all
sounds clear as mud so let me recap:  default -> 3G-4G access allowed,
MEMCHECK -> 0-4G allowed, NOCHECK -> zero, zip, nada, can't access
memory outside of RAM space without lockups, failure, or spontaneous
flooding.

Lastly, to follow-up on the announcement of a $0.10 donation to the
International Federation of Red Cross and Red Crescent Societies
(www.ifrc.org) for each unique IP address downloading either the
source or binary package of