At 06:25 PM 11/9/2005 +0300, Arkady V.Belousov wrote:
>>MD> block. Specifically, this caused problems when trying to unload
CTMOUSE
>>MD> via its /U option.
>> Do you mean, when no DOS=UMB is present (else DOS allocates all UMA
>>for itself and never releases it)?
MD> I mean also if DOS=UMB is present. CTMOUSE still walks the UMB allocator
MD> chain during unloading.
Ah, sure, FreeMem calls XMM unconditionally.
BTW, I don't remember my reasons to call both XMM and DOS to deallocate
memory, but now I fear, that with some manager this may be wrong, if this
manager for function 11h (release UMB) accepts not only segment of UMB
start, but also any segment inside UMB. XMS doesn't clarifies this aspect.
EMM386, at least, retains the segments of upper memory blocks allocated
through its handler, up to its maximum allocation of 8 blocks. No match on
free, no release of block.
In fact, it was the exit on match failure which had erroneous code and was
causing the crash. If EMM386 were handling UMBs (no DOS=UMB), it probably
wouldn't crash with CTMOUSE /U under pre-2.07 versions, because the block
release successful code doesn't have the bug.
-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Freedos-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/freedos-devel
