Hi!
17-Авг-2006 21:20 [EMAIL PROTECTED] (Michael Devore) wrote to
freedos-devel@lists.sourceforge.net:
MD> 1. QuickBASIC (I assume) frees a block of memory via INT 21h function 49h
MD> 2. QuickBASIC resizes a second block of memory via function 4ah with value
MD> 3. QuickBASIC resizes the second block of memory via function 4ah with the
MD> 4. QuickBASIC tries to re-free the first block of memory via function
MD> 49h. Tsk, tsk. Naughty, but not too naughty under normal
MD> conditions. Here MS-DOS and FreeDOS differ: while both will allow
MD> re-freeing the same block without error under some circumstances (which I
MD> don't know what they are since I'm not a kernel guy),
See memmgr.c:DosMemFree() (which called from inthndlr.c:case 0x49):
DosMemFree() returns error DE_INVLDMCB (9) when passed segment address not
points to valid MCB, else it marks it as free.
MD> the intervening
MD> resizes of the second block apparently flush out FreeDOS's memory of the
MD> first block,
? memmgr.c:DosMemChange() doesn't joins previous block with current,
only following free blocks. May you specify, what you mean? Or you wish to
say, that "first block" comes after "second block"?
MD> so it returns an error code.
If you mean, that "first block" B comes after "second block" A and that
resizing A makes second free for B report error - true. This is because
joinMCBs() (called from DosMemChange()) invalidates header of joined block.
MD> MS-DOS still remembers that the
MD> block was recently valid and does not return an error code on the second
MD> free.
This mean, MS-DOS doesn't invalidates joined block header. Interesting,
what happen, if there will be performed resize (0x4A) on already joined
block (which have header, but not exist)?
[...]
MD> those keeping count, is QB mistake #3. As a consequence, you have
MD> no-feedback lockup of the application using FreeDOS, but not using MS-DOS.
MD> Unfortunately, if we want to be compatible with some (all?) of QB 4.0
MD> applications which use BRUN40, FreeDOS has to act like MS-DOS and allow the
MD> re-freeing of a memory block to occur without an error,
Issue is, that there are no more valid memory block!
MD> even though
MD> intervening INT 21h actions have occurred. I'd guess the problem isn't in
MD> QB 4.5 or we have heard earlier, but frankly I do not know if it does or
MD> does not.
MD> I don't know if it's feasible to change FreeDOS kernel at this point to
MD> make it work, but this is a compatibility issue that ought to be addressed
MD> in some fashion. Even if it's a "QB4 is too stupid to live" announcement.
1. I think, this change may be delayed (for post-1.0).
2. I think, change not very hard and contains two steps:
2.1. joinMCBs() should now not invalidate header of joined block (remove
"q->m_type = 'K';" and insert comment, which says, that header of
joined block not invalidated for compatibility with MS-DOS and QB4).
2.2. DosMemChange() (and, probably, some other functions - but not
DosMemFree()) should use instead mcbValid() macro some function, which
will check _also_, that segment points to block header inside current
chain - this should protect against trying to resize "block", which is
not in chain (ie., it part of other blocks).
-------------------------------------------------------------------------
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
