Re: ver 4.0 c_func problem on WIN98 Here Is proof of the problem !
- Posted by bernie Apr 22, 2009
- 1213 views
This is wrong.
You call
tok = c_func(rid, {b,d})
So we need to know the correct calling convention to pass the arguments (b and d) onto the stack to the machine code, and then we need to know the convention again to obtain the correct return value.
Thus, for the call to rid to be successful, the calling convention is important. You can't just assume that c_func() will magically know the right thing to do.
However,
1. The default calling convetion on Windows is STDCALL (and '+' means CDECL). 2. Your machine code appears to be using STDCALL, if i understand the assembly languge correctly.
Therefore, this example should have worked on w98.
What I meant is I know when I am calling windows code or my code so I have control over cleaning stack when its neccesary.
The only difference between CDECL and STDCALL is:
- CDECL
- CDECL calling convention the following holds:
- Arguments are passed on the stack in Right-to-Left order, and return values are passed in eax.
- The calling function cleans the stack. This allows CDECL functions to have variable-length argument lists (aka variadic functions). For this reason the number of arguments is not appended to the name of the function by the compiler, and the assembler and the linker are therefore unable to determine if an incorrect number of arguments is used.
- STDCALL
- STDCALL passes arguments right-to-left, and returns the value in eax. (The Microsoft documentation erroneously claims that arguments are passed left-to-right, but this is not the case.)
- The called function cleans the stack, unlike CDECL. This means that STDCALL doesn't allow variable-length argument lists.
These are quotes from this web page: http://en.wikibooks.org/wiki/X86_Disassembly/Calling_Convention_Examples
