Why use CDECL? / Figuring DLL API calls!

[Mark Alexander Bertenshaw]

Hi -

I have been recently been trying to call functions in a DLL, and all the
functions are CDECL. This can only be done in VB with Matt Curland's book.
But why declare them like this in the first place? Do you gain advantages,
such as allowing optional parameters, or something?

Also, can somebody tell me how to go about figuring out parameters for unpublished
API calls? Does this require a debugger? And if so, can somebody give me
pointers about how I would go about doing this? Please take into account
that my assembly experience is limited to 8086, and even then it is a bit
sketchy.

Thanks a lot

--
Mark Alexander Bertenshaw
Programner/Analyst
Chordiant Software, Inc.
Brentford
UK

[Willy Van den Driessche]

CDECl is the standard way C and C++ functions get called. If you program in
C or C++, this is the natural way to go. (It has something to do with the
order the parameters are put on the call stack)
As far as unplished API calls go, I am pretty sure that there is no simple
way to find out what the prameters are. The hard-core guys typically take a
disassembler to have a look at that code to figure out where the arguments
come from. It can take even them much time to figure out even one
undocumented function.
"Mark Alexander Bertenshaw" <mark.bertenshaw@virgin.net> wrote in message
news:3affd051$1@news.devx.com...
>
> Hi -
>
> I have been recently been trying to call functions in a DLL, and all the
> functions are CDECL. This can only be done in VB with Matt Curland's
book.
> But why declare them like this in the first place? Do you gain
advantages,
> such as allowing optional parameters, or something?
>
> Also, can somebody tell me how to go about figuring out parameters for
unpublished
> API calls? Does this require a debugger? And if so, can somebody give me
> pointers about how I would go about doing this? Please take into account
> that my assembly experience is limited to 8086, and even then it is a bit
> sketchy.
>
> Thanks a lot
>
> --
> Mark Alexander Bertenshaw
> Programner/Analyst
> Chordiant Software, Inc.
> Brentford
> UK

[Willy Van den Driessche]

CDECl is the standard way C and C++ functions get called. If you program in
C or C++, this is the natural way to go. (It has something to do with the
order the parameters are put on the call stack)
As far as unplished API calls go, I am pretty sure that there is no simple
way to find out what the prameters are. The hard-core guys typically take a
disassembler to have a look at that code to figure out where the arguments
come from. It can take even them much time to figure out even one
undocumented function.
"Mark Alexander Bertenshaw" <mark.bertenshaw@virgin.net> wrote in message
news:3affd051$1@news.devx.com...
>
> Hi -
>
> I have been recently been trying to call functions in a DLL, and all the
> functions are CDECL. This can only be done in VB with Matt Curland's
book.
> But why declare them like this in the first place? Do you gain
advantages,
> such as allowing optional parameters, or something?
>
> Also, can somebody tell me how to go about figuring out parameters for
unpublished
> API calls? Does this require a debugger? And if so, can somebody give me
> pointers about how I would go about doing this? Please take into account
> that my assembly experience is limited to 8086, and even then it is a bit
> sketchy.
>
> Thanks a lot
>
> --
> Mark Alexander Bertenshaw
> Programner/Analyst
> Chordiant Software, Inc.
> Brentford
> UK

[Jonathan Wood]

CDECL allows for a variable number of arguments so functions like wsprintf
still use uses it.

--
Jonathan Wood
SoftCircuits Programming
http://www.softcircuits.com
"Mark Alexander Bertenshaw" <mark.bertenshaw@virgin.net> wrote in message
news:3affd051$1@news.devx.com...
>
> Hi -
>
> I have been recently been trying to call functions in a DLL, and all the
> functions are CDECL. This can only be done in VB with Matt Curland's
book.
> But why declare them like this in the first place? Do you gain
advantages,
> such as allowing optional parameters, or something?
>
> Also, can somebody tell me how to go about figuring out parameters for
unpublished
> API calls? Does this require a debugger? And if so, can somebody give me
> pointers about how I would go about doing this? Please take into account
> that my assembly experience is limited to 8086, and even then it is a bit
> sketchy.
>
> Thanks a lot
>
> --
> Mark Alexander Bertenshaw
> Programner/Analyst
> Chordiant Software, Inc.
> Brentford
> UK

[Jonathan Wood]

CDECL allows for a variable number of arguments so functions like wsprintf
still use uses it.

--
Jonathan Wood
SoftCircuits Programming
http://www.softcircuits.com
"Mark Alexander Bertenshaw" <mark.bertenshaw@virgin.net> wrote in message
news:3affd051$1@news.devx.com...
>
> Hi -
>
> I have been recently been trying to call functions in a DLL, and all the
> functions are CDECL. This can only be done in VB with Matt Curland's
book.
> But why declare them like this in the first place? Do you gain
advantages,
> such as allowing optional parameters, or something?
>
> Also, can somebody tell me how to go about figuring out parameters for
unpublished
> API calls? Does this require a debugger? And if so, can somebody give me
> pointers about how I would go about doing this? Please take into account
> that my assembly experience is limited to 8086, and even then it is a bit
> sketchy.
>
> Thanks a lot
>
> --
> Mark Alexander Bertenshaw
> Programner/Analyst
> Chordiant Software, Inc.
> Brentford
> UK

[Matthew Curland]

For unpublished API calls, you absolutely need a debugger. There are two
keys to this process. The first is the esp register, and the second is the
ret statement at the end of the called function. ret gives you the size of
the parameters being pushed (for _stdcall, no help for _cdecl). ret 4 means
to pop 4 bytes (1 parameter) off the stack when the function returns ret 8
means two parameters, etc. esp gives you the stack pointer. Immediately
after a call statement, you'll generally be sitting at assembly code that
says push esp mov ebp,esp. At this point, put the esp value in the memory
window. The first value (reading top down) will be the instruction
immediately after the call statement, and the following 4 byte values will
be parameter values. You can examine this data to determine type, etc. You
can also look at push statements immediately before the call statement.

After this point, you're pretty much on your own. -Matt

> Also, can somebody tell me how to go about figuring out parameters for
unpublished
> API calls? Does this require a debugger? And if so, can somebody give me
> pointers about how I would go about doing this? Please take into account
> that my assembly experience is limited to 8086, and even then it is a bit
> sketchy.
>
> Thanks a lot

[Matthew Curland]

For unpublished API calls, you absolutely need a debugger. There are two
keys to this process. The first is the esp register, and the second is the
ret statement at the end of the called function. ret gives you the size of
the parameters being pushed (for _stdcall, no help for _cdecl). ret 4 means
to pop 4 bytes (1 parameter) off the stack when the function returns ret 8
means two parameters, etc. esp gives you the stack pointer. Immediately
after a call statement, you'll generally be sitting at assembly code that
says push esp mov ebp,esp. At this point, put the esp value in the memory
window. The first value (reading top down) will be the instruction
immediately after the call statement, and the following 4 byte values will
be parameter values. You can examine this data to determine type, etc. You
can also look at push statements immediately before the call statement.

After this point, you're pretty much on your own. -Matt

> Also, can somebody tell me how to go about figuring out parameters for
unpublished
> API calls? Does this require a debugger? And if so, can somebody give me
> pointers about how I would go about doing this? Please take into account
> that my assembly experience is limited to 8086, and even then it is a bit
> sketchy.
>
> Thanks a lot

[Mark Alexander Bertenshaw]

"Matthew Curland" <mattcur@microsoft.com> wrote:

Matt -

Thanks for the reply.

>For unpublished API calls, you absolutely need a debugger. There are two
>keys to this process. The first is the esp register, and the second is the
>ret statement at the end of the called function. ret gives you the size
of
>the parameters being pushed (for _stdcall, no help for _cdecl).

If the value of ret is no help for _cdecl functions, then what would a C
compiler normally put here? And am I right in saying that the following
sequence is what normally happens in a _stdcall procedure call:

* Push arguments from right to left onto the stack.
* Use the call instruction to execute the procedure.
/ Put the address of the next instruction on the stack.
\ Jump to the procedure address.
* Execute code - your arguments are now offsets from the ESP register.
* Execute the ret instruction - the argument(?) tells you the 32 bit
value this number of bytes away is the address you will return to, so jump
there.
* Pop arguments from the stack. [Couldn't we just decrement ESP directly?]

And what makes _cdecl different?

>ret 4 means
>to pop 4 bytes (1 parameter) off the stack when the function returns ret
8
>means two parameters, etc. esp gives you the stack pointer.

So, you never call pop yourself?

>Immediately
>after a call statement, you'll generally be sitting at assembly code that
>says push esp mov ebp,esp.

I thought that you pushed _before_ executing the call instruction.

>At this point, put the esp value in the memory
>window. The first value (reading top down) will be the instruction
>immediately after the call statement, and the following 4 byte values will
>be parameter values. You can examine this data to determine type, etc. You
>can also look at push statements immediately before the call statement.
>
>After this point, you're pretty much on your own. -Matt

A further question: using Visual Studio, can I set breakpoints in a DLL at
the entry point to one of the functions? In the case I'm looking at, I see
that in the "modules loaded" box, my DLL is listed, but I can't seem to find
it in the box that represents the memory. It doesn't help that my copy of
Win2000 doesn't seem to have installed that neat QuickView utility.

Anyhow, sorry for all the questions, but this is an area I would really like
to understand so that I can fully appreciate the chapter on calling function
pointers. If this is something that is hard to explain, then please give
me a reference to a decent book on this subject.

Thanks,

Mark Alexander Bertenshaw
Programmer/Analyst
Chordiant Software, Inc.
Brentford
UK

[Mark Alexander Bertenshaw]

"Matthew Curland" <mattcur@microsoft.com> wrote:

Matt -

Thanks for the reply.

>For unpublished API calls, you absolutely need a debugger. There are two
>keys to this process. The first is the esp register, and the second is the
>ret statement at the end of the called function. ret gives you the size
of
>the parameters being pushed (for _stdcall, no help for _cdecl).

If the value of ret is no help for _cdecl functions, then what would a C
compiler normally put here? And am I right in saying that the following
sequence is what normally happens in a _stdcall procedure call:

* Push arguments from right to left onto the stack.
* Use the call instruction to execute the procedure.
/ Put the address of the next instruction on the stack.
\ Jump to the procedure address.
* Execute code - your arguments are now offsets from the ESP register.
* Execute the ret instruction - the argument(?) tells you the 32 bit
value this number of bytes away is the address you will return to, so jump
there.
* Pop arguments from the stack. [Couldn't we just decrement ESP directly?]

And what makes _cdecl different?

>ret 4 means
>to pop 4 bytes (1 parameter) off the stack when the function returns ret
8
>means two parameters, etc. esp gives you the stack pointer.

So, you never call pop yourself?

>Immediately
>after a call statement, you'll generally be sitting at assembly code that
>says push esp mov ebp,esp.

I thought that you pushed _before_ executing the call instruction.

>At this point, put the esp value in the memory
>window. The first value (reading top down) will be the instruction
>immediately after the call statement, and the following 4 byte values will
>be parameter values. You can examine this data to determine type, etc. You
>can also look at push statements immediately before the call statement.
>
>After this point, you're pretty much on your own. -Matt

A further question: using Visual Studio, can I set breakpoints in a DLL at
the entry point to one of the functions? In the case I'm looking at, I see
that in the "modules loaded" box, my DLL is listed, but I can't seem to find
it in the box that represents the memory. It doesn't help that my copy of
Win2000 doesn't seem to have installed that neat QuickView utility.

Anyhow, sorry for all the questions, but this is an area I would really like
to understand so that I can fully appreciate the chapter on calling function
pointers. If this is something that is hard to explain, then please give
me a reference to a decent book on this subject.

Thanks,

Mark Alexander Bertenshaw
Programmer/Analyst
Chordiant Software, Inc.
Brentford
UK

[Jonathan Wood]

Mark,

> If the value of ret is no help for _cdecl functions, then what would a C
> compiler normally put here?

CDECL functions do not restore the stack on return so a C compiler would
just put a ret instruction here. With the CDECL convention, it is up to the
caller to restore the stack.

> And am I right in saying that the following
> sequence is what normally happens in a _stdcall procedure call:

> * Push arguments from right to left onto the stack.
> * Use the call instruction to execute the procedure.
> / Put the address of the next instruction on the stack.
> \ Jump to the procedure address.
> * Execute code - your arguments are now offsets from the ESP register.
> * Execute the ret instruction - the argument(?) tells you the 32 bit
> value this number of bytes away is the address you will return to, so jump
> there.

Right.

> * Pop arguments from the stack. [Couldn't we just decrement ESP directly?]

That's what ret n does.

> And what makes _cdecl different?

The stack is retored by the caller. This is how a function can take a
variable number of arguments, as I stated in another post.

> >Immediately
> >after a call statement, you'll generally be sitting at assembly code that
> >says push esp mov ebp,esp.
>
> I thought that you pushed _before_ executing the call instruction.

You push the argument values and return address before the call.

> A further question: using Visual Studio, can I set breakpoints in a DLL at
> the entry point to one of the functions? In the case I'm looking at, I
see
> that in the "modules loaded" box, my DLL is listed, but I can't seem to
find
> it in the box that represents the memory. It doesn't help that my copy of
> Win2000 doesn't seem to have installed that neat QuickView utility.

The easiest way I know of is to step into the call.

--
Jonathan Wood
SoftCircuits Programming
http://www.softcircuits.com

[Jonathan Wood]

Mark,

> If the value of ret is no help for _cdecl functions, then what would a C
> compiler normally put here?

CDECL functions do not restore the stack on return so a C compiler would
just put a ret instruction here. With the CDECL convention, it is up to the
caller to restore the stack.

> And am I right in saying that the following
> sequence is what normally happens in a _stdcall procedure call:

> * Push arguments from right to left onto the stack.
> * Use the call instruction to execute the procedure.
> / Put the address of the next instruction on the stack.
> \ Jump to the procedure address.
> * Execute code - your arguments are now offsets from the ESP register.
> * Execute the ret instruction - the argument(?) tells you the 32 bit
> value this number of bytes away is the address you will return to, so jump
> there.

Right.

> * Pop arguments from the stack. [Couldn't we just decrement ESP directly?]

That's what ret n does.

> And what makes _cdecl different?

The stack is retored by the caller. This is how a function can take a
variable number of arguments, as I stated in another post.

> >Immediately
> >after a call statement, you'll generally be sitting at assembly code that
> >says push esp mov ebp,esp.
>
> I thought that you pushed _before_ executing the call instruction.

You push the argument values and return address before the call.

> A further question: using Visual Studio, can I set breakpoints in a DLL at
> the entry point to one of the functions? In the case I'm looking at, I
see
> that in the "modules loaded" box, my DLL is listed, but I can't seem to
find
> it in the box that represents the memory. It doesn't help that my copy of
> Win2000 doesn't seem to have installed that neat QuickView utility.

The easiest way I know of is to step into the call.

--
Jonathan Wood
SoftCircuits Programming
http://www.softcircuits.com

[Mark Alexander Bertenshaw]

"Jonathan Wood" <jwood@softcircuits.com> wrote in message
news:3b017125@news.devx.com...

Jonathan -

Thanks for the reply. Just a couple of points:

> CDECL functions do not restore the stack on return so a C compiler would
> just put a ret instruction here.

Is this "ret" instruction effectively ret 00 ?


> > A further question: using Visual Studio, can I set breakpoints in a DLL
at
> > the entry point to one of the functions? In the case I'm looking at, I
> see
> > that in the "modules loaded" box, my DLL is listed, but I can't seem to
> find
> > it in the box that represents the memory. It doesn't help that my copy
of
> > Win2000 doesn't seem to have installed that neat QuickView utility.
>
> The easiest way I know of is to step into the call.

Hmm. Tricky, this one, since I am currently attaching the debugger to
Outlook Express, and pressing the Check Spelling button. I haven't worked
out how to start tracing straight after pressing the button

>
> --
> Jonathan Wood
> SoftCircuits Programming
> http://www.softcircuits.com
>
>
>

[Mark Alexander Bertenshaw]

"Jonathan Wood" <jwood@softcircuits.com> wrote in message
news:3b017125@news.devx.com...

Jonathan -

Thanks for the reply. Just a couple of points:

> CDECL functions do not restore the stack on return so a C compiler would
> just put a ret instruction here.

Is this "ret" instruction effectively ret 00 ?


> > A further question: using Visual Studio, can I set breakpoints in a DLL
at
> > the entry point to one of the functions? In the case I'm looking at, I
> see
> > that in the "modules loaded" box, my DLL is listed, but I can't seem to
> find
> > it in the box that represents the memory. It doesn't help that my copy
of
> > Win2000 doesn't seem to have installed that neat QuickView utility.
>
> The easiest way I know of is to step into the call.

Hmm. Tricky, this one, since I am currently attaching the debugger to
Outlook Express, and pressing the Check Spelling button. I haven't worked
out how to start tracing straight after pressing the button

>
> --
> Jonathan Wood
> SoftCircuits Programming
> http://www.softcircuits.com
>
>
>

[Jonathan Wood]

Mark Alexander Bertenshaw,

> Is this "ret" instruction effectively ret 00 ?

Yes.

> Hmm. Tricky, this one, since I am currently attaching the debugger to
> Outlook Express, and pressing the Check Spelling button. I haven't worked
> out how to start tracing straight after pressing the button

Yeah, that is tricky. I don't have an answer for you. I know there is a
table in the DLL that indicates how to access each exported symbol but I
don't know off the top of my head how to extract that information in a
debugger.

--
Jonathan Wood
SoftCircuits Programming
http://www.softcircuits.com

[Jonathan Wood]

Mark Alexander Bertenshaw,

> Is this "ret" instruction effectively ret 00 ?

Yes.

> Hmm. Tricky, this one, since I am currently attaching the debugger to
> Outlook Express, and pressing the Check Spelling button. I haven't worked
> out how to start tracing straight after pressing the button

Yeah, that is tricky. I don't have an answer for you. I know there is a
table in the DLL that indicates how to access each exported symbol but I
don't know off the top of my head how to extract that information in a
debugger.

--
Jonathan Wood
SoftCircuits Programming
http://www.softcircuits.com