At 06:20 PM 7/18/2006 +0200, Japheth wrote: >There is a bug left in the FD-Himem.exe memory manager. > >When a program that had allocated several XMS blocks doesn't release these >blocks in the order FD-Himem likes it, it will report a too small "largest >free block". Luckily the memory is not "permanently" lost, FD-Himem is >able to >regenerate if certain conditions are met.
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. Merging of XMS blocks does occur when blocks are freed, rather than at allocation as I had thought, which is a superior method of handling fragmentation. Both leading blocks and following blocks are checked for contiguity in a double loop at release. So the original HIMEM is smarter than I thought. Tom Ehlert's code was improperly maligned by me and as a reward he gets to say one mean thing about my mother for free if he wants -- since she's been taking an earth bath for the last 36 years, it probably won't hurt her feelings much. If I can't duplicate the exact situation required to get less than fully merged contiguous blocks on free, I'll have to come up with a thought experiment which could cause failure to merge and subsequent block fragmentation by eyeballing the source code. Don't know how successful that will be. ------------------------------------------------------------------------- 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 Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
