I have done about as much work as I feel like on this version and it seems to be up and working OK with all of the test code I have available. Its major changes are unicode support along with a new include file format. Many of the macros support either ascii or unicode depending on the __UNICODE__ equate. There are additional library modules to provide further unicode support and the WINDOWS.INC - WINEXTRA.INC include file pair have been updated with a large number of equates and structures. The CG.EXE code tool produces an output that can be built as either ASCII or UNICODE but uncommenting the __UNICODE__ equate.
I have just done about 2 months of work on this version so i am not all that interested in redesigns or smartarse wisecracks but if I can get any useful feedback in the short term I will fix any obvious problems but I want to get this version out reasonably soon as I am just tired of looking at it.
Use the link below.
Hutch,
On my P4 WinXP SP2, installation worked just fine with OutLook and eight Firefox windows open.
MasmBasic is a very tough test, with loads of exotic macros, but it installed just fine (but it needs ml 6.15 or Jwasm, of course).
Problems with JWasm - many errors of this kind:
***********
ASCII build
***********
winextra.inc(22454) : Error A2151: Unexpected literal found in expression:
winextra.inc(22454): Included by
windows.inc(25081): Included by
masm32rt.inc(38): Included by
MasmBasic.inc(2): Included by
Tmp_File.asm(1): Main line code
My compliments - I know that adding Unicode was extremely hard work, and prone to break existing code. You seem to have succeeded so far :U
Thanks for that, it was an incorrect data type, MMVERSION <> should have been MMVERSION ? as it is equated to a UINT which is a DWORD. Just to test it would you do a global replace in winextra.inc changing "MMVERSION <>" to "MMVERSION ?" and see if the error goes away.
This is the replacement.
this has been replaced with the link below.
hi,
the GDI+ definitions are not complete and cause a conflict when using with my own include. In the attachment a file containting all needed definitions.
qWord
Plug this replacement for winextra.inc and see if this works correctly, it has your file added in place of the gdiplus version before it.
Quote from: hutch-- on November 24, 2011, 11:35:51 AM
Plug this replacement for winextra.inc and see if this works correctly, it has your file added in place of the gdiplus version before it.
Works like a charm, no more problems with JWasm. I suggest a minor change:
ifndef Masm32verbose
Masm32verbose=1
endif
if Masm32verbose
IFDEF __UNICODE__
echo
echo *************
echo UNICODE Build
echo *************
echo
ELSE
echo
echo ***********
echo ASCII build
echo ***********
echo
ENDIF
ENDIF
The echos clutter my output window ;-)
will the libs be made with /safeseh enabled? (looking forward to that if they are)
Hi Hutch,
Thanks for this new release.
The file \masm32\macros\lst.txt is containing some NULL characters. Running lst.exe, the output of the text file in qeditor displays some small box symbols identified as NULL chars.
H:\masm32\macros>debug lst.txt
-d
1500:0100 72 65 70 61 72 67 20 4D-41 43 52 4F 20 61 72 67 reparg MACRO arg
1500:0110 00 0D 0A 72 65 70 61 72-67 76 20 4D 41 43 52 4F ...repargv MACRO
1500:0120 20 61 72 67 00 0D 0A 72-65 70 61 72 67 6F 66 20 arg...repargof
1500:0130 4D 41 43 52 4F 20 61 72-67 00 0D 0A 74 73 74 61 MACRO arg...tsta
1500:0140 72 67 20 4D 41 43 52 4F-20 61 72 67 00 0D 0A 61 rg MACRO arg...a
1500:0150 72 67 63 6F 75 6E 74 20-4D 41 43 52 4F 20 61 72 rgcount MACRO ar
1500:0160 67 73 3A 56 41 52 41 52-47 00 0D 0A 67 65 74 61 gs:VARARG...geta
1500:0170 72 67 20 4D 41 43 52 4F-20 6E 75 6D 3A 52 45 51 rg MACRO num:REQ
Hutch,
Easy Code, a MASM32 project, compiles, links and works perfectly well with this new pre-release 2.
Congratulations!
Ramon
JJ,
Will this do the job ? i want it there by default but specifying "__NO_NOISE__" before the include files shuts it up.
IFNDEF __NO_NOISE__
IFDEF __UNICODE__
echo
echo *************
echo UNICODE Build
echo *************
echo
ELSE
echo
echo ***********
echo ASCII build
echo ***********
echo
ENDIF
ENDIF
Erol,
Thanks, its fixed, needed a -1 at the end of the algo that produced each line of text.
Ramon,
Thanks for the testing, I sent you an email on the ntoskrnl problem that I hope fixes it.
Quote from: hutch-- on November 24, 2011, 10:59:08 PM
JJ,
Will this do the job ? i want it there by default but specifying "__NO_NOISE__" before the include files shuts it up.
Perfect, thanks :U
Hutch,
After following the instructions in the email you sent me, the ntoskrnl problem is solved.
Thanks!
I have done all the mods mentioned, tracked down some duplicates in the WINDOWS.INC file that were stopping POASM from building files, fixed a typo in MASM32.INC and it all seems to be working correctly at the moment.
www.masm32.com/v11beta/v11pr3.zip
I would like to be able to get this released so if you find any quirks please let me know quickly.
- Missing in \masm32\include\htmlhelp.inc:
HtmlHelpA PROTO :DWORD,:DWORD,:DWORD,:DWORD
- there is an odd "error A2002:cannot have more than one ELSE clause per IF block" that I get with the attachment:
.listall
nops 9
if 1
invoke Sleep, 100
counter_begin LOOP_COUNT, HIGH_PRIORITY_CLASS
invoke crt__strrev, addr Src
counter_end
if useMB and 0 ; put 0 to see....
Print str$(eax), 9, "cycles for crt__strrev", 13, 10
else ; ... how it chokes with Masm32 print
print str$(eax), 9, "cycles for crt__strrev", 13, 10
endif
else
invoke Sleep, 100
counter_begin LOOP_COUNT, HIGH_PRIORITY_CLASS
push offset Src
call RevString2a
counter_end
print str$(eax), 9, "cycles for RevString2a", 13, 10
endif
nops 9
.nolist
It might have to do with line 208 in the attached tmp.lst (there is no lbl1 set in the listing):
IFNDEF __UNICODE__
2 goto lbl1
Strangely enough, it assembles fine with a) JWasm, b) if useMB is set to 0 or c) if I redefine the chr$ macro on top of the file.
This version inserted in \masm32\macros\Macros.asm works fine:
chr$ MACRO any_text:VARARG
LOCAL txtname,lbl1,lbl2
.data
IFNDEF __UNICODE__
txtname db any_text,0
align 4
.code
EXITM <OFFSET txtname>
ELSE
WSTR txtname,any_text
align 4
.code
EXITM <OFFSET txtname>
ENDIF
ENDM
JJ,
No error here.
Intel(R) Core(TM)2 Quad CPU Q9650 @ 3.00GHz (SSE4)
******** timings for unaligned strings, useMB=0
620 cycles for crt__strrev
268 cycles for RevString2c
267 cycles for RevString2d
273 cycles for RevString2e
267 cycles for RevString3
226 cycles for Masm32 szRev
702 cycles for FlipFlop
******** timings for 16-byte aligned strings:
130 cycles for RevString2a
129 cycles for RevString2c
120 cycles for RevString2d
139 cycles for RevString2e
119 cycles for RevString3
210 cycles for Masm32 szRev
62 cycles for RevLingo (GPF for non-aligned strings)
701 cycles for FlipFlop
This is a string, 100 characters long, that serves a variety of purposes, such a
s testing my algos..
..sogla ym gnitset sa hcus ,sesoprup fo yteirav a sevres taht ,gnol sretcarahc 0
01 ,gnirts a si sihT
..sogla ym gnitset sa hcus ,sesoprup fo yteirav a sevres taht ,gnol sretcarahc 0
01 ,gnirts a si sihT
This is a string, 100 characters long, that serves a variety of purposes, such a
s testing my algos..
Sizes:
64 RevString
64 RevString2a
67 RevString2b
67 RevString2c
67 RevString2d
63 RevString2e
0 MbFlipP
67 RevString3
64 RevStr
64 szRev
107 RevLingo
23 FlipFlop
--- ok ---
Hutch,
No error for useMB=0, i.e. no MasmBasic (http://www.masm32.com/board/index.php?topic=12460).
chr$ is the culprit, and the new version below works fine with MasmBasic & useMB=1.
The goto lb1 technique may save some lines, but it chokes in this particular setting. The same might happen with other macros that my code does not use...
Here is an optimised version:
include \masm32\include\masm32rt.inc
include \masm32\macros\ucmacros.asm
if 0
__UNICODE__=1 ; comment out to see the ANSI version
endif
chr$ MACRO any_text:VARARG
LOCAL txtname
.data
align 4
IFNDEF __UNICODE__
txtname db any_text,0
ELSE
WSTR txtname,any_text
ENDIF
.code
EXITM <OFFSET txtname>
ENDM
.code
start:
IFNDEF __UNICODE__
invoke MessageBoxA, 0, chr$("ANSI"), chr$("it works"), MB_OK
ELSE
invoke MessageBoxW, 0, chr$("UNICODE"), chr$("it works"), MB_OK
ENDiF
exit
end start
Hutch,
I tested MASM32 version 11 pre-Release 3 as much as I could and everything seems to work fine.
Good work!
Ramon
Thanks Ramon. :U
JJ, I used the goto label technique for a reason, some combinations cause nesting level depth problems with MASM with IFDEF - IFNDEF so I wrote an alternative to it.
You are mixing old code with a line like this.
include \masm32\macros\ucmacros.asm
In version 11 the ucmacros.asm file is a stub that displays an error if it is included.
What I don't know is if you are building the test piece with MASM or JWASM. The macros were written and tested on ML 6.14 and also tested on later versions of ML.EXE. I would expect JWASM to be properly MASM compliant but its not in the testing range I undertake with this project.
Quote from: hutch-- on November 25, 2011, 10:29:16 PM
JJ, I used the goto label technique for a reason, some combinations cause nesting level depth problems with MASM with IFDEF - IFNDEF so I wrote an alternative to it.
I'd love to see an example for that. Must have driven you crazy chasing this one :green
QuoteYou are mixing old code with a line like this.
I know. It's simply because I have not yet installed the new version on my home PC. Inter alia because the installer tells me every time I should delete all the previous stuff :toothy
QuoteWhat I don't know is if you are building the test piece with MASM or JWASM. The macros were written and tested on ML 6.14 and also tested on later versions of ML.EXE. I would expect JWASM to be properly MASM compliant but its not in the testing range I undertake with this project.
JWasm is insofar "incompliant" as it is the only one that does assemble the test piece with useMB=1 and the "goto" version of chr$.
You don't have to delete it, just temporarily rename your old MASM32 installation to something else. The install tests for an existing MASM32 installation by the directory name and if its present on that partition, it will not install there.
> Must have driven you crazy chasing this one
It was a genuine joy, with the level of interdependence I have to go backwards re-writing a whole heap of the macros.
Quote from: hutch-- on November 26, 2011, 10:01:18 AM
You don't have to delete it, just temporarily rename your old MASM32 installation to something else. The install tests for an existing MASM32 installation by the directory name and if its present on that partition, it will not install there.
So i rename while launching the installer, and before installing "for good", I rename again to masm32? And it will not overwrite or delete any non-Masm32 files?
Quote
> Must have driven you crazy chasing this one
It was a genuine joy, with the level of interdependence I have to go backwards re-writing a whole heap of the macros.
Can you test it with the "shortened" chr$ again? If it chokes with MasmBasic, it may choke with other complex macros, too... I had no problems with my standard MB testbed, it's sheer accident that I opened this one and found the problem.
Another option for Masm32 test installations is to use a virtual disk driver. ImDisk can create very fast RAM Disks :
http://www.ltr-data.se/opencode.html/#ImDisk
Create a virtual partition and assign a letter with ImDisk. After formatting the partition, the installation of Masm32 goes very fast.
Thanks for the link Erol, that is the first decent ramdisk I have seen for a long time. Saves the drive image to disk and can be opened again as a drive. :U
JJ,
The shortened version is almost identical to the version I had to re-write into the current one. The "chr$()" macro uses standard MASM notation and the goto label approach was used to step out of the conditional block so that the EXITM code was not contained in it.
Now when you have a working version 11 installed instead of the hybrid you have so far tested, the next step would be to see why your macro "chokes".
Hutch,
Attached a version that boils it down to one line or even one half line:
print str$(eax) ; works
print str$(eax), 9 ; chokes
Two LST files are attached - one with MasmBasic enabled (it chokes with ml.exe but not with JWasm), the other uses Masm32 only (it works with ML.exe and JWasm). The two files are almost identical - see line 214 for a difference...
Note the code starts working if either
- you take away the "9" after print str$() or
- you comment out the empty else
It is pretty mysterious, but as far as I can see my macros are not directly involved. At least, I don't see any of them, even in a more complete listing. I guess it has to do with the local macro variables.
Again, the shortened chr$ works fine, and I would like to see a case where that one fails ::)
I am not seeing it here with simple example. The "print" macro uses the "chr$()" macro to handle the VARARG data after the 1st argument and its working exactly as it is supposed to.
IF 0 ; ¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤
Build this template with "CONSOLE ASSEMBLE AND LINK"
ENDIF ; ¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤
__UNICODE__ equ 1
include \masm32\include\masm32rt.inc
.code
start:
; ¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤
call main
inkey
exit
; ¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤
main proc
LOCAL var :DWORD
mov var, 1234567
print "Numbers ",48,49,50,51,52,53,54,55,56,57,13,10
print "Howdy "
print ustr$(var)
print chr$(13,10)
ret
main endp
; ¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤
end start
The output is,
Numbers 0123456789
Howdy 1234567
Press any key to continue ...
Quote from: hutch-- on November 26, 2011, 08:31:56 PM
I am not seeing it here with simple example. The "print" macro uses the "chr$()" macro to handle the VARARG data after the 1st argument and its working exactly as it is supposed to.
Yes, there is no problem in a simple app. But Masm is a buggy pig. The error message says there is one else too much.
I have stripped it down to the absolute minimum:
Quote.nolist
useMB = 1 ; 1 to choke, 0 to go
ife useMB
include \masm32\include\masm32rt.inc
else
include \masm32\MasmBasic\MasmBasic.inc
endif
.listall
.code
start:
if 1 ; <<<<<<<<<<<<<< trouble starts here <<<<<<<<<<<<<<<<<
nop ; v v v v v no trouble without the 9 v v v v
print "Ciao ", 9
nop
else ; <<<<<<<<<<<<<<<<< works if commented out <<<<<<<<<<<<<<<<
NOP
endif
inkey "bye"
exit
end start
Full "testbed" attached. The two LST files differ only marginally...
Now, just in case somebody might suspect that MasmBasic (http://www.masm32.com/board/index.php?topic=12460) was the culprit, here a version that definitely does not use MB:
Quote.nolist
useMasm32 = 0 ; 1 to choke, 0 to go
ife useMasm32
include \masm32\include\masm32rt.inc
else
include \masm32\include\masm32rt.inc
endif
.listall
.code
start:
if 1 ; <<<<<<<<<<<<<< trouble starts here <<<<<<<<<<<<<<<<<
nop ; v v v v v no trouble without the 9 v v v v
print "Ciao ", 9
nop
else ; <<<<<<<<<<<<<<<<< works if commented out <<<<<<<<<<<<<<<<
nop
endif
inkey "bye"
exit
end start
Builds perfectly here with version 11. Am I missing something or is it the case that it builds OK in MASM but fails when the MasmBasic macros are added ?
Microsoft (R) Macro Assembler Version 6.14.8444
Copyright (C) Microsoft Corp 1981-1997. All rights reserved.
Assembling: K:\jj\elsebug2\ElseBug.asm
***********
ASCII build
***********
Microsoft (R) Incremental Linker Version 5.12.8078
Copyright (C) Microsoft Corp 1992-1998. All rights reserved.
Volume in drive K is drv_k
Volume Serial Number is 4421-FFA6
Directory of K:\jj\elsebug2
11/26/2011 10:06 PM 517 ElseBug.asm
11/27/2011 08:20 AM 2,560 ElseBug.exe
11/27/2011 08:20 AM 1,045 ElseBug.obj
3 File(s) 4,122 bytes
0 Dir(s) 248,225,169,408 bytes free
Press any key to continue . . .
RE : Nesting macros that contain chr$().
print right$(left$(rev$(ustr$(uval(rev$(chr$(48,49,50,51,52,53,54,55))))),6),5),13,10
Works fine.
I can confirm this bug.
In my experience, MASM some time simply goes crazy when using GOTO. A common IF/ELSE construct should solve the problem.
Quote from: hutch-- on November 26, 2011, 09:29:23 PM
Builds perfectly here with version 11. Am I missing something or is it the case that it builds OK in MASM but fails when the MasmBasic macros are added ?
See the post above yours, and qWord's answer. It's not MasmBasic.
Actually, the trigger is this one:
useMasm32 = 1 ; 1 to choke, 0 to go
ife useMasm32
include \masm32\include\masm32rt.inc
else
include \masm32\include\masm32rt.inc
endif
A simple include does not exhibit the problem. Somewhere in masm32rt.inc it starts choking over an unbalanced if/else/endif construct.
Still builds correctly. I need to be able to see what the problem is and with code that builds correctly in the default installation of version 11 I am not seeing it.
IF 0 ; ¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤
Build this template with "CONSOLE ASSEMBLE AND LINK"
ENDIF ; ¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤
__UNICODE__ equ 1
useMasm32 = 1 ; 1 to choke, 0 to go
ife useMasm32
include \masm32\include\masm32rt.inc
else
include \masm32\include\masm32rt.inc
endif
.code
start:
; ¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤
call main
inkey
exit
; ¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤
main proc
LOCAL var :DWORD
mov var, 1234567
print "Numbers ",48,49,50,51,52,53,54,55,56,57,13,10
print "Howdy "
print ustr$(var)
print chr$(13,10)
print right$(left$(rev$(ustr$(uval(rev$(chr$(48,49,50,51,52,53,54,55))))),6),5),13,10
ret
main endp
; ¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤
end start
hutch,
use jj last example.
The problem is the GOTO-construct in chr$: changing it to a IF/ELSE, solves the problem.
.nolist
useMasm32 = 0 ; 1 to choke, 0 to go
ife useMasm32
include \masm32\include\masm32rt.inc
else
include \masm32\include\masm32rt.inc
endif
.listall
.code
start:
if 1 ; <<<<<<<<<<<<<< trouble starts here <<<<<<<<<<<<<<<<<
nop ; v v v v v no trouble without the 9 v v v v
print "Ciao ", 9
nop
else ; <<<<<<<<<<<<<<<<< works if commented out <<<<<<<<<<<<<<<<
nop
endif
inkey "bye"
exit
end start
Or add this to your example:
if 1
print "Numbers ",48,49,50,51,52,53,54,55,56,57,13,10
else
nop
endif
qWord, your example builds perfectly here.
Microsoft (R) Macro Assembler Version 6.14.8444
Copyright (C) Microsoft Corp 1981-1997. All rights reserved.
Assembling: K:\jj\elsebug2\tst2.asm
***********
ASCII build
***********
Microsoft (R) Incremental Linker Version 5.12.8078
Copyright (C) Microsoft Corp 1992-1998. All rights reserved.
Volume in drive K is drv_k
Volume Serial Number is 4421-FFA6
Directory of K:\jj\elsebug2
11/27/2011 09:06 AM 464 tst2.asm
11/27/2011 09:06 AM 2,560 tst2.exe
11/27/2011 09:06 AM 1,045 tst2.obj
3 File(s) 4,069 bytes
0 Dir(s) 248,225,157,120 bytes free
Press any key to continue . . .
JJ,
Builds correctly here.
.nolist
useMasm32 = 0 ; 1 to choke, 0 to go
ife useMasm32
include \masm32\include\masm32rt.inc
else
include \masm32\include\masm32rt.inc
endif
.listall
.code
start:
if 1 ; <<<<<<<<<<<<<< trouble starts here <<<<<<<<<<<<<<<<<
nop ; v v v v v no trouble without the 9 v v v v
print "Ciao ", 9
nop
else ; <<<<<<<<<<<<<<<<< works if commented out <<<<<<<<<<<<<<<<
nop
endif
if 1
print "Numbers ",48,49,50,51,52,53,54,55,56,57,13,10
else
nop
endif
inkey "bye"
exit
end start
This nests correctly as well.
IFNDEF 1
IFNDEF 1
IFNDEF 1
IFNDEF 1
IFNDEF 1
IFNDEF 1
IFNDEF 1
IFNDEF 1
IFNDEF 1
IFNDEF 1
print "Howdy Folks",13,10
ELSE
nop
ENDIF
ELSE
nop
ENDIF
ELSE
nop
ENDIF
ELSE
nop
ENDIF
ELSE
nop
ENDIF
ELSE
nop
ENDIF
ELSE
nop
ENDIF
ELSE
nop
ENDIF
ELSE
nop
ENDIF
ELSE
nop
ENDIF
You guys must be doing something different, all of this stuff so far builds correctly in version 11.
I changed the ML version to 9.00 and it works exactly as before with 6.14.
there is definitely a bug caused by the GOTO-directive in chr$:
ife 1
include \masm32\include\masm32rt.inc
else
include \masm32\include\masm32rt.inc
endif
.code
start:
if 1
mov eax,chr$("1234")
else
endif
end startQuoteml /c /coff /Cp "main.asm"
Assembling: main.asm
***********
ASCII build
***********
main.asm(10) : error A2002:cannot have more than one ELSE clause per IF block
Microsoft (R) Macro Assembler Version 11.00.40825.2
Copyright (C) Microsoft Corporation. All rights reserved.
Error(s) occured.
OK, that example tracks the problem down. Its a clash between "if" and "ife"
Change ife to if and it builds, alternately change if to ife and it builds. It does not occur if the "ife" block is put in the code section of this example.
ife 1
include \masm32\include\masm32rt.inc
else
include \masm32\include\masm32rt.inc
endif
.code
start:
if 1
mov eax,chr$("1234")
else
endif
end start
Now the problem as I see it is the naive replacement of "chr$()" with a conditional block version is likely to just shift the problem elsewhere.
Quote from: hutch-- on November 26, 2011, 11:05:37 PMNow the problem as I see it is the naive replacement of "chr$()" with a conditional block version is likely to just shift the problem elsewhere.
I've had similar problems several times (IFxx/ELSExx/ELSE/ENDIF + GOTO) - believe me, removing GOTO is the best choice.
If I double click masm32\datetime\demo\WorldTimes.exe says that do not have found datetime.dll.
But, if build again works fine (if I click in masm32\datetime\demo\makeit.bat works correct).
This version of chr$() works with the example that broke the last one that used "ife"
chr$ MACRO any_text:VARARG
LOCAL txtname,lbl1,lbl2,flag
.data
IFDEF __UNICODE__
flag = 1
ELSE
flag = 0
ENDIF
IF flag eq 0
txtname db any_text,0
align 4
ENDIF
IF flag eq 1
WSTR txtname,any_text
align 4
ENDIF
.code
EXITM <OFFSET txtname>
ENDM
mineiro,
Thanks, I will have a look at it.
a bit simpler:
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
Quote from: qWord on November 26, 2011, 11:39:32 PM
a bit simpler:
Resembles a little bit my version (http://www.masm32.com/board/index.php?topic=17795.msg149991#msg149991). By the way: What is the purpose of aligning after the string?
Quote from: jj2007 on November 26, 2011, 11:47:07 PM
Quote from: qWord on November 26, 2011, 11:39:32 PM
a bit simpler:
Resembles a little bit my version (http://www.masm32.com/board/index.php?topic=17795.msg149991#msg149991). By the way: What is the purpose of aligning after the string?
:bg
I think he want to leave the segment aligned? I also wouldn't do it, but on the other hand, it doesn't hurt.
...
mov eax,chr$(...)
.data
myDW dd ? ; align not needed
.code
...
Its easy to write it simpler with just one conditional block but I intentionally wrote it with the double step to avoid another problem of nesting. The local flag does the job and if falls out the bottom of the block, the two IF blocks are fall through and the EXITM <> is off the bottom of all of the conditional blocks without being enclosed by them. It does not need the two local labels of course, I simply forgot to remove them while testing.
I tend to align uncontrolled size data on exit so the next item is not misaligned.
It gets worse from here, "IFE" is buggy and reports the error,
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.
This bug is not limited to IFE:
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 start
You can replace the IF/ENDIF's + GOTO's in the macro a/ucfm$ with something like this:
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.
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.
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.
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,
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,
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.
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:
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:
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...
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.
Quote from: hutch-- on November 28, 2011, 08:20:10 AM
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
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
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.
Quote from: hutch-- on November 28, 2011, 09:24:10 AM
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.
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
> 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,
Quote
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.
Quote from: hutch-- on November 28, 2011, 11:18:51 AM
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
ntoskrnl.inc has some problems:
>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:
. . .
;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
. . .
Gratsie, will do. :U
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.
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
mineiro,
Thanks for making the effort, it is appreciated. I had to track down an unusual quirk in the MASM macro engine and what I have done is minimise the conditional blocks and in this instance avoid the use of GOTO even though it is valid MASM macro syntax. There appears to be an obscure bug in some of the conditional block operators that generate an ELSE clause error even when there is no else clause. This is the version that is test up OK at the moment.
; -----------------------------------------
; non branching version with no ELSE clause
; -----------------------------------------
chr$ MACRO any_text:VARARG
LOCAL txtname
.data
IFDEF __UNICODE__
WSTR txtname,any_text
align 4
.code
EXITM <OFFSET txtname>
ENDIF
txtname db any_text,0
align 4
.code
EXITM <OFFSET txtname>
ENDM
Hi Hutch
I want to report a bug in the new Windows.inc file (Version 1.5 RELEASE October 2011).
The lines IFDEF __UNICODE__
TBBUTTONINFO equ TBBUTTONINFOW
LPTBBUTTONINFO typedef ptr TBBUTTONINFOW
ELSE
TBBUTTONINFO equ TBBUTTONINFOA
LPTBBUTTONINFO typedef ptr TBBUTTONINFOA
ENDIF
should beIFDEF __UNICODE__
TBBUTTONINFO equ <TBBUTTONINFOW>
LPTBBUTTONINFO typedef ptr TBBUTTONINFOW
ELSE
TBBUTTONINFO equ <TBBUTTONINFOA>
LPTBBUTTONINFO typedef ptr TBBUTTONINFOA
ENDIF
Regards, Biterider
QuoteI want to report a bug in the new Windows.inc file (Version 1.5 RELEASE October 2011).
has it officially been released ?
Hi Hutch
Another minor problem is the IUnknown declaration in winextra.inc, which stays in conflict with the most basic COM interface/structure definition.
IUnknown equ void
I would suggest to comment it out.
Regards, Biterider
Biterider,
Thanks, that makes sense, I cannot find any form of "typedef void" that even comes close to anything that can be defined in MASM.
Where's the masm11 test version? I only see masm10r
http://www.masm32.com/v11beta/v11pr3.zip
Thanks gunner. later
Hi Hutch
I have another catch. Should be:
IFDEF __UNICODE__
NMHDDISPINFO equ <NMHDDISPINFOW>
LPNMHDDISPINFO typedef ptr NMHDDISPINFOW
ELSE
NMHDDISPINFO equ <NMHDDISPINFOA>
LPNMHDDISPINFO typedef ptr NMHDDISPINFOA
ENDIF
Biterider
If you need the extra pointer you would be better to add it in an external file as all of the structures are done much the same way in only having the name equated to either ASCII or UNICODE depending on the __UNICODE__ equate.
IFDEF __UNICODE__
LPNMHDDISPINFO typedef ptr NMHDDISPINFOW
ELSE
LPNMHDDISPINFO typedef ptr NMHDDISPINFOA
ENDIF
This is the format in the vc2010 header file.
typedef struct tagNMHDDISPINFOW
{
NMHDR hdr;
int iItem;
UINT mask;
LPWSTR pszText;
int cchTextMax;
int iImage;
LPARAM lParam;
} NMHDDISPINFOW, *LPNMHDDISPINFOW;
typedef struct tagNMHDDISPINFOA
{
NMHDR hdr;
int iItem;
UINT mask;
LPSTR pszText;
int cchTextMax;
int iImage;
LPARAM lParam;
} NMHDDISPINFOA, *LPNMHDDISPINFOA;
Hi Hutch
Sorry, I was not clear enough. It was too late in the morning :(
The original definition looks like
NMHDDISPINFO equ NMHDDISPINFOW
and
NMHDDISPINFO equ NMHDDISPINFOA
Here, the square brackets are missing.
Regards,
Biterider