At 06:20 PM 7/18/2006 +0200, you 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.phpp=sourceforgeCID=DEVDEV
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user
