Its been reported to me that with the installation of the latest v12 of the c++ runtime installer, that both 9.0.30729.4148 and 9.0.30729.6225 show in the add/remove programs, for both the x86 and x64 versions of the 2008 runtimes. This is on a completely fresh install. I haven't seen the occurrence of the 4148 versions myself, can people check and see if they are installed too (they shouldn't be)? thanks!
burf, I checked on mine and I only see 9.0.30729.6225 for x86 & x64 (no .4148 shown) with v12 installed. Maybe a game or another app installed that older runtime on the other system??
Thats what I thought but Trinket (who asked me about it) said that it was on a fresh install... I too believe it may have been a program installer that installed it. Its a fair enough question though, because when the installer installs, the 4148 version should have been removed... I say it might be a 'dodgy' install, in many cases the order that you install things can have an affect, as well as program choice.
Like I said it's on a fresh install on VMWare Workstation 8. So it could have something to do with the fact it's a virtual machine setting, but usually installs in VMware are pretty indistinguishable from real life installs. Like I said earlier, no other programs were installed, and I checked installed programs before and after installing the VC runtimes and got that result. So who knows what caused it. BTW, when I do a fresh OS install the runtimes are normally the first thing I do, as I did this time, so again this precludes any programs from having installed earlier. In fact, I'm aware of this issue because I hate it when installers include these old runtimes and you end up with 12 different vc runtimes showing up under Programs & Features My test scenario was a fresh install in VMWare of Win7 x64. I tried a Win7 x86 install on VirtualBox later on, and there I did not get the multiple entries for VC 2008. Obviously those numbers in VMWare come from somewhere, but it is likely then that this will not take place in a live install scenario and thus may be a VM glitch/bug somehow. But, I was just checking, because most people using your installer might not immediately be using it on a fresh install of Windows, is why I wanted to make sure. So unless someone comes forward with similar problems, we can probably rule it out as a unique thing
They end up being inactive copies in the WinSxS folder instead... but at least the active copies are what matters, and they are the ones that show in Programs and Features. There's no way around this that I am aware of. DirectX and all the c++ runtimes should have been part of Windows, and have backward compatibility, at least the you can greatly limit the amount of loose files and files that are redundant still floating around everywhere. The worst thing is if programs have loose runtime files in their program folders, because they will use those over the installed runtimes if present. This means you are missing out on important stability, security, and performance changes with the newer runtimes.
Lots of MSI installers come with runtimes in them, I personally edit and remove them from all my installers: AdobeRdr, Shockwave, etc. (only one that its impossible to remove them from office 2010)
Yes, that is true, many programs include runtime files in their program folders. I wonder about the reason some apps have older runtimes included, and if it's just a matter of them being so widely tested with those particular runtimes.
Is the a resent update/hotfixlist for for office 2010? I'm talking about office updates post 2012-02-16 (Last SoLoR update)?
I think its because they're not included with the OS, and updated through Windowsupdate, like they should be. Since the runtimes aren't on the computer by default, they have to package them in case you haven't already got them installed. This is where the system is fundamentally flawed in terms of distribution. If there is the claim that individual versions are packaged for compatibility reasons, this is more of an excuse by Microsoft to take the easy way out. Newer versions should be backwards compatible, its not difficult to do so. Its an unfortunate consequence of what probably seemed a viable easy method at the time, but the result of course is a mess of outdated files. If you aren't aware, there have been security updates (cumulative, so the installer's runtimes include the security changes) for the runtimes released on Windowsupdate. That's fine, but like I was saying about programs with the runtimes in their own folders... these are loaded over the ones in the system folders, meaning there's a potential security risk. A workaround is to delete all occurrences of the runtime files not in the system folder, by doing a search in explorer (top right hand corner of explorer is the search window, unless you disabled the search feaure (search service can be disabled, and I recommend that it is!) over the program files, and program files (x86) folders. DLL files that end in 80 (2005 runtimes), 90 (2008 runtimes), or 100 (2010 runtimes), and begin with msvc are the runtime files. Main loose filenames are: msvcm80.dll, msvcp80.dll, msvcr80.dll, msvcm90.dll, msvcp90.dll, msvcr90.dll, msvcm100.dll, msvcp100.dll, msvcr100.dll These can be searched by typing in msvc*.dll and then simply deleted. This will force the apps to use the newer runtimes you installed, that reside in the system32 and syswow64 (only for x64) folders. Then you have: atl80.dll, atl90.dll, atl100.dll and then the 'mfc' files like mfcm90.dll, mfc100.dll etc. Although this is 'safe' to do, I hadn't recommended it in case people delete the wrong files. If you follow the above examples it should be fine
Hi Trinket, Just thought that I would chime in with a question regarding your problem... Did you install the VMware Tools? That installs VC runtimes.
My guess is that seeing that it is Friday (well very early Saturday here), SoLoR is going to wait until his Sunday scan before posting them...? luckily most of the updates have been already requested and link PM'd to him by PointZero, so it should make things a bit quicker and easier for him.
Thats representative of the repository, not the recent big batch of updates that SoLoR hasn't posted yet... you haven't got kb2661672 installed.