Because one version isn’t confusing enough!
Yes, I’m sorry to say, you probably do, and no, you should not delete any of them.
I have six copies myself.
This is a symptom of a problem faced by software vendors that, at its core, is unsolvable in any pragmatic sense. The problem even has a name: DLL Hell.
Become a Patron of Ask Leo! and go ad-free!
So many copies of the Visual C++ runtime
Yes, you need all the Microsoft Visual C++ redistributable downloads, and you should delete none of them. These libraries ensure the proper functioning of various programs, preventing failures caused by missing dependencies. Deleting any of them can cause software issues because of version-specific requirements. This is why there are so many on your machine.
Trying not to reinvent the wheel
The origin of the problem is very simple: programmers trying not to duplicate work that’s already been done.
For example, let’s say as I’m working on a program, I write a little bit of code that does something moderately useful; perhaps it’s a simple function to convert all alphabetic characters in a string to lower case.1 It takes a string of characters like “Ask Leo!” and converts it to “ask leo!”.
It’s not uncommon for many programs to require that feature. So rather than writing or including a case-conversion function into every program that might want it, we package it up into what’s called a “library”. Any program that wants to convert a string of characters to lower case simply uses this library function. The software developers don’t have to write, test, and include their own version of that function.
The Microsoft Visual C++ Runtime is nothing more than a large collection of those kinds of functions. They’re not nearly as simple as just changing the case of characters in a string , but they are things that are very common to programs written in Microsoft Visual C++ (a programming language), specifically for Windows.
By providing all this functionality in one package, programs are easier and faster to write, since they don’t have to duplicate all this effort.
And that much, at least, is mostly true.
Progress versus compatibility
As time goes on, several things happen:
- Programs change and improve in response to customer and market demand.
- The software those programs are built on — like Microsoft Visual C++ — also change and improve to provide the functionality required to make those customers and market happy.
- Bugs (errors) are created and bugs are fixed.
- New versions are released.
In the example above, I have six copies representing three versions of the redistributable library (each version comes in to flavors: 32bit and 64bit).
In an ideal world, a program relying on Microsoft Visual C++ 2010 x64 Redistributable would be equally served by the Microsoft Visual C++ 2013 x64 Redistributable. It’s just a new version, after all.
We don’t live in an ideal world. Depending on how it’s written, a program written to use the 2010 version might experience failures if it tried to use the 2013 version as a replacement. That program requires the 2010 version, no matter how many subsequent versions are installed.
The uninstall problem
Consider this scenario: you install program “A” and it uses library version 2010. You then install program “B” and it also uses library version 2010, so it doesn’t need to install it — it can just use the copy that’s already there courtesy of program “A”.
Now you uninstall program “A”. Three things can happen:
- It uninstalls the library because it installed it and it should clean up after itself, not realizing that another program relies on the library. Program “B” breaks.
- It never uninstalls the library because another program might use it. As a result, libraries check in, but they never leave.
- We devise some method of tracking how many installed programs are using the library, and only remove it when the last one is uninstalled. Unfortunately, any single program’s failure — be it a programming error or a failure to install or uninstall properly — breaks this technique. At best, you’re left with copies of the library you no longer need, and at worst, uninstalling one program can cause one or more other unrelated programs to fail.
It’s a mess. In fact, it’s such a mess that many programs now don’t bother to try to share at all.
Versions, versions and versions
One of the most entertaining2 scenarios of this problem is that of large application suites. It’s not at all uncommon for two things to be true:
- Even if most of the suite is written for a 64-bit platform, there may still be 32-bit utilities included (which run just fine on 64-bit operating systems). This means both 64-bit and 32-bit versions of the runtime libraries need to be included.
- Even if most of the suite is written for version “X” of the runtime library, there may still be portions that rely on version “Y”, or even version “Z”. So both or all three must be included, and possibly in both 32- and 64-bit flavors.
It could have been better, but it’s not
I’m certain there are ways that this problem could have been approached differently from the start. That this isn’t nearly as big a deal on non-Windows platforms is, perhaps, the single biggest sign of that. Those platforms either didn’t attempt this type of code sharing, or do it in less interdependent ways.3
And while developers still benefit from not needing to re-invent the wheel each time they need it, they end up shipping and installing a lot of wheels with every program that needs it. They save some work by not starting from scratch each time, but your system becomes littered with different versions of (essentially) the same thing.
Do this
What we ultimately don’t know is exactly the same thing those install and uninstall programs don’t know: we don’t know what’s safe to delete.
Thus, the safest approach, by far, is to leave well enough alone and delete nothing.
Subscribe to Confident Computing! Less frustration and more confidence, solutions, answers, and tips in your inbox every week.
Footnotes & References
1: Programmers, please rest assured that I know about things like lcase() and strtolower() and the existing functions to do exactly this. I’m choosing a simple example to make my point.
2: I chose “entertaining” over “depressing”.
3: In other operating systems, the duplication of the content of those files is still there. It’s just more commonly carried around within applications themselves.
“libraries check in, but they never leave.” Welcome to the Hotel DLL Hell.
Was wondering if someone would catch that. :-)
Great article and as usual very informative.
I have seen all these replicated files on my computer, especially the runtime and net framework files and just like your questioner wondered why all the different versions were there. Is there not a case – now that HDDs are getting physically smaller and smaller – and cheaper – while giving massively larger memory – to have a dedicated drive for storing all these libraries. I’m sure a small modern day drive could handle all this stuff for many many years with a built in piece of software that would only remove stuff that hadn’t been used for say 10 or more years or was known never to be needed again. I’m sure the software vendors between them could put that together quite easily.
I also realise that everything I have said may be totally naïve and not at all workable, it was just a thought.
It requires a massive amount of coordination that’s not likely to happen. :-) Also, there’s no need for a separate drive – the single drive in most computers has more than enough space in most cases.
Thank you, thank you, thank you. I too have been asking myself the same question, Too bad about the answer.
Your avid reader ( and book buyer),
Bill
This is another thing I’ve always hated about Microsoft is their shared libraries and their ineptness at managing them. A case could be made for sharing code like this back when storage was expensive and keeping program size to a minimum was necessary, but now that is not a problem and programs should be self-contained (what’s called “portable” nowadays). The developers could keep their own libraries of common code if they want, and just include a copy of the actual code from the library into the program they produce instead of a link to an external library. IOW, the program should not need to depend on anything but the OS it’s installed on.
Ultimately what I described is exactly what you described – tools are becoming more and self-sufficient. (“Portable” isn’t actually so much about not sharing code – it has more to do with where state information like settings and such are kept.)
I tune-up computers for residential clients and run into this all the time. I’ve known about the problem and why it exists for at least a dozen years now. Thanks for explaining it in terms my clients will understand. Now when I get the question during a tune-up I can point them toward this article.
I’m interested to know how the Chromebook is handling the common library problem. I haven’t used one yet, but imagine it’s more like a tablet than a PC. Google pushes updates to the Chrome browser when you ask it’s status, and I imagine their OS does the same. Anyone?
Isn’t the .NET framework better at this? It seems to me I’ve only seen multiple versions (1.1, 2.0, 3.0, 3.5, 4) on my computer but not multiple copies of those versions, unlike seeing multiple copies of multiple versions of the C++ runtime.
Yes, .NET is better – though as those multiple versions attest to, not perfect. But it’s also different from the C/C++ runtime.
I have some exact same copies C++ 2008 redistributable so what should I do because obviously less programs means faster overall speed of any computer. So my question is if the programs are EXACTLY the same (apart from the program size) is it ok to delete 1 of them
There is a risk involved in removing duplicate program files.
https://askleo.com/why-are-there-duplicate-files-on-my-computer/
http://ask-leo.com/is_it_safe_to_delete_duplicate_files.html
Installed programs have no impact on the speed of your computer unless those programs are running.
Thank you – excellent explanation.
I HAVE erased duplicated files when I can see it’s a text file I no longer want, but I’ve been told to never delete anything that has to do with Microsoft.
By deleting my own text files, will that harm my computer.
Deleting your own text and user created files shouldn’t be any problem. Deleting system created files can pose a risk.
Shouldn’t, but as always, it depends on the specific files.
At last someone I can trust. Thanks for your no bull advice and knowledge Leo. There are way too many charlatans out there.
I came here looking for advice on Microsoft C + +, and found what I was looking for.
Cheers, oh and Happy New Year 2017
I have 2005, 2008 and 2015 redistributables in my 64 bit windows 7 but when trying to install xampp i get the message that api-ms-win-runtime-l1-1-0.dll is missing in my computer. How can i solve this problem