How can I do a malloc within a DLL on data, which is not located in the DLL itself? I have a texture loader which does a malloc on a structure which contains a member called void *data. I pass the structure as a pointer to the DLL function. In this DLL, I try to malloc the data member. It works, but if I try to write to it, the program behaves strange. Sometimes it overwrites my FILE * handle, and fread always reads 0 bytes out of the texture file. Is there a way to malloc the data in the DLL or do I have to use static libraries? Darkening P.S. I''m using Win2000 and Visual C++ 6.0

1. When you do a malloc/new in a DLL, the memory is allocated from the heap of the process the DLL is loaded into. A DLL is always part of a process, it doesn''t live outside.

2. When a DLL is loaded into a process, all global variables (data and bss sections) are COPIED for that process. So if you have two processes using the same DLL, each has its own copy of the variables. (You can get round this by manually forcing some data into a shared section).

3. The DLL only sees one of its processes at a time (the way virtual memory addressing works! - each process always starts at the same address, even if there are more running).

--
Simon O''''Connor
Creative Asylum Ltd
www.creative-asylum.com

A very important thing to remember is that you cannot allocate in the dll and delete in the app and vice versa.

The way I did it was to provide an interface to expand my data sets from the dll, like EnlargePoints(int NumPoints), so the dll couldn''t allocate memory for the app.

quote:

---

Original post by ludemann8

A very important thing to remember is that you cannot allocate in the dll and delete in the app and vice versa.

---

euh, no! They share the same exact heap.

quote:

---

A very important thing to remember is that you cannot allocate in the dll and delete in the app and vice versa.

---

quote:

---

euh, no! They share the same exact heap.

---

For a general purpose DLL, you shouldn''t do this. They may share the same Win32 process heap, but the allocation systems for the DLL and the EXE may be different. For example, if your DLL calls new from MSVCRT.DLL, but the application is statically linked to the library and calls delete, a crash may occur, since each has it''s own C run-time heap-management structures. (I believe the C run-time still does it''s own heap management for blocks below a certain size. Older versions of the run-time do their own heap management for all blocks.)

Something I''ve found when creating DLL "plug-in''s" is to create your own heap (using HeapCreate.) This helps prevent your plug-in from corrupting the process heap, and vice-versa.