At 04:39 PM 7/12/2005 +0200, Eric Auer wrote:
Thanks! Actually GVEdit grows the XMS block very often (in multiples of 4k)
so no wonder that GVEdit crashed. However, it is strange that nobody has
noticed this problem before. Documentation tells that reallocation can
only fail due to A20 problems, the handle being locked, or not enough XMS
being free.
Reallocation can fail if the memory manager doesn't support it,
specifically growing the same XMS block. Growth of a block is not
guaranteed because of memory contiguity issues. HIMEM didn't support it
at all since growing can be complex in any case.
Outside of the lack of guarantee that growing will work, it is not a good
idea to do it extensively, because of potential copy overhead and
fragmentation issues. And if a program does grow via reallocate, it must
gracefully handle failure on the reallocate. GVEDIT grow reallocated a
block approximately 32 times in increasing increments of 8K prior to
graphic screen startup. I would recommend against behaving that way,
although nothing forbids it assuming the program is prepared to properly
process a failure along the way.
Yet another strange problem is that FDXMS works but FDXXMS fails - which
is what made me think of an XMS 3 specific problem.
GVEDIT growth reallocation is via function 8fh, an XMS 3.x call.
-------------------------------------------------------
This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening
July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual
core and dual graphics technology at this free one hour event hosted by HP,
AMD, and NVIDIA. To register visit http://www.hp.com/go/dualwebinar
_______________________________________________
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user
