4

Do we still need to bother with vcredist.exe when distributing windows native applications ? Does any of these come bundled with Win-7 ?

If not, are there any technical reasons these are not shipped to people via e.g. windows update - insteadof letting us burden the customers with yet-another-thing-that.must-work ? (Ok, that might sound argumentative, but I'm really wondering the reason these libraries are not default installed/updated on windows machines)

leeeroy
  • 11,216
  • 17
  • 52
  • 54

4 Answers4

2

I think it depends how / what you're linked to. If you're linked directly to kernel32.dll etc then it doesn't matter, of course (i.e. the c runtime library is embedded), but Microsoft don't recommend that method of distribution.

If you're linked through msvcr80/90/whatever 2010 is.dll, then you may need to distribute that runtime library as on XP it doesn't come as standard. msvcr80 comes on Vista but msvcr90 doesn't I don't think - although it might get added by windows update. Still, you can't rely on it being there therefore the failsafe is to have a copy of it just in case.

As far as I know msvcrt.dll (that mingw links to) is distributed with everything > xp. Does vc6 link to this? I didn't have VC++ back then.

Take a look at the executable with depends.exe from the Windows SDK and work out what it comes with above and beyond parts of the Windows API.

  • The C runtime is msvcrt.dll. It has nothing to do with kernel32.dll. +1 for depends.exe though. – Billy ONeal Apr 14 '10 at 20:58
  • It is, but msvcrt.dll links to kernel32.dll. If you link against the static library version of msvcrt you are directly linked to kernel32.dll. Either way, you're doing to be linked to kernel32.dll whether you like it or not. My point was, what you depend upon (i.e what your program asks to be loaded) depends on how you're linked. It'll either be via msvcrt, msvcrXX.dll or straight to the API if statically linked. –  Apr 14 '10 at 21:01
  • Ah -- that's not inherently clear from your answer -- you're not linking through the C runtime library. You're still linked to kernel32.dll even if you use the DLL version of the C runtime. – Billy ONeal Apr 14 '10 at 21:04
  • 1
    msvcrt.dll is *not* the C runtime. It is an internal component of Windows that should never be used by 3rd party applications. You'll note that you can't find any references on MSDN that use this DLL. Once upon a time 3rd party applications used this but that hasn't been the case for about 10 years. – Larry Osterman Apr 14 '10 at 23:29
1

Yes, you do. Otherwise your program will crash spectacularly when you try to run it. Lots of users aren't running Win7, and even then there's no way to ensure they have the runtime installed without including it in your installer.

Alternately, you could link with the static build of the runtime, avoiding the need of bothering with the C runtime redistributable.

Billy ONeal
  • 104,103
  • 58
  • 317
  • 552
  • Microsoft discourage static linking with their runtime, the reason being if they find a vulnerability in the runtime they can update the dll and your application is also protected - otherwise you need to rebuild. I don't know of any vuln's in the msvcrt runtime, but there's clearly reason for them to issue this advice, so, there it is. –  Apr 14 '10 at 21:30
  • @Ninefingers: Yes, but some of us can't justify forcing users to install ~20MB redist packages. If you need single EXE XCOPY deployment then you have little choice. – Billy ONeal Apr 14 '10 at 22:57
0

When compiling with GCC I always link with MSVCRT.DLL which is always there on XP and newer.

Joshua
  • 40,822
  • 8
  • 72
  • 132
  • You have to link with Microsoft's C runtime to use GCC? Odd. – Billy ONeal Apr 14 '10 at 20:56
  • @Billy well you don't but it's the one stdio.h, etc. are set up for in the mingw distribution. – Joshua Apr 14 '10 at 20:57
  • I believe that's the default behaviour and makes sense - you're linked against glibc on Linux. Why not just use Microsoft's "libc" on Windows? That's all it is, it's guaranteed to be there pretty much, as a bonus. –  Apr 14 '10 at 20:59
0

This is in response to Larry Osterman's comment dated Apr 14 at 23:29:

You say:

msvcrt.dll is not the C runtime. It is an internal component of Windows that should never be used by 3rd party applications. You'll note that you can't find any references on MSDN that use this DLL. Once upon a time 3rd party applications used this but that hasn't been the case for about 10 years. – Larry Osterman Apr 14 at 23:29

This seemed to go against the entire premise of the mingw system which is based on accessing msvcrt.dll and your comment allowed me to better understand how mingw works. It turns out that mingw still uses the msvcrt.dll that was shipped back in 1998! See this link:

http://www.mingw.org/wiki/C99

Thank you,

Todd

Sabuncu
  • 5,095
  • 5
  • 55
  • 89
  • 1
    "The msvcrt.dll is now a "known DLL," meaning that it is a system component owned and built by Windows. It is intended for future use only by system-level components." (from http://msdn.microsoft.com/en-us/library/abx4dbyh.aspx ) – Lucas Nov 12 '10 at 17:00
  • Thank you Lucas, I was unaware of the "known DLL" concept. Wonder if mingw would work with msvcr100.dll instead of msvcrt.dll? – Sabuncu Nov 12 '10 at 21:41