Hi!

18-Авг-2006 13:36 [EMAIL PROTECTED] (Eric Auer) wrote to
freedos-devel@lists.sourceforge.net:

EA> Basically the updated patch means "free MCBs become unlinked
EA> when their memory is merged with the memory of adjacent free
EA> MCBs, but thear are no longer invalidated". Quite clean...

     ...except, that this ("this code comment out for compatibility with
MS-DOS and buggy QB/BRUN40 library") not explained in comment somewhere in
code. (As usually, "true programmers" don't like to comment, :( what they do.)

EA> How about marking free blocks as unresizable at the moment
EA> when joinMCBs splices them out of the chain, leaving an
EA> unlinked but "double-freeable" data structure in RAM?

     Interesting idea! There may be _added_ "return DE_INVLDMCB if MCB is
free".

EA> I imagine you could set m_size to -1 to mark a (former /
EA> unlinked) MCB as unresizable. Such a MCB would link to
EA> itself (seg+1+-1==seg) and can be identified as "fake"
EA> MCB that way. DosMemFree should accept "valid but fake"
EA> MCBs (for QB compatibility) while DosMemChange and the
EA> rest must only accept "valid nonfake" MCBs.

     There exist more bullet-prof check for "non-fake MCB" - just check that
it in current MCB chain.  But don't forget about UMBs (which may be unlinked
from conventional memory chain).

EA> Again, I would like to know how MS DOS reacts to resizing
EA> freed MCBs.

     This is unimportant - FreeDOS anyway shouldn't hang in this case.

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Reply via email to