At 10:50 AM 3/11/2004 +0300, Arkady V.Belousov wrote: >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.
I suppose as an interim solution I could add support for a "super" unique handle for XMS in the XMM that EMM uses for its own EMS and VCPI allocations. The super handle would track and fill in the memory gaps between active XMS block allocations plus extend allocations out into the contiguous free XMS free pool as necessary. The XMM would respect the special handle and check its extra info at every XMS allocation/deallocation. This approach would mean that XMS doesn't yet have to be rewritten to support true reallocing of its block size, although obviously that would be the final goal. Right now the HIMEM XMM only supports a unintelligent shrink of blocks by reducing the marked length of a block on a realloc XMS function call and growth is not supported at all. Still, XMS would be prone to fragmentation in that half-step solution. Say there were 32M of XMS, and an application made a 4M XMS request, then a series of VCPI allocations chewed up 1M, then there was a 8M XMS request, then VCPI made a single 4K request, then the 8M XMS block was freed. Instead of having 32M-5M=27M (-4K) free, you would have a lump of 8M and lump of 19M free for XMS. Of course, XMS can be fragmented with its own allocations in a similar fashion, but VCPI makes a great number of little memory allocations (since an allocation is always 4K by definition) compared to the generally infrequent XMS allocations of typically far greater size, so the fragmentation with VCPI/EMS mixed in there could be extreme. Ultimately the only way to avoid fragmentation is to bite the bullet and move everything to page table-based memory management in the XMM. Another problem besides fragmentation is that the interim solution doesn't avoid rewriting parts of HIMEM as well as EMM386 to make it super handle aware, which isn't a task I particularly relish jumping into without a lot of thought. I guess the big question is: Are XMS and EMS/VCPI allocations almost always made either at startup in one contiguous problem-free chunk or within a single running application which nicely clears them all out when it's done? Or are control programs/shells and drivers and TSR's and the like drawing from the pool at different times in an application's execution (or at the DOS prompt) and leaving the pool fragmented for the life of the DOS session? I keep thinking from the multi-tasking perspective I've been using for the past many years, but that really isn't an issue here in FreeDOS. It's strictly drivers and such making dynamic allocation/frees where you would have to worry about permanent fragmentation in FreeDOS. That and ill-behaved programs which don't always clear out all their XMS/EMS/VCPI allocations, crapping in the pool for applications which run after them -- and unfortunately those ill-behaved type of applications are out there and not the rarest of birds. ------------------------------------------------------- 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_id=1470&alloc_id=3638&op=click _______________________________________________ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
