Hi!
11-Мар-2004 03:28 [EMAIL PROTECTED] (Michael Devore) wrote to
[EMAIL PROTECTED]:
>> I see no troubles: in simplest implemenation you may track EMM pages as
>>XMS blocks (inside list of "handles", shown by EMM386) and even not hide
>>them in XMS handles list. This even not requires defragmentation or changing
>>blocks size.
MD> I suppose as an interim solution I could add support for a "super" unique
MD> handle for XMS in the XMM that EMM uses for its own EMS and VCPI
MD> allocations.
Back door in HIMEM for EMM386?
MD> allocation/deallocation. This approach would mean that XMS doesn't yet have
MD> to be rewritten to support true reallocing of its block size, although
MD> obviously that would be the final goal.
See the difference: you say "reallocation", so you mean "all EMS pages
in one contiguous memory block", but I suggest that all XMS blocks and EMS
pages will be tracked in one directory, which reside in EMM data (because it
allocates all below XMS and traps XMM interface). With this, you may or may
not add defragmentation possibilities right now, even if this may be useful
in future.
BTW, I suggest that for defargmentation may be used simples method of
moving down all used blocks (over free blocks) (unless there are blocks with
locks at fixed addresses - in this case may or may not used more advanced
algorithms). Of course, copying all memory (ie. defragmentation may/should
be performed only if there are no enough contiguous free memory block) is
not the fastest operation, but I think, this is better, than rejecting
requests for memory allocation.
BTW, EMM (usually) allocates fixed size (16k) memory blocks, so this
should greatly reduce fragmentation.
BTW, implementing XMS in EMM should speed up this interface (because no
extra call layers when copying memory).
MD> I guess the big question is: Are XMS and EMS/VCPI allocations almost always
MD> made either at startup
"At startup" of what? System? Some program?
MD> in one contiguous problem-free chunk or within a
MD> single running application which nicely clears them all out when it's done?
I think, almost always (very often) memory allocation is stack based
procedure: app starts, then allocates (some times) memory, then deallocates
memory, then exits. "App" may be TSR, called inside other app. Very rarely
(almost never) applications allocates memory and not deallocates at end.
There is one big exclusion: multitasking environment, but this is not
FreeDOS headache currently.
MD> ill-behaved programs which don't always clear out all their XMS/EMS/VCPI
MD> allocations, crapping in the pool for applications which run after them --
MD> and unfortunately those ill-behaved type of applications are out there and
MD> not the rarest of birds.
Anyway with such _buggy_ apps you (quickly) end up with no free memory,
so fragmentation in this case is not the biggest issue.
-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id70&alloc_id638&op=click
_______________________________________________
Freedos-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-devel
