Board index » off-topic » Defining a dll-function as a C -type call (needing stack-cleanup afterwards)

Defining a dll-function as a C -type call (needing stack-cleanup afterwards)


2003-10-21 11:19:12 PM
off-topic17
Hello All,
I'm in the habit of using Pascal (?) -type function-calls, where the
stack-cleanup of the arguments is done by the called function.
Now I'm trying-out a few functions outof a C-oriented library (fopen and the
like), that expects the calling program to cleanup the stack. I was
wondering if I could shift the task of adding this cleanup to the
assembler/linker.
Is it possible to do so, and how should I define such an external function
outof a C-type DLL so tasm/tlink will only try to add stack-cleanup to
those, and not to the other, "normal", function-call's.
Currently I'm using "extrn {dll-function name}:proc".
Oh, I'm using Tasm32/TLink32 for the task.
Regards,
Rudy Wieser
 
 

Re:Defining a dll-function as a C -type call (needing stack-cleanup afterwards)

Quote
Is it possible to do so, and how should I define such an external function
outof a C-type DLL so tasm/tlink will only try to add stack-cleanup to
those, and not to the other, "normal", function-call's.
When you call such C functions, you can write like this
call YourFun C, param1, param2, etc
Use the 'C' calling conversion, and put all parameters in one line,
then TASM will generate the stack cleanup code for you(add esp, xxxx).
*****Pardon my poor English*****
---------------------
My TASM homepage, resource for assembly. Tools, articles, links.
komsbomb.ols-lab.com
 

Re:Defining a dll-function as a C -type call (needing stack-cleanup afterwards)

Koms Bomb < XXXX@XXXXX.COM >schreef in berichtnieuws
XXXX@XXXXX.COM ...
Hello Koms,
Quote
>Is it possible to do so, and how should I define such an external
function
>outof a C-type DLL so tasm/tlink will only try to add stack-cleanup to
>those, and not to the other, "normal", function-call's.

When you call such C functions, you can write like this

call YourFun C, param1, param2, etc
And I was thinking that I it was something I had to add to the "extrn
{function}:proc" -line. I don't think I would have found the above answer
... Thanks.
Quote
Use the 'C' calling conversion, and put all parameters in one line,
then TASM will generate the stack cleanup code for you(add esp, xxxx).
I did allready realize that the assembler/linker would only be capable to
finding the number of arguments to a C-call (and thus calculate the correct
clean-up value) when they where on the same line as the call, but
nevertheless thanks for the warning :-)
Regards,
Rudy Wieser
 

{smallsort}

Re:Defining a dll-function as a C -type call (needing stack-cleanup afterwards)

this is an extract from tasm docs:
Ideal and MASM mode: PROC [language modifier][language] name [distance]
[USES items,] [argument [,argument]...]
[RETURNS argument [,argument]...]
MASM mode: name PROC [language modifier] [language] [distance] [USES
items,] [argument [,argument]...]
[RETURNS argument [,argument]...]
Defines the start of procedure name. language modifier is either WINDOWS or
NOWINDOWS, to specify generation of MSWindows entry/exit code. language
specifies which language you will be calling from to access this procedure:
C, PASCAL, BASIC, FORTRAN, ASSEMBLER, or PROLOG. This determines symbol
naming conventions, the order of any arguments on the stack, and whether the
arguments will be left on the stack when the procedure returns. distance is
NEAR or FAR and determines the type of RET instruction that will be
assembled at the end of the procedure. items is a list of registers and/or
single-token data items to be pushed on entry and popped on exit from the
procedure. argument describes an argument the procedure is called with. Each
argument has the following syntax:
argname [[count1]][[:distance][PTR]type][:count2]
argname is the name you'll use to refer to this argument throughout the
procedure. distance is NEAR or FAR to indicate that the argument is a
pointer of the indicated size. type is the data type of the argument and can
be BYTE, WORD, DWORD, FWORD, PWORD, QWORD, TBYTE, or a structure name. WORD
is assumed if none is specified. count1 and count2 are the number of
elements of type. PTR tells Turbo Assembler to emit debug information to let
Turbo De{*word*81} know that the argument is a pointer to a data item. Using PTR
without distance causes the pointer size to be based on the current memory
model and segment address size. RETURNS introduces one or more arguments
that won't be popped from the stack when the procedure returns.