At 02:22 PM 7/26/2006 -0500, I wrote: >I can't duplicate the XMS memory block fragmentation with DOOM or anything >else handy, so whatever's happening depends upon the gameplay or memory >configuration or moon phase or any of the usual suspects.
Okay, I can get minor XMS free block fragmentation during direct calls to the VCPI/EMS allocator for large blocks. Since the VCPI/EMS allocator directly manipulates the XMS handles, it is possible to confuse the allocator's merge of free block back to adjacent XMS block if they are done out of sequence. The question is: who's responsible for merging them back? Should EMM386's VCPI/EMS allocator walk all the available XMS blocks multiple times on a freed block and sew them back together, or is that the responsible of HIMEM, which after all is the XMS "manager"? I can make HIMEM's allocator and free memory function force a free block merge walk every time it's called and that will clear up any remaining fragmentation, except for programs which directly access the XMS handles before HIMEM has a chance to do the merge walk. Or, I can make EMM386's VCPI/EMS allocator do it, clear up any fragmentation it is personally responsible for, but not cover the possibility of other programs directly accessing the XMS handles also, potentially leaving them in a fragmented state. Or I can make both HIMEM and EMM386 do it. Which sounds like a bit of overkill. ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
