Hi!
17-Июн-2004 22:40 [EMAIL PROTECTED] (Michael Devore) wrote to
[EMAIL PROTECTED]:
MD> I hope to have some free time later this weekend and will try to get caught
MD> up on a few FreeDOS items, including your requested test, a stand-alone UMB
MD> stress test, and code up an XMS block auto-grabber/releaser for Erwin
MD> Veermans' NWDSK if it proves feasible and fixes the immediate problem with
MD> NIOS load limitations.
Ok.
MD> However, EMM386 may not necessary return a next higher block address
MD> depending on the size and order of what has already loaded in UMBs. It can
MD> split large blocks and/or alloc a free block with a lower address than a
MD> previously allocated one.
Of course, I know. Moreover, it should do it: for example, B000-B800
32k segment is shorter than segment at C800-F000, thus should be returned
later.
MD> If you're depending on that particular load/alloc behavior, you'll have to
MD> let me know not to load anything else which uses UMB's
No, this is not _my_ dependations, this is analyzation of _current_
umb_init() behavior when enumerated conditions satisfied. Of course, this is
low probable that last paragraph in returned block will contain 'M' in first
byte, but this is possible, and I wish to confirm my verification of code.
>>- at next call to XMS/AH=10h your EMM386 should return next _higher_ block
>> (say, at 0xC800). This should force inifinite loop in prev_mcb().
"This should force" if mean "this will force, if I right analyze".
-------------------------------------------------------
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
_______________________________________________
Freedos-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-devel
