While testing out a users bug report, I found a terribly obscure difference between the way MS-DOS kernel works and FreeDOS kernel works. It shouldn't matter, but it does to QuickBASIC 4.x applications, at least for some using BRUN40. I don't know the scope of how many QB applications are affected.
Here's the situation, running under QB 4.0. The code is found in BRUN40.EXE and duplicated in the application's executable files: 1. QuickBASIC (I assume) frees a block of memory via INT 21h function 49h that it previously allocated. Success in FreeDOS and MS-DOS. 2. QuickBASIC resizes a second block of memory via function 4ah with value 0FFFFh to determine all free memory available to the block. The function fails, as designed, but returns the maximum possible block size. Success in both. 3. QuickBASIC resizes the second block of memory via function 4ah with the amount returned in last 4ah call, as expected. Success, again. 4. QuickBASIC tries to re-free the first block of memory via function 49h. Tsk, tsk. Naughty, but not too naughty under normal conditions. Here MS-DOS and FreeDOS differ: while both will allow re-freeing the same block without error under some circumstances (which I don't know what they are since I'm not a kernel guy), the intervening resizes of the second block apparently flush out FreeDOS's memory of the first block, so it returns an error code. MS-DOS still remembers that the block was recently valid and does not return an error code on the second free. 5. Okay, first mistake is QuickBASIC's. But it's still in decent shape. QB knows to check for an error code and will continue working properly. Uh-oh, QB digs itself deeper. It only checks for error codes 7 and 8 (8 due to shared INT 21h code). Freeing an invalid block is error code 9. 6. Boom! That was QB mistake #2 and it's serious. Now QB is unhappy. An unexpected error code gets transferred way off into another part of the code for further handling. What does QB try to do there? I have no idea and I don't care. It never comes back and it never recovers. And that, for those keeping count, is QB mistake #3. As a consequence, you have no-feedback lockup of the application using FreeDOS, but not using MS-DOS. Unfortunately, if we want to be compatible with some (all?) of QB 4.0 applications which use BRUN40, FreeDOS has to act like MS-DOS and allow the re-freeing of a memory block to occur without an error, even though intervening INT 21h actions have occurred. I'd guess the problem isn't in QB 4.5 or we have heard earlier, but frankly I do not know if it does or does not. I don't know if it's feasible to change FreeDOS kernel at this point to make it work, but this is a compatibility issue that ought to be addressed in some fashion. Even if it's a "QB4 is too stupid to live" announcement. PS#1: I directly patched the QB application executable to make it work by allowing more than the original error codes, but obviously that's not a general solution. PS#2: If this was modified to work recently, I'm a bad boy for not having the absolute latest kernel revisions. ------------------------------------------------------------------------- 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
