New Release: EMM386 2.10, HIMEM 3.13
From: Michael Devore
Date: Sat, 08 Jul 2006 22:18:36 -0500

Uploaded to ftp://ftp.devoresoftware.com/downloads/emm386/ are the files 
emmx210.zip, EMM386 version 2.10 and HIMEM version 3.13 memory managers, 
mostly executables; and emms210.zip, source code files for the new release.

The latest revisions (effectively completed in May) contain several 
compatibility modifications and two bugfixes.  The bugfixes apply to 
DOS-extended programs for certain DOS extenders running under large (>256M) 
free memory conditions.  The compatibility modifications remove the need 
for a few programs to specify options or memory configurations to work 
correctly, and they stop VDS warning feedback for users of DiamondWare's 
Sound Toolkit (DWSTK).  Almost everyone is welcome and encouraged to give 
feedback on the revised memory managers, particularly should any problems 
persist.

As regular readers know, gory details follow:

First, the bugfixes.  Previously, EMS allocations were insufficiently 
coupled to VCPI allocations, meaning that sometimes the reported and actual 
EMS available for allocations did not take into account VCPI allocations 
already made from their pool (EMS and VCPI always share the same memory 
pool).  This was not instantly fatal to DOS extenders which depended on the 
information, but depending on their allocation strategies could confuse 
some extenders to the point of serious misbehavior, plus it was generally a 
bad idea that needed fixing.  So it was.

Second, the VCPI server, aka EMM386, did not temporarily reset linear 
memory to its own memory mapping via CR3 reload on direct calls to the 
server.  Since most memory tables lived within the common 4M memory shared 
with a VCPI client, this typically was not an issue.  However, if a target 
environment had more than around 256M free, and a DOS extender made 
protected mode calls back into EMM386 to allocate memory blocks (not all 
do), the memory page table mappings were large enough to extend beyond the 
shared 4M zone, and EMM386 tried to grab pages from memory that owned 
solely by the VCPI client.  This Is A Bad Thing And Made Bad Things 
Happen.  Since it has been established that I do not ever have any bugs in 
my code and the bug is indisputably present, the only logical explanation 
is the covert intervention of a malign deity.  Watch yourself while coding; 
dark forces gather to oppose FreeDOS 1.0.

Moving along to compatibility changes, EMM386 VDS function 0ch no longer 
returns an unsupported code.  It is treated as the no-op it effectively is 
under EMM386 and always returns success without warning feedback.  Also, 
VDS function 0bh silently returns an unsupported code without giving 
warning feedback.  Previously, both would give  feedback, which caused 
great consternation to users of DiamondWare's Sound Toolkit that made the 
function calls.  Riots ensued, dogs howled, and the entire student body of 
a women's college stripped to nothing and ran down the street...uhh, no, 
wait, that was last week's late night Cinemax movie that I had far too much 
self-respect to watch a single minute of.  Anyway, the warning message is 
gone with DWSTK under EMM386 and people should feel less worried about the 
whole thing.

EMM386 has a more efficient memory allocator when a user requests more 
memory be set-aside on the command line options than is available in the 
machine.  Previously EMM386 would divide by 2 until the request could be 
met.  So, if you requested 64M and 30M was available at startup, you would 
up with 16M.  Now, after failure on initial request, EMM386 tries to 
allocate all it can that it sees available, so in the example you should 
wind up with 30M, assuming no memory fragmentation.

Also, EMM386 reserves more XMS memory from ever being allocated by EMS/VCPI 
for those few goofy programs that always want a little bit of free XMS or 
else throw a tantrum.  386K is now reserved, of which FreeCOM usually 
chomps off about 100K or so, leaving between 256K and 300K XMS.

HIMEM now defaults to using the /X2MAX32 option, because two people have 
reported (buggy) applications that needed it.  Depending on what multiplier 
you use for reports vs. actual problems, that likely means 20, 200 or 2000 
people really need the option turned on.  Since it's such a silly thing 
anyway, I just decided to make it the default and avoid a bit of confusion 
in the world.  Also added was a new /NOX2MAX32 option to inhibit the 
/X2MAX32 behavior and restore the world to its normal state of affairs.

Oh yeah, XMS 3.0 function 88h was modified to have ECX correctly return the 
highest available memory address per XMS 3.0 specification.  Wooo, that 
might be a big deal and fix some problematic stuff you say?  Forget it, 
Microsoft's own HIMEM from MS-DOS 6.x screws it up and returns a garbage 
value.  Probably nothing uses the value, or should, anyway.

Finally, copyright messages were updated.  Yup, saved the biggest change 
for last.

_______________________________________________
Freedos-devel mailing list
https://lists.sourceforge.net/lists/listinfo/freedos-devel