<Oops, this reply goes to both lists I guess. Or I'm seeing double on your original post.>
At 06:20 PM 7/18/2006 +0200, Japheth wrote: >There is a bug left in the FD-Himem.exe memory manager. Nope. But see further... >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. > >This is a snapshot of the FD-XMS handle table after DOOM was launched and >terminated: > >---------------------------------------------------------------------- >XMS version: 0300h >XMS3+ largest free block (kB): 702036 <-------- BAD No, "GOOD". Or, actually, "CORRECT", but not terribly "GOOD". Is there a "BARELY COMPETENT" choice? Again, we have a situation where there is a bug label for what is merely suboptimal behavior. Besides suboptimal, programmers also refer to this type of code as "dumb", "idiotic", and "so bad my 90-year-old blind grandmother could code it better by typing with a pencil clenched between her butt cheeks". (That would be a number 2 pencil, naturally). Wow, two butt reference e-mails in a row. I must be anal. Okay, I'm having way too much fun with that, time to move on. What is happening is that the handles are associated with memory that is fragmented into separate chunks. To the best of my knowledge, under FreeDOS a memory report does not force blocks to coalesce, so FreeDOS is correctly reporting the largest (allocatable) block. In its defense, I believe that contiguous XMS blocks will be merged on allocation if there is insufficient memory contained in a single block, although I might be remembering that wrong. In other words, if my memory is correct, block merges are done on allocation, but not on release or reports. You could argue that FreeDOS HIMEM should be more intelligent about coalescing contiguous blocks on memory reports. And you would be right. It should. That particular code function is hardly the smartest memory management in the DOS world. That title would be reserved for how EMM386 shares XMS memory with EMS and VCPI (well, maybe not, but it IS pretty damn smart there). Suboptimal behavior which acts in a well-defined manner, however rude that manner may be, does not rise to the level of a "bug". Should I "fix" it? Yup. Should I fix it before FreeDOS 1.0 is released? I'm not convinced it's time to go in and start ripping around the code with less than two weeks to go. Particularly since the actual benefits for almost everyone using FreeDOS would be nonexistent. Later tonight as time presents itself, I'll look at the actual offending code and see what would be involved in upgrading HIMEM's IQ points in that area without any possibility of my introducing potential nasty bugs at the last minute. Uhh, not me introducing bugs, I mean that Sith Lord. But to be honest, there's a good chance this one won't make the FreeDOS 1.0 cut. ------------------------------------------------------------------------- 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-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user ------------------------------------------------------------------------- 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
