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