Hi Michael, Thanks for the update! I am unable to get the file via FTP (unable to connect), could you please give alternative ways, or upload it to ibiblio?
Thanks! Aitor 2006/7/9, Michael Devore <[EMAIL PROTECTED]>: > 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 > [email protected] > https://lists.sourceforge.net/lists/listinfo/freedos-devel > ------------------------------------------------------------------------- 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 [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
