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. ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
