I had a little code in one of my programs. It was a .WHILE loop that looped until ecx == 16. It pushed ecx, called wsprintf, set the selection in a rich edit box, replaced that selection, poped ecx, and incremented ecx. Well, for some reason it didn't work, so I used WinDbg to debug it. I found out that after the wsprintf, masm added "add esp, 0Ch" to adjust the stack. After the two SendMessage APIs for the rich edit, it was time to pop ecx, yet esp was pointing two bytes away from where ecx was pushed on the stack, with the result that the entire ecx counter idea was blown to pieces. This makes me wonder how trustworthy masm really is. ????
Hi wsprintf is the ONLY one C/C++ like function in WinAPI (all the rest are STDCALL aka reverse order Pascal like) Because of this YOU have to keep track of the stack for it ... wsprintf can take unknown number of parameters...so it can not know how to balance the stack at the end...this is the way C/C++ works...sorry... :) (Pascal is Better, ASM rocks ) Bogdan
Your question is kindda "Is there Life on Mars?" If you want make your prog work, please, send the code. You are using C like func. not stdcall Problems with stack are highly dependable on your whole algo and if it is a part of some callback procedure. As to MASM usage you can always disassemble code and look for sure if it is the code you exepcted to be done from your source. Good luck with debuggers. The Svin.
Hel: I have never had a problem with such things before. I did something similar to your description. MASM keeps track of the stack automatically for you in case of wsprintf IF and ONLY IF you use the prototype of wsprintf. And it's much more reliable than keeping track of the stack yourself. If you can paste your loop here, we can discuss it more
yes i think there may be a bug/conflict between masm and wsprint. Because masm seems to have a tendacy to assume all arguments passed to a function are 32 bits (if you are in a 32 bit segment). If you try to pass 2 DWORD's and 1 WORD as parameters to wspintf, masm might get it wrong and that will be where the add esp,0ch comes from, 3*4=0ch. This means you will probably have to manualy clean up the stack, or convert your no DWORD arg to 32 bits.
Manual stack coding is very error prone, MASM has a way to avoid these mistakes, use a prototype and the invoke syntax, end of problem. wsprintfA PROTO C :DWORD,:VARARG wsprintf equ
The other option is that wsprintf is modifying ECX, windows convention is to preserve EBX ESI & EDI but EAX, ECX & EDX can be freely modified, try using a memory operand as a counter to see if this is the problem.
This message was edited by hutch--, on 1/28/2001 7:49:36 AM