tags:

views:

66

answers:

3

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)

+1  A: 

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
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.
Ninefingers
@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
A: 

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

Joshua
You have to link with Microsoft's C runtime to use GCC? Odd.
Billy ONeal
@Billy well you don't but it's the one stdio.h, etc. are set up for in the mingw distribution.
Joshua
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.
Ninefingers
+1  A: 

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.

Ninefingers
The C runtime is msvcrt.dll. It has nothing to do with kernel32.dll. +1 for depends.exe though.
Billy ONeal
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.
Ninefingers
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
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