The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Installing msvcrt.dll and msvcp60.dll

Hey guys,

I'm creating the install program for my shareware program, and I just found out that one of the DLL's that ships with my program needs msvcrt.dll and msvcp60.dll to be installed on the user's computer.

Question: What's the overall strategy for installing these 2 DLLs?  Do I need the versions which are compatible with the DLL my program uses?  Or versions which are compatible with the version of Windows the user has?  If it's the latter, is it possible those versions won't be compatible with my program?
Tuesday, January 25, 2005
I have no idea, but I've been stymied by this very recently.  An utility I wrote in-house uses these DLL's.  But a new download of the Microsoft tools - and voila, these DLL's have new names.  Not only that, these DLL's seem to change names somewhat frequently (with .Net framework updates most recently, with compiler revisions in the past).

In my case, since its just an in-house tool, the user is instructed to download the latest VC tool kit.  Which is a real pain, as its not always compatible with their version of Visual Studio.

Its very humorous.
hoser Send private email
Tuesday, January 25, 2005
You can put them in the same folder as your EXE, and they will be picked up. I started doing this for a free program I wrote, and has fixed the problems for (at least) the people who asked about it.
Tuesday, January 25, 2005
Hoser, thanks for the reply.  Tom - that makes sense, and was verified by the vendor of the DLL my program uses.  Do you know if I include those 2 MS DLLs off my WinXP SP2 box whether or not that should be fine with users running Win98, NT and 2000?
Tuesday, January 25, 2005
AFAIK msvcrt.dll, together with other runtime files from VC++ 6.0, is included with the OS from W2K onwards.

For earlier versions of the OS (NT4, 9x, (Me if you must) you can install VCREDIST.EXE from the following URL, my experience is that installing the latest version works with any DLLs I've used:;en-us;259403

MSVCP60.DLL is a problem to which I haven't found a proper solution.  For earlier OS's, it is installed by VCREDIST.EXE, so no problem.

For W2K or later, VCREDIST.EXE detects the OS version and does nothing - so there seems to be no way to install MSVCP60.DLL from a Microsoft-supplied redistributable package.  I've searched the KB and never found a sensible recommendation about this.

As others have suggested, the easiest is to include it with your own distributable package.
Tuesday, January 25, 2005
I just searched by name on the hard disk (Win2K SP4) and used the first one it found. I don't know about MSVCP60.DLL, but MSVCRT.DLL can't change that much because it's the C runtime and used by so many programs.
Tuesday, January 25, 2005
I don't do Windows, but:

If you are shipping a single .EXE and you have DLL hell, wouldn't you be best off doing a static link?

(If the product contains multiple .EXEs then this becomes less attractive...)
David Jones Send private email
Tuesday, January 25, 2005
It isn't that MSVCRT.DLL which came with Windows changes, its that the same version that gets linked against by the compiler/linker changes.  The last time I downloaded Visual C++ Toolkit it is named MSVCR71.DLL.

I've tried all kinds of work-arounds on this, including generating my own import library (rather interesting notes abound about how to use sed on linker output).

But alas, with recent compilers, you cannot seem to link against MSVCRT.DLL.  WTF, eh?
hoser Send private email
Tuesday, January 25, 2005
I just went through this.  You can't just use the MSVCP60.DLL that's on your machine.  You have to create a CAB (I wish I'd written all this down) using the IDE to create an empty install kit, and then extract all the DLLs from it.  Then put that MSVCP60.DLL in your EXE's folder on your customer's PC.

MSVCRT.DLL, though, should *not* be redistributed, according to Microsoft.  I wish I had a KB article to point you to, but I distinctly recall reading that doing so is a very bad idea.

I apologize for the vagueness of this, but hopefully someone will recognize what I'm talking about a post a complete answer.
Saturday, January 29, 2005
Implies MSVCRT is redistributable:

"If you dynamically link your application to the MFC library, you will, at a minimum, need to redistribute Mfc42.dll and Msvcrt.dll. All MFC DLLs use the shared version of the C run-time library; thus, Msvcrt.dll is required."

Also check out "redist.txt" in your vc6/vc98/ folder -- msvcrt.dll is marked as being "redistributable code - extended use". Sounds good. And according to vc6/vc98/setup/1033/eula.txt:

"2.2. Redistributable Code-Standard. Microsoft grants you a nonexclusive, royalty-free right to reproduce and distribute the object code form of any portion of the SOFTWARE PRODUCT listed in REDIST.TXT ("Redistributable Code")."

This is defined further in section 3, but the gist is (subject to my having missed something) that they don't disallow you from giving away the redistributables with your program. So it looks like actually you are safe, though naturally anyone seriously concerned about these matters should consult someone qualified to give legal advice, which I'm not.
Thursday, February 03, 2005

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz