Here's the changelog I see needed for the repo. This list should be considered a starting point for getting the repo current since there's probably an error or two (or more). Once this batch gets uploaded, we can test and refine it further. Also, I did this on x64, so there might be a couple differences for x86. All thanks should go to komm and SoLoR since they're the ones doing the hard work on this. SoLoR, if this info isn't sufficient, let me know and I'll try to add detail as needed. Add: 951422-v2 (partially superseded by 2647409) 2461249 2519922-v2 2524478-v2 2525835 2582203-v2 2603469 2619836 2627489-v3 2633200 2633205 2636056-v2 2640696 2644491 2646168 2649905 2652029 2652246 2652553 2653030 2653312 2653385 2654363 2655087 2657025 2659071 2659158 2660114 2661001 2661641 2661663 2661672 2661794 2661796-v2 2662288 2662585 2663352 2663418 2664055 2664408-v2 2664446 2664888 2669522 2675469 Superseded: 2401588 (by 2661001) 2491683 (by 2644491) 2507840 (by 2633205) 2512889 (by 2659071) 2515325 (by 2664055) 2519922 (by 2519922-v2) 2534111 (by 2652029) 2553549 (by 2655087) 2561708 (by 2649905) 2569339 (by 2664446) 2578963 (by 2633200) 2580442 (by 2653030) 2584146 (by 2636056-v2) 2598773 (by 2669522) 2614122 (by 2662288) 2624641 (by 2524478-v2) 2627484 (by 2627489-v3) 2633952 (by 2657025) 2635217 (by 2654428) 2646761 (by 2654363) 2647841 (by 2603469) 2649868 (by 2663352) 2660465 (by 2661001) 2661663 (by 2664408-v2) 2654347 (by 2675469)
Yes those versions are correct I was meant to also put in the last post that even though the file versions for 2005 redist are 8.0.20727.6229, it shows as 8.0.61186 (for x64) and 8.0.61187 (for x86) in add/remove programs A side note to anyone that may be confused as to why x86 and x64 versions show on x64 system, the x86 versions are used by 32-bit programs, and the x64 versions by 64-bit programs. On x64, you need both installed so both 32-bit and 64-bit programs are covered.
A couple of things I seeL KB2519922 (V2) not needed. The V2 is available alongside the original version, the difference being V2 includes the GDR files as well, whereas the original version only the LDR files (same versions of the LDR files in original and V2). KB951422-V2 seems to be valid, must have been missed earlier. KB2640696 is KB2640696-V3, not just KB2640696 KB2661663 is KB2661663-V3, not just KB2661663 KB2675469 links are requestable, but not downloadable (file not found error)
Maybe, but we should always take the latest version. So move 2519922-v1 to LDR placeholder and take 2519922-v2. Or will your installer tell the user to uninstall v2 and install v1? We should not discuss about "not taking an update with a higher version number"! If 2 different kb# updates contain the same version we can decide witch one to take. But it should be a rule to always take the highest version#. Kb2675469 is a .net update. There seams to be a problem of downloading this kind of updates with the strange link. I saw that in the last view weeks. You must try as long as you can and then, suddenly, it can be downloaded. Nevertheless, it can be found in my win7 folder. @PointZero Thanks for your quick work. 2647841: only the x64 version is superseded. you missed 2644615 in the superseded updates (replaced by 2582203) 2661663-v3 is superseded by 2664408 2554746 is superseded by 2665875 (MSMQ) "partially superseded" we should not use this kind; only YES or NO like pregnancy. If nobody else found a problem in pointzero's list, someboy else should create a .7z with all the new updates. So SoLoR can download it. I think he would prever the -zip.exe files so the filedates are preserved. This .7z must not be public only send Solor the link.
No, haven't needed to! apart from a few code 'cosmetics' that I could do, there really isn't anything that needs changing.
I added the updates you suggested, uploaded the batch of the original .zip versions of the updates (except for 3 that are in .msu format) and sent links to SoLoR via PM.
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