Date: 14/10/2004
| For those who write code in the Microsoft Visual C++ environment here is a little pearl of wisdom for you. In the project options, you can build with several types of "Code Generation":
- Single Threaded
- Multi Threaded
- Multi Threaded DLL
Now this seems all innocent and nice. But those of you that have experiemented with different settings across DLL/exe boundaries have surely discovered that mixing code gen types generally causes crashes.
But there is more to it than that. In fact something which I found quite disturbing. (And I'm assuming that no one uses Single Threaded anymore).
There is a major difference between "Multithreaded" and "Multithreaded DLL" that is not so obvious, in a "Multithreaded" exe and associated DLL's the memory allocated by the DLL cannot be freed or realloc'ed by the exe and visa versa. With the "Multithreaded DLL" code gen you CAN free memory in the exe that was allocated in a DLL.
Now there are 2 camps here, the DLL crowd and the non-DLL crowd. Both have written swathes of code based around the assumption that the memory model has always been this way. I certainly had no idea the other camp even existed until today. But I met someone from that camp and had a good 'ol argument about it. In the end we both realised there is a whole other model out there that we just didn't know anything about. Lgi is firmly written in the DLL camp, and can't be used in just "Multithreaded" mode even if you wanted to.
I think the technical reason behind all this is that when you link to msvcrt.dll (i.e. "Multithreaded DLL") you get 1 clib (e.g. malloc/free) and 1 heap. If you don't, each DLL and exe has it's own clib and it's OWN heap. And the malloc and free calls don't work with memory from another heap.
And I've been coding for how long without realising all this? ;)
|
