(I'm not sure if this should be posted in the MASM32 forum, but I figured that only stuff regarding Hutch's MASM32 package should be posted there, please tell me if I did right or wrong, so I now the next time)


I just found a very strange thing in MASM, regarding the scope of the parameters of the "invoke" directive. I was experimenting a little with data in the code section, and wrote the following very simple procedure:



invoke MessageBox, 0, offset str1, offset str2, MB_OK
jmp theend
str1 db "Test1", 0
str2 db "Test2", 0
theend:
ret


When I try to compile this I get "Undefined symbol" errors on str1 and str2 in the invoke command (and it does not matter if I change the label types to "code type labels" either, but if the strings are defined before the line with the invoke, all works fine though).


But it all works fine if I just do the call manually instead, without the "invoke" directive, like this:


push 0
push offset str1
push offset str2
push 0
call MessageBox
jmp ende
str1 db "Test1", 0
str2 db "Test2", 0
ende:
ret


My program does not have a data segment at all, but it's the same thing if I add a data segment and put the data in this instead. As long as the declaration is after the line with the invoke command in the source file, it refuses to recognize those symbols. :(


Why is this?! Is it a bug in MASM, or do I need to add something to the invoke command to make it accept data labels that are positioned after it in the code?

I assume that this could be a problem even for "normal programs", e.g. when they need to call an API that needs a function pointer as a parameter, and that function is located after the invoke in the source file?

Or is there maybe a global MASM directive to fix this?


Any help would be highly appreciated.

Thanks!
Posted on 2002-12-05 20:27:33 by dELTA
INVOKE is a built-in macro, and it's processed first to generate the code that will be assembled on following passes. Since str* isn't defined yet, you get the error.

I guess it could have ignored the error and generated the code anyway, since if they were truely undefined, it would catch it on the next pass. I suppose it's a minor design "flaw"...

:)
Posted on 2002-12-05 21:06:05 by S/390
Minor Design flaw? well we are talking about the Microsoft
developers now arnt we? ( :grin: ) Anyway, this is a bug
within the Macro. Ofcourse you could just ignore the error,
but that doesnt make it go away now does it?

If you dont want to write something like that yourself, there
are tons of different versions on this board. However personally
i like the one EliCZ created. Go here to find it: http://www.anticracking.sk/EliCZ/infos.htm && Download 'EliASM2'.


EDIT: Posts = 137, only 1200 more before I become 1337 ( :grin: )
Posted on 2002-12-05 21:22:31 by natas