Hi!

10-Мар-2004 20:00 [EMAIL PROTECTED] (Michael Devore) wrote to
[EMAIL PROTECTED]:

>>     As I understand, EMM386 may inserts itself into XMM chain and behave as
>>XMM over HIMEM. Thus, you will one memory available both through EMS and
>>XMS, as in QEMM386.
MD> No, the memory allocation is quite different.

     I know, that XMS and EMS are different specifications, but what
prevents XMM and EMM use common memory (alloc, dealloc, lock)? QEMM386 does
this easily.

MD> XMS memory is allocated in
MD> discrete sizes, with an extremely limited number of handles, and locking a
MD> block gives you a starting address which references the whole block.  Memory
MD> within the block is always assumed linear for access.

     And? You fear, that XMM handle table is too short in HIMEM? No problem:
EMM (may/should) allocate all memory, insert itself into XMM chain and
behaves like XMM and EMM (over common memory). Similarly to DOS in HMA: DOS
allocates all HMA and then allows suballocation (though, in old MS-DOS there
are no deallocation implemented).

MD> There is no such thing as an absolute address with EMS other than the 64K
MD> page frame in low memory and a single 16K (EMS) or 4K (VCPI) block.  As a

     This even better, because EMM may now defragment memory to make one big
contiguous memory area for XMS requests [if there is not enough memory in
existing free blocks].

MD> If you start allocating XMS in a random spray to satisfy a number of VCPI 4K
MD> requests, you immediately fragment its memory pool and require more than a
MD> simple array of handles to track where things go.

     What makes this impossible?

MD> XMS is currently tracked
MD> as a position in and a length of physical memory per handle, not as a list
MD> of varying sized allocations per handle (which wouldn't even work for linearity).

     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> memory through the page tables with each page change, but it's by no means a
MD> simple task and a good bit of the code to do it would have to be written
MD> from scratch, not to mention side issues.  Doing all that's a lot of work,
MD> well beyond anything I'm ready to take on right now.

     This is bigger reason for me. :(




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

Reply via email to