Debug- & Release-DLL

[martho]

Debug- & Release-DLL

Hello !

I've got a DLL-EXE-Probleme:
When using Debug-DLL with a Debug-EXE, everything works fine.
When using Release-DLL with a Release-EXE, everything works fine, too.
But when mixing it up (Release-DLL with Debug-EXE or Debug-EXE with Release-DLL) there are some unexplainable faults. Any ideas ?

Regards

Martin

[ALM]

It makes sense. The Debug and Release versions use different C run-time libraries which handle memory allocation quite differently. So if you allocate memory in a Debug module and then free it in a Release module, boom!

So don't do it!
Alvaro

[Paul McKenzie]

To add to Alvaro's post, if you want to allocate memory between a DLL and an EXE, the best way to do this is to use GlobalAlloc() using the GMEM_SHARE flag (this flag is not necessary with 32-bit progs; you do need it if your DLL is 16-bits).

The reason for this is that GlobalAlloc() bypasses the heap manager of the compiler and gets the memory directly from the operating system. The problem with using malloc or new is that the pointer that is returned *is not* a pointer to Windows's memory: it is really a pointer that the specific compiler's heap manager gave to you, and it points to a data structure that only the specific compiler and task knows about. I couldn't use your DLL if I were using C++ builder, or some other compiler.

You will need to use GlobalAlloc for the following reasons:

- Your DLL allocates memory, and the EXE is responsible for freeing the memory (as mentioned by Alvaro)

- Your DLL may be used with *any* language, C++ compiler, or programming environment. For example, how is a VB program that uses your DLL going to free the memory if you used malloc() or "new"? The answer is to use GlobalAlloc instead, and the VB program can call GlobalFree (any program / language that allows calls to a Win32 API function can call GlobalFree).

Regards,

Paul McKenzie