[BX], OFFSET BUG - JWASM should throw error too, as MASM v5.10 does

[sinsi]

Sorry, I meant NE (new executable)

[TimoVJL]

Sorry, I meant NE (new executable)

Why worry, as i listen Dire Straits band.
That LE was in drivers in Win 9x before WinNT.

EDIT: Phillips promoted CD with Dire Straits and first time 100 dB noise immunity was in CD.
Also Phillips digital amblifiers was used in shows to show to good coming digital can be.
Yes, i am really that old to know that.

[bugthis]

Sorry, I forgot that DOSXNT.EXE isn't in that archive. Just found it here:

https://github.com/nandahkrishna/MASM/blob/master/DOSXNT.EXE

and here:

https://github.com/fititnt/assembly-masm/blob/master/MASM611/BIN/DOSXNT.EXE

It's written by Phar Lap Software and I suppose that the file was intended to be redistributable.

Thanks. MASM v6.11d is now ready to use in my FreeDOS VM.

I don't think a warning is justified in this case. Why emulate quirks of very old MASM versions?

I understand. Therefore, I agree, assuming MASM >= v6.x also works without "WORD PTR" like JWASM. Unfortunately, I don't have MASM >= v6.x and haven't been able to test it with it.

I have now tested this with MASM v6.11d and v6.11d compiles the code even without "WORD PTR".

I still have a question about MASM. The binaries generated by MASM are significantly larger than those generated by JWASM. This was also the case with version 5.10.
With JWASM, for example, the generated binary is 560 bytes in size, whereas the binary generated by MASM is 1024 bytes in size.
However, debug information isn't included. Using a hex editor, I noticed that MASM fills a large portion of the file at the beginning starting from address 27h (or 2Fh) up to address 1FFh with zeros, which isn't the case with JWASM.

Regarding JWASM, I'll continue to use it as my default assembler. I'm only using MASM v6.11d, like 5.10 before it, to test any differences. This gives me the opportunity to test JWASM extensively.

By the way, did you know that MASM v.5.10 cannot resolve multiplication when passing parameters to macros?
This doesn't work in MASM v5.10, but it works in MASM v6.11d and JWASM:

Code Select Expand

  ROWS EQU 10
  COLUMNS EQU 5
  ...
.CODE
 ...
  MYMACRO MY_LIST, ROWS * COLUMNS

MASM v5.10 requires a workaround like this:

Code Select Expand

  ROWS EQU 10
  COLUMNS EQU 5
  LENGTH EQU ROWS * COLUMNS
  ...
.CODE
  ....
  MYMACRO MY_LIST, LENGTH


[_japheth]

By the way, did you know that MASM v.5.10 cannot resolve multiplication when passing parameters to macros?

The Masm preprocessor handles text only, it doesn't evaluate expressions.

MASM v5.10 requires a workaround like this:

Code Select Expand

  ROWS EQU 10
  COLUMNS EQU 5
  LENGTH EQU ROWS * COLUMNS
  ...
.CODE
  ....
  MYMACRO MY_LIST, LENGTH


It's because Masm v5.x handles macro arguments differently - a "white space" will separate macro arguments there, while with Masm v6+, a comma is needed. With Masm v5.1, you'll have to enclose the macro argument in angle brackets (<>) it it contains spaces. OTOH, you can get Masm v6+ to behave like Masm v5 with the "option oldmacros" directive.