Call C functions in a DLL without sdtcall convention

[PV]

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.

[Mark Alexander Bertenshaw]

"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

[Mark Alexander Bertenshaw]

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

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

[PV]

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

[Mark Alexander Bertenshaw]

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

[Mark Alexander Bertenshaw]

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

[P.V.]

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

[P.V.]

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

[Matthew Curland]

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.

[Matthew Curland]

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.

[Mark Alexander Bertenshaw]

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

[Mark Alexander Bertenshaw]

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

[Matthew Curland]

> 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

[Matthew Curland]

> 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