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