how to exchange large string between any prog and dll
-
If the DLL is loaded into your processes address space, you can already see each other's memory - no extra steps required. Just allocate space for the string, and pass it to a method in the DLL. Or pass the memory to a method in the DLL and have it return the string in it. Or have the DLL allocate the memory and return it to you. Etc. Peace! -=- James
If you think it costs a lot to do it right, just wait until you find out how much it costs to do it wrong!
Avoid driving a vehicle taller than you and remember that Professional Driver on Closed Course does not mean your Dumb Ass on a Public Road!
DeleteFXPFiles & CheckFavorites (Please rate this post!) -
If the DLL is loaded into your processes address space, you can already see each other's memory - no extra steps required. Just allocate space for the string, and pass it to a method in the DLL. Or pass the memory to a method in the DLL and have it return the string in it. Or have the DLL allocate the memory and return it to you. Etc. Peace! -=- James
If you think it costs a lot to do it right, just wait until you find out how much it costs to do it wrong!
Avoid driving a vehicle taller than you and remember that Professional Driver on Closed Course does not mean your Dumb Ass on a Public Road!
DeleteFXPFiles & CheckFavorites (Please rate this post!) -
James R. Twine wrote:
Or have the DLL allocate the memory and return it to you.
Don't forget the let the dll free the memory it has allocated. Every module exe/dll is resposible for its own allocated memory. codito ergo sum
Actually, I abhor writing hand-off memory functions, where memory is allocated by the called function and returned from it with the understanding that the caller is now responsible for it. IME, there seems to be an "out of sight, out of mind" mentality where if the caller did not make an explicit call to a memory allocating function/operator that they are familiar with (
new,malloc(...),SysAllocString(...), etc.), they tend not to realize that they are now responsible for deallocating it. I tend to write functions that need memory such that they take a pointer to a previously-allocated block of memory and the size of that block. That way, it is clear that the caller manages the memory. I was just detailing examples for the poster. Besides, I am fairly certain that a DLL loaded into your address space can allocate memory that you can free (as long as it was allocated while in the context of your process, and not another). Peace! -=- James
If you think it costs a lot to do it right, just wait until you find out how much it costs to do it wrong!
Avoid driving a vehicle taller than you and remember that Professional Driver on Closed Course does not mean your Dumb Ass on a Public Road!
DeleteFXPFiles & CheckFavorites (Please rate this post!) -
Actually, I abhor writing hand-off memory functions, where memory is allocated by the called function and returned from it with the understanding that the caller is now responsible for it. IME, there seems to be an "out of sight, out of mind" mentality where if the caller did not make an explicit call to a memory allocating function/operator that they are familiar with (
new,malloc(...),SysAllocString(...), etc.), they tend not to realize that they are now responsible for deallocating it. I tend to write functions that need memory such that they take a pointer to a previously-allocated block of memory and the size of that block. That way, it is clear that the caller manages the memory. I was just detailing examples for the poster. Besides, I am fairly certain that a DLL loaded into your address space can allocate memory that you can free (as long as it was allocated while in the context of your process, and not another). Peace! -=- James
If you think it costs a lot to do it right, just wait until you find out how much it costs to do it wrong!
Avoid driving a vehicle taller than you and remember that Professional Driver on Closed Course does not mean your Dumb Ass on a Public Road!
DeleteFXPFiles & CheckFavorites (Please rate this post!)James R. Twine wrote:
Besides, I am fairly certain that a DLL loaded into your address space can allocate memory that you can free
It used to be no problem, on OS like Win9x and Win2000. We had writen our own Dll who encrypted some data returning the BYTE* pointer to the encrypted data which was freed after use in our application. Without any problems what so ever. We then moved to WinXP and our application crashed on the the delete[] of the memory returning in a access violation. Found this on the net:
Potential Problems When Crossing DLL Boundaries
It is not possible to allocate memory in a DLL (either explicitly with malloc / new or
implicitly with aforementioned strdup) and pass the pointer across the DLL boundary into
the process space to free it, when the DLL and the application are using different copies
of the CRT (C-RunTime) libraries. This will cause a nasty memory access violation or worse:
corrupt the heap! When you bump into an assert in the CRT lib when it tries to execute free(),
you will know you have run into this very problem.Memory is only valid for the copy of the CRT where they were allocated. This means that when
you are using two different CRT libraries (LIBCMT.LIB and MSVCRT.LIB for example) together,
you cannot expect one to correctly free something the other has allocated. Because they most
probably are using different heap managers, the heap runs the risk of becoming corrupted when
you run the application in release mode! Pity the programmer who has to track the bug that
crashes his application this way.So its better safe the sorrow. codito ergo sum