proc Find               textBuffer,queryBuffer,resultBuffer    

basic "proc" with a "ret" in it is stdcall anyways.

;stdcall-calling convention is the default, other one that
;fasm macros support is cdecl-calling convention
proc StdCallProc uses esi edi ebx, params
;do something and return result in eax
;of course you can leave esi, edi or ebx out of 'uses *' if you dont use of them...
ret
endp    

you still have to preserve right registers,

Code:

proc StdCallProc uses esi edi ebx, params    

RedGhost wrote:

basic "proc" with a "ret" in it is stdcall anyways.

wrong, you still have to preserve right registers,

Code:

;stdcall-calling convention is the default, other one that
;fasm macros support is cdecl-calling convention
proc StdCallProc uses esi edi ebx, params
;do something and return result in eax
;of course you can leave esi, edi or ebx out of 'uses *' if you dont use of them...
ret
endp    

Actually, register preserving *is* part of stdcall.

The stdcall[3] calling convention is the de facto standard calling convention for the Microsoft Windows NT application programming interface. Function parameters are passed right-to-left. Registers EAX, ECX, and EDX are preserved for use within the function. Return values are stored in the EAX register. Unlike cdecl, the called function cleans the stack, instead of the calling function. Because of this fact, stdcall functions cannot support variable-length argument lists.

UCM wrote:

Actually, register preserving *is* part of stdcall.

Quote:

The stdcall[3] calling convention is the de facto standard calling convention for the Microsoft Windows NT application programming interface. Function parameters are passed right-to-left. Registers EAX, ECX, and EDX are preserved for use within the function. Return values are stored in the EAX register. Unlike cdecl, the called function cleans the stack, instead of the calling function. Because of this fact, stdcall functions cannot support variable-length argument lists.

All I see is that there is no promise that ecx, ecx, or edx will be preserved across the call, when infact esi, edi and ebx go unmentioned.

Registers EAX, ECX, and EDX are preserved for use within the function. Return values are stored in the EAX register.

RedGhost wrote:

UCM wrote:

Actually, register preserving *is* part of stdcall.

Quote:

The stdcall[3] calling convention is the de facto standard calling convention for the Microsoft Windows NT application programming interface. Function parameters are passed right-to-left. Registers EAX, ECX, and EDX are preserved for use within the function. Return values are stored in the EAX register. Unlike cdecl, the called function cleans the stack, instead of the calling function. Because of this fact, stdcall functions cannot support variable-length argument lists.

All I see is that there is no promise that ecx, ecx, or edx will be preserved across the call, when infact esi, edi and ebx go unmentioned.

You shouldnt rely on wikipedia that much...

Quote:

Registers EAX, ECX, and EDX are preserved for use within the function. Return values are stored in the EAX register.

clearly means that function CAN(most likely WILL) trash ECX and EDX, and that EAX is used for return value... In other words, EBP, EBX, ESI, and EDI stay untouched, and those facts are part of STDCALL...

oh and I suggest reading http://www.agner.org/optimize/calling_conventions.pdf
especially part "6. Register Usage", it has an table that shows ebx, esi, edi, and ebp are 'callee-saves' registers in win32/linux/bsd/mac stdcall...

..I've done enough reversing in my time to know that from HLL generation push ebx or push esi followed by a pop before return is something you rarely see (: Infact most winapi don't even do this.