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
Freedos-devel mailing list

Reply via email to