Hi Michael, > Against all my fitting inclinations to maintain a non-development stance > -- especially since this isn't really a bug in HIMEM -- I added the > capability to HIMEM to grow an existing XMS block, when possible.
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. Or do you mean "GVEdit crashes if the resizing changes the absolute location of the block in RAM"? As resizing is allowed to fail for locked blocks (and only for such blocks, the location is known), that should not be the problem here... > As a side note, GVEDIT does use XMS 3.x calls, quite frequently. Hm. Bad. Then DOSEmu does not flag whether a call is XMS 2 or XMS 3 in the log :-(. Yet another strange problem is that FDXMS works but FDXXMS fails - which is what made me think of an XMS 3 specific problem. > http://homepage.ntlworld.com/gvision/gv/gvedit.zip Eric PS: I just saw that reallocation is not possible at all in XMS 2, so this is probably what you wanted to tell me. Oops. But what does GVEdit do under XMS 2 hosts then? SUGGESTION: Add a command line switch "report version number 2.xx" to HIMEM. As /X2MAX32, such a switch will help to work around compatibility troubles. ------------------------------------------------------- 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
