support heap in HMA

[stsp]

We can optionally support heap in HMA and create an UMB where kernel initially was. Such UMB will not be adjacent to others unfortunately.

[andrewbird]

Perhaps you could use it to load device drivers there as they wouldn't need to be unloaded etc?

[stsp]

This is pretty much impossible. Only tiny-linked code can work in HMA.

[andrewbird]

Only tiny-linked code can work in HMA.

I actually meant could drivers be loaded into the non-adjacent UMBs.

[stsp]

That would be a rather small UMB, like 2.5K. But its not the only space to save. On dosemu2 side I can free a bit more, and in an adjacent way. Also I wonder why KernelAlloc() can't use HMA... I think it can.

[stsp]

Yep, KernelAlloc() looks like a low-hanging fruit! Got +8K of UMB for free.

[stsp]

I actually meant could drivers be loaded into the non-adjacent UMBs.

Its up to DOS to decide. Small non-adjacent UMBs produce problems with fragmentation etc, but this is up to DOS to handle.

[stsp]

Someone needs to find out why mem reacts inadequately to an additional UMB in dosemu's heap. For that, in config.c:755 #if 0 should be replaced with #if 1 while $_dos_up is set to 2. Such change increases the amount of free UMBs properly, but it also increases the amount of used UMBs for unclear reason, and increases total UMBs much more than expected.

Andrew, since you are good at compiling freedos tools, maybe you can take a look? Should be fairly simple... for someone who builds mem.exe. :)

[stsp]

The problem is likely in FDPP_LMHEAP_ADD define of dosemu2, which seems to be too small and misused. That probably results in UMBs inside e820-reserved regions, which confuses mem. This theory have to be verified.

[stsp]

Seems fixed. Though not entirely sure by what exactly.