[Addon] Microsoft Runtime Libraries Collection(x86) 2.0.7

[yumeyao]

This is intended for keep code65536's work going. Besides merely an update, I decide to divide it into several packs, for VC7-9 runtimes is almost a must-have while old VC1/VB1-4 runtimes is only for those who work with old apps. Adding to that, VC10 is a new-comer, on which nearly no apps are developed till now.

Goal

Different from code65536's goal, my goal is to provide basic Microsoft runtime coverage to satisfy the common needs that is missing from Windows XP while still providing stuffs to fill the "gaps" that Microsoft left. I have included only Microsoft C-family runtimes (CRT/MFC/etc.) and VB runtimes. No third-party non-Microsoft runtimes are included. No ActiveX controls are included. Only language runtimes. If you are looking for more than just runtimes or if you are looking for third-party libraries, then one of the other addons may be better suited for your needs.


Why a "true addon" and why not?

First, this is a "no-frills" pack. Second, the installation happens during the text setup and the very beginning of GUI setup(VC8-9), which means that the runtimes here will be installed early enough that programs that depend on these runtimes can be run at any time during Windows setup. Finally, this is an extremely "clean" install; there are no CABs to unpack, no INFs to process, which means this pack "leaves no trace".

The cons of this pack, however, is the unavoidable size increase of you XP Disc. The size increase is further more than the addon's size since the addon is compressed in 7-zip, probably the best one, while the files on XP Disc are compressed in cabinet. In the case you want to save space, please consider using a switchless installer. Additionally, there seems to be some apps that don't like the true addon and insist to install the runtimes of their own.

So I offer them both.


Overview of Microsoft Runtimes

• VC1: included in this addon as a component of Legacy Addon
• VC2-VC6: bundled with WinXP (untouched by this addon)
• VC7-VC10: included in this addon as Mainstream Addon
• VB1-VB4: included in this addon as components of Legacy Addon
• VB5-VB6: bundled with WinXP (untouched by this addon)
• VB7+: part of the .NET CLR; not included in this addon, please check my .NET Releases.

Mainstream Pack
Contains VC7-10 runtimes.

• True Addon(The VC8/9 runtimes are installed as WinSxS assemblies, and VC7/VC10 runtimes are installed to %SystemRoot%\system32. And if you are wondering, yes, I omitted msdia on purpose.):
  • YumeYao_MicrosoftVC78910RuntimeLibraries_Addon_2_0_7.7z
    Size: 5.15 MB (5,403,130 Bytes)
    MD5: b9570dcacdb203f135c94ae03760d49e
  Mixed Addon(VC7 are integrated as true addon, VC8-10 are installed at T-13):
  • YumeYao_MicrosoftVC78910RuntimeLibraries_MixedAddon_2_0_7.7z
    Size: 6.43 MB (6,745,727 Bytes)
    MD5: 708bd36e0bd3a00c59f76597eb83e636
  • Contents in detail:

  Code: Select all

  /*-- C standard library (CRT) ----------------------------------------*/ 
  
  [7.0.9981.0    ] msvcr70.dll
  [7.10.7031.4   ] msvcr71.dll
  [8.0.50727.6195] msvcr80.dll
  [9.0.30729.6161] msvcr90.dll
  [10.0.40219.325] msvcr100.dll
  
  /*-- Managed C runtimes ----------------------------------------------*/ 
  
  [8.0.50727.6195] msvcm80.dll
  [9.0.30729.6161] msvcm90.dll
  
  /*-- Legacy iostream.h library ---------------------------------------*/ 
  
  [7.0.9955.0    ] msvci70.dll
  
  /*-- C++ standard library (STL) --------------------------------------*/ 
  
  [7.0.9466.0    ] msvcp70.dll
  [7.10.6052.0   ] msvcp71.dll
  [8.0.50727.6195] msvcp80.dll
  [9.0.30729.6161] msvcp90.dll
  [10.0.40219.325] msvcp100.dll
  
  /*-- Microsoft Foundation Class Library (MFC) ------------------------*/ 
  
  [7.0.9975.0    ] mfc70.dll, mfc70u.dll, mfc70???.dll
  [7.10.6119.0   ] mfc71.dll, mfc71u.dll, mfc71???.dll
  [8.0.50727.6195] mfc80.dll, mfc80u.dll, mfc80???.dll
  [9.0.30729.6161] mfc90.dll, mfc90u.dll, mfc90???.dll
  [10.0.40219.325] mfc100.dll, mfc100u.dll, mfc100???.dll
  
  /*-- Microsoft Foundation Class Managed Library ----------------------*/
  
  [8.0.50727.6195] mfcm80.dll, mfcm80u.dll
  [9.0.30729.6161] mfcm90.dll, mfcm90u.dll
  [10.0.40219.325] mfcm100.dll, mfcm100u.dll
  
  /*-- Active Template Library (ATL) -----------------------------------*/
  
  [7.0.9975.0    ] atl70.dll
  [7.10.6119.0   ] atl71.dll
  [8.0.50727.6195] atl80.dll
  [9.0.30729.6161] atl90.dll
  [10.0.40219.325] atl100.dll
  
  /*-- Open Multi-Processing libraries (OMP) ---------------------------*/
  
  [8.0.50727.6195] vcomp.dll
  [9.0.30729.6161] vcomp90.dll
  [10.0.40219.325] vcomp100.dll

Legacy Pack
Contains VC1 and VB1-4 runtimes. The VB runtimes are installed to %SystemRoot%\system, and VC1 CRT runtime is installed to %SystemRoot%\system32.

• • YumeYao_MicrosoftOldRuntimeLibraries_Addon_1_0_0.7z
    Size: 1.09 MB (1,151,861 Bytes)
    MD5: 43f688e16ddeffbfbe74b0b0c670d7de
  • Contents in detail:

  Code: Select all

  /*-- C standard library (CRT) ----------------------------------------*/
  
  [1.0           ] msvcrt10.dll
  
  /*-- Visual Basic runtimes -------------------------------------------*/
  
  [1.00          ] vbrun100.dll
  [2.0.9.8       ] vbrun200.dll
  [3.0.5.38      ] vbrun300.dll
  [4.0.24.22     ] vb40016.dll
  [4.0.29.24     ] vb40032.dll

Changelog:
* 2011/8/14: Updated VC10.
* 2011/6/17: Updated VC8 and VC9.
* 2011/4/12(again): Updated VC7.1 too.
* 2011/4/12: Updated VC8/VC9 Runtimes to latest MFC Update.
* 2011/3/10: Updated VC10 Runtime to SP1.
* 2011/1/21: Updated VC9 libraries. Merged VC10 into Mainstream pack(Time for this, I think).
* 2010/10/28: Updated VC9 and VC10 libraries.
* 2010/9/18: Fixed the errors in VC10 addon. Added the T-13 installer addons.
* 2010/9/15: Contains VC7.1 ATL/MFC, VC8 runtimes for MS09-35 and VC9 runtimes for KB982062.

[George King]

Nice, waiting for this

[mr_smartepants]

The VC10 runtime addon .ini file list doesn't match the file names and is causing a "missing file" error during dosnet filecopy.
[dosnet_files]
<snip>
d1,mfc100cn.dll
d1,mfc100de.dll
d1,mfc100es.dll
d1,mfc100fr.dll
d1,mfc100it.dll
d1,mfc100jp.dll
d1,mfc100ko.dll
d1,mfc100ru.dll
d1,mfc100tw.dll
d1,mfc100us.dll


Filenames are:
mfc100chs.dll (instead of mfc100cn.dll)
mfc100deu.dll (instead of mfc100de.dll)
etc...

[yumeyao]

Oh, yes, I forgot to rename the files. Fixed. Sorry for that.

[ChiefZeke]

Great job and thanks for all the good work.

[mr_smartepants]

Yumeyao, you need to update the first post with the new MD5 for the VC10 pack.
MD5: deef2442f07469b252caf2f7a0c64a7f

Great job for all these!

[yumeyao]

Yes. Done.

[vioplujjnsjzfg]

Thanks for this updated pack however I have a quick question.

When I used to use code65536's pack to provide the VC8 & VC9 runtimes for your .NET installer, everything used to work fine except when I would install other programs which needed these runtimes, they would install the runtimes again from the redist installer as if it couldn't detect the runtimes from code65536's pack. Will this be an issue with this pack?

Thanks again.

[yumeyao]

yes. the integration method is same as code65536's.

[bphlpt]

Is there not a way to "register" (for lack of a better word) the runtimes so that this issue does not occur? Personally, it always annoys me when that happens. ("But they're already there!" I scream at my monitor) Not a huge deal, but an annoyance.

Cheers and Regards

[yumeyao]

Maybe a similar solution like Onepiece's .NET True addons could fix this issue.

Alternatively, you can use T-13 installer for VC8/9.

[mr_smartepants]

There's another bug in the vc10 addon. Extra trailing commas ',' in the entries.ini. Causes an "error in line xxxx in txtsetup.sif..."

Code: Select all

[txtsetup_files]
atl100.dll   = 100,,,,,,,2,0,0
mfc100.dll   = 100,,,,,,,2,0,0
mfc100cn.dll = 100,,,,,,,2,0,0,mfc100chs.dll
mfc100de.dll = 100,,,,,,,2,0,0,mfc100deu.dll
mfc100es.dll = 100,,,,,,,2,0,0,mfc100esn.dll
mfc100fr.dll = 100,,,,,,,2,0,0,mfc100fra.dll
mfc100it.dll = 100,,,,,,,2,0,0,mfc100ita.dll
mfc100jp.dll = 100,,,,,,,2,0,0,mfc100jpn.dll
mfc100ko.dll = 100,,,,,,,2,0,0,mfc100kor.dll
mfc100ru.dll = 100,,,,,,,2,0,0,mfc100rus.dll
mfc100tw.dll = 100,,,,,,,2,0,0,mfc100cht.dll
mfc100us.dll = 100,,,,,,,2,0,0,mfc100enu.dll
mfc100u.dll  = 100,,,,,,,2,0,0,
mfcm100.dll  = 100,,,,,,,2,0,0,
mfcm100u.dll = 100,,,,,,,2,0,0,
msvcp100.dll = 100,,,,,,,2,0,0,
msvcr100.dll = 100,,,,,,,2,0,0,
vcomp100.dll = 100,,,,,,,2,0,0,

should be:

Code: Select all

[txtsetup_files]
atl100.dll   = 100,,,,,,,2,0,0
mfc100.dll   = 100,,,,,,,2,0,0
mfc100cn.dll = 100,,,,,,,2,0,0,mfc100chs.dll
mfc100de.dll = 100,,,,,,,2,0,0,mfc100deu.dll
mfc100es.dll = 100,,,,,,,2,0,0,mfc100esn.dll
mfc100fr.dll = 100,,,,,,,2,0,0,mfc100fra.dll
mfc100it.dll = 100,,,,,,,2,0,0,mfc100ita.dll
mfc100jp.dll = 100,,,,,,,2,0,0,mfc100jpn.dll
mfc100ko.dll = 100,,,,,,,2,0,0,mfc100kor.dll
mfc100ru.dll = 100,,,,,,,2,0,0,mfc100rus.dll
mfc100tw.dll = 100,,,,,,,2,0,0,mfc100cht.dll
mfc100us.dll = 100,,,,,,,2,0,0,mfc100enu.dll
mfc100u.dll  = 100,,,,,,,2,0,0
mfcm100.dll  = 100,,,,,,,2,0,0
mfcm100u.dll = 100,,,,,,,2,0,0
msvcp100.dll = 100,,,,,,,2,0,0
msvcr100.dll = 100,,,,,,,2,0,0
vcomp100.dll = 100,,,,,,,2,0,0

[yumeyao]

Fixed. I was too careless.

And added 2 T-13 addons for those apps to detect installed runtimes.

BTW IE9 sucks the mediafire's uploader doesn't work. I'll later provide a mirror.

[wolfsoul]

Ok sorry for the queston.. but basically kel's runtiems contains these too right?
I need these for your NET addons.. but I keep getting runtimes errors so Im trying to figure out the best method, well I usually use his pack

[digital john]

is possible to provid a new mirror, because it downloads
until 3mb and it brokes

[yumeyao]

updated.

[kinzy2004]

any other download mirror please

[DeTard]

Is there any other upload sites you can possibly choose other than FileSonic? It's okay if I'm only downloading 1 file, I can wait the 1 minute required for that. But each and every subsequent files are 15 minutes wait. And sometimes after waiting the 15 minutes, it incorrectly thinks you already are downloading a file and starts your timer over. That's a bit ridiculous is it not?

[kinzy2004]

U know mediafire and rapidshare could have done more better than that website ive been over since the topic started cant inetgrate this into my cd becoz i cant download it! filesonic is the most ridiclouse server ever it will give me after countin down not allowed and then when i try again wait 15 mins plz reupload on differnt mirror asap

[yumeyao]

updated.

I'll later add a direct link.

[yumeyao]

Fixed MixedAddon. The previous one didn't work, please re-download the MixedAddon.

[trippinferret]

Thanks YumeYao

Will try out your addon, with my choice of other as well, see how it goes.

[yumeyao]

Updated VC10 Runtime Library to SP1.

[vmanda]

@yumeyao
Mixed mode addon contains VC 9.0.30729.5558. Where did you get this version?
The latest version that i have are (the most common) 9.0.30729.4148

Also seems that most of programs ask for 9.0.30729.4148

[ricktendo64]

Mixed mode addon contains VC 9.0.30729.5558. Where did you get this version?

KB2435853

[vmanda]

thanks ricktendo64 for clarifications.

but since i'm not one visual studio developer, i'm need it?

lookink at description for VS90SP1-KB2435853-x86.exe make me laugh.

Description VS 2008 SP1: Different return values from the trigonometric method sin() in 32bit and 64bit

Just in M$ world this can happens.

[code65536]

but since i'm not one visual studio developer, i'm need it?

You don't have to be a developer to take advantage of runtime changes. Any program compiled w/ VS9 that dynamically links to the CRT can make use of this new runtime.

Just in M$ world this can happens.

No. Trig functions are floating-point operations, and floating point math, unlike integer math, is very complicated. In the world of FP, there are many different ways to calculate something. Some are more precise but slow, some are faster but less precise. Some make use of certain CPU optimizations, while some do not. Etc. The problem here is that the x64 runtime uses a different method to calculate than the x86 runtime. Neither method is wrong per se, but different approaches produce slightly different results (and have different performance figures). Personally, I'm not sure I'd even call this a bug.

[vmanda]

Different return values from the trigonometric method sin() in 32bit and 64bit

Just in M$ world this can happens.

Well, mathematically speaking, trigonometric method sin(), from a given number,
with same given precision, needs to have same result both on 32bit or 64bit processors or OS'es.
Given precision means same number of digits after zero and same rounding methods.

Another thing, wtf to stop programs that install it's own versions of VC 8/9, even if allready
is installed one newer version?

[bphlpt]

Well, mathematically speaking, trigonometric method sin(), from a given number,
with same given precision, needs to have same result both on 32bit or 64bit processors or OS'es.

And preferably the correct result.

Another thing, wtf to stop programs that install it's own versions of VC 8/9, even if allready
is installed one newer version?

I have wondered this myself.

[5eraph]

Well, mathematically speaking, trigonometric method sin(), from a given number,
with same given precision, needs to have same result both on 32bit or 64bit processors or OS'es.
Given precision means same number of digits after zero and same rounding methods.

64-bit calculations can offer much higher native precision than 32-bit. This applies to floating point operations as well as integer operations. 64-bit processors also have many more registers in x64 mode (enabled by 64-bit operating systems), which can make certain operations far more efficient. Different methods are required to take full advantage of 64-bit.

And preferably the correct result.

LOL. I remember the original Pentium's huge floating point flaw. Is that what you're referring to?

[code65536]

same given precision

There are two definitions of "precision" here. The first is simply the bit count. A 32-bit floating point number, naturally, has less precision and less range than a 64-bit floating point number.

The other definition of precision is an algorithmic one, usually dealing with accuracy (but incorrectly called "precision" in the official language) and its trade-off for performance, and that is what we're talking about.

[vmanda]

Well, mathematically speaking, trigonometric method sin(), from a given number,
with same given precision, needs to have same result both on 32bit or 64bit processors or OS'es.
Given precision means same number of digits after zero and same rounding methods.

I'm physicist, for me nevermind what procesor i have on mine's computer, if i'm using computer,
or i'm using just my pen and some paper, and nevermind what method i'm using to calculate,
theses are just minor details, but allways 1 = 1 . In the computer world, seems that this is not allways true.
I never refered to CPU or FPU precision. And because M$ allready fixed differences between 32 and 64
bit versions, by releasing VC 9.0.30729.5558, seem that are technically possible to have same results on both.

Just in M$ world this can happens,

I just wondered why m$ not made this way from first release, nothing else.

[5eraph]

As a physicist you should be more concerned with significant digits than a processor's precision. The datum of lowest mathematical precision determines a calculation's usable accuracy. In this case, fast yet less accurate results are still usable as long as it's accurate to the least significant digit.

[bphlpt]

And preferably the correct result.

LOL. I remember the original Pentium's huge floating point flaw. Is that what you're referring to?

- Yes -

Another thing, wtf to stop programs that install it's own versions of VC 8/9, even if allready is installed one newer version?

I have wondered this myself.

I would love to see a discussion of what people have found successful to keep this from happening.

Cheers and Regards

[ricktendo64]

Another thing, wtf to stop programs that install it's own versions of VC 8/9, even if allready
is installed one newer version?

Depends on the installer, if its a MSI you can probably delete or update the vc runtimes installer thats in the MSI

[vmanda]

Also, I want some clarifications from Yumeyao and maybe Kelsenellenelvian.

When we are using Kelsenellenelvian: Kels' Runtimes v7.6+, we are need to use and one
of "Mainstream Packs" (True Addon or Mixed Addon) and "Legacy Pack" too?

I'm corect integrating this packs?
1.Kels_Runtimes_addon_v7.6.rar
2.a.YumeYao_MicrosoftVC78910RuntimeLibraries_Addon_2_0_3.7z
OR
2.b.YumeYao_MicrosoftVC78910RuntimeLibraries_MixedAddon_2_0_3.7z
3.YumeYao_MicrosoftOldRuntimeLibraries_Addon_1_0_0.7z

[jaynbe]

Depends on what you want to integrate; if you want them all:

1.Kels_Runtimes_addon_v7.6.rar
2.YumeYao_MicrosoftVC78910RuntimeLibraries_Addon_2_0_3.7z
3.YumeYao_MicrosoftOldRuntimeLibraries_Addon_1_0_0.7z

Kels does NOT contain any of YumeYao's
VC78910 a/or b are the same (TRUE vs. Mixed-T13 pack)
T13 has some detection advantage over the TRUE packs.
(Mixed-T13 installs the MS VC++ redistributables)

[bphlpt]

And then in addition you need .NET along with some of the extra addons that YumeYao has created since he has separated things out into separate addons so not to have duplicates. But that still doesn't answer the question of a reliable way to do things to minimize the likelyhood of another installer thinking they need to add their own version of VC 8/9 as well, or is there one?

Cheers and Regards

[jaynbe]

Some third party apps may check for installed VC++ strings.
Your best bet will be the VC++ distributables which are complete installs.
Be aware that Microsoft also documents side by side install for VC++.

[code65536]

As a physicist you should be more concerned with significant digits than a processor's precision. The datum of lowest mathematical precision determines a calculation's usable accuracy. In this case, fast yet less accurate results are still usable as long as it's accurate to the least significant digit.

Indeed. Scientific computing applications that require higher degrees of precision usually roll their own algorithms anyway.

I remember, many years ago, I was using a video encoding program (can't remember what it was), and it had the option to use some of the CPU's multimedia acceleration instructions, instead of using a slower, but (slightly) more accurate method. The difference in results between the two were imperceptible.

Another thing, wtf to stop programs that install it's own versions of VC 8/9, even if allready is installed one newer version?

Since the new versions override the old ones, the only downside here is a few MB of lost disk space. But aside from ripping out the redist MSI from the installer, there is no way that I'm aware of.

[user_hidden]

Also, I want some clarifications from Yumeyao and maybe Kelsenellenelvian.

When we are using Kelsenellenelvian: Kels' Runtimes v7.6+, we are need to use and one
of "Mainstream Packs" (True Addon or Mixed Addon) and "Legacy Pack" too?

i use the below with my updatepack and my ROE dotNet:
Kels_Runtimes_addon_v7.6.rar
YumeYao_MicrosoftVC78910RuntimeLibraries_AddonMixed_2_0_3.7z
YumeYao_MicrosoftOldRuntimeLibraries_Addon_1_0_0.7z

[vmanda]

Thanks user_hidden. It's like i have thinked from first, but it's most good to be crystal clear.

Another thing, wtf to stop programs that install it's own versions of VC 8/9, even if allready is installed one newer version?

Since the new versions override the old ones, the only downside here is a few MB of lost disk space. But aside from ripping out the redist MSI from the installer, there is no way that I'm aware of.

When/if an older version overwrite this registry keys

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\DevDiv\VC\Servicing\8.0\RED\1033]
"Install"=dword:00000001
"InstallerType"="MSI"
"SP"="1"
"SPIndex"=dword:00000000
"SPName"="RTM"

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\DevDiv\VC\Servicing\9.0\RED\1033]
"Install"=dword:00000001
"InstallerType"="MSI"
"SP"=dword:00000001
"SPIndex"=dword:00000001
"SPName"="SP1"

some of applications will fail to start even if the correct dll's are into system32 and/or WinSxS folder.
I do not say that's a general situation but this sh!ts happens.
The main mistake come from m$, that never think to make things easy to be upgraded and serviced.
The second mistake come from software developers, that almost never do not check if installed version are newer.
But i blame only m$, she do not have one uniform and failfree strategy for updating visual studio C++, .NET, etc.

[Zoom7000]

Does anyone have any mirrors as filesonic is just terrible for me!

EDIT: Sorry, just saw the MediaFile link!

[RicaNeaga]

Additionally, there seems to be some apps that don't like the true addon and insist to install the runtimes of their own.

I have the mixed addon, and those apps STILL installs their own runtimes. Or at least that's what my add/remove programs windowis saying.

[jaynbe]

Additionally, there seems to be some apps that don't like the true addon and insist to install the runtimes of their own.

I have the mixed addon, and those apps STILL installs their own runtimes. Or at least that's what my add/remove programs windowis saying.

Some apps allways install their own (even outdated) runtimes.

That's why we should make addons with removed VC++ runtimes.

Example: PaintNet: http://www.ryanvm.net/forum/viewtopic.php?t=8881

[yumeyao]

updated.

[Shiva]

VS7.1sp1-KB2465373-X86
http://www.microsoft.com/downloads/en/d ... laylang=en
http://support.microsoft.com/?kbid=2465373

THANKS!!

[yumeyao]

updated. Thanks for reminding.

[adric]

Is MS11-025: security update for Visual C++ 2005 SP1 Redistributable Package: April 12, 2011 KB2467175 included in any of the changes or do I need to manually update this?

Al

[yumeyao]

Sure it's included.