Question regarding "MS Visual C++ Redistributable"

[Scryder]

I was going through the list of programs I have installed and noticed a number of installs of "Microsoft Visual C++ <<INSERT YEAR>> Redistributable".
Not only that, I also have 32 and 64 bit versions as well for some of these.
I have 2005, 2008, 2010, 2012, 2013, 2015-2019.

I know most of these were installed by games I've installed, some probably no longer installed. I can't tell which game installed what version anymore.

The question I have is, do I really need all these versions? Can I get away with un-installing all but one? Does anyone know?

Thanks in advance.

[DanceswithUnix]

Sadly, MS dll hell being what it is, I'm pretty sure you need all of them.

Sane dll versioning and application packaging is something that MS really need to learn from the Linux community.

[AGTDenton]

Agreed with DwU, they'll just come back in some form and you'll have to redownload all the updates to them again so you're sadly not solving anything.

If you're looking to do a general Windows tidy up, I'd recommend using the built in Disk Clean-Up utility which has the option to 'Clean up System Files'. This can remove redundant installers, old OS versions and anything lying around that you feel you don't need. Start by un-ticking everything then tick only the options you want to remove. All the options are considered safe, but things like Temp folders you might have something in there without realising or you may not want to have your Thumbnails index rebuilt for example.

[Scryder]

Thank you both for the clarification. So I assume it's the dll's that are used by these games? I've done some C++ coding in Uni, but that was a long time ago! I've noticed Paradox games install some of these Redistributes on install.

@AGTDenton You know what, I've used third party disk cleaners, but neglected the windows built-in Disk Cleanup! Appreciate the reminder, will do that. Thank you.

[cheesemp]

The only two ways to know which are need are:
1) Using something like dependency walker on every exe/dll you use. (There maybe more automated ways to do this scan)
2) Remove them all and then test everything re-adding as you need.

I suspect 90% of them will still be needed however! I work on an app that installs some of these for 3rd party libraries we directly use and its nearly impossible to reduce their need to 0 (even the oldest ones sadly). They are pretty small. Just view them as Windows Updates.

[Scryder]

Thanks, I'll ignore them. It doesn't really bother me too much, now that I know what they do. What confused me was why there were so many versions... I remember hearing years back that older versions of Java could leave your system vulnerable, so was careful with those. I was not sure this was the same case for these, but it doesn't to be the same case.

I appreciate the replies.

[DanceswithUnix]

What confused me was why there were so many versions...

There are two mindsets to that.

"When we made it, we tested the software with that version, so that is the only one it will link to" is rather common. People think they are being risk averse in working like that, but in reality they are just change averse and are as likely to increase risk as decrease it. But hey, the bugs are static for all time, some people like that.

OTOH the Linux community tend to push the dynamic library idea rather hard; if a program is built against a library version 1.5.2 then it will expect at least that version number installed, A lower number might not have all the features you need, so you don't run. Higher numbers should have new features you don't care about and bug fixes, so you can use that. A major number change to 2.x.x means something was done that breaks compatibility with old software, so you don't jump major versions. So generally a library will have the very latest version installed, and maybe an old compatibility version one major version behind in case something is using it. The package tools can track usage though, and can tell you if nothing is using a library. Some even automatically clean up when the last dependency stops using a library.

Microsoft have talked about this sort of thing, but it sounds like they are worried that putting it in place would drive the companies that make installers out of business overnight and that would be seen as hostile. I think that just shows a dreadful lack of imagination on their part.