The first release candidate version of EMM386 with VCPI support is available at ftp://ftp.devoresoftware.com/downloads in the files EMM386.ZIP and EMM386SR.ZIP, as executable and ASM+C source. Note well: the uncompressed executable name is now EMM386.EXE, and not the previous test release name of EMM38664.EXE
This version of EMM386 corrects an incompatibility with Duke3D using the high resolution 800x600 mode, and potentially with similar DOS extended programs. The NOEMS option of EMM386 has been corrected to allocate more memory for larger memory machines (>192M), as well as allocate additional memory to VCPI. EMM386 parsing has been slightly improved. It also has a (completely untested) check for VMware with auto exclusion of UMB's in the range 0E800-0EFFF. Please bang on this version of EMM386 as hard as you can to uncover any problems affecting maximum compatibility with all known extenders and DOS extended programs, as well as various memory setups. This version is a candidate for next official release of EMM386 (except for any additional fixes, tweaks, and enhancements that Tom Ehlert may add to it). As always, further details follow: Fixed a problem where EMM386 did not always clear the high word of the ESP register when necessary depending on how the VCPI handler was entered, leading to problems with Duke3D in high resolution mode. Theoretically this could fix other compatibility issues. With NOEMS EMM386 dynamically allocates more memory for its page tables than the previous static amount which caused problems when extended memory was more than 192M. NOEMS now allocates 1/16th of free XMS memory to reserve for VCPI at startup. This is to accommodate accursed DOS extended applications which fail to allocate from the XMS memory pool as is standard for extended environments, and consequently generate out of memory errors. If you want more or less of an allocation to VCPI, you will need to use the EMM= setting to explicitly set an EMS amount -- which directly goes to the VCPI available since the memory pool is shared between the two. EMM= was moved to internally parse before NOEMS so that NOEMS could properly shut off any allocation EMM= wanted to make. If zero UMB's are available at startup (for example with an X=C000-EFFF) it no longer breaks EMM386 by virtue of EMM386 trying to allocate zero bytes of XMS memory and manipulate that (non)amount. EMM386 was internally rejiggered to work with the 386SWAT protected mode debugger. Code was added to detect a session running under VMware via the unofficial method of accessing port 5856h and checking a return value. If VMware is detected, memory from e800-efff is automatically eXcluded from UMB's, per VMware's official documentation to avoid VMware failure. This code is absolutely untested. Aside from bugfixes, the remaining TO-DO list of EMM386 is merging the EMS/VCPI and XMS memory pools into a single shared pool and VDS support. As it stands now, I don't anticipate either of those tasks being started in the near future, at least by me. ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
