MASM32 version 11 pre-Release 3

[hutch--]

It gets worse from here, "IFE" is buggy and reports the error,

Code Select Expand


error A2002: cannot have more than one ELSE clause per IF block


even when there is not occurrence of ELSE in any of the conditional blocks. I rewrote the cfm$() macro but it failed after removing the GOTO form, directly called the acfm$() macro and it reports this error even though acfm$() has no ELSE clause in it.

[qWord]

This bug is not limited to IFE:

Code Select Expand


if 1 NE 1
   include \masm32\include\masm32rt.inc
else
   include \masm32\include\masm32rt.inc
endif
.code
start:
  if 1
mov eax,cfm$("1234")
else
  endif
end starta/ucfm$ also use GOTOs.  you may replace them with EXITM?

[qWord]

You can replace the IF/ENDIF's + GOTO's in the macro a/ucfm$ with something like this:

Code Select Expand

          cpos INSTR 1,<t\q0lrxabn>
          chr SUBSTR <   009h05ch022h000h03ch03eh021h028h029h10,13>,cpos*4,4+(cpos/10)
          buffer CATSTR buffer,<",chr,">
However, you can also call the macros UCCSTR and ?cstr?, which use this technique.

[hutch--]

Now the results get even funnier. I put the acfm$() macro in the same file AFTER the IFE block and it works correctly.

LATER: Here is another one.

Code Select Expand



    ife 1
       include \masm32\include\masm32rt.inc
    else
       include \masm32\include\masm32rt.inc
    endif

    include \masm32\macros\macros.asm

  ..................


Duplicate the inclusion of MACROS.ASM and the problem goes away.

Yet LATER Again: If the macro file is only included locally in the source code all of the macros work fine, it is when the include directive is contained in an external include file that the problem occurs. The problem is not with the macros but with some very obscure bug in MASM related to using the "include" directive.

[hutch--]

i basically have a dilemma to solve, the problems with macros when multiple systems of macros are used generates a non-existent error in MASM of multiple ELSE clauses. The problem occurs when some macros are called in source code.

With some experimentation the problem can be solved by adding an extra "include" directive directly in the source code that the non-existent error occurs in. By adding the line,

Code Select Expand


    include \masm32\macros\macros.asm


The test pieces that displayed the problem build correctly so it is not a problem with the macro but a problem from elsewhere. I don't have a reliable way to track it down as it is an internal limitation in MASM but I am guessing that it has something to do with the sum total of conditional blocks used before it.

In some instances a change in the logic can solve the problem. Shifting from a negative to a positive evaluation or vice versa often removes the problem.

Instead of,

Code Select Expand


IFE whatever
  do this
ELSE
  dothat
ENDIF

It can be inverted to,

IF whatever
  dothat
ELSE
  dothis
ENDIF


Now some resolution of the problem can be had by rewriting some of the macros to avoid conditional blocks but it generally shifts the problem elsewhere and does not address the cause of the problem, something that can be fixed by calling the macro file again.

I would be interested to hear any comments that can resolve the problem but I am inclined to leave the solution of adding another call to macros.asm in place if a macro error occurs as a consequence of using a conditional block.

[jj2007]

You risk fixing a messy workaround with another workaround.
Back to the original problem...

This one works, looks like good coding practice, but some of your more complex macros started choking:

Code Select Expand

chr$ MACRO any_text:VARARG
LOCAL txtname
.data
  IFNDEF __UNICODE__
txtname db any_text,0
  ELSE
WSTR txtname,any_text
  ENDIF
align 4
.code
  EXITM <OFFSET txtname>
ENDM


So you went for the goto solution, which chokes on other occasions:

Code Select Expand

chrBug$ MACRO any_text:VARARG
LOCAL txtname,lbl1,lbl2
.data
  IFNDEF __UNICODE__
goto lbl1
  ELSE
goto lbl2
  ENDIF
:lbl1
  txtname db any_text,0
  align 4
.code
  EXITM <OFFSET txtname>
  :lbl2
  WSTR txtname,any_text
  align 4
  .code
  EXITM <OFFSET txtname>
ENDM


IMHO it might help if you could supply one example where version 1 causes trouble - maybe there is a simple reason for it. You must have invested a lot of time chasing this one, but "fresh eyes" might spot the solution...

[hutch--]

I think you missed what the problem is, if the macro works, its not the problem. I discovered this effect after pasting in what was supposed to be a problem macro into a test piece to edit it and it ran correctly when the macro was local to the calling code. I get the same effect when directly calling the macros.asm file from the source code file that calls its macros.

Now this places the problem elsewhere, instead of guessing what will work under unknown conditions by repeatedly rewriting macros that work correctly, the idea is to track down why an included file breaks while a direct macro does not.

That you can "reload" the macros by including the file again tells you something, the definitions in the first call to the macro file has in some sense been damaged but the second call to include the macros file overwrites them. Like it or lump it GOTO is a valid MASM macro operative that works and by it working, GOTO is not the problem. You know somethiing is wrong when the error message refers to an invalid ELSE clause when it does not even exist.

[jj2007]

the idea is to track down why an included file breaks while a direct macro does not

The "non-goto" macro works fine when inserted into macros.asm and called exactly as the "goto" version. So logic would dictate that the gotos cause the problem. You say it breaks your code elsewhere - an example would be helpful.
:thumbu

Attached a minimalist testbed using different versions of chr$ in macrosXX.asm called from masm32rtXX.inc

Code Select Expand

ife 1
include whatever
else ; v v v comment out one of the versions v v v

; include \masm32\include\masm32rt_good.inc
include \masm32\include\masm32rt_buggy.inc

endif ; ^ ^ ^ comment out one of the versions ^ ^ ^


.listall
.code
start:
  if 1 ; v v v no trouble without the 9 v v v
print "Ciao ", 9
  else ; <<<<<< works if commented out <<<<
nop
  endif
  inkey "bye"
  exit
end start


[hutch--]

Siting example of macros that work under the conditions that you are using does not address the problem, the GOTO operator in MASM works fine until you mess something else up. Coding a new macro does not address the problem and the proof is clear, reloading the macro file removes the non-existent ELSE clause error. Now you can try and hide from the problem by restricting how you write macros but you just shift the problem elsewhere.

The problem you are getting is a product of further nesting of conditional blocks with a body of macros that already have multiple levels of conditional block nesting. I already have the direct use of the macros working and it is additional code that further nests the macro file that are causing the error, something that is beyond my control. I have worked on this nesting problem to try and work out why additional conditional blocks generate a non-existent error and the only working method i have found so far is to reload the macro file. Alternately the called macro works fine when added locally to the source file.

[jj2007]

Citing example of macros that work under the conditions that you are using does not address the problem, the GOTO operator in MASM works fine until you mess something else up. Coding a new macro does not address the problem

Megabytes of fairly complex code with loads of exotic macros assembles just fine with the straightforward "non-goto" chr$ macro in macros.asm. It is the goto version that chokes in some settings.

It would really be helpful if you could post a single example where the straight macros causes code to fail.

Code Select Expand

chr$ MACRO any_text:VARARG
LOCAL txtname
.data
  IFNDEF __UNICODE__
txtname db any_text,0
  ELSE
WSTR txtname,any_text
  ENDIF
.code
  EXITM <OFFSET txtname>
ENDM

[hutch--]

> It is the goto version that chokes in some settings.

This is if fact not true, even though I posted a non goto version of chr$() which you appear to have missed, the goto version works just fine. It is when you try and wrap it with incompatible conditional blocks that you are getting the problem.

Now lets face it there is nothing exciting about the macro that you keep reposting, even if it fails to align the end of the data which leaves the following data unaligned. It IS valid MASM macro notation to use GOTO label and if your code breaks on it then you need to fix it.

RE the megabytes of tested code, MASM32 has been tested successfully on terrabytes of code and many of its macros have GOTO in them.

What I have tried to do since you explained that there is an incompatibility between your macros and the new ones in MASM32 was to find out WHY there is a problem, not just look for a quick fix to your problem while generating a set of new ones.

The obvious is that if reloading the macros solves the problem then its not the macros that are the problem. If you look at the collective amount of conditional testing in,

1. WINDOWS.INC
2. The API include files
3. MACROS.ASM

and then add an even larger number of conditional tests you are likely to find a limit of some type. The line count in WINDOWS.INC was the last one that required splitting up the file.

When you keep getting this error notification,

error A2002: cannot have more than one ELSE clause per IF block

even though there is no ELSE clause in the code calling it then you know something is wrong.

> It would really be helpful if you could post a single example where the straight macros causes code to fail.

I don't intend to reverse rewrite a set of macros at your request, for the little that its worth the first macro that failed with nesting errors was "printf" which calls the "cfm$()" macro.

[jj2007]

What I have tried to do since you explained that there is an incompatibility between your macros and the new ones in MASM32

It has absolute nothing to do with my macros. As posted before, it fails with code that does not even touch my macros, and uses just Masm32 include files.

My projects works just fine with version 11, I just wanted to point out that somebody might run into problems with the observed behaviour.

Hutch, Masm32 is your project, so do as you like :thumbu

[MichaelW]

ntoskrnl.inc has some problems:

Code Select Expand


>d:\masm32\bin\ml /c /coff ntoskrnl_test1.asm
Microsoft (R) Macro Assembler Version 6.15.8803
Copyright (C) Microsoft Corp 1981-2000.  All rights reserved.

Assembling: ntoskrnl_test1.asm

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

\masm32\include\ntoskrnl.inc(1447) : error A2111: conflicting parameter definition
\masm32\include\ntoskrnl.inc(1447) : error A2112: PROC and prototype calling conventions conflict
\masm32\include\ntoskrnl.inc(1449) : error A2111: conflicting parameter definition
\masm32\include\ntoskrnl.inc(1449) : error A2112: PROC and prototype calling conventions conflict
\masm32\include\ntoskrnl.inc(1452) : error A2111: conflicting parameter definition
\masm32\include\ntoskrnl.inc(1452) : error A2112: PROC and prototype calling conventions conflict
\masm32\include\ntoskrnl.inc(1464) : error A2008: syntax error : PROTO
strcat(17): Macro Called From
  \masm32\include\ntoskrnl.inc(1464): Include File
>Exit code: 1


Commenting out the problem lines eliminated the errors:

Code Select Expand


. . .
;atol PROTO C :VARARG
isdigit PROTO C :VARARG
;islower PROTO C :VARARG
isprint PROTO C :VARARG
isspace PROTO C :VARARG
;isupper PROTO C :VARARG
isxdigit PROTO C :VARARG
mbstowcs PROTO C :VARARG
mbtowc PROTO C :VARARG
memchr PROTO C :VARARG
memcpy PROTO C :VARARG
memmove PROTO C :VARARG
memset PROTO C :VARARG
qsort PROTO C :VARARG
rand PROTO C :VARARG
sprintf PROTO C :VARARG
srand PROTO C :VARARG
;strcat PROTO C :VARARG
. . .


[hutch--]

Gratsie, will do.  :U

[mineiro]

I have made these changes in chr$ macro to work, but I do not understand why and how. I have seen that the original macro works fine if not included in any segment, in the header of assembly file being made. I do not have sure if this can help you. My intention is only help.

Code Select Expand


chr$ MACRO any_text:VARARG
.data
IFB <@CurSeg>
LOCAL txtname,lbl1,lbl2
IFNDEF __UNICODE__
  goto lbl1
ELSE
  goto lbl2
ENDIF
ENDIF
:lbl1
txtname db any_text,0
align 4
.code
EXITM <OFFSET txtname>
:lbl2
WSTR txtname , any_text
align 4
.code
EXITM <OFFSET txtname>
ENDM