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

[bugthis]

I already mentioned this in another thread about a different bug, but it only caused confusion, and I just tested this new old bug in a recent version of JWASM >= v2.19, and unfortunately, it's still there. So I'm starting a new thread here to avoid confusion.

This is the code:

Code (asm) Select Expand

.MODEL SMALL, C
.STACK

.DATA
  STR_1 DB 160 DUP("*")

.CODE
START:
  MOV AX, @DATA
  MOV DS, AX
  MOV [BX], OFFSET STR_1 ; This line is intentionally wrong.
                         ; MASM returns an ERROR because the square brackets are invalid
                         ; current JWASM >= v2.19 doesn't complain and produces code
                         ; with undefined behavior.

;  MOV BX, OFFSET STR_1   ; This is the correct version

  MOV AH, 4Ch
  INT 21h
END START

That's the error message, MASM v5.10 throws:

Code Select Expand

CRASHME.ASM(11): error A2035: Operand must have size
...                             
  1 Severe Errors   

JWASM >= v2.19 compiles the code and the resulting executable produces undefined behavior.
JWASM should throw an error message too to prevent that.

[sinsi]

Both should be valid, MASM can't work out the size of an OFFSET so needs a WORD PTR override

Code Select Expand

MOV WORD PTR [BX], OFFSET STR_1

[bugthis]

I understand, thank you. Is JWASM able to determine the size of the operand in all cases?

EDIT:
If JWASM can do this automatically, at least a warning message would be helpful for compatibility reasons. Then the code will compile even if someone uses MASM.

[sinsi]

ML 6.14 has no trouble.
Isn't JWASM MASM 6.x compatible?

[lucho]

I understand, thank you. Is JWASM able to determine the size of the operand in all cases?

The size of an offset is 16 bits, so "WORD PTR" isn't needed (nor is wrong). Although it's required if the source is an immediate number and the destination is memory, in this case it can be omitted.

If JWASM can do this automatically, at least a warning message would be helpful for compatibility reasons. Then the code will compile even if someone uses MASM.

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

[bugthis]

The size of an offset is 16 bits, so "WORD PTR" isn't needed (nor is wrong). Although it's required if the source is an immediate number and the destination is memory, in this case it can be omitted.
..
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.

[lucho]

Unfortunately, I don't have MASM >= v6.x and haven't been able to test it with it.

Visual Studio includes MASM and can be downloaded and installed free of charge. See this topic in this forum:

https://masm32.com/board/index.php?topic=8732.0

By the way, the MASM32 package includes MASM 6.14. Take into account that MASM versions newer than 6.11d require Windows but work with the HX DOS extender too.

[bugthis]

Visual Studio includes MASM and can be downloaded and installed free of charge. See this topic in this forum:

https://masm32.com/board/index.php?topic=8732.0

By the way, the MASM32 package includes MASM 6.14. Take into account that MASM versions newer than 6.11d require Windows but work with the HX DOS extender too.

Thanks for the information. Strictly speaking, I don't have a more recent 16-bit version of MASM than the one I mentioned. The assembly language book I bought back then came with a 32-bit version of MASM for Windows on CD-ROM, but unfortunately, there wasn't a 16-bit version included. And I'm using Linux as host system and FreeDOS in a VM for programming in assembly, so no Windows.

The MASM 5.10 version included with the MS-DOS 4.0 source code release is the only legal and still publicly available source for a 16-bit binary of MASM that I know of.

That's why I use JWASM. As a nice side effect, I can also put it through its paces. It is also included in the FreeDOS distribution.

I didn't know that the 32-bit Windows version of MASM was supposed to work under DOS with the HX DOS extender. I might try that.

[lucho]

The MASM 5.10 version included with the MS-DOS 4.0 source code release is the only legal and still publicly available source for a 16-bit binary of MASM that I know of.

By the way, there is an even older publicly available version (1.10) here:

https://github.com/microsoft/MS-DOS/blob/main/v2.0/bin/MASM.EXE

And the last DOS version (running through a DOS extender) – 6.11d, is included in the free Windows 98 DDK:

https://web.archive.org/web/20010413194514/http://www.microsoft.com/ddk/download/98/BINS_DDK.EXE

Here is the End User License Agreement for the Windows 98 DDK, part of which is the above MASM 6.11d:

https://cs.emory.edu/~cheung/Courses/255/Syllabus/9-Intel/masm32/licence/ddk_eula.txt

The last Microsoft linker that produces 16-bit DOS executables (version 5.60.339) is here:

http://ftpmirror.your.org/pub/misc/ftp.microsoft.com/Softlib/MSLFILES/LNK563.EXE

[bugthis]

By the way, there is an even older publicly available version (1.10) here:

I know.

And the last DOS version (running through a DOS extender) – 6.11d, is included in the free Windows 98 DDK:

6.11d doesn't run in DOS with a normal DOS Extender like DOS4G/W or DOS/32A. The first one throws a "General Protection fault" message and the second one displays the error message:

Code Select Expand

DOS/32A fatal (3004): exec format not supported in file "ml.exe"
It probably doesn't like the PE32 format.

Code Select Expand

$ # In Linux:
$ file ml.exe
ml.exe: PE32 executable (console) Intel 80386, for MS Windows, 7 sections

Without a DOS extender i get the error message:

Code Select Expand

C:\TEMP\> ml.exe
This program requires DOSXNT.EXE to be in your path
It might work with the HX DOS Extender, as some have said before, but unfortunately it is not included in FreeDOS.
I would have to install it manually, which involves some effort to get it into the VM.

Without a special DOS extender, this MASM version does not work under DOS.

https://web.archive.org/web/20010413194514/http://www.microsoft.com/ddk/download/98/BINS_DDK.EXE

Thanks. I used cabextract in Linux to extract it. I then had to rename the extracted file.

The last Microsoft linker that produces 16-bit DOS executables (version 5.60.339) is here:

http://ftpmirror.your.org/pub/misc/ftp.microsoft.com/Softlib/MSLFILES/LNK563.EXE

Thanks.

[lucho]

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.

[TimoVJL]

Now test is with msdos.exe
http://takeda-toshiya.my.coocan.jp/msdos/index.html

Code Select Expand

msdos.exe -v5.0 debug.exe

[_japheth]

6.11d doesn't run in DOS with a normal DOS Extender like DOS4G/W or DOS/32A. The first one throws a "General Protection fault" message and the second one displays the error message:

What's a normal DOS Extender? ML v6.11d uses the PharLap DOS extender, and that's probably the oldest one at all ( the "386" variant, at least - the TNT variant came later, after the invention of the PE format ).

[sinsi]

The linker used to be an MZ EXE with an OS/2 LE file inside which would run if you were using Windows 95.
For some reason when the OS/2 subsystem started up it would spin up the floppy drive which, at 2am, would usually make me spill my beer

The version with MASM32 is an MZ

Code Select Expand

Microsoft (R) Segmented Executable Linker  Version 5.60.339 Dec  5 1994Looking inside with a hex editor we find a PE as well

Code Select Expand

Copyright (C) 1986-1991 Phar Lap Software, Incwith a few GOTNTDXs sprinkled around.

I think version 5.635.12 was the last pre-PE version.

[TimoVJL]

LE files was a while for drivers at that time before WinNT.