CoInvoke

[Ryan]

My version throws an error if edx gets overwritten by an addr xyz

addr uses edx?  I thought it used eax exclusively?

[jj2007]

JJ, deliberately misunderstanding people is an indication of a TROLL. Are you a TROLL?

Japheth,

I am not deliberately misunderstanding anybody. Ernie wrote that macro ten years ago, and I asked why he so firmly states that edx cannot be used. Not because I am a troll, but because I failed to see a concrete reason for this statement.

I posted my version, it works fine even with edx as parameter, and in "response" to that somebody dumps idiosyncratic macros in this thread that do not prove anything and have little to do with the original question.

You wrote "The problem is that expansion is done from left to right". That is correct but irrelevant, if during expansion edx is not getting destroyed (and Ole$() won't destroy edx for that precise reason). And it is completely irrelevant for the final part of the macro where edx (or eax) is being used to dereference the pointer.

Regarding the problem that JWasm doesn't like the GuidFromString macro, I will post it on SourceFourge.

That was a problem for JWasm 2.08 of 30 August, but I just downloaded version 7 September, and voilà, it works :t

[jj2007]

My version throws an error if edx gets overwritten by an addr xyz

addr uses edx?  I thought it used eax exclusively?

In a macro you can use whatever you like. The standard implementation of invoke uses the lea eax, localvar/push eax sequence, but eax is frequently a return value from some API call, so it can be convenient to use edx instead. You may have seen an error message that eax will be overwritten - see snippet below for a test of the options.

Code: [Select]

include \masm32\include\masm32rt.inc

.code
AppName db "Masm32 is great!", 0
Hello db "A message:", 0

start:
call MyTest
exit

MyTest proc
LOCAL bufText[100]:BYTE
LOCAL bufTitle[100]:BYTE
; prepare local buffers for testing:
invoke lstrcpy, addr bufText, offset AppName
invoke lstrcpy, addr bufTitle, offset Hello

; standard behaviour:
invoke MessageBox, 0, addr bufText, addr bufTitle, MB_OK

; no error because eax gets pushed before lea is being used:
lea eax, bufTitle
invoke MessageBox, 0, addr bufText, eax, MB_YESNO

; Error A2165: Register value overwritten by INVOKE:
; lea eax, bufText
; invoke MessageBox, 0, eax, addr bufTitle, MB_OK

; workaround using edx instead of eax:
lea edx, bufText
invoke MessageBox, 0, edx, addr bufTitle, MB_YESNOCANCEL

ret
MyTest endp

end start

P.S.: "edx is not used in the last line of the macro, so is this necessary?"
No, mov edx, [eax+Method] is just a leftover from testing.

[TouEnMasm]

All macros calling an interface are differents from other macros.
The first thing they do is loading the pointer off interface (ppv) in one register.
Others macros don't do that.
Then the normal contrust for call is made.At this time , if you reuse the register pointing on the interface this one is overwritten.

[jj2007]

Yves,

My macros are different from yours, and they work just fine.

Bonne journée,
Jochen

[TouEnMasm]

Here is your original question:

Is there any good reason not to allow edx? My version throws an error if edx gets overwritten by an addr xyz, but otherwise I just can't see why edx should not work with CoInvoke...

answer is made.