"Alexander Nickolov" <agnickolov@mvps.org> wrote in news:#ZIaw6C5HHA.5740
@TK2MSFTNGP04.phx.gbl:
There shouldn't be a problem of both runtimes being loaded
in the same process by different DLLs. The problem of different
CRT version comes with linking static libs compiled with different
compilers, but shouldn't be an issue for DLLs (provided your
DLLs only export C functions, not C++ classes, and beware
function arguments - don't pass C++ classes or they will get
exported as well; passing C++ interfaces is fine though since
these are essentially pure vtables with no regular methods nor
members to export - that's how COM works for example).
You still need to be careful to let each DLL manage its own
objects, otherwise memory errors will occur (one CRT cannot
deallocate memory allocated by another CRT).
Also, consider static CRT linking.
C++ interfaces work well - but one thing (well a couple) to watch out
for. (It took me a couple meltdowns before I smacked myself and went
'duh!')
I have a statically linked exe that I decided to extend with some plugin
dlls (also statically linked). The dll exports a "C" name that returns an
interface. So LoadLibrary/GetProcAddress work really nicely. Now, my
interface had a simple method (well, it has a bunch, but this is all we
need for this example):
std::string GetName() const;
At this point warning bells should be CRASHING in your head... (They
didn't crash in mine until my app crashed!). For those still wondering
why - where does the string's memory get allocated? And where is it
freed? And how many heaps do I have? Ans: Dll, Exe, 2. This gets to what
Alexander mentions above: do NOT export C++ classes. And all of STL is
exactly that. The above then morphed to:
class IMyWhateverInterface
{
public:
char* GetName() const;
void releaseBuffer(char*);
anyway). Note that BSTR is UNICODE, even on Windows 9x.
...
Dave Connet