MS installs Visual C++ redistribution files

Reply

  #1  
Old 02-24-17, 07:48 AM
Norm201's Avatar
Member
Thread Starter
Join Date: Sep 2013
Location: United States
Posts: 9,184
Received 255 Votes on 229 Posts
MS installs Visual C++ redistribution files

Microsoft seems to install multiple copies of Visual C++ redistribution files.

Can I delete these files? Or at least the old ones?

 
Sponsored Links
  #2  
Old 02-24-17, 08:50 AM
P
Member
Join Date: Dec 1999
Location: Cleveland, OH USA
Posts: 593
Received 5 Votes on 5 Posts
They are installed because there are programs that use them. The problem is knowing which programs, that you have installed today or will install tomorrow, want to use them. It may even be used by part of the OS. One way to find out if you can get rid of them is to change the name or move them to a different directory. If you can run your computer for a couple of months or weeks without any pain, then you might be able to totally delete them. If anything fails, you just need to move or rename back to the original. Unless you are VERY tight on space, this 100MB is not a big deal on a modern computer.

- Peter
 
  #3  
Old 02-24-17, 09:07 AM
C
Member
Join Date: May 2015
Location: USA
Posts: 3,138
Received 2 Votes on 2 Posts
Multiple versions are kept because there are some version dependencies built into to some software. Newer programs often require features that are only present in newer versions, while older programs may not recognize or work properly with newer versions. Microsoft has come a long way toward minimizing impacts of version changes from the old dll h3!! days, but there is still a lot of old software being used.

Pjaffe gave good advice for testing whether or not they can be removed, but why bother or take the chance?

For one thing, just removing the actual libraries does nothing to remove references in the registry, so you can have problems in the future, long after having forgotten that you deleted them.
 
  #4  
Old 02-24-17, 09:29 AM
Norm201's Avatar
Member
Thread Starter
Join Date: Sep 2013
Location: United States
Posts: 9,184
Received 255 Votes on 229 Posts
Pete,

Thanks for the reply. That was my plan and I think I will try it. But you mentioned being tight on space. That is in fact my situation. I have two 1TB hard drives and both are full. I need to trim down what's on them and come up with alternative storage.
 
  #5  
Old 02-24-17, 02:50 PM
Z
Member
Join Date: Jan 2008
Location: Southeastern Pennsylvania
Posts: 3,188
Received 22 Votes on 22 Posts
Many years ago I picked up the pieces of a software project which had been suspended for about a year. The project was combining two commercial Satellite Image Processing Applications (ArcInfo and Erdas Imagine) into one new Application which would provide the benefits of those two commercial packages combined. The system was based on Windows NT and the new user interface would look very similar to Windows Explorer. The user would request certain processing for the satellite images and collect and combine results and store the products in folders, etc.

I was new to Windows (but not software) and after I had figured out where all the pieces of the project were, and what the previous team had in mind in terms of design, I encountered a problem after I was able to build and modify the software to a point where the system worked very well. The software build output was an “Installation CD” to be used in the typical Windows Software Installation process on target systems.

The problem which blew my mind is now what is known as “.dll hell”. (.dll = dynamic linked library, pieces of software used and shared by Applications). When you develop and Application in the MS Development environment, you use many of the libraries which MS makes available to you. Those libraries need to be made available, that is installed, on the target system because they are part of your Application.

So if you used a library (for example “ABC.dll) in development, then ABC.dll must be installed on the target system or your software can’t run. The problem is, like all software, MS may update the library into a newer version. So I might develop my Application “X” with ABC.dll version 1, and someone else might develop their Application “Y” with ABC.dll version 2. So both versions of ABC.dll would be needed on the target for Applications “X” and “Y” to run on that target.

But back then you couldn’t have 2 versions of the same .dll installed on the same system. The installer would ask you “which version do you want to keep?” That is an impossible situation.

Well we never finished our project and I went on to other non-MS things, and I felt bad for many years because I thought that apparently I just wasn’t smart enough to understand what MS was doing – even though I had years of experience as a programmer. I thought I must have been doing something very wrong in terms of building a software system for installation.

In my wildest dreams I never would have believed that MS had such an amateurish system – well actually a tremendously flawed and unworkable system. But as I later found out - they did! I have never gotten over that and to this day have very little confidence in any MS design. Maybe that’s not fair, but that error or whatever you want to call it defies belief.

But now off the soapbox – I would be very careful about which installed packages for Applications I removed. The installation process today is tremendously complex (download Orca and dissect an .msi file to see some of the installation variables. It’s a complex database) and MS takes into consideration MS Installed Policy Files which supersede other Policy Files and so on, which specify which .dll’s to use, etc.

For example, I might build my App with ABC.dll version 10, but an MS Policy File on the target says ABC.dll 10 is now superseded by ABC.dll 15, and yet another Policy File says ABC.dll version 15 is now superseded by ABC.dll version 17. So my App may actually run with ABC.dll version 17 (if I were a MS developer I’m not sure I would like that. I have to believe MS did a thorough job and 17 is correctly backward compatible).

Suppose your App was built with ABC.dll version 10, but ABC.dll version 10 has been superseded by ABC.dll version 11 according to a Policy File on the target. Your App will have been running with ABC.dll version 11 on the target. But suppose you remove ABC.dll version 11 on the target, so now ABC.dll version 10 is the only ABC.dll version on the target and so Windows will run your App with version 10.

Your App should run with ABC.dll version 10 because that’s what it was built with. But there will be a difference. There may be something the App used in 10, which gives a specific result in that specific target environment, which the App does not handle properly. But that problem has been masked by the fact that you have actually been using 11 and not 10 on that target environment, and 11 does different filtering so that your App sees a set of results it will in fact handle properly when it uses 11 – but not when it uses 10.

Thus dropping back to an older library might cause a new problem on your computer. So you might delete newer library packages and notice that everything still runs – but you may have caused a problem which is not immediately obvious. It may be more insidious.

If you do decide to remove some of those packages then I would do as pjaffe says.
 
Reply
Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are Off
Refbacks are Off


Thread Tools
Search this Thread
 
Ask a Question
Question Title:
Description:
Your question will be posted in: