Reputation: 1316
I need to use some DLLs compiled against msvcrt.dll in my app. I've already tried it and all seems well. My first worry though is having the extra dependency on msvcrt.dll; I'm already including the Visual Studio 10 runtime libs and was hoping not to have to add more. I know msvcrt.dll is always in the window system folder but should I rely on this?
Here is the page about the libraries:
http://www.zlatkovic.com/libxml.en.html
I could download the source and compile from scratch, and may do so long term, but for now I wanted to make sure there would be no problems linking against these libraries and using the DLLs.
There's a bit on that page that reads:
"Every program you compile using these binaries must use the same runtime. Unless you like your app crashing, set up your project to use msvcrt.dll. If you for some reason must use a different runtime, then you must get the source and compile libxml and friends yourself."
That is what worries me. It might all seem well for the moment but I'm worries what will happen when it is out in the wild on other systems with varying setups..
Upvotes: 2
Views: 2140
Reputation: 16081
Usually in the DLL's you create or use, they will depend on a numbered version of msvcrt, say: msvcrt90.dll or a debug version of that: msvcrt90d.dll. Or perhaps msvcrt100.dll/msvcrt100d.dll. These DLL's contain implementations of what's called the C Runtime libraries. Perhaps you are confusing this msvcrt.dll and the ones I named above? They are two different things.
From what I've heard msvcrt.dll is Microsoft's own internal version for the operating system. You don't have to worry, think, scrunch your head, wiggle your brow, or lose sleep over that DLL at all.
One of the only thing you need to be careful about in 'mixing' C runtime libraries is not allocating memory from one version of the CRT, and freeing it using a different version of the CRT. Ultimately that involves allocating from one Heap and freeing it another Heap. That's bad, and the CRT will complain and throw an exception.
If you deploy your app with a dependency on any particular version of the CRT, you can also deploy an installer that installs the CRT too. Microsoft in fact offers free downloads for those. If you for instance compiled your app with a dependency on a super old version of the CRT (One that for instance doesn't ship with windows anymore) when you start your app, the only thing that will happen is windows will refuse to start your app. It will give you a cryptic message, that you will have to google to figure out.
Upvotes: 0
Reputation: 247969
I know msvcrt.dll is always in the window system folder but should I rely on this?
Yes. msvcrt.dll
is owned and maintained by Windows. You can rely on it being present, and you do not need to (and should not) distribute it yourself.
There is no problem in having dlls linked against different runtime versions, as long as they don't pass types defined by the CRT across DLL boundaries (they may have different implementations of std::vector
, for example, so passing such an object from a dll linked with msvcr100.dll to a dll linked with msvcrt.dll will likely cause problems, and as long as you don't allocate memory in one dll, and release it in another (again, they'll likely have different malloc
/free
implementations, and perhaps use different heaps)
But they can coexist just fine, as long as you don't ask them to do anything "unreasonable" which requires them to know about the CRT version that the other dll is linked against. (And I believe that virtually every program ends up with a dependency on msvcrt.dll, because if nothing else, then they link against various Windows DLL's, which in turn are linked against msvcrt.dll. So if that scenario wasn't safe, then virtually every program written for Windows would be unsafe)
Upvotes: 3