WDOSX v0.94 (alpha3)

• DOS find first/find next are not correctly extended - this bug is fixed in the non-beta (sorry about any confusion)

PMODE/W v1.33

• INT 31h/0a00h always returns successful (carry clear)
• DOS func 4b00h fails under Windoze if used more than once (I don't know how long PMODE/W has had this bug)
• DOS func 4b00h seems to add extra junk at the end of the enviroment block of the new program to be executed (when using any spawn..e() funcs) NOTE : QLIB v2.01- had a bug and it's spawn...e() funcs did not work, but v2.02 fixed QLIBs bugs, but PMODE/W's bug still remains.
• Hopefully v1.34 will be out soon to fix these.

PMODE/W v1.31

• Does not show correct exception #s (but that does not effect the extender in any way) Fixed in v1.33.
• Still can not set int 3 (although this is not a bug but just what DPMI specs say should be done - that bytes!)

PMODE/W v1.3

• The enviroment selector provided is invalid under Win95. (well I've talked to the creators for some time and they assure me it is not, so maybe there is something wrong with my code or my Win95 has bugs. (FIXED - twas a Win95 bug)
• It turns out that the above bug is not from PMODE/W but from Windoze. MS simple does not follow DPMI specs correctly and they were extending DOS func #51h when it should not be. PMODE/W v1.31 compensates for this bug.
• setting int 3 causes an exc 13. This will not effect you unless you try and creat your own debugger and WD is good enough. (once again they say this should not happen and does not for them - dito)
• Does not show correct exception #s (but that does not effect the extender in any way)

DOS32 v3.3

• I must point out the bugs in the DMA-init system of dos32v3.3 and the hazard of 'abnormal termination' (read: hang) of the extender when the drives are accessed during DMA-processing. (thanx to R.P. Van Z. who pointed this out to me) FIXED in v3.5
  
• Other than that this extender is bug free as far as I am concered. Although the program base it not zero. (UPDATED - v3.5 has a base of zero always)

DOS32 v3.5 (BETA rev 6)

• Under Win95 sometimes very little RAM is available (like 39k). Other users say they have not incountered this. Maybe it's just me.
• Has fixed the DMA bug from v3.3.
• The program base is now always zero. (finally!)
• The debugger will not let you set brkpts. Says you can't set more than 80 but I haven't set any yet, wierd bug? I looked at the code and it looks ok but something is oviously wrong.
• DOS32 v3.5 will be a crippled DOS extender. Only 4MB will every be avail until you register it (Not a BUG but I thought you should know).
• This extender is still in beta so I suggest not getting it until it's fully released. So they will fix these bugs soon.

DOS/4GW v1.97

• ah=62h int 21h fails under Windoze (sometimes)
• setting int 3 is permitted but calling int 3 does not go to where it is suppose to and simple does nothing. So I was unable to make my own debugger. I was trying to use the debugger from DOS32 and make it DOS/4GW compatiable which was easy but without the use of int 3 it's useless. (I've now almost got it working under PMODE/W - in theory it should be working now, but it doesn't and anyways, who cares, WD is great!) FIX : QDEBUG now works with WDOSX, and is the best 32bit debugger that even works under Win95.
• Now that PMODE/W v1.31 is released I see no reason to use this extender anymore.

WLINK v11.0

• If no 'option stub' is provided then WLINK provides a small DOS EXE thats header's 'last page size' is incorrect making the LE/PE/LX-EXE image lost.

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

• v4.5 would not allow you to put labels inside ASM {} blocks
• v5.0 allows labels inside ASM {} blocks

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

• Initilized class pointer are not properly done. ie: Try the following code:

  class myclass {
    int a,b,c;
  };
  myclass *p=NULL;  //this will not be init to NULL.
                    //Watcom C++ will place 'p' into the _BSS segment!
  

• To force the compiler to add underscores to externs/publics use the following:
  

  //enable Watcom underscore appending
  //Also force Watcom to return double in st(0)
  #ifdef __WATCOMC__
    #pragma aux default "_*" parm caller [] \
    value struct routine [eax 8087] \
    modify [eax];
  //Change asm to _asm for Watcom v11.0
    #define asm _asm
  #endif
  

  Which now has been incorperated into QLIB v2.00. This also allows Watcom code to return floats in st(0) which is a standard in other compilers.
  
• I've discovered a bug (see code below for details) it has to do with using the #pragma aux thing within functions and attempting to use the parameters given to the function.

Differences between Borland C and Watcom C:

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

demo proc,a:dword
  mov eax,a
  ret
demo endp
...
invoke demo,bx

  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

TASM v3.1

• This compiler is not suited for 32bit compiling due to many bugs.
• Get something newer.

TASM v3.2+

• I beleive this is good enough. Although it will not compile MASM source.

TASM v5.0

• Can compile MASM v5.0 source (I think) but still can not compile v6.11 source.

WASM v10.x

• I've tried using this but it can not compile MASM source.

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.

WinNT v4.0

• WinNT trashes the invisible portion of ES during exception handlers. It has not been determined where or when this occurs. Remedy : Reload ES before each use, and a push es/pop es will not work since you need to reload the invisible portion.

Win95 v4.0

• Win95 trashes the AX register during the mouse callback thingy. (INT 33h/ax=0ch) You must ignore AX and instead use BX to get the status of the mouse buttons.
  

Copyright © 1995-2005 Nexus Systems Privacy