Ok, im using wsprintf to turn a number into a string so i can use WritePrivateProfileString to save it to an ini file. This is the code...
invoke	wsprintf, addr Buffer, addr szForStr1, DlgMainRect.left

invoke WritePrivateProfileString, addr szAppTitle, addr szDlgMainX, addr Buffer, addr szIniFile
invoke wsprintf, addr Buffer, addr szForStr1, DlgMainRect.top
invoke WritePrivateProfileString, addr szAppTitle, addr szDlgMainY, addr Buffer, addr szIniFile
invoke wsprintf, addr Buffer, addr szForStr1, bStayOnTop
invoke WritePrivateProfileString, addr szAppTitle, addr szStayOnTop, addr Buffer, addr szIniFile


I put that in the WM_DESTROY message. Now when i close the app, i get an illegal operation error. So i used a debugger and stepped through the code. The error comes when it gets to the return instruction after a wm_destroy message. At this point i was totally clueless as to what the problem was. Eventaully i looked in my helpfile and saw this...
Note  Unlike other Windows functions, wsprintf uses the C calling convention (_cdecl), rather than the Pascal calling 

convention. As a result, it is the responsibility of the calling process to pop arguments off the stack, and arguments
are pushed on the stack from right to left. In C-language modules, the C compiler performs this task.

Am i supposed to put a "pop eax" for every call to wsprintf? Could not doing that cause the illegal operation error?
Posted on 2001-08-27 19:07:58 by ChimpFace9000
The assmebler should be doing this for you if the function PROTO is defined as C type function. Is the stack not the same as when you entered? Break before before and after and compare the stack. What do you see?
Posted on 2001-08-27 19:16:25 by bitRAKE
Ya, your right. After the wsprintf, there an "add esp, c" line. But I still dont know whats causing it do screw up though.
Posted on 2001-08-27 20:02:20 by ChimpFace9000
I'm sorry, but I would need more information to help. If your sure the error is in WM_DESTROY then post that whole section up to next '.if'.
Posted on 2001-08-27 20:05:42 by bitRAKE
Ok, i figured out what the errror is. The variable bStayOnTop, is a byte. I changed it to a dword, and it works. But why would that create an error when its returning after the wm_destroy message and not during the wsprintf call. And why does it create an error at all?
Posted on 2001-08-27 21:08:11 by ChimpFace9000
I think you have to pass the address of the byte, not the value.
Posted on 2001-08-27 21:46:42 by bitRAKE
Obviously it isnt generally known here in this board that INVOKE doesn't work correctly expanding byte/word sized arguments to dword parameters. Example:



xx proto a1:dword

byte1 byte 0
word1 word 0
word2 sword 0

main proc

invoke xx,byte1
invoke xx,word1
invoke xx,word2



in cases 1 and 2 MASM produces wrong code as you can easily see in the listing file (use command line parameter /Sg). Case 3 is ok, though!?!

This error is known by Microsoft since at least 5 years but they haven't corrected the bug till now.

japheth
Posted on 2001-08-28 06:27:48 by japheth
Thanks, japheth. Another bolt in the invoke casket. :)
Posted on 2001-08-28 08:16:50 by bitRAKE
This is the "callp" macro written by Peter Quiring for his QLIB project.
It was supposed to fix a number of problems with invoke, I think.
Perhaps bitrake could have a look at it, fixing it up, etc? :). Also,
is it possible to PURGE the old "invoke" keyword, and replace it by
the callp version? This could turn out interesting...
Posted on 2001-08-28 09:24:39 by f0dder
I haven't had any luck with PURGE, but I haven't played with it rescently - I was maybe using it wrong before. Can you think of any features that you'd like added? Only thing I can think of is adding support for passing memory addresses like invoke does, you know 'ADDR' stuff.
Posted on 2001-08-28 12:13:34 by bitRAKE
Well, purge is supposed to "remove masm's knowledge of a macro",
as I read it. However, it will only work for macros, and probably not
for built-in macros.

As for additional features... I dunno. callp probably only works with
C-style calling convention, dunno if you can make it support "all"
calling conventions, or if separate versions will have to be written
for C/STDCALL/whatever :(. And a feature like ADDR might be hard
to incorporate. Darn, if only microsoft made MASM opensource, or
at least fixed the bugs and shortcomings.

If you plan on working on this, bitrake, I think it should be moved to
a post under "algorithms".
Posted on 2001-08-28 12:25:55 by f0dder