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

As with the previous release, EMM386 version 1.15 contains a
significant number of both fixes and enhancements.  It is recommended
for anyone having any problems with a previous EMM386 release, or who
thinks their copy of EMM386 could be operating incorrectly.  User
feedback on problems is vital to further bugfixes.

Version 1.15 EMM386 adds support for VDS function 2, to allow the Fast
Tracker application to execute without failure.  It fixes an error in
EMS function 53h, so that PCTool's MI program will not crash.  It
fixes a long-standing error in EMS function 58h, to allow
Quarterdeck's Manifest program to properly display EMS information.
It allows Doom to operate without use of the NOEMS option.  Other
problematic applications may also be affected by these changes.  Plus,
EMM386 version 1.15 adds support for several lesser EMS 4.0 functions,
and reworks sections of VCPI code, including fixing a problem with
EMM=#### option values greater than  approximately 261000.

The code for several low-level operations was modified.  Tests with
DOS extended applications (i.e. using VCPI) to ensure compatibility is
recommended.

An optional more in-depth description of the changes follows.  Users
only, cut here...

Previous version 1.14's new EMS function 53h support broke PCTool's
Memory Information program because it wrote the handle information to
the wrong area of memory, overwriting critical areas of either DOS or
MI.  Masters of Orion still works.

The Fast Tracker program -- version 2.09 tested -- would fail because
the EMM386 VDS option did not include support for function 2, basic
identification and flags.  FT tests okay in EMM386 1.15, at least as
far as buttons working.  I don't have a clue how to use for real work.

EMS function 58h, subfunction 1, did not properly return the number of
EMS mappable pages.  The bug caused Manifest to fail to display most
EMS information properly and crashed the Benchmark selection.  This
was fixed.  Timings still crash on my machine because it's too fast
for MFT.

Support for several lesser EMS 4.0 functions and a few cosmetic source
code changes were made based on Eric Auer's contribution.

Specifying EMM=#### amounts greater than around 256M (261000), would
overflow and limit EMS and VCPI to the overflow amount, although the
full XMS allocation was made.  This was fixed and VCPI allocations
were limited to a maximum of 511M.   Intelligent DOS extenders can
still use XMS beyond that limitation in addition to VCPI allocations
for their memory needs (though needing more than 511M is pretty
scary).  Increasing the VCPI maximum is theoretically possible, but
would require uncoupling the EMS memory available report from the VCPI
memory report, and probably isn't a good idea.  More on this in the
following discussion.

Doom would break if the NOEMS option of EMM386 was NOT specified, for
fairly complex reasons.  This was a consequence of the version 1.14
change wherein I modified the VCPI protected mode entry code to use
the server CR3 linear address space.  This was done so that server
accesses of extended memory would be relative to server memory
addresses and not a potentially completely different memory area based
on client memory mappings.  Right idea, bad choice.  Doom failed
because its client stack, used by the server, was not in the same
memory space as the server.  As it turns out, since EMS and VCPI
allocations are indirectly manipulated through tables in shared memory
space, there is no need to change to the server CR3 address.  The CR3
change was reverted to pre-1.14 status, which made Doom happy again.
By the way, some bored individual might volunteer to update the
comp.os.msdos FAQ which says FreeDOS doesn't work with Doom.

Why did Doom work with the NOEMS option?  Because NOEMS would throttle
the free EMS memory report back down to one page, which Doom detected
and changed to allocating all its memory through XMS, which didn't go
through VCPI allocations in protected mode.   In case anyone wonders
about the type of bugs that make professional programmer debugging
types get prematurely bald and wrinkly, this is an excellent example.
The NOEMS/VCPI topic leads to the final point...

The NOEMS option no longer throttles the free EMS memory report in
function 42h to one page.  Why not?  Because Microsoft EMM386 version
7.x doesn't, and because the VCPI specification recommends using the
EMS memory function to determine available VCPI memory.  Why did
FreeDOS EMM386 originally throttle the free EMS?  Because NOEMS option
is supposed to mean no EMS usage allowed.  Obviously, Microsoft didn't
get the memo.  One page was originally left to allow VCPI detection by
successful single page allocate.  Now, even with NOEMS all available
EMS/VCPI memory is reported in function 42h.  Up to 7fffh 16K-sized
pages, or 511M.  The high bit is left clear for dumb programs which
use signed instead of unsigned compares.  Similar to the way Disney's
Aladdin program does on >32M of XMS, causing Aladdin to fail on higher
memory machines unless HIMEM's /MAX option is used or external XMS
allocations are made.  Walt would kick somebody's butt for that.

Hmm, Zombie Walt Disney kicking butt, now that would be a cool game.

--Micheal Devore