Why are there multiple copies of the same C++ .dll's on my computer?

Question

I notice that Microsoft Visual C++ runtime libraries are duplicated all over my computer, eg: at the following locations:

C:\Windows\System32
C:\Windows\SysWOW64
C:\Program Files\Common Files\microsoft shared
C:\Program Files (x86)\Mozilla Firefox
C:\Windows\WinSxS\amd64_microsoft-windows-u..lcrt-apifwd-winblue_31bf3856ad364e35_6.3.9600.18036_none_b157f27efd203c73
C:\Windows\WinSxS\x86_microsoft-windows-u..lcrt-apifwd-winblue_31bf3856ad364e35_6.3.9600.18036_none_553956fb44c2cb3d

Why is this? I thought a specific .dll could only be registered ONCE with windows? Is that not the case? Can you really register the same .dll from multiple locations?

I uninstalled an old version of Skype which had the C++ .dll's in its own folder. But doing so caused a whole load of other programs to break (eg Adobe Acrobat, etc). I fixed it by repairing the C++ 2015 redistributable from Control Panel's Programs & Features window. But while checking the damaged files were re-created and re-registered, I discovered so many versions. How do I know which one is registered with Windows?

If I wanted to write code that referenced those .dll's, which one would it use?

Answer 1

I found a hint of reason for this in this article.

Consider this scenario: you install program “A” and it uses library version 1. You then install program “B” and it also uses library version 1, 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 as a result.
• It never uninstalls the library because another program might be using 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 most programs now don’t bother to try and share at all.

Putting Your Fate in Someone Else’s Hands:

Ultimately, application vendors realized that by relying on shared libraries like this, they were putting their fate into the hands of every other application that happened to use the same version of the same library. If only one of them made a mistake, and the library was accidentally removed or updated when it shouldn’t have been, it put all the others at risk.

So, application vendors typically now install their own copy of the library that they manage and that they can rely on. Disk space is cheap – much cheaper than the errors and frustration that were happening when they tried to share.

So now, on my machine, many different applications all carry with them their own copy of the Microsoft Visual C++ Runtime.

And each is more stable as a result, by virtue of being in control of their own destiny.

However, it remains unclear how dll files can be registered with the same name but from different locations. I did not think this was possible, but perhaps it is.