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:
.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:
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.
Both should be valid, MASM can't work out the size of an OFFSET so needs a WORD PTR override
MOV WORD PTR [BX], OFFSET STR_1
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.
ML 6.14 has no trouble.
Isn't JWASM MASM 6.x compatible?
Quote from: bugthis on April 15, 2025, 08:53:59 AMI 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.
QuoteIf 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?
Quote from: lucho on April 16, 2025, 08:06:18 PMThe 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.
Quote from: bugthis on April 17, 2025, 04:29:07 AMUnfortunately, 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 (https://masm32.com/board/index.php?topic=8732.0)
By the way, the MASM32 (https://masm32.com/download.htm) 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.
Quote from: lucho on April 18, 2025, 01:39:56 AMVisual 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 (https://masm32.com/board/index.php?topic=8732.0)
By the way, the MASM32 (https://masm32.com/download.htm) 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 (https://github.com/microsoft/MS-DOS/tree/main/v4.0/src/TOOLS) 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.
Quote from: bugthis on April 18, 2025, 04:45:03 AMThe MASM 5.10 version included with the MS-DOS 4.0 source code release (https://github.com/microsoft/MS-DOS/tree/main/v4.0/src/TOOLS) 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 (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 (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 (https://web.archive.org/web/20250430054452/http://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 (https://web.archive.org/web/20250502134158/https://ftpmirror.your.org/pub/misc/ftp.microsoft.com/Softlib/MSLFILES/LNK563.EXE)
Quote from: lucho on April 30, 2025, 03:43:22 AMBy the way, there is an even older publicly available version (1.10) here:
I know.
QuoteAnd 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:
DOS/32A fatal (3004): exec format not supported in file "ml.exe"
It probably doesn't like the PE32 format.
$ # 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:
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.
Quotehttps://web.archive.org/web/20010413194514/http://www.microsoft.com/ddk/download/98/BINS_DDK.EXE (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.
QuoteThe 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 (http://ftpmirror.your.org/pub/misc/ftp.microsoft.com/Softlib/MSLFILES/LNK563.EXE)
Thanks.
Sorry, I forgot that DOSXNT.EXE isn't in that archive. Just found it here:
https://github.com/nandahkrishna/MASM/blob/master/DOSXNT.EXE (https://github.com/nandahkrishna/MASM/blob/master/DOSXNT.EXE)
and here:
https://github.com/fititnt/assembly-masm/blob/master/MASM611/BIN/DOSXNT.EXE (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.
Now test is with msdos.exe
http://takeda-toshiya.my.coocan.jp/msdos/index.html (http://takeda-toshiya.my.coocan.jp/msdos/index.html)
msdos.exe -v5.0 debug.exe
Quote from: bugthis on May 02, 2025, 11:11:39 PM6.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 ).
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 :biggrin:
The version with MASM32 is an MZ
Microsoft (R) Segmented Executable Linker Version 5.60.339 Dec 5 1994Looking inside with a hex editor we find a PE as well
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.
LE files was a while for drivers at that time before WinNT.
Sorry, I meant NE (new executable) :sad:
Quote from: sinsi on May 04, 2025, 02:57:27 AMSorry, I meant NE (new executable) :sad:
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.
Quote from: lucho on May 03, 2025, 12:06:54 AMSorry, I forgot that DOSXNT.EXE isn't in that archive. Just found it here:
https://github.com/nandahkrishna/MASM/blob/master/DOSXNT.EXE (https://github.com/nandahkrishna/MASM/blob/master/DOSXNT.EXE)
and here:
https://github.com/fititnt/assembly-masm/blob/master/MASM611/BIN/DOSXNT.EXE (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.
Quote from: bugthis on April 17, 2025, 04:29:07 AMQuote from: lucho on April 16, 2025, 08:06:18 PMI 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:
ROWS EQU 10
COLUMNS EQU 5
...
.CODE
...
MYMACRO MY_LIST, ROWS * COLUMNS
MASM v5.10 requires a workaround like this:
ROWS EQU 10
COLUMNS EQU 5
LENGTH EQU ROWS * COLUMNS
...
.CODE
....
MYMACRO MY_LIST, LENGTH
Quote from: bugthis on May 04, 2025, 03:20:56 AMBy 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.
QuoteMASM v5.10 requires a workaround like this:
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.