Re: Conflicting C Runtimes can of worms
Pavel A. wrote:
"Carl Daniel [VC++ MVP]"
3) What are the dangers of having one DLL using the shared/dll
version of the CRT and another that has been statically linked with
the CRT? This can happen often when using 3rd party DLLs that don't
provide the source to build it.
No danger if objects allocated in one DLL always remain within that
DLL. If any object allocated in one DLL are shared with code in
another DLL, you'll likely have problems - unless the sharing is
through pure interfaces, such as with COM components.
Hi Carl,
Could you comment a bit more how this actually works:
Do CRT copies in each DLL use the private pool of the DLL?
How file handles are shared between multiple copies of CRT in the
main app and DLLs?
Each CRT has it's own heap. i.e. it's not the executable objects (EXEs and
DLLs) that define pools, it's CRT instances. If you have the CRT linked
statically twice and dynamically once in a single EXE+DLLs, then you have
three separate heaps (and three separate copies of other CRT structures such
as file descriptors).
File handles, e.g. HANDLE, are kernel objects and are valid throughout the
process. File descriptors, e.g. FILE* and file numbers are unique to each
CRT instance and cannot be shared between code using different copies of the
CRT.
What is a good, supported way to build a DLL that works with VC++
2005 or 2008 apps
built with *any* RTL variant - static or DLL, debug or release?
(of course, given that malloc's and free's are done in same module)
Follow the model of the Win32 API:
- Only pure "C" interaces - no C++ class at all.
- Use opaque "handles" to pass (temporary) ownership of module-allocated
objects to callers.
- For every kind of "handle" that's returned by your API, providing a
matching free/release/delete funciton.
By far the most widely applicable solution is to use COM - it was designed
for this very purpose. You can definitely "roll your own" though, just just
need to be mindful in your API design that 100% of the code that allocates,
frees or interprets the contents of memory blocks created by your DLL
resides within your DLL. You can loosen the "interprets the contents"
requirement for pure C-style structs, just make sure that your API header
files explicitly set packing around the struct definition so that you're not
dependent on the context. Likewise, make sure to explicitly decorate all of
your API entry points with a calling convention (e.g. __stdcall) - never
rely on the default.
-cd