I am going to change the way EMM386 works a final time and since EMM386 with VCPI support is close to signing off as a generally stable release as far the VCPI feature, I'm posting the status so people know where we're at and have a last chance for input on VCPI-related mods.
NIOS has problems if it allocates extended memory above the 16M barrier, possibly an artifact of old 80286 code. There may be other programs with similar errors. As a consequence, I'm changing the VCPI reserve to max out at 12M with NOEMS. This means that programs such as NIOS can start their problematic allocations around the 14M-15M location in the worst case scenario. This change DOES fix the problem with NIOS and NOEMS, based on a test case and grants a substantial amount of VCPI reserve on large memory machines. In conjunction with the above change, I'm modifying the NOEMS VCPI reserve to be 1/8th, rather than the previous 1/16th amount of extended memory (subject to 12M maximum). This allows lower memory NOEMS machines to allocate a decent-sized amount of VCPI memory for those DOS extended programs that will not use XMS. The 1/8th allocation won't chew up enormous gobs of VCPI reserve memory from XMS on higher memory machines due to the new 12M maximum. Of course, you can control all of the memory allocation directly through the EMM= settings instead of using NOEMS. To make that more efficient for UMB's, I'm also adding FRAME=NONE support to the EMM386 command line parameters, matching Microsoft. That way, you can exactly control how much VCPI (or EMS) memory is reserved with EMM=, without losing 64K or more of UMB's to the EMS page frame if you don't want to. The reserve issue should go away if ever the EMS and XMS memory pool is shared and we eliminate a NOEMS-specific VCPI reserve. That may should like a poor substitute for Microsoft behavior, but it isn't the case. Microsoft's EMM386 prior to the 4.45 versions first included in MS-DOS 6.x -- as well as earlier versions of third-party memory managers -- did not share the EMS and XMS pool either. What we have now is likely more powerful than the pre-MS-DOS 6.x EMM386 memory manager versions. We are in good shape and compatibility for a FreeDOS 1.0 release at this level of EMM386 up to an approximate level at or above MS-DOS 5.0. While there are almost certainly individual programs that may need additional tweaking for EMM386 VCPI with additional V86-protected instructions to emulate etc., overall VCPI support appears to now be fully behaving per spec. The next release of EMM386 with VCPI will likely be the last featuring major VCPI changes for a long time, except for any individual program compatibility mods. Other options, I don't know, not my department. Thanks go to all of you who reported problems and worked with me to get the bugs out of the VCPI. A special thanks go to Tom Ehlert for providing valuable bugfixes and optimizations to my code along the way as well as adding his own code, and generally keeping the main HIMEM/EMM386 enhancement project on track. By the way, if there is anyone who uses Lynx under DOS beside the off-list user who reported problems, please let me know. ------------------------------------------------------- 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
