At 03:38 AM 3/11/2004 +0300, Arkady V.Belousov wrote: >Hi! > >10-Мар-2004 15:54 [EMAIL PROTECTED] (Michael Devore) wrote to >[EMAIL PROTECTED]: > >MD> What would you think about an EMM386 that decided to steal some of your XMS >MD> memory at startup, just in case a VCPI-using program wanted it later on? I > > 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.
No, the memory allocation is quite different. XMS memory is allocated in discrete sizes, with an extremely limited number of handles, and locking a block gives you a starting address which references the whole block. Memory within the block is always assumed linear for access. There is no such thing as an absolute address with EMS other than the 64K page frame in low memory and a single 16K (EMS) or 4K (VCPI) block. As a consequence, you can allocate EMS/VCPI memory in a random spray across a memory range without any side effects -- you need only track what 4K/16K pages goes with what EMS handle. EMS memory can be, and usually is, nonlinear. If you start allocating XMS in a random spray to satisfy a number of VCPI 4K requests, you immediately fragment its memory pool and require more than a simple array of handles to track where things go. XMS is currently tracked as a position in and a length of physical memory per handle, not as a list of varying sized allocations per handle (which wouldn't even work for linearity). The only XMS handle allocation which can potentially grow would be the last one on the chain of allocations into the free area, the other XMS handle allocations are bounded by their neighbors. Currently the EMM could use a single chunk of XMS memory and suballocate it into 4K and 16K memory allocations as requested for EMS/VCPI memory requests only. But that single chunk would have to be allocated at startup and couldn't change size. And if fact, that's how it does work right now. What you'd have to do to share EMS and XMS is dynamically support growing and shrinking of any arbitrary XMS block that the EMM would use. It could be done by virtualization and dynamically remapping physical to linear memory through the page tables with each page change, but it's by no means a simple task and a good bit of the code to do it would have to be written from scratch, not to mention side issues. Doing all that's a lot of work, well beyond anything I'm ready to take on right now. It's much of the reason QEMM used to be able to charge a good price for their memory manager over what Microsoft then supplied for free. There are fairly complex memory allocation issues here, probably beyond the scope of me trying to describe them in one message. ------------------------------------------------------- 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
