DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Page 1 of 2 12 LastLast
Results 1 to 15 of 21

Thread: Why use CDECL? / Figuring DLL API calls!

  1. #1
    Mark Alexander Bertenshaw Guest

    Why use CDECL? / Figuring DLL API calls!


    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

  2. #2
    Willy Van den Driessche Guest

    Re: Why use CDECL? / Figuring DLL API calls!

    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




  3. #3
    Willy Van den Driessche Guest

    Re: Why use CDECL? / Figuring DLL API calls!

    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




  4. #4
    Jonathan Wood Guest

    Re: Why use CDECL? / Figuring DLL API calls!

    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




  5. #5
    Jonathan Wood Guest

    Re: Why use CDECL? / Figuring DLL API calls!

    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




  6. #6
    Matthew Curland Guest

    Re: Why use CDECL? / Figuring DLL API calls!

    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





  7. #7
    Matthew Curland Guest

    Re: Why use CDECL? / Figuring DLL API calls!

    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





  8. #8
    Mark Alexander Bertenshaw Guest

    Re: Why use CDECL? / Figuring DLL API calls!


    "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

  9. #9
    Mark Alexander Bertenshaw Guest

    Re: Why use CDECL? / Figuring DLL API calls!


    "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

  10. #10
    Jonathan Wood Guest

    Re: Why use CDECL? / Figuring DLL API calls!

    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




  11. #11
    Jonathan Wood Guest

    Re: Why use CDECL? / Figuring DLL API calls!

    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




  12. #12
    Mark Alexander Bertenshaw Guest

    Re: Why use CDECL? / Figuring DLL API calls!


    "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
    >
    >
    >




  13. #13
    Mark Alexander Bertenshaw Guest

    Re: Why use CDECL? / Figuring DLL API calls!


    "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
    >
    >
    >




  14. #14
    Jonathan Wood Guest

    Re: Why use CDECL? / Figuring DLL API calls!

    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



  15. #15
    Jonathan Wood Guest

    Re: Why use CDECL? / Figuring DLL API calls!

    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



Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
HTML5 Development Center
 
 
FAQ
Latest Articles
Java
.NET
XML
Database
Enterprise
Questions? Contact us.
C++
Web Development
Wireless
Latest Tips
Open Source


   Development Centers

   -- Android Development Center
   -- Cloud Development Project Center
   -- HTML5 Development Center
   -- Windows Mobile Development Center