MASM 4.0 bug list.

From:
Roger Schlafly
Borland International

Date 04/19/1986, Time 11:18:25.

(1) You cannot redirect the output to save the error messages
in a file.

(2) If you run out of disk space while the assembler is
assembling, the machine hangs.

(3) The /ML option does not work with the /Dsymbol option,
unless the /ML option precedes it.

(4) The instruction

    fmul    st(1),st(1)

is invalid, but MASM assembles it without reporting an error,
as if the instruction were:

    fmul    st(1),st(0)

(5) The following file assembles correctly with the command,

    >masm bug /r;

but puts a bad opcode in the OBJ file if assembled with the
command:
    >masm /ML bug /r;

;*************************************************************
; BUG.ASM
; File to demonstrate one of the bugs in MASM 4.0

s   segment
    assume  cs:s
abCd2   dt  11223344556677889900R
    org 20h
x   proc    near

    fld abCd2
    mov ax,7
    ret

x   endp
s   ends
end
;*************************************************************

(6) You cannot include a file that has been edited with Wordstar.
The problem is that Wordstar puts end-of-file characters (hex 1A)
at the end of the file, but MASM chokes saying "extra characters"
if it sees more than one.

(7) MASM sometimes incorrectly gives a "value out of range"
error, as in the following:

;*************************************************************

false   equ 0
true    equ not false

    db  -1      ; This line is OK.
    db  true        ; MASM 4.0 chokes on this line.

;*************************************************************

(8) This is not a bug, but when I read the ad that said, "define
symbols from the command line," I certainly expected that I would
be able to define the symbols to be something. For example,

    /Dxmax=15

on the command line should be equivalent to

    xmax    equ 15

at the beginning of the file. This is what Microsoft C and a
number of other compilers and asemmblers do. Of course, I could
just put into my file a lot of ifdefs, e.g.,

    ifdef   xmax12
    xmax    equ 12
    endif
    ifdef   xmax13
    xmax    equ 13
    endif
    ifdef   xmax14
    xmax    equ 14
    endif
    ifdef   xmax15
    xmax    equ 15
    endif
    ifdef   xmax16
    xmax    equ 16
    endif
    ifdef   xmax17
    xmax    equ 17
    endif

and then just put /Dxmax15 on the command line if I wanted xmax
to be 15. Is this how the feature is intended to be used?

(9) This is perhaps not a bug either, but I find MASM's treatment
of far labels very strange when they are declared EXTRN inside a
segment. In such a case, MASM attempts to force the label to be
relative to a segment other than the segment it was defined to be
in. It seems to me that a far EXTRN label inside a segment should
be the same as outside the segment.

(10) SYMDEB still misses breakpoints a lot. I don't have a simple
example to prove it, but that bug has been in for a long time so
I assume you know about it.

(11) The new linker (3.05) changed the link map format, thereby
breaking most of the symbolic debuggers on the market. Is this a
deliberate attempt to stifle competition?

(12) MASM still requires a carriage return at the end of the last
line in the file, or it ignores the line. There is a similar bug
in DOS's execution of batch files, so I assume it is intentional.

(13) This bug was reported by
            From : JIM BUYENS (ID1358)   Date:04-16-1986 18:22:31

It was presumably introduced in 4.0 when Microsoft ported MASM
from Lattice C to Microsoft C. In Lattice C, characters are
unsigned and range from 0 to 255. In MS C, characters are signed
and range from -128 to +127. IBM characters above 127 are thus a
little awkward.

The following statement won't assemble!
     HDR_MSG2 DB 'º',13,10

Actually, the character in quotes is the double vertical line,
ASCII 186, which I see I can't transmit.  The diagnostic I get is
"error 50: Value is out of range".  The assembler substitutes a
hex FF in the code, instead of a BA as it should.  I got around
the problem by putting 186 in place of the literal.