Re: Where did my VB function go?

Sorry, that was my fault: I didn't see the "DLL" following "C++" in the
first posting of yours - I assumed that you were talking about a C++ EXE.
Yes, you are right: If the VB application loads the C++ DLL, the DLL gets
mapped to the virtual address space of the VB application, and it should be
able to call any function of the VB application by using its address.

Did you verify that the function pointer passed from the VB app to the C++
DLL is really the same as the one the DLL uses when trying to call the VB
function?

And there is a very common error with shared memory, for which I will give
you an example:
A DLL has a shared memory section. Now it allocates memory with malloc(),
calloc(), GlobalAlloc(), or whatever, and stores the memory handle to the
shared memory section. While the memory handle know is readable, the same
and shared by all processes attached to the DLL, the allocated memory is
not! Only the process in the context of which the DLL has allocated the
memory, will be able to access the allocated memory. If other processes
will try to access this memory, this is very likely to result in a GPF.
Can this error be excluded for you DLL?

--
----------------------------------------------------------------------
THORSTEN ALBERS Universität Freiburg
albers@
uni-freiburg.de
----------------------------------------------------------------------



Thanx again again for the troubleshooting advice. Yeah, I made a rookie
mistake, lol, been programming for like 12 years and some times I still
miss it, I passed the VB function address to the C++ DLL as byref,
which passes a pointer to the address of the function (basically a
double pointer). I found out by taking your advice with checking what
the function address was in VB and noticing that this function address
wasnt coming into the C++ DLL function, however when i went to the
passed address location, lone behold i found the function address which
was being stored in VB, thus telling me I messed up with the byref
byval issues when i declared my C++ function in VB.

Now, thats that fixed, it seems I have another problem, the VB
function, when called from C++ is causing an access violation in the
NTDLL DLL, so i figure i probably dont have correct parm setup between
my VB function and my C++ function pointer (I know I have the C++ one
setup as stdcall, so that shouldnt be the problem, but i pass a byte
array back to VB (via a pointer) from the C++ DLL, so this may be the
cause of contention).

Oh yes, regarding that common shared memory issue, i've made that
mistake as well. When I first started using shared memory between
processes, I needed to make a linked list used by all attached
processes, and figured I could maintain a single linked list shared
between processes (while not located inside shared memory, but only the
address of the first link located in shared memory). Not realizing the
whole idea of seperate memory pages used in the virtual memory model,
my linked list wasnt working correctly. Then after reading the MSDN
section all about processes, threads, the virtual memory model and IPC,
I realized that yes you cannot store the address of the 1st link in the
linked list in shared memory and expect that linked list to be usable
to all attached processes, b/c each process has its own virtual memory
space, seperate from another process, so only one process will have
access to the linked list, which will be the one that alloc'd
(malloc'd, or what ever was used to get heap memory) the memory for the
first link and stored that memory block address as the 1st link in the
shared memory area. So the way I got around this was by basically using
IPC shared memory techniques and synchronization objects to maintain a
series of coherent linked lists local to each attached process. I used
a background thread in each process to handle the maintenance of the
given process's linked list. Infact thats how I got the idea of
implementing the Message Passing system which i'm currently working on.


Sorry for the long response wait, and thanx again for the help.

Nathaniel

.

Relevant Pages

  • Re: exporting global variables from dynamically linked libraries
    ... Although the code is in common memory, it may be mapped to different ... If you're after shared memory (like the DLL memory in 16-bit Windows ...
    (comp.os.linux.development.apps)
  • Re: Why do we need executables in certain formats ?
    ... > complex binary formats was that programs need to be relocated, ... > perhaps linked with libraries. ... Modern virtual memory processors can locate to ... > has a hidden problem with the new .DLL. ...
    (comp.lang.asm.x86)
  • Re: Why is Base3.exe using 700+ K in windows task manager ?
    ... DLL function. ... handles opened by any thread of the calling process ... The DLL allocates memory from the virtual address space of the calling ... Who can tell where memory is really located in a virtual adress space? ...
    (alt.lang.asm)
  • Re: new / delete in a dll
    ... memcpy(&ob.pData, pData, width * height); ... In my dll, i'm calling 'new' to allocate the correct amount of memory to ... Is this involving shared memory data segments? ...
    (microsoft.public.vc.mfc)
  • Re: shared DLL VS static Link, Are they different?
    ... MFC exits, and if there is any memory that is freed at that time, MFC will ... business dumping leaks; it should wait until the CRT DLL dumps leaks after ... ALL RESOURCES OWNED BY THAT PROCESS ARE RELEASED. ...
    (microsoft.public.vc.mfc)
Quantcast