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.

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
XMS3+ highest address: 2FFF0000
XMS3+ total extended memory (kB): 783957

no handle region            size(kB) locks flags
-------------------------------------------------------
  1 07A9   00110000-0022ABFF     1131     1 02 used
  2 07B3   0022AC00-0025ABFF      192     1 02 used
  3 07BD   0025AC00-023DAFFF    34305     0 01 free
  4 07C7   00000000-00000000        0     0 01 free
  5 07D1   023DB000-0255AFFF     1536     0 01 free
  6 07DB   0255B000-0285AFFF     3072     0 01 free
  7 07E5   0285B000-02E5AFFF     6144     0 01 free
  8 07EF   02E5B000-03A5AFFF    12288     0 01 free
  9 07F9   03A5B000-0525AFFF    24576     0 01 free
10 0803   0525B000-2FFEFFFF   702036     0 01 free
11 080D   00000000-00000000        0     0 01 free
12 0817   00000000-00000000        0     0 01 free
13 0821   00000000-00000000        0     0 01 free
14 082B   00000000-00000000        0     0 01 free
15 0835   00000000-00000000        0     0 01 free
16 083F   00000000-00000000        0     0 01 free
17 0849   00000000-00000000        0     0 01 free
...
----------------------------------------------------------------------

As it can be seen, the largest block is 80 MB too small.
What's bad, a try to alloc 750 MB will fail now. One first has to alloc 
smaller chunks until Himem is cured again.


As a comparison, if one does the same procedure with MS Himem, the table looks 
like this after DOOM:

----------------------------------------------------------------------
XMS version: 0300h
XMS3+ largest free block (kB): 783888  <------------- GOOD
XMS3+ highest address: 000B02DF
XMS3+ total extended memory (kB): 783888

no handle region            size(kB) locks flags
-------------------------------------------------------
  1 D58E   00110000-00110FFF        4     1 02 used
  2 D598   00111000-00140FFF      192     1 02 used
  3 D5A2   00141000-0026BFFF     1196     0 02 used
  4 D5AC   0026D000-2FFEFFFF   783884     0 04 unused
  5 D5B6   041AC800-0422D7FF      516     0 04 unused
  6 D5C0   0422D800-0432E7FF     1028     0 04 unused
  7 D5CA   0432E800-0452F7FF     2052     0 04 unused
  8 D5D4   0452F800-049307FF     4100     0 04 unused
  9 D5DE   04930800-051327FF     8200     0 04 unused
10 D5E8   05132800-06134BFF    16393     0 04 unused
11 D5F2   06134C00-2FFEFFFF   686829     0 04 unused
12 D5FC   2413EC00-2813E7FF    65535     0 04 unused
13 D606   2813E800-2C13E3FF    65535     0 04 unused
14 D610   2C13E400-2FFEFFFF    64199     0 04 unused
16 D624   00000000-00000000        0     0 04 unused
17 D62E   00000000-00000000        0     0 04 unused
...
-------------------------------------------------------

This is much better (although there is a bug in MS-Himem with the "highest 
address" value)


-------------------------------------------------------------------------
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

Reply via email to