Here is a list of several bugs I know of.
Programming the PC has become an art of bug awareness.

DOS Extenders (Updated : Feb 1/97)
C compiler bugs (BC and WC) (Updated:Dec 29/96)
Linker bugs
ASM compiler bugs (TASM and MASM) (Updated : Jan 10/97)
Operating System bugs
80x86 Flaws (86-586)

Last update:Apr 19/98
Dos Extenders
Here is a list of several DOS extenders showing bugs and important features (or lack of them) I've personally found in them.

WDOSX v0.94 (alpha3)

PMODE/W v1.33

PMODE/W v1.31

PMODE/W v1.3

DOS32 v3.3

DOS32 v3.5 (BETA rev 6)

DOS/4GW v1.97

I do not mean to blame the programers of these bugs, I'm just releasing this info to help the user. I hope that all programmers keep releasing these wonderful products.

Bottom line:
If you are using Watcom now use PMODE/W.
If you are using DOS32 then use v3.3 until v3.5 is perfect.

Both DOS32 and PMODE/W are wonderful products, please support the authors and register your copy.
Please report other bugs to the developers of these programs. Although I'd like to know too.


WLINK v11.0

C/C++ Compilers

Borland C 32bit (Win32) compiler (bcc32.exe) v4.5 and v5.0

Watcom C/++ 32bit v10.6 - v11.0

Example of Watcom Bug (this requires QLIB v2.00)
The above code will compile under Watcom C without any warning or errors but the code generated is faulty. If you debug the program and step thru the code you will see that in iasm_1() it tries to access 'm' but does not do it properly. It may have to do with some Watcom optimzation or something, but I've been unable to find out what. This bug is hard to reproduce.

Differences between Borland C and Watcom C:

The only difference between them is that Borland expects float values returned from functions to be on top of the FPU stack. Watcom expects them to be returned in EAX or EAX:EDX.
When using Borland it uses _ftol() function to convert floats to longs. In v5.0 it also uses _TurboFloat which should be a global equate which is set to 8087 in the Borland LIBs (but I use 80387 in QLIB)
Watcom uses __chp() which chops a float. (this is also part of QLIB).
After some time I now prefer the Borland compiler over Watcom because returning values on the FPU stack is easier and faster and Watcom has bug(s)!

ASM Compilers

MASM v6.11(a/c/d),v6.12,v6.13 and 7.00

MASM bugs involve the INVOKE command in 32bit segments only. INVOKE calls a proc in C style. Here is an example of the problems

demo proc,a:dword
  mov eax,a
demo endp
invoke demo,bx
Invoke will widen all arguments to dwords as defined by C calling convention. When the above is compiled, MASM will expand bx to a dword by pushing a 16bit 0(zero) and then BX. But they forget to put a db 66h somewhere so they actually push a 32bit 0(zero) instead and this messes everything up on the stack.
MASM also assumes that segment registers when pushed are 16bit and they are not in 32bit mode. When pushing seg regs in PMODE the CPU pushes a dword not a word, for alignment purposes. Masm just does not do it properly in some cases.
  case 1-if a dword is expected but a word is given then it messes up.
         NOTE: varargs are all considered dwords
  case 2-segment registers are assumed 16bit when pushed (so masm will push
         a 16bit 0(zero) before pushing the segment register) which is wrong.

MASM v6.12 and v6.13

opattr no longer seems to provide the same information as in earlier versions.

TASM v3.1

TASM v3.2+

TASM v5.0

WASM v10.x

Bugs in Intel 80x86 Processors

PreFetch bug : 8086-80486
If any instruction modifies code to be executed that is held by the prefetch then the CPU will execute what was held in the prefetch BEFORE it was modified. It avoid this use a jmp after modifing code. The size of the prefetch ranges from 4 to 32 bytes. The Pentium final resolved this bug, but you should never the less use the jmp so 386/486 users can use your code.

POPAD bug : 80386
After 'popad' any instruction that uses EAX for indirect memory accessing may not work correctly (causing mayham). I forget most of the details of this. Should never be a problem since most programs use RET after popad.

FDIV bug : Pentium
Early processors would give incorrect results when using FDIV. This problem was fixed by Intel as they replaced any defective CPUs for free. (MS could learn from them)

FooF bug : Pentium
The Bug is related to mixing the LOCK prefix with the CMPXCHG8B instruction and using a register as an operand. The CMPXCHG8B opcode is only meant to be used with a 64bit memory reference but the encoding allows use for registers. Simply force it to use a register which would normally cause an Exception #6 (invalid opcode). But because the LOCK prefix is used the CPU stalls until you press Reset. Intel has released two methods for overcoming the bug but they require massive overhauls of your OS. Other approaches have been created by DDJ and work much better. See DDJ May/98 issue for more details. The BUG seems to be related to a cache problem, since disabling your cache prevents the BUG. DDJ has found if you mark the EXC#6 descriptor write-thru that it prevents the BUG (or something like that).
The Opcode is : 0f0h,00fh,0c7h,0c8h hense the "foof" name. The 0c8h can be replaced with and value from 0c8h thru 0cfh for other registers but the outcome is the same.

Operating Systems

WinNT v4.0

Win95 v4.0

Copyright © 1995-2005 Nexus Systems Privacy
SourceForge.net Logo