winextra.inc Visual Studio 2019's ML build errors

[turtoise]

First of all, hello everyone, since this is my first post in the forum. :)

I'm having a bit of a problem trying to assemble a simple hello-world-ish program in Visual Studio 2019. I know many of you said VS for asm is more trouble than it's worth, but unfortunatelly I'm required to use it, so please bear with me.

So, assembling this simple thingy:

Code Select Expand


.686
.model flat, stdcall

option casemap:none

include C:\masm32\include\windows.inc

.data
.code

main proc
xor eax, eax
ret
main endp
end main


ends with three errors, first two ones being:

A2026 - constant expected

pointing to lines 11052 and 11053 in winextra.inc.

I decided to take a look at those lines and found this:

Code Select Expand


STD_ALERT struct
    alrt_timestamp dd ?
    alrt_eventname WCHAR  [EVLEN + 1] dup(?) ; error
    alrt_servicename WCHAR [SNLEN + 1] dup(?) ; error
STD_ALERT ends


Now, I found those array/string definitions a bit strange. As far as I know (and I know very little about asm, so correct me if I'm wrong!), they should go like:

Code Select Expand

alrt_eventname WCHAR  EVLEN + 1 dup(?) i. e. without the brackets. What's more, removing the brackets really does make it assemble. However, given my entry-level knowledge, I don't know what to think about it. Clearly, it cannot be an error in the SDK.

So there are multiple questions here, really:

• Do I get something wrong? Is the code in winextra.inc doing something I simply do not understand and changing it breaks it?
• When trying to assemble it with masm32's own ml, all seems to work just fine (and to be honest, doing it that way makes way more sense to me, but that's the way I was told it's "supposed to work" in the exercise). Could using the newer toolset be the source of the problem?

Any help is appreciated, thanks for reading up to this point :P

[Vortex]

No any problem in my test :

Code Select Expand

C:\ml-14-22-27905-0>ml.exe
Microsoft (R) Macro Assembler Version 14.22.27905.0
Copyright (C) Microsoft Corporation.  All rights reserved.

usage: ML [ options ] filelist [ /link linkoptions]
Run "ML /help" or "ML /?" for more info

C:\ml-14-22-27905-0>ml /c /coff Sample.asm
Microsoft (R) Macro Assembler Version 14.22.27905.0
Copyright (C) Microsoft Corporation.  All rights reserved.

Assembling: Sample.asm

***********
ASCII build
***********

C:\ml-14-22-27905-0>dir Sample.obj

15.10.2020  11:51               524 Sample.obj
               1 File(s)            524 bytes


[jj2007]

Hi turtoise,

Welcome to the forum

As Vortex notes, your code assembles fine. We have many thousands of sources that do assemble fine with Windows.inc, so the problem is clearly on the side of VS 2019.

I have tested the code with ml.exe versions 14 and 15, the latest that I have on my disk: no problem. Which is your version? Usually they hang around in C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\ml.exe or similar. And some of the later ML versions have serious bugs, see here for an example.

In case you can point VS to another assembler, that would be worth a test. The old MASM 6.14 normally sits in C:\Masm32\bin\ml.exe and works fine for not too recent SSE etc stuff. UAsm and AsmC are excellent alternatives, too.

Attention: ML comes in 32- and 64-bit flavours; are you sure VS picks the 32-bit version?

HTH, Jochen

P.S. below an extended test case. The output looks totally correct, there is no problem with that structure...

Code Select Expand

if 1
include \masm32\include\masm32rt.inc ; get access to print, str$() etc
else
.686
.model flat, stdcall
option casemap:none
include \masm32\include\windows.inc
endif

.data
if 0
STD_ALERT struct
  alrt_timestamp dd ?
  alrt_eventname WCHAR  [EVLEN + 1] dup(?) ; error
  alrt_servicename WCHAR [SNLEN + 1] dup(?) ; error
STD_ALERT ends
endif

std_alert STD_ALERT <>
after dd ?

.code

main proc
cls
mov eax, offset after
sub eax, offset std_alert
print str$(eax), " bytes for the struc", 13, 10
print str$(EVLEN), " bytes for EVLEN", 13, 10
print str$(SNLEN), " bytes for SNLEN", 13, 10
ret
main endp
end main

[TouEnMasm]

The definition of the structrure is correct:

STD_ALERT   STRUCT DEFALIGNMASM
   alrt_timestamp DWORD ?
   alrt_eventname WORD EVLEN+1 dup (?)
   alrt_servicename WORD SNLEN+1 dup (?)
STD_ALERT      ENDS

lmcons.sdk and     lmalert.sdk
miss in windows.inc EVLEN et SNLEN,surely in another include.

SNLEN   equ   < 80>
EVLEN   equ   < 16>

[turtoise]

Whoa, so many responses :)

Okay, here goes.

No any problem in my test :

Fair enough, however I noticed you're using ml version 14.22.27905. The one shipped with my VS is 14.27.29112. I guess that might count for something, can't be sure though.

I have tested the code with ml.exe versions 14 and 15, the latest that I have on my disk: no problem. Which is your version?

It's 14.27.29112.

In case you can point VS to another assembler, that would be worth a test. The old MASM 6.14 normally sits in C:\Masm32\bin\ml.exe and works fine for not too recent SSE etc stuff.

I've actually done this. I tried using masm32's ml and it assembles fine. That's why this whole business bugs me even more.

Attention: ML comes in 32- and 64-bit flavours; are you sure VS picks the 32-bit version?

Yes, I even double-checked that. It's the x86 version for x64 host, so no problem here.

Btw. in the OP I mentioned that definitions such as this:

Code Select Expand

alrt_eventname WCHAR  [EVLEN + 1] dup(?)

are confusing to me, because of the square brackets. If I may ask while we're at it - are the brackets optional here? Is the code semantially the same with and without them? Thanks!

The definition of the structrure is correct:

That's great, because that's how I'd have written it. What I was really confused about was the one with [square brackets], though, because it's the one shipped with masm32.

[hutch--]

What has happened is that the 32 bit version has changed slightly over time. The very old version of ML in the MASM32 SDK works fine on the old stuff but is only a place holder for the much later versions like the current VS if you are writing SSE and later AVX code.

On a needs basis, if you run into minor notation differences like the redundant square brackets, you don't have much choice other than to change it so it works OK. Square brackets have their place in MASM around registers to denote an address stored in the register but other assemblers long ago used them differently and apparently this is why ML allows redundant bracketing.

[Vortex]

Hi turtoise,

Fair enough, however I noticed you're using ml version 14.22.27905. The one shipped with my VS is 14.27.29112. I guess that might count for something, can't be sure though.

You are right, thanks. I downloaded the latest MS VS 2019 Build tools. Here is the result of the new test :

Code Select Expand

C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\VC\Tools\MSVC\14.27.29110\bin\Hostx86\x86>ml.exe /c /coff Sample.asm
Microsoft (R) Macro Assembler Version 14.27.29112.0
Copyright (C) Microsoft Corporation.  All rights reserved.

Assembling: Sample.asm

***********
ASCII build
***********

C:\masm32\include\winextra.inc(11052) : error A2026:constant expected
C:\masm32\include\winextra.inc(11053) : error A2026:constant expected


[jj2007]

We need a new list of known bugs, it seems

MASM 14.0 .if signed comparison bug (nasty!)
14.00.23026.0 produces garbage
mov eax, [ecx+edx+esi+10]      ; three register addressing in MASM!
https://www.japheth.de/JWasm/Manual.html#CHAPMASMBUGS
http://masm32.com/board/index.php?topic=2251.msg27108#msg27108

Yesterday I found a nasty bug in MASM 6.15 (code assembles fine but a few addresses are wrong; ML 8+ is ok), but I haven't been able to isolate it

UAsm and AsmC also have occasional bugs, but the authors are very active here in the forum, so normally the bug gets fixed in a couple of days.

[hutch--]

 

I am pleased to see that you have discovered even more MASM features. Once you learn the features, you have no problems with them. Now as you would be familiar with MASM's characteristic of biting the hand that feeds it, on the bright side you learn to make far fewer coding mistakes rather than trying to comprehend screens full of garbage and you produce higher quality code for having mastered the many virtues of MASM. 

[TouEnMasm]

MASM don't need virtues (Strange vocabulary).
MASM need include files who can work with another system than 32 bits XP
http://masm32.com/board/index.php?topic=8740.msg95471#msg95471

[hutch--]

 

> MASM need include files who can work with another system than 32 bits XP

Ah, you mean like XP, Vista, Win7, Win8 Win10 32 + 64 bit. You seem to forget that Windows has changed various things over time.

[TouEnMasm]

You seem to forget that Windows has changed various things over time.

Follow this link http://masm32.com/board/index.php?topic=8740.msg95471#msg95471
It isn't the only one common structure who have problems and that date from XP
Perhaps a .h can be more explicit

typedef struct tagTOOLINFOA {
    UINT cbSize;
    UINT uFlags;
    HWND hwnd;
    UINT_PTR uId;
    RECT rect;
    HINSTANCE hinst;
    LPSTR lpszText;
    LPARAM lParam;
#if (NTDDI_VERSION >= NTDDI_WINXP)                                                              <<<<<<<<<<<<<<< AFTER WIN XP
    void *lpReserved;
#endif
} TTTOOLINFOA, NEAR *PTOOLINFOA, *LPTTTOOLINFOA;

[turtoise]

Okay, so it seems it's solved. Thanks for all the help :) . It's good to know it's not due to a silly mistake of mine, haha.

[hutch--]

As long as you are happy with the result. 

[zjoel]

Hi, I just want to say that I also attempted to use MASM that is installed with Visual Studio 2019, and ran into the same issue as turtoise
C:\masm32\include\winextra.inc(11052) : error A2026:constant expected
C:\masm32\include\winextra.inc(11053) : error A2026:constant expected

VS version of MASM is
Microsoft (R) Macro Assembler Version 14.29.30040.0

Turtoise was very polite about the brackets.  I think they are wrong!
The syntax guide for MASM https://docs.microsoft.com/en-us/cpp/assembler/masm/operator-brackets?view=msvc-160
Says that brackets are indexing operator, and that
expr1 [ expr2 ]      produces expr1 + expr2

Also I would like to point out that when TouEnMasm said "the definition of the structure is correct", that is with square brackets removed.  So Turtoise, TouEnMasm, and now me too, are all removing the square brackets from lines 11052, 11053 in winextra.inc.

Maybe earlier versions of masm32 which compiled it just fine were just not strict?  or were getting ok result because "expr1" was assumed to be 0
VAR [a + 1]    was being interpreted as VAR (0) + (a+1)  ?