The following information is provided for developers interested in
using Microsoft MASM 6.x for Windows NT during their driver

Note that the few DDK driver sources written in assembler were
tested/verified with the assembler (based on MASM 5.1) included in the
Windows NT Win32 SDK/DDK rather than Microsoft MASM 6.x.  The changes
mentioned below are provided as examples, there may be other possible
methods and workarounds.


Add the following to the beginning of lines.asm, alignblt.asm,
cblt.asm, colorpat.asm, dib2vga.asm, fasttext.asm, glyphblt.asm,
nalgnblt.asm, patblt.asm, pointer.asm, strblt.asm, vgablts.asm,
and vgalines.asm:

   IF @version GE 600
      option noscoped

There may be a bug in MASM 6.1 (not yet fixed) which shows up on Line
261 of bitblt.inc:

   a_brush     db  (NUMBER_PLANES * SIZE_PATTERN) dup (?)

The work around is to take out the parens

   a_brush     db  NUMBER_PLANES * SIZE_PATTERN  dup (?)

In blt.asm after the "xxxvCompiledBlt proc" there are many parameters
after the uses statement with line continuation characters, this line
is too long for masm611 to handle, thus the line too long error.  The
error on the "local fr[SIZE FRAME]:byte" line and the "Unmatched block
nesting" error on "xxxvCompiledBlt Endp" which are all related to the
line that's too long.

The errn$ macro in cmacflat.inc works only with masm386, it doesn't
work for masm510, masm61a or masm611.  This will cause undefined
symbols on "phase_proc_50, phase_proc_60 and bitblt_exit" when used with
those assemblers.

Dib2vga.asm has "align 16" in 4 spots in the code segment, these are
invalid under masm6 because it is specifying an alignment thats
greater than the segment alignment specified earlier.  This is not
possible in MASM 6.1.  It should be possible to use an "IF @version GE
600" workaround of some sort.

Around line 212 of Glyphblt.asm, the following code:

   call    offset FLAT:vgblt_table.[eax*4]

should be changed to:

   call    vgblt_table.[eax*4]

Masm510 and masm6 generate an error on the first call, which is a
correct error.  The same EXACT code that masm386 generates for the
first call example is generated by masm6 on the second call example,
but masm386 generates an error on the second call example.  Use an "IF
@version GE 600" workaround with these two call instructions.

   IF @version GE 600
      call    vgblt_table.[eax*4]              ; Correct syntax for masm6
      call    offset FLAT:vgblt_table.[eax*4]  ; Masm386 is ok here

Similar code exists in strblt.asm. the following code:

   mov  bl, offset FLAT:xgi_buffer_offset[eax]

should be:

   mov  bl, byte ptr xgi_buffer_offset[eax]

Simply replace the "offset FLAT: " with "type ptr" for the "mov"
instructions or take out " offset FLAT: " for the jmps and calls.

In patblt.asm there's a proc named vMonoPatBlt and it declares a bunch
of locals ( pfnWesTrick, ulVbMask, etc ).  Masm6 generates "undefined
symbol" errors when trying to use these locals outside of the
procedure that declared them.  These local variables are only visible
to the defining procedure.  This is by design for masm6, the code
would need to be changed to correctly work with MASM 6.

In pointer.asm, if "IF @version GE 600 " is added as described above,
a symbol redefinition error on the label "flip_next_scan" may occur
because it's used in two different procs, the vFlipMask proc and
vConvertDIBPointer proc.  This can be fixed by changing one of the

Five forced errors will be produced by errnz when assembling
pointer.asm with masm6.

In rleblts.asm line 755, "BT cl, 0".  There is no opcode for doing a
bit test on a byte register and Masm386 should err on this but
doesn't.  Masm386 translates this instruction either to use CX or ECX,
Masm6 correctly generates an error here.


Add the following to the beginning of colorpat.asm, fastline.asm,
fasttext.asm, lines.asm, monpat.asm, scroll.asm, srccopy.asm,
stretch8.asm and vgablts.asm:

   IF @version GE 600
      option noscoped

Colorpat.asm has " EXTRNP vPlanarDouble, 20" towards the beginning of
the file and declares the vPlanarDouble proc as a near external
_within_ the .DATA segment, Move the " EXTRNP vPlanarDouble, 20" just
before the .DATA segment and everything will assemble ok.

An error may occur noting that it's incorrect to have a call to a near
label in another segment.  This proc was external in the .data segment
and called from the .code segment which caused problems.

The same is true for fastline.asm, move the "EXTRNP PATHOBJ_bEnum, 8"
outside of the .data segment.  In monopat.asm, move the "EXTRNP
vTryBlt, 24 " outside of the .data segment.  In scroll.asm move
"EXTRNP bPuntToScreen...." outside of the .data segment.


Add the following to the beginning of fastline.asm:

   IF @version GE 600
      option noscoped

In fastline.asm, move the 2 externp statements ( PATHOBJ_bEnum,
bLines) outside of the .data segment.


There are various .asm files under the video\miniport subdir
(clhard.asm, et4hard.asm, etc.) which include callconv.inc which has a
macro called "stdCall", stdcall is a reserved word so it's necessary to
place the following:

   IF @version GE 600
      option nokeyword:<stdcall>

at the beginning of callconv.inc so there are no syntax errors when
calling the stdcall macro.  Either that or change the name of the
Stdcall macro.  This will mark stdcall as a non-keyword.