Call C functions in a DLL without sdtcall convention


DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

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

Thread: Call C functions in a DLL without sdtcall convention

  1. #1
    PV Guest

    Call C functions in a DLL without sdtcall convention


    Hello.

    I need call functions in a C DLL, but that functions are declaredwith cdecl
    calling convention instead stdcall. Do you know how bypass this problem?
    Could a Type library (created with MIDL.EXE) allow a Visual Basic application
    call functions in the DLL although the cdecl declaration?

    Thank you for read this.
    Sincerely,

    P.V.


  2. #2
    Mark Alexander Bertenshaw Guest

    Re: Call C functions in a DLL without sdtcall convention


    "PV" <pomeloverde@hotmail.com> wrote in message
    news:3b05bce7$1@news.devx.com...
    >
    > Hello.
    >
    > I need call functions in a C DLL, but that functions are declaredwith

    cdecl
    > calling convention instead stdcall. Do you know how bypass this problem?
    > Could a Type library (created with MIDL.EXE) allow a Visual Basic

    application
    > call functions in the DLL although the cdecl declaration?
    >
    > Thank you for read this.
    > Sincerely,
    >
    > P.V.


    "P.V." -

    Unfortunately, you are unable to call CDECL functions at all, even using
    type libraries. However, you _can_ do it using code from the "Advanced
    Visual Basic 6" book by Matthew Curland. I have managed to use it to call
    one function from mssp232.dll, but I've yet to be able to call the other
    functions without a crash. Then again, I don't know what other CDECL
    functions there are that I can call to get more experience with all this
    stuff.

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




  3. #3
    Mark Alexander Bertenshaw Guest

    Re: Call C functions in a DLL without sdtcall convention


    "PV" <pomeloverde@hotmail.com> wrote in message
    news:3b05bce7$1@news.devx.com...
    >
    > Hello.
    >
    > I need call functions in a C DLL, but that functions are declaredwith

    cdecl
    > calling convention instead stdcall. Do you know how bypass this problem?
    > Could a Type library (created with MIDL.EXE) allow a Visual Basic

    application
    > call functions in the DLL although the cdecl declaration?
    >
    > Thank you for read this.
    > Sincerely,
    >
    > P.V.


    "P.V." -

    Unfortunately, you are unable to call CDECL functions at all, even using
    type libraries. However, you _can_ do it using code from the "Advanced
    Visual Basic 6" book by Matthew Curland. I have managed to use it to call
    one function from mssp232.dll, but I've yet to be able to call the other
    functions without a crash. Then again, I don't know what other CDECL
    functions there are that I can call to get more experience with all this
    stuff.

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




  4. #4
    PV Guest

    Re: Call C functions in a DLL without sdtcall convention


    Please, Mark, Would do you like to tell me more about that "code" (you wrote
    "However, you _can_ do it using code from ..."? Are that part in the MSDN
    (I have found only "Inside Visual Basic 5" book)?

    Actually I'am doing a second DLL in C that wraps the first one, exporting
    functions with _stdcall that call to the original _cdecl functions, but I
    don't like to depend on this deflection.

    Thanks you very very much.
    Sincerely,
    P.V.

    "Mark Alexander Bertenshaw" <mark.bertenshaw@virgin.net> wrote:
    >
    >"PV" <pomeloverde@hotmail.com> wrote in message
    >news:3b05bce7$1@news.devx.com...
    >>
    >> Hello.
    >>
    >> I need call functions in a C DLL, but that functions are declaredwith

    >cdecl
    >> calling convention instead stdcall. Do you know how bypass this problem?
    >> Could a Type library (created with MIDL.EXE) allow a Visual Basic

    >application
    >> call functions in the DLL although the cdecl declaration?
    >>
    >> Thank you for read this.
    >> Sincerely,
    >>
    >> P.V.

    >
    >"P.V." -
    >
    >Unfortunately, you are unable to call CDECL functions at all, even using
    >type libraries. However, you _can_ do it using code from the "Advanced
    >Visual Basic 6" book by Matthew Curland. I have managed to use it to call
    >one function from mssp232.dll, but I've yet to be able to call the other
    >functions without a crash. Then again, I don't know what other CDECL
    >functions there are that I can call to get more experience with all this
    >stuff.
    >
    >--
    >Mark Alexander Bertenshaw
    >Programer/Analyst
    >Chordiant Software, Inc.
    >Brentford
    >UK
    >
    >
    >



  5. #5
    PV Guest

    Re: Call C functions in a DLL without sdtcall convention


    Please, Mark, Would do you like to tell me more about that "code" (you wrote
    "However, you _can_ do it using code from ..."? Are that part in the MSDN
    (I have found only "Inside Visual Basic 5" book)?

    Actually I'am doing a second DLL in C that wraps the first one, exporting
    functions with _stdcall that call to the original _cdecl functions, but I
    don't like to depend on this deflection.

    Thanks you very very much.
    Sincerely,
    P.V.

    "Mark Alexander Bertenshaw" <mark.bertenshaw@virgin.net> wrote:
    >
    >"PV" <pomeloverde@hotmail.com> wrote in message
    >news:3b05bce7$1@news.devx.com...
    >>
    >> Hello.
    >>
    >> I need call functions in a C DLL, but that functions are declaredwith

    >cdecl
    >> calling convention instead stdcall. Do you know how bypass this problem?
    >> Could a Type library (created with MIDL.EXE) allow a Visual Basic

    >application
    >> call functions in the DLL although the cdecl declaration?
    >>
    >> Thank you for read this.
    >> Sincerely,
    >>
    >> P.V.

    >
    >"P.V." -
    >
    >Unfortunately, you are unable to call CDECL functions at all, even using
    >type libraries. However, you _can_ do it using code from the "Advanced
    >Visual Basic 6" book by Matthew Curland. I have managed to use it to call
    >one function from mssp232.dll, but I've yet to be able to call the other
    >functions without a crash. Then again, I don't know what other CDECL
    >functions there are that I can call to get more experience with all this
    >stuff.
    >
    >--
    >Mark Alexander Bertenshaw
    >Programer/Analyst
    >Chordiant Software, Inc.
    >Brentford
    >UK
    >
    >
    >



  6. #6
    Mark Alexander Bertenshaw Guest

    Re: Call C functions in a DLL without sdtcall convention

    > "Mark Alexander Bertenshaw" <mark.bertenshaw@virgin.net> wrote:
    > >
    > >"PV" <pomeloverde@hotmail.com> wrote in message
    > >news:3b05bce7$1@news.devx.com...
    > >>
    > >> Hello.
    > >>
    > >> I need call functions in a C DLL, but that functions are declaredwith

    > >cdecl
    > >> calling convention instead stdcall. Do you know how bypass this

    problem?
    > >> Could a Type library (created with MIDL.EXE) allow a Visual Basic

    > >application
    > >> call functions in the DLL although the cdecl declaration?
    > >>
    > >> Thank you for read this.
    > >> Sincerely,
    > >>
    > >> P.V.

    > >
    > >"P.V." -
    > >
    > >Unfortunately, you are unable to call CDECL functions at all, even using
    > >type libraries. However, you _can_ do it using code from the "Advanced
    > >Visual Basic 6" book by Matthew Curland. I have managed to use it to

    call
    > >one function from mssp232.dll, but I've yet to be able to call the other
    > >functions without a crash. Then again, I don't know what other CDECL
    > >functions there are that I can call to get more experience with all this
    > >stuff.
    > >
    > >--
    > >Mark Alexander Bertenshaw
    > >Programer/Analyst
    > >Chordiant Software, Inc.
    > >Brentford
    > >UK


    "PV" <pomeloverde@hotmail.com> wrote in message
    news:3b0775b2$1@news.devx.com...
    >
    > Please, Mark, Would do you like to tell me more about that "code" (you

    wrote
    > "However, you _can_ do it using code from ..."? Are that part in the MSDN
    > (I have found only "Inside Visual Basic 5" book)?
    >
    > Actually I'am doing a second DLL in C that wraps the first one, exporting
    > functions with _stdcall that call to the original _cdecl functions, but I
    > don't like to depend on this deflection.
    >
    > Thanks you very very much.
    > Sincerely,
    > P.V.


    "P.V." -

    If you are asking me whether I got the code from MSDN, then no, I got it
    from the book "Advanced Visual Basic 6" by Matthew Curland, not "The
    Mandelbrot Set" - easy mistake to make. The content is pretty interesting,
    and like Desaware's components, enables you to do extend the VB language,
    rather than doing application domain stuff. The difference is that the book
    is cheaper, and has all the source code - in Visual Basic.

    One concept that Curland introduces is "Function Delegators", which allow
    you to call function pointers from Visual Basic. You can use this to use
    LoadLibrary and GetProcAddress to call functions in a DLL. Whilst you can
    do this in VB using Declare statements or Type Libraries, in neither case
    can you control when the DLL gets unloaded. The book first of all tells you
    how to call STDCALL functions, and then explains CDECL functions. The code
    is a mixture of a stand-alone DLL and a whole series of BAS files, which you
    add to each project that needs them. There is also an option of removing
    the dependency of the DLL, and instead compiling all the code into your VB
    code.

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



  7. #7
    Mark Alexander Bertenshaw Guest

    Re: Call C functions in a DLL without sdtcall convention

    > "Mark Alexander Bertenshaw" <mark.bertenshaw@virgin.net> wrote:
    > >
    > >"PV" <pomeloverde@hotmail.com> wrote in message
    > >news:3b05bce7$1@news.devx.com...
    > >>
    > >> Hello.
    > >>
    > >> I need call functions in a C DLL, but that functions are declaredwith

    > >cdecl
    > >> calling convention instead stdcall. Do you know how bypass this

    problem?
    > >> Could a Type library (created with MIDL.EXE) allow a Visual Basic

    > >application
    > >> call functions in the DLL although the cdecl declaration?
    > >>
    > >> Thank you for read this.
    > >> Sincerely,
    > >>
    > >> P.V.

    > >
    > >"P.V." -
    > >
    > >Unfortunately, you are unable to call CDECL functions at all, even using
    > >type libraries. However, you _can_ do it using code from the "Advanced
    > >Visual Basic 6" book by Matthew Curland. I have managed to use it to

    call
    > >one function from mssp232.dll, but I've yet to be able to call the other
    > >functions without a crash. Then again, I don't know what other CDECL
    > >functions there are that I can call to get more experience with all this
    > >stuff.
    > >
    > >--
    > >Mark Alexander Bertenshaw
    > >Programer/Analyst
    > >Chordiant Software, Inc.
    > >Brentford
    > >UK


    "PV" <pomeloverde@hotmail.com> wrote in message
    news:3b0775b2$1@news.devx.com...
    >
    > Please, Mark, Would do you like to tell me more about that "code" (you

    wrote
    > "However, you _can_ do it using code from ..."? Are that part in the MSDN
    > (I have found only "Inside Visual Basic 5" book)?
    >
    > Actually I'am doing a second DLL in C that wraps the first one, exporting
    > functions with _stdcall that call to the original _cdecl functions, but I
    > don't like to depend on this deflection.
    >
    > Thanks you very very much.
    > Sincerely,
    > P.V.


    "P.V." -

    If you are asking me whether I got the code from MSDN, then no, I got it
    from the book "Advanced Visual Basic 6" by Matthew Curland, not "The
    Mandelbrot Set" - easy mistake to make. The content is pretty interesting,
    and like Desaware's components, enables you to do extend the VB language,
    rather than doing application domain stuff. The difference is that the book
    is cheaper, and has all the source code - in Visual Basic.

    One concept that Curland introduces is "Function Delegators", which allow
    you to call function pointers from Visual Basic. You can use this to use
    LoadLibrary and GetProcAddress to call functions in a DLL. Whilst you can
    do this in VB using Declare statements or Type Libraries, in neither case
    can you control when the DLL gets unloaded. The book first of all tells you
    how to call STDCALL functions, and then explains CDECL functions. The code
    is a mixture of a stand-alone DLL and a whole series of BAS files, which you
    add to each project that needs them. There is also an option of removing
    the dependency of the DLL, and instead compiling all the code into your VB
    code.

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



  8. #8
    P.V. Guest

    Re: Call C functions in a DLL without sdtcall convention


    Ok, Thanks very much, Mark.

    I deduce from your reply that the solution suggested by Mattew Curland is
    based on a DLL used to provide the aditional support to VB. I think that
    if it consists in a DLL to call to another DLL then it's easier to do my
    own DLL with stdcall exported functions that call the required cdecl functions.
    This is actually that I are doing.

    Thanks Mark. Your reply has help to me to decide.

    Thanks again.

    Sincerely,
    Frank.

    Note: Perhaps you think that I am refractory to buy a book... It's false.
    The problem are that I write from Spain and if you give me a Book reference
    it's probable that I will have problems to encounter it in my country, specially
    in my town. This is the reason by I searched in MSDN first. This is all.
    Thank you again, Mark.

    "Mark Alexander Bertenshaw" <mark.bertenshaw@virgin.net> wrote:
    >> "Mark Alexander Bertenshaw" <mark.bertenshaw@virgin.net> wrote:
    >> >
    >> >"PV" <pomeloverde@hotmail.com> wrote in message
    >> >news:3b05bce7$1@news.devx.com...
    >> >>
    >> >> Hello.
    >> >>
    >> >> I need call functions in a C DLL, but that functions are declaredwith
    >> >cdecl
    >> >> calling convention instead stdcall. Do you know how bypass this

    >problem?
    >> >> Could a Type library (created with MIDL.EXE) allow a Visual Basic
    >> >application
    >> >> call functions in the DLL although the cdecl declaration?
    >> >>
    >> >> Thank you for read this.
    >> >> Sincerely,
    >> >>
    >> >> P.V.
    >> >
    >> >"P.V." -
    >> >
    >> >Unfortunately, you are unable to call CDECL functions at all, even using
    >> >type libraries. However, you _can_ do it using code from the "Advanced
    >> >Visual Basic 6" book by Matthew Curland. I have managed to use it to

    >call
    >> >one function from mssp232.dll, but I've yet to be able to call the other
    >> >functions without a crash. Then again, I don't know what other CDECL
    >> >functions there are that I can call to get more experience with all this
    >> >stuff.
    >> >
    >> >--
    >> >Mark Alexander Bertenshaw
    >> >Programer/Analyst
    >> >Chordiant Software, Inc.
    >> >Brentford
    >> >UK

    >
    >"PV" <pomeloverde@hotmail.com> wrote in message
    >news:3b0775b2$1@news.devx.com...
    >>
    >> Please, Mark, Would do you like to tell me more about that "code" (you

    >wrote
    >> "However, you _can_ do it using code from ..."? Are that part in the MSDN
    >> (I have found only "Inside Visual Basic 5" book)?
    >>
    >> Actually I'am doing a second DLL in C that wraps the first one, exporting
    >> functions with _stdcall that call to the original _cdecl functions, but

    I
    >> don't like to depend on this deflection.
    >>
    >> Thanks you very very much.
    >> Sincerely,
    >> P.V.

    >
    >"P.V." -
    >
    >If you are asking me whether I got the code from MSDN, then no, I got it
    >from the book "Advanced Visual Basic 6" by Matthew Curland, not "The
    >Mandelbrot Set" - easy mistake to make. The content is pretty interesting,
    >and like Desaware's components, enables you to do extend the VB language,
    >rather than doing application domain stuff. The difference is that the

    book
    >is cheaper, and has all the source code - in Visual Basic.
    >
    >One concept that Curland introduces is "Function Delegators", which allow
    >you to call function pointers from Visual Basic. You can use this to use
    >LoadLibrary and GetProcAddress to call functions in a DLL. Whilst you can
    >do this in VB using Declare statements or Type Libraries, in neither case
    >can you control when the DLL gets unloaded. The book first of all tells

    you
    >how to call STDCALL functions, and then explains CDECL functions. The code
    >is a mixture of a stand-alone DLL and a whole series of BAS files, which

    you
    >add to each project that needs them. There is also an option of removing
    >the dependency of the DLL, and instead compiling all the code into your

    VB
    >code.
    >
    >--
    >Mark Alexander Bertenshaw
    >Programmer/Analyst
    >Chordiant Software, Inc.
    >Brentford
    >UK
    >
    >



  9. #9
    P.V. Guest

    Re: Call C functions in a DLL without sdtcall convention


    Ok, Thanks very much, Mark.

    I deduce from your reply that the solution suggested by Mattew Curland is
    based on a DLL used to provide the aditional support to VB. I think that
    if it consists in a DLL to call to another DLL then it's easier to do my
    own DLL with stdcall exported functions that call the required cdecl functions.
    This is actually that I are doing.

    Thanks Mark. Your reply has help to me to decide.

    Thanks again.

    Sincerely,
    Frank.

    Note: Perhaps you think that I am refractory to buy a book... It's false.
    The problem are that I write from Spain and if you give me a Book reference
    it's probable that I will have problems to encounter it in my country, specially
    in my town. This is the reason by I searched in MSDN first. This is all.
    Thank you again, Mark.

    "Mark Alexander Bertenshaw" <mark.bertenshaw@virgin.net> wrote:
    >> "Mark Alexander Bertenshaw" <mark.bertenshaw@virgin.net> wrote:
    >> >
    >> >"PV" <pomeloverde@hotmail.com> wrote in message
    >> >news:3b05bce7$1@news.devx.com...
    >> >>
    >> >> Hello.
    >> >>
    >> >> I need call functions in a C DLL, but that functions are declaredwith
    >> >cdecl
    >> >> calling convention instead stdcall. Do you know how bypass this

    >problem?
    >> >> Could a Type library (created with MIDL.EXE) allow a Visual Basic
    >> >application
    >> >> call functions in the DLL although the cdecl declaration?
    >> >>
    >> >> Thank you for read this.
    >> >> Sincerely,
    >> >>
    >> >> P.V.
    >> >
    >> >"P.V." -
    >> >
    >> >Unfortunately, you are unable to call CDECL functions at all, even using
    >> >type libraries. However, you _can_ do it using code from the "Advanced
    >> >Visual Basic 6" book by Matthew Curland. I have managed to use it to

    >call
    >> >one function from mssp232.dll, but I've yet to be able to call the other
    >> >functions without a crash. Then again, I don't know what other CDECL
    >> >functions there are that I can call to get more experience with all this
    >> >stuff.
    >> >
    >> >--
    >> >Mark Alexander Bertenshaw
    >> >Programer/Analyst
    >> >Chordiant Software, Inc.
    >> >Brentford
    >> >UK

    >
    >"PV" <pomeloverde@hotmail.com> wrote in message
    >news:3b0775b2$1@news.devx.com...
    >>
    >> Please, Mark, Would do you like to tell me more about that "code" (you

    >wrote
    >> "However, you _can_ do it using code from ..."? Are that part in the MSDN
    >> (I have found only "Inside Visual Basic 5" book)?
    >>
    >> Actually I'am doing a second DLL in C that wraps the first one, exporting
    >> functions with _stdcall that call to the original _cdecl functions, but

    I
    >> don't like to depend on this deflection.
    >>
    >> Thanks you very very much.
    >> Sincerely,
    >> P.V.

    >
    >"P.V." -
    >
    >If you are asking me whether I got the code from MSDN, then no, I got it
    >from the book "Advanced Visual Basic 6" by Matthew Curland, not "The
    >Mandelbrot Set" - easy mistake to make. The content is pretty interesting,
    >and like Desaware's components, enables you to do extend the VB language,
    >rather than doing application domain stuff. The difference is that the

    book
    >is cheaper, and has all the source code - in Visual Basic.
    >
    >One concept that Curland introduces is "Function Delegators", which allow
    >you to call function pointers from Visual Basic. You can use this to use
    >LoadLibrary and GetProcAddress to call functions in a DLL. Whilst you can
    >do this in VB using Declare statements or Type Libraries, in neither case
    >can you control when the DLL gets unloaded. The book first of all tells

    you
    >how to call STDCALL functions, and then explains CDECL functions. The code
    >is a mixture of a stand-alone DLL and a whole series of BAS files, which

    you
    >add to each project that needs them. There is also an option of removing
    >the dependency of the DLL, and instead compiling all the code into your

    VB
    >code.
    >
    >--
    >Mark Alexander Bertenshaw
    >Programmer/Analyst
    >Chordiant Software, Inc.
    >Brentford
    >UK
    >
    >



  10. #10
    Matthew Curland Guest

    Re: Call C functions in a DLL without sdtcall convention

    No, it does not involve another Dll at all. Some of the techniques in the
    book require a set of helper objects that I called VBoost. These objects can
    either be shipped in a precompiled C++ Dll, or compiled into your
    application. I prefer the compiled-in version because it is cleaner, but the
    C++ version is more stable in the VB IDE debugger (toggling them is a
    conditional compilation change, the instability in break mode comes because
    VB summarily blocks AddressOf-generated vtable entries that the debugger is
    trying to use).

    That said, FunctionDelegator and CDECLFunctionDelegator do not require any
    VBoost object support, nor do they require a helper Dll. All you need to do
    is provide a function prototype via a typelib interface (this is trivial
    with the 'PowerVB Type Library Editor' add-in that comes with the book), and
    to give me the correct stack size. I also provide a thunking mechanism to
    let you expose your own AddressOf function pointers as CDECL functions. The
    following code turns a .bas function into a cdecl function and calls it with
    the CDECLFunctionDelegator. This requires VBoostTypes6.olb and
    CDECLFunctionDelegator.bas from the book. For an external Dll, you'd need a
    LoadLibrary/GetProcAddress call to get an initial function pointer (instead
    of AddressOf).

    Sub Main()
    Dim pCall As ICallLongReturnLong 'Provide a function prototype
    Dim Delegator As CDECLFunctionDelegator 'Stack-allocated delegator
    Dim Thunk As CDECLThunk 'Thunk for demo purposes to generate a CDECL
    function pointer
    InitCDECLThunk Thunk, AddressOf CallAsCDECL, 4 '4 = stack size for 1
    long parameter
    Set pCall = InitCDECLDelegator(Delegator, Thunk.pfn, 4)
    MsgBox pCall.Call(10)
    End Sub
    Function CallAsCDECL(ByVal x As Long) As Long
    CallAsCDECL = x
    End Function

    -Matt
    http://www.PowerVB.com (book links, CD Updates)

    > I deduce from your reply that the solution suggested by Mattew Curland is
    > based on a DLL used to provide the aditional support to VB. I think that
    > if it consists in a DLL to call to another DLL then it's easier to do my
    > own DLL with stdcall exported functions that call the required cdecl

    functions.
    > This is actually that I are doing.





  11. #11
    Matthew Curland Guest

    Re: Call C functions in a DLL without sdtcall convention

    No, it does not involve another Dll at all. Some of the techniques in the
    book require a set of helper objects that I called VBoost. These objects can
    either be shipped in a precompiled C++ Dll, or compiled into your
    application. I prefer the compiled-in version because it is cleaner, but the
    C++ version is more stable in the VB IDE debugger (toggling them is a
    conditional compilation change, the instability in break mode comes because
    VB summarily blocks AddressOf-generated vtable entries that the debugger is
    trying to use).

    That said, FunctionDelegator and CDECLFunctionDelegator do not require any
    VBoost object support, nor do they require a helper Dll. All you need to do
    is provide a function prototype via a typelib interface (this is trivial
    with the 'PowerVB Type Library Editor' add-in that comes with the book), and
    to give me the correct stack size. I also provide a thunking mechanism to
    let you expose your own AddressOf function pointers as CDECL functions. The
    following code turns a .bas function into a cdecl function and calls it with
    the CDECLFunctionDelegator. This requires VBoostTypes6.olb and
    CDECLFunctionDelegator.bas from the book. For an external Dll, you'd need a
    LoadLibrary/GetProcAddress call to get an initial function pointer (instead
    of AddressOf).

    Sub Main()
    Dim pCall As ICallLongReturnLong 'Provide a function prototype
    Dim Delegator As CDECLFunctionDelegator 'Stack-allocated delegator
    Dim Thunk As CDECLThunk 'Thunk for demo purposes to generate a CDECL
    function pointer
    InitCDECLThunk Thunk, AddressOf CallAsCDECL, 4 '4 = stack size for 1
    long parameter
    Set pCall = InitCDECLDelegator(Delegator, Thunk.pfn, 4)
    MsgBox pCall.Call(10)
    End Sub
    Function CallAsCDECL(ByVal x As Long) As Long
    CallAsCDECL = x
    End Function

    -Matt
    http://www.PowerVB.com (book links, CD Updates)

    > I deduce from your reply that the solution suggested by Mattew Curland is
    > based on a DLL used to provide the aditional support to VB. I think that
    > if it consists in a DLL to call to another DLL then it's easier to do my
    > own DLL with stdcall exported functions that call the required cdecl

    functions.
    > This is actually that I are doing.





  12. #12
    Mark Alexander Bertenshaw Guest

    Re: Call C functions in a DLL without sdtcall convention


    Matt -

    A couple of questions subsequent to my exploits with the CDECLDelegator:

    "Matthew Curland" <mattcur@microsoft.com> wrote:
    >No, it does not involve another Dll at all. Some of the techniques in the
    >book require a set of helper objects that I called VBoost. These objects

    can
    >either be shipped in a precompiled C++ Dll, or compiled into your
    >application. I prefer the compiled-in version because it is cleaner, but

    the
    >C++ version is more stable in the VB IDE debugger (toggling them is a
    >conditional compilation change, the instability in break mode comes because
    >VB summarily blocks AddressOf-generated vtable entries that the debugger

    is
    >trying to use).


    I take it that the only reason you have made a DLL of for the VBoost objects
    is because of the IDE instability problem? And the other .BAS files do not
    have this problem?

    >That said, FunctionDelegator and CDECLFunctionDelegator do not require any
    >VBoost object support, nor do they require a helper Dll. All you need to

    do
    >is provide a function prototype via a typelib interface (this is trivial
    >with the 'PowerVB Type Library Editor' add-in that comes with the book),

    and
    >to give me the correct stack size.


    I think this is where I have gone wrong with using the CDECLDelegator.

    I tried calling a function with this declaration:

    void (int *,int *, int *);

    ... using a stack value of 4 + 4 + 4 = 12. This worked.

    Then I tried calling this function:

    int (int *, WizSpecCharsType *);

    ... using a stack value of 4 + 4 + 4 = 12. This failed.

    All this is making the assumption that each pointer put onto the stack is
    4 bytes.

    Obviously, I am making a bad assumption somewhere here. *8-)

    >I also provide a thunking mechanism to
    >let you expose your own AddressOf function pointers as CDECL functions.



    Interesting. Does this mean that all BAS functions are in fact CDECL ?
    Does this give us an advantage somewhere?

    Thanks,

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


  13. #13
    Mark Alexander Bertenshaw Guest

    Re: Call C functions in a DLL without sdtcall convention


    Matt -

    A couple of questions subsequent to my exploits with the CDECLDelegator:

    "Matthew Curland" <mattcur@microsoft.com> wrote:
    >No, it does not involve another Dll at all. Some of the techniques in the
    >book require a set of helper objects that I called VBoost. These objects

    can
    >either be shipped in a precompiled C++ Dll, or compiled into your
    >application. I prefer the compiled-in version because it is cleaner, but

    the
    >C++ version is more stable in the VB IDE debugger (toggling them is a
    >conditional compilation change, the instability in break mode comes because
    >VB summarily blocks AddressOf-generated vtable entries that the debugger

    is
    >trying to use).


    I take it that the only reason you have made a DLL of for the VBoost objects
    is because of the IDE instability problem? And the other .BAS files do not
    have this problem?

    >That said, FunctionDelegator and CDECLFunctionDelegator do not require any
    >VBoost object support, nor do they require a helper Dll. All you need to

    do
    >is provide a function prototype via a typelib interface (this is trivial
    >with the 'PowerVB Type Library Editor' add-in that comes with the book),

    and
    >to give me the correct stack size.


    I think this is where I have gone wrong with using the CDECLDelegator.

    I tried calling a function with this declaration:

    void (int *,int *, int *);

    ... using a stack value of 4 + 4 + 4 = 12. This worked.

    Then I tried calling this function:

    int (int *, WizSpecCharsType *);

    ... using a stack value of 4 + 4 + 4 = 12. This failed.

    All this is making the assumption that each pointer put onto the stack is
    4 bytes.

    Obviously, I am making a bad assumption somewhere here. *8-)

    >I also provide a thunking mechanism to
    >let you expose your own AddressOf function pointers as CDECL functions.



    Interesting. Does this mean that all BAS functions are in fact CDECL ?
    Does this give us an advantage somewhere?

    Thanks,

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


  14. #14
    Matthew Curland Guest

    Re: Call C functions in a DLL without sdtcall convention

    > I take it that the only reason you have made a DLL of for the VBoost
    objects
    > is because of the IDE instability problem? And the other .BAS files do

    not
    > have this problem?

    The only bits of the VBoost functionality that have any problem at all are
    the IUnknown hooking pieces. I tracked this once to the debugger asking the
    typeinfo returned by IDispatch::GetTypeInfo if it supported an extra
    interface, and thereby determining the object to be a native vb object (and
    then making lots of assumptions). Of course, with the IUnknown hook in
    place, it is not really a VB object, and everything breaks down. This
    happens even though the IUnknown hook fails a higher level query when
    another part of the debugger asks a very similar question, and block things
    at this level would be extremely difficult. If you're using the arithmetic
    or memory functions only then you won't see any problems. Also, even if you
    don't hit these problems, constantly stepping into QueryInterface, AddRef,
    and Release gets really annoying after a while, so it is nice to have the
    Dll toggled in while debugging.

    Besides the debugging implications, the other reasons for the Dll are for
    Dll size when you're using it in lots of simultaneous components, minor
    speed gains (the Dll is in C++ after all), and a shared blind vtable. In the
    built-in implementation, the blind vtable is regenerated per apartment,
    which adds about 10k of per-thread memory if you use the full 1024 item
    vtable (you can reduce it significantly with conditional compilation). For
    heavily threaded stuff (MTS/COM+) that use the aggregation objects, you
    might want to use the dll for this reason. Note that I have heard of
    problems with the Dll loading under COM+, but it loads fine using
    ComDllLoader.bas in this situation.

    > Obviously, I am making a bad assumption somewhere here. *8-)

    Yep, you have to get the stack size right.

    >
    > >I also provide a thunking mechanism to
    > >let you expose your own AddressOf function pointers as CDECL functions.

    >
    >
    > Interesting. Does this mean that all BAS functions are in fact CDECL ?
    > Does this give us an advantage somewhere?

    No. The .bas functions are stdcall, as are .cls functions. The CDECLThunk
    turned the stdcall function into a cdecl function. The CDECLThunk was added
    so that you could provide callbacks for functions like qsort in msvcrt.dll,
    but it also provides a nice testcase to help you get your
    CDECLFunctionDelegator declares and stack size correct.

    -Matt



  15. #15
    Matthew Curland Guest

    Re: Call C functions in a DLL without sdtcall convention

    > I take it that the only reason you have made a DLL of for the VBoost
    objects
    > is because of the IDE instability problem? And the other .BAS files do

    not
    > have this problem?

    The only bits of the VBoost functionality that have any problem at all are
    the IUnknown hooking pieces. I tracked this once to the debugger asking the
    typeinfo returned by IDispatch::GetTypeInfo if it supported an extra
    interface, and thereby determining the object to be a native vb object (and
    then making lots of assumptions). Of course, with the IUnknown hook in
    place, it is not really a VB object, and everything breaks down. This
    happens even though the IUnknown hook fails a higher level query when
    another part of the debugger asks a very similar question, and block things
    at this level would be extremely difficult. If you're using the arithmetic
    or memory functions only then you won't see any problems. Also, even if you
    don't hit these problems, constantly stepping into QueryInterface, AddRef,
    and Release gets really annoying after a while, so it is nice to have the
    Dll toggled in while debugging.

    Besides the debugging implications, the other reasons for the Dll are for
    Dll size when you're using it in lots of simultaneous components, minor
    speed gains (the Dll is in C++ after all), and a shared blind vtable. In the
    built-in implementation, the blind vtable is regenerated per apartment,
    which adds about 10k of per-thread memory if you use the full 1024 item
    vtable (you can reduce it significantly with conditional compilation). For
    heavily threaded stuff (MTS/COM+) that use the aggregation objects, you
    might want to use the dll for this reason. Note that I have heard of
    problems with the Dll loading under COM+, but it loads fine using
    ComDllLoader.bas in this situation.

    > Obviously, I am making a bad assumption somewhere here. *8-)

    Yep, you have to get the stack size right.

    >
    > >I also provide a thunking mechanism to
    > >let you expose your own AddressOf function pointers as CDECL functions.

    >
    >
    > Interesting. Does this mean that all BAS functions are in fact CDECL ?
    > Does this give us an advantage somewhere?

    No. The .bas functions are stdcall, as are .cls functions. The CDECLThunk
    turned the stdcall function into a cdecl function. The CDECLThunk was added
    so that you could provide callbacks for functions like qsort in msvcrt.dll,
    but it also provides a nice testcase to help you get your
    CDECLFunctionDelegator declares and stack size correct.

    -Matt



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