passing pointers to extern C function in a DLL from VB

Question

I am a C++ (MSVC) writer, VB newbie trying to assist an expert VB.net writer who has just not done this task before.

We wish to develop both C/C++ and VB applications to use a DLL written in C++ with C extern-ed API functions. The C++ program is working just fine. It's VB where we are having difficulties.

The DLL provides an extern C function:

RegisterCallback( void* cbFuncPtr, void* dataPtr );

NOTE 1: See my note below for a design change and the reasons we made it.

NOTE 2: Additional update added as an answer below.

where the callback function havs this C typedef:

typedef   (void)(* CALL_NACK)(void*);

The cbFuncPtr is expected to be a function pointer to some VB function that will get called as the CALL_BACK. The dataPtr is a pointer to a data structure that has this C definition:

typedef struct 
{
   int      retCode;
   void*    a_C_ptr;
   char     message[500];
}  cbResponse_t;

where a_C_ptr is an internal pointer in the DLL that the VB can cast tolong`. It uniquely identifies where in the DLL the callback was made and allows the VB function to recognize calls from same/different locations.

We are able to access and run the RegisterCallback() function from VB just fine. Logging shows we get there and that data is passed in. It is the actual data that seems to be the problem.

In reading about a million forum entries we have learned that VB doesn't know what pointers are and that a VB structure is more than just organized memory. We're pretty sure the "address" of a VB structure is not what C thinks an address is. We've seen repeated references to "marshaling" and "managed data", but lack enough understanding to know what that is telling us.

How should we code VB to give the DLL the execution address of its callback function and how do we code up a VB construct that the DLL can fill in just as it does for C++?

Might we need a DLL function where the calling app can say "C" or "VB" andhave the DLL handle the sturcture pointers differently? If so, how would one code up C to fill in the VB structure?

Answer 1

This is a bit too big and deep to just be an edit to the original posting...

From the link posted by @DaveNewman, I extracted this gem:

---

Here's a bit about the compact framework, but it's the same in the grown-ups framework:

The .NET Compact Framework supports automatic marshaling of structures and classes that contain simple types. All fields are laid out sequentially in memory in the same order as they appear in the structure or class definition. Both classes and structures appear in native code as pointers to C/C++ structs.

Objects in the managed heap can be moved around in memory at any time by the garbage collector, so their physical addresses may change without notice. P/Invoke automatically pins down managed objects passed by reference for the duration of each method call. This means pointers passed to unmanaged code will be valid for that one call. Bear in mind that there is no guarantee that the object will not be moved to a different memory address on subsequent calls.

http://msdn.microsoft.com/en-us/library/aa446538.aspx#netcfmarshallingtypes_topic6

---

This is major hurdle for a RegisterCallback( fcnPtr, dataPtr) function. The pointer passed in at registration time could change at any time the RegisterCallback() is not the current statement. The posting author summed it up this way

You don't need to do anything as the structures are pinned automatically for duration of the call.

implying, of course, not pinned down outside the call.

For this reason we decided on a design change to have the response structure built in, so to speak, the C/C++ world of the DLL, not in VB's space. That way it'll stay put. The actual callback function's signature will remain unchanged so the VB program can know where the DLL put the response. This also allows the responders in the DLL to allocate separate response structures for separate needs.