Bugs in DOS and DOS Programs and there fixes (if any)

These are bugs/fixes that I know of and that people have told be about. If you know of a bug and/or fix
not displayed here, or you have more info on a bug/fix displayed here, please let me know.

DOS Utilities - Bugs with DOS Utilities
DOS Compilers/Assemblers - Bugs with DOS compilers/assemblers

DOS Utilities - Bugs with DOS Utilities
Version (11:11a) (Win 95) and most likely all before
Founded: Forever Young Software (did you know about it?)
Date: Oct 1998
Fix: No/Unknown
As I was playing with the CALL FAR instruction in DEBUG.EXE, I noticed a few bugs.
Enter DEBUG and then the A command to start assembling.
- Now enter:
  CALLF 100
  CALLFA 100
  <enter key>

- Now Enter U 100 to unassemble what you just entered.
If you notice, for CALLF and CALLFA, DEBUG added the F and FA as literals to the command.

  CALLF [DI] above now = CALL [DI+0F]
  CALLFA [DI] above now = CALL [DI+00FA]
  CALLF 100 above now = CALL 010F
  CALLFA 100 above now = CALL 01FA

The only thing I can think of is that DEBUG is looking at it as:

  CALL 0Fh+[DI]

which are legal instructions. So DEBUG must parse the line until it finds a legal mnemonic, instead of
finding a space.

Do the following in Debug:
-e 100 d9 e2
-u 100

notice that nothing is printed on the 100 line.

D9 currently doesn't encode to a valid instruction, so DEBUG must keep going until it finds a valid instruction
before it starts printing anything.

DOS Compilers/Assemblers - Bugs with DOS compilers/assemblers
Version 4.5 (Quick Basic 4.5)
Founded: Unknown
Date: Unknown
Fix: No/Unknown
The line "PRINT var1, var2" results in var2 getting redefined. This only occurs in a compiled program, when called as a SUB. This does not occur when in the environment (interpreter).

'---------start of main module
DECLARE SUB dispdebug (v1%, v2%)
dispdebug 10, 15

'---------start of subroutine
DEFINT V ' make sure you get this in there
SUB dispdebug (v1%, v2%)
PRINT v1; " "; v2
PRINT v1; v2
PRINT v2, v2
PRINT v1, v2
PRINT v1; v2
PRINT v2; v1
'---------end of subroutine
'---------end of code

Compiled output:
(The question marks (??) denotes the value that is wrongly printed)
(It is different on most occasions (I got zero (0))

15 10
15 10
10 ??
15 ??

15 ??
?? 15

Notice after the print v2, v2 line the v2 var is redefined.
I think that it has to do with the stack. Basic pushes the variables on the stack when passed to the sub, then it uses these stack positions as the variables. QB does not define two new variables and use them.

Try it with a few other variations. You get some different values with different variations.

Version 4.5 (Quick Basic 4.5)
Founded: Unknown
Date: Unknown
Fix: No/Unknown
The Quick Basic compiler will not compile a source file (text or binary (fast save)) if it is named USER.BAS.

The compiler expects input from stdin rather than the file USER.BAS.
Try it and see.

There is a large text file of Compiled Basic Bugs and Quirks for version QB2.x through QB4.5. It is at ftp://ftp.cyberway.com.sg/pub/coast/msdos/qbasic/msquirks.zip and details a bug and/or quirk for just about every command in Basic. Great reading.

Patch to tell BC/Link not to include the communications code if you don't use COM: in your code
- http://support.microsoft.com/download/support/mslfiles/NOCOM450.EXE

The Critical Error patch is at: - http://support.microsoft.com/download/support/mslfiles/QB4CRIT.EXE

Some must have utilities for Quick Basic 4.5 from Microsoft.
Microsoft has three utilities for QB45 that I found interesting.
- HMAKE100.EXE allows you to modify the existing help files to your wants, or create a whole new one to replace the existing one.
- NOCOM450.EXE has an object file to include with your program to cut out 4k of the over head if you use the OPEN command with strings and not communications.
- QB45CRIT.EXE has documentation and source to patch the current QB.LIB and QB.QLB files to fix the critical error hang.
For more on these files and to download them see here

This next one isn't really a bug, it is a "quirk" that Basic does that caught me once.
You know that the BIOS places the COM port addresses at memory location 0x00400. When in
Basic, you open a COM port, Basic changes the corresponding value at location 0x0040x to
a zero (0x000) so that other apps will think there is not COM port at that address.
Basic restores the value when you close it.

MASM upgrades/patches:
If you don't already have MASM 6.11d, then get it from here
- - Execute it in an empty directory. You should get a single .CAB file
- - Now using EXTRACT, extract BIN_WIN98_ML.EXE and BIN_WIN98_ML.ERR.
- - Simply rename to ML.EXE and ML.ERR respectively.
- - (you can get LINK563.EXE from here.)

Now for the patches:
- ML614.EXE --> MASM 614 Patch (Windows only)
- ML613.EXE --> MASM 613 Patch (Windows only)
- ML612.EXE --> MASM 612 Patch (Windows only)
- ML611D.EXE --> MASM 611d Patch (TRUE DOS)
Microsofts information on MASM 6.1x: http://www.microsoft.com/catalog/display.asp?subid=22&site=239&pg=1

Turbo Pascal (Inprise/Borland)
Info at http://www.inprise.com/devsupport/pascal/
- Int 3 patch and info at: http://www.inprise.com/devsupport/pascal/ti_list/TI113.html
- Turbo Vision directories patch and info at: http://www.inprise.com/devsupport/pascal/ti_list/TI1259.html
- Editor patch at: http://www.inprise.com/devsupport/pascal/ti_list/TI1259.html
- Turbo Debug info (version 5) info at: http://www.inprise.com/devsupport/pascal/ti_list/TI456.html
- Crt patch or runtime error 200 patch: (unsupported by Borland/Inprise): http://europe.rainbow.com/tech/tech_notes/tn2030_a.html