[Release] Microsoft Runtime Libraries 1.4.8 (32-bit)

code65536 · Post by **code65536** » Tue Jul 21, 2009 2:26 pm

SymSpaceT wrote:For some of us non-coders but otherwise tech-savvy, could somebody explain why one would use this pack? What is a "runtime"?

http://en.wikipedia.org/wiki/Runtime_library

Basically, every program(*) compiled with Microsoft's C, C++, or Visual Basic compiler is going to need a Microsoft runtime library in order to run. If it was compiled with Borland's compiler, it would need a Borland runtime library. Etc.

Now, there are several ways in which a program can get the runtime library that it needs:
1) It can statically link the runtime (i.e., incorporate the stuff directly into the EXE so that it doesn't need the DLL at all), but this makes the EXE (and installer) bigger.
2) It can bundle the runtime DLL with the install package so that the runtime gets installed when the EXE gets installed; this makes the installer bigger and more complicated.
3) It can assume (or hope) that the runtime is already on the system.

In the case of (3), the runtime might be one of the runtimes bundled with Windows (see the first post for what runtime libs are bundled with XP), or the program might instruct the user to download and install the runtime before installing the program (this is something usually seen with homegrown software). Or, since so many programs use the VC8 and VC9 runtimes, the programmer might assume that the user had probably already installed those runtimes when installing another program.

Depending on which version of Microsoft's compiler is used, the program that takes the (3) route might require a runtime that is already included in Windows (if using VC6 or earlier or if using a DDK compiler which links to the system CRT instead of a VC CRT) or, more commonly, it might require a runtime that is not included, e.g., people who compile with Visual Studio 2002/3/5/8 (or an early VB version).

This pack adds the runtimes for VS2K2/3/5/8 (and the early VB versions) so that programs that go with method 3 are covered. This runtime pack is different than most other runtime packs because it is installed during text setup, which means that if you happen to run a method 3 program at T-13, it will be covered.

Oh, and one more thing: these are the latest versions available, and due to SxS version override "policies", installing this pack also means that any program that needs one of these runtime DLLs (even if they take the bundle-their-own method 2 approach (**)) will end up using these latest runtimes with all the latest bug fixes.

(*) Actually, I lied. Not all C/C++ programs require a runtime library, and it is possible to build programs that don't require the C runtimes at all (e.g., my FontReg utility), but these programs are relatively rare (if you don't count drivers), so for the purposes of illustration, I said "every program".

(**) Well, there are exceptions, but there's no need to bore into the technical minutiae.

SymSpaceT · Post by **SymSpaceT** » Tue Jul 21, 2009 2:43 pm

Hi code65536!

Thanks for the great explanation. You are one of those few who can explain things very clearly; I wish all folks were like this.
What is notoriously missing from like 98% of the topics here is a brief, well-written intro on the issue at hand in the first post. A few to-the-point sentences (including some background info) make all the difference!

Thanks again.

SymSpaceT

code65536 · Post by **code65536** » Tue Jul 28, 2009 11:53 pm

Updated the VC7.1 ATL/MFC, VC8, and VC9 runtimes for today's MS09-35 security bulletin.

ricktendo64 · Post by **ricktendo64** » Fri Jul 31, 2009 12:03 am

ty code

BTW MU still tells me I need to install KB973923 is that related to this pack at all?

code65536 · Post by **code65536** » Fri Jul 31, 2009 7:17 am

ricktendo64 wrote:BTW MU still tells me I need to install KB973923 is that related to this pack at all?

The files installed by KB973923 are exactly identical to the files found in this pack (I've verified the checksums). So if MU is offering KB973923, then it is obviously having trouble detecting that the new runtimes are present. Could be a bug in MU. Or could be another one of those cases where MU checks for some magic registry key. Or MU might be looking for some MSI information (since these runtimes are installed using Windows Setup and not MSI, there won't be any residual MSI information left behind for MU to sniff). You can ignore the MU update. At least the MU update only contains ATL (and not the other runtimes that the full update bundles), so it's a fairly small package.

ricktendo64 · Post by **ricktendo64** » Sat Aug 01, 2009 12:58 pm

This is all MU needed to shush, I can add it to the entries.ini so nLite will add it to nlite.inf using a [registry_addreg] directive

entries_msrtl.ini:

Code: Select all

[registry_addreg]
HKLM,"SOFTWARE\Microsoft\DevDiv\atl80sp1\Servicing\9.0\kb973923\1033","Install",0x10001,1
HKLM,"SOFTWARE\Microsoft\DevDiv\atl80sp1\Servicing\9.0\kb973923\1033","InstallerType",,"MSI"
HKLM,"SOFTWARE\Microsoft\DevDiv\atl80sp1\Servicing\9.0\kb973923\1033","SP",0x10001,1
HKLM,"SOFTWARE\Microsoft\DevDiv\atl80sp1\Servicing\9.0\kb973923\1033","SPIndex",0x10001,1
HKLM,"SOFTWARE\Microsoft\DevDiv\atl80sp1\Servicing\9.0\kb973923\1033","SPName",,"SP1"
HKLM,"SOFTWARE\Microsoft\DevDiv\VC\Servicing\9.0","SP",0x10001,1
HKLM,"SOFTWARE\Microsoft\DevDiv\VC\Servicing\9.0","SPIndex",0x10001,1

dumpydooby · Post by **dumpydooby** » Sat Aug 08, 2009 12:40 pm

code65536 wrote:
chetri wrote:doesnot support resume
Resumption is not supported on my personal server as an unfortunate and unavoidable side-effect of forcing abusive download accelerators to behave. The other links are located on file hosting services (Google Page Creator, Rapidshare, and Stashbox), and none of these file hosting services support resumption either (probably also because of the abusive DA problem).

If anyone really must have resumption support because of things like an unstable connection, then, if requested via PM, I can provide download URLs for a section of my server that does not have resumption support disabled. (chetri, check your PM)

I might consider making my downloads available via BitTorrent (which would obviously be resumable), but that seems like a lot of hassle, and I think that it is fairly uncommon to get cases where a connection is so unstable that resumption is necessary for a file of this size.

Easiest solution seems like it would be to have a guest FTP and ban users that abuse it. FTP has resumption support. You can use links to dynamically populate the FTP directory, in the event that you don't want everything to be visible to the account. Or make the file listing password-dependent with the password being a file name so that only versions of that file show up.

If I were looking to come up with an easy alternative, that would be it.

Personally, though, I'd just write a script that limits the number of simultaneous connections a user can establish to any files that are served through the script, and then, of course, put all of the files in a non-public location.

laddanator · Post by **laddanator** » Fri Aug 14, 2009 2:53 pm

ricktendo64 wrote

This is all MU needed to shush, I can add it to the entries.ini so nLite will add it to nlite.inf using a [registry_addreg] directive

entries_msrtl.ini:
Code:
[registry_addreg]
HKLM,"SOFTWARE\Microsoft\DevDiv\atl80sp1\Servicing\9.0\kb973923\1033","Install",0x10001,1
HKLM,"SOFTWARE\Microsoft\DevDiv\atl80sp1\Servicing\9.0\kb973923\1033","InstallerType",,"MSI"
HKLM,"SOFTWARE\Microsoft\DevDiv\atl80sp1\Servicing\9.0\kb973923\1033","SP",0x10001,1
HKLM,"SOFTWARE\Microsoft\DevDiv\atl80sp1\Servicing\9.0\kb973923\1033","SPIndex",0x10001,1
HKLM,"SOFTWARE\Microsoft\DevDiv\atl80sp1\Servicing\9.0\kb973923\1033","SPName",,"SP1"
HKLM,"SOFTWARE\Microsoft\DevDiv\VC\Servicing\9.0","SP",0x10001,1
HKLM,"SOFTWARE\Microsoft\DevDiv\VC\Servicing\9.0","SPIndex",0x10001,1

I couldnt get this to work for me kb973923 is still showing up in MU

ricktendo64 · Post by **ricktendo64** » Fri Aug 14, 2009 5:11 pm

Only works with nLite

vioplujjnsjzfg · Post by **vioplujjnsjzfg** » Wed Nov 18, 2009 10:47 am

Thanks, code, for this great addon. I've been using it for several months in my regular system builds.

Something has come up recently, though, that's causing me some minor aggravation. While writing some software installers, I decided to use MsiQueryProductState Function as a method of testing for the presence of the latest Runtimes on the system. The research I've done indicated that this was probably the most reliable method of checking for the presence of a required runtime.

Needles to say, since your addon package installs the runtimes without the use of an msi installer, the runtimes remain undetectable using this method. Could you (or anyone else reading this) suggest a better mthod or, perhaps, give me an additional method to test for the presence of the runtime installed using your addon?

Post by **mooms** » Wed Nov 18, 2009 2:18 pm

windows update can detect, but it will not help in you case.
btw, the runtimes are not up to date anymore, but you can easily replace the files in the archive with the latest ones.

jaynbe · Post by **jaynbe** » Fri Nov 20, 2009 7:07 am

@ vioplujjnsjzfg,
The addon lacks the msi reghives for WindowsUpdate and the MsiQueryProductState Function.
On 1-aug ricktendo has post the entries to add to the .ini to solve this problem when using nLite.
For RVMI these entries require a new .inf in the addon since RVMI doesn't support addreg from ini.
Also the hives for KB973924 should be added for MsiQuery.

@ mooms,
If you followed the recent posts in the thread, you would have noticed that the addon contains all
of the last up to date .dll's. It is the above same reason why WU doesn't detect it.

vioplujjnsjzfg · Post by **vioplujjnsjzfg** » Fri Nov 20, 2009 4:12 pm

jaynbe wrote:The addon lacks the msi reghives for WindowsUpdate and the MsiQueryProductState Function.
On 1-aug ricktendo has post the entries to add to the .ini to solve this problem when using nLite.
For RVMI these entries require a new .inf in the addon since RVMI doesn't support addreg from ini.
Also the hives for KB973924 should be added for MsiQuery.

It's interesting because I have no WU/MU issues using this update. In addition, I added Rick's registry entries and then tried using the MsiQueryProductState Function and there was no detection of the presence of any of the C++ 2005 or 2008 runtimes. I tested using all 7 Product Codes for the various x_86 msi installers and didn't find a single match.

ricktendo64 · Post by **ricktendo64** » Fri Nov 20, 2009 4:34 pm

Does it work when you use the c++ redist 2k5/8 installers?

dumpydooby · Post by **dumpydooby** » Fri Nov 20, 2009 6:48 pm

It doesn't look like these are installed using the WinSxS folder structure. That's not the proper way to install them. Like code65536 pointed out, SxS does have version override policies, but its structure is built in such a way that it can retain obsolete versions. It's important that runtimes are installed into this structure properly, lest programs looking for hard-coded paths to obsolete versions fail to find the file. My guess is that the MsiQueryProductState method is looking for the runtimes within the SxS structure and it's failing to find them because they're actually located in System32.

Runtimes should only be installed into System32 on Windows 9x/NT systems.

I am by no means an expert when it comes to runtimes, so take this post with a grain of salt. If code65536 ever comes back, I'm sure he'd be willing to share his take on the issue.

ricktendo64 · Post by **ricktendo64** » Fri Nov 20, 2009 10:38 pm

Couls also be missing msdia http://www.ryanvm.net/forum/viewtopic.php?p=81430#81430

vioplujjnsjzfg · Post by **vioplujjnsjzfg** » Sat Nov 21, 2009 7:56 pm

ricktendo64 wrote:Does it work when you use the c++ redist 2k5/8 installers?

Yep, the MsiQueryProductState Function works fine when I use the 'official' runtime installers.

ricktendo64 · Post by **ricktendo64** » Sat Nov 21, 2009 8:48 pm

What about if you manually copy and register msdia files

RogueSpear · Post by **RogueSpear** » Sun Nov 22, 2009 9:08 am

Reading about MsiQueryProductState and based on my experience with windows installer (msi), it looks like the function queries the product code. The product code being one of these nonsensical Microsoft numbers (similar to sids). Perhaps if you manually merge in the appropriate registry entries it would work.

EDIT - Here are the reg entries I was talking about:

Code: Select all

[HKEY_CLASSES_ROOT\Installer\Products\0D756077321A70C3E844C138CE981581]
"ProductName"="Microsoft Visual C++ 2005 ATL Update kb973923 - x86 8.0.50727.4053"
"PackageCode"="6011BC15392D7BF4C9D1384B04754675"
"Language"=dword:00000409
"Version"=dword:0800c627
"Assignment"=dword:00000001
"AdvertiseFlags"=dword:00000184
"InstanceType"=dword:00000000
"AuthorizedLUAApp"=dword:00000001
"DeploymentFlags"=dword:00000003
"Clients"=hex(7):3a,00,00,00,00,00

[HKEY_CLASSES_ROOT\Installer\Products\3e43b73803c7c394f8a6b2f0402e19c2]
"ProductName"="Microsoft Visual C++ 2005 Redistributable"
"PackageCode"="89402836B2F60B04F9803CF6D2C84E21"
"Language"=dword:00000000
"Version"=dword:0800e739
"Assignment"=dword:00000001
"AdvertiseFlags"=dword:00000184
"InstanceType"=dword:00000000
"AuthorizedLUAApp"=dword:00000000
"DeploymentFlags"=dword:00000003
"Clients"=hex(7):3a,00,00,00,00,00

[HKEY_CLASSES_ROOT\Installer\Products\6F9E66FF7E38E3A3FA41D89E8A906A4A]
"ProductName"="Microsoft Visual C++ 2008 Redistributable - x86 9.0.21022"
"PackageCode"="F37207D363F3FBE43901D6914195B624"
"Language"=dword:00000409
"Version"=dword:0900521e
"Assignment"=dword:00000001
"AdvertiseFlags"=dword:00000184
"InstanceType"=dword:00000000
"AuthorizedLUAApp"=dword:00000001
"DeploymentFlags"=dword:00000003
"Clients"=hex(7):3a,00,00,00,00,00

[HKEY_CLASSES_ROOT\Installer\Products\b25099274a207264182f8181add555d0]
"ProductName"="Microsoft Visual C++ 2005 Redistributable"
"PackageCode"="ECF0C5769D85D534A98DCACD5B08A8A3"
"Language"=dword:00000000
"Version"=dword:0800dc10
"Assignment"=dword:00000001
"AdvertiseFlags"=dword:00000184
"InstanceType"=dword:00000000
"AuthorizedLUAApp"=dword:00000000
"DeploymentFlags"=dword:00000003
"Clients"=hex(7):3a,00,00,00,00,00

[HKEY_CLASSES_ROOT\Installer\Products\CFD2C1F142D260E3CB8B271543DA9F98]
"ProductName"="Microsoft Visual C++ 2008 Redistributable - x86 9.0.30729.4148"
"PackageCode"="F709078B0C8D814418F6D4823715B182"
"Language"=dword:00000409
"Version"=dword:09007809
"Assignment"=dword:00000001
"AdvertiseFlags"=dword:00000184
"InstanceType"=dword:00000000
"AuthorizedLUAApp"=dword:00000001
"DeploymentFlags"=dword:00000003
"Clients"=hex(7):3a,00,00,00,00,00

[HKEY_CLASSES_ROOT\Installer\Products\D20352A90C039D93DBF6126ECE614057]
"ProductName"="Microsoft Visual C++ 2008 Service Pack 1 Redistributable"
"PackageCode"="6C7E9C94F9A4F6E4EA39E910D4A1AC39"
"Language"=dword:00000409
"Version"=dword:09007809
"Assignment"=dword:00000001
"AdvertiseFlags"=dword:00000184
"InstanceType"=dword:00000000
"AuthorizedLUAApp"=dword:00000000
"DeploymentFlags"=dword:00000003
"Clients"=hex(7):3a,00,00,00,00,00

[HKEY_CLASSES_ROOT\Installer\Products\E5D9D200AB92D6E3B94CD3D7D6CB37C5]
"ProductName"="Microsoft Visual C++ 2008 ATL Update kb973924 - x86 9.0.30729.4148"
"PackageCode"="6DEFFA6BC34900042AA8FFFFEB08CF53"
"Language"=dword:00000409
"Version"=dword:09007809
"Assignment"=dword:00000001
"AdvertiseFlags"=dword:00000184
"InstanceType"=dword:00000000
"AuthorizedLUAApp"=dword:00000001
"DeploymentFlags"=dword:00000003
"Clients"=hex(7):3a,00,00,00,00,00

vioplujjnsjzfg · Post by **vioplujjnsjzfg** » Tue Nov 24, 2009 10:11 pm

ricktendo64 wrote:What about if you manually copy and register msdia files

Sorry, Rick, but I think we just went passed my limited knowledge in this area. I'm not really certain how to do what you're suggesting.

RogueSpear wrote:Reading about MsiQueryProductState and based on my experience with windows installer (msi), it looks like the function queries the product code.
The product code being one of these nonsensical Microsoft numbers (similar to sids). Perhaps if you manually merge in the appropriate registry
entries it would work.

I think you're dead on, here, RogueSpear! The 'Product Codes I've been using to test came from here and here. By the way, I just added your
suggested registry entries and tested again using MsiQueryProductState and it still does NOT detect the presence of the runtimes installed
using Code's method, which sort of begs the question as to whether this is the best method of installing runtimes into a system build?

My thought is that if future software installs are unable to detect the presence of the runtimes on the system, they're simply going to install
potentially old, outdated versions of the runtimes anyway. If I'm correct, then it probably makes more sense to use a Runtime installation
package that's completely detectable - like yours... which leads me to ask where did it go?

jaynbe · Post by **jaynbe** » Fri Dec 04, 2009 4:01 am

vioplujjnsjzfg,

You are right, only RogueSpear's 2_VC2005SP1VC2008SP1.exe is completely detectable to apps that
check for the required VC08&09_runtimes. I did the test with a modified paint.Net installer
(without merged runtimes) from beats http://www.ryanvm.net/forum/viewtopic.php?t=7892

First I installed roguespear's 2_VC2005SP1VC2008SP1.exe at T13
then beats_paint.net installer at T13 (the one without VC08&09)
finally dotNet3.5SP1_Family at ROE (modified without VC08&09)

It turns out that the runtimes are perfectly detected and result in an actually working app.
This didn't work with any other VCruntimes_addon.
mr_smartepants had this same experience as well, but with the ATI Catalyst installer.

Note that dotNet seems not to be an install requirement but is rather needed for running the app.

2_VC2005SP1VC2008SP1.exe http://www.mediafire.com/file/wnnkumyyz ... 008SP1.EXE

beats · Post by **beats** » Fri Dec 04, 2009 4:03 am

Thank you for all the testing jaynbe, saves me some work.

Outbreaker · Post by **Outbreaker** » Fri Dec 04, 2009 5:38 am

I had also this bug but i didn't expect that it was bug in this addon is there a other Addon like this without this bug ?

RogueSpear · Post by **RogueSpear** » Fri Dec 04, 2009 5:53 am

There is no bug in this addon. Using this addon, my Paint.NET installer works just fine.

Outbreaker · Post by **Outbreaker** » Fri Dec 04, 2009 6:03 am

But what about this "MsiQueryProductState" if i understand this right then with this addon Programs are not decting that the Runtimes are already installed and will install the Runtimes agan

RogueSpear · Post by **RogueSpear** » Fri Dec 04, 2009 6:48 am

Maybe the addon has a bug with the default Paint.NET installer, but not with mine. I've yet to run into a single program where I had the problem described above. In some cases the installs are my own modified installers and in other cases I'm using the stock download from the author.

DaRk MaDnEsS · Post by **DaRk MaDnEsS** » Fri Dec 04, 2009 7:47 am

well here what i think the original .net paint installer modded by RogueSpear doesn't install the runtimes but it just register them they way they should that why it works fine and no other complains happens

but if we used the one beats made it doesn't register the files so the .Net Paint doesn't work

and about the MsiQueryProductState it searches for registry and this addon is clean it doesn't install any reg so i think that is the problem

RogueSpear · Post by **RogueSpear** » Fri Dec 04, 2009 8:07 am

That is perhaps the explanation.

FWIW, I've begun using this addon rather than my own VC installer. It's quite a bit cleaner and straight forward (as is code's implementation of DirectX).

Outbreaker · Post by **Outbreaker** » Fri Dec 04, 2009 8:22 am

What about the Kels' Runtimes v6 Addon has this addon the same problem ?

DaRk MaDnEsS · Post by **DaRk MaDnEsS** » Fri Dec 04, 2009 8:22 am

RogueSpear wrote:That is perhaps the explanation.

FWIW, I've begun using this addon rather than my own VC installer. It's quite a bit cleaner and straight forward (as is code's implementation of DirectX).

well i searched a little more and here what i found

almost all the programs on the net doesn't check if the dll exist or not they search for the product key

so can any one try this

like in vc++ 8.0 runtimes

this is the product keys

for x64 071c9b48-7c32-4621-a0ac-3f809523288f

for x86 7299052b-02a4-4627-81f2-1818da5d550d

and there is also

{1F1C2DFC-2D24-3E06-BCB8-725134ADF989} for the latest 9

and {837b34e3-7c30-493c-8f6a-2b0f04e2912c} for the 8

and they search in

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\[ProductCode]

so maybe an empty reg should fix this problem sadly i don't have time for tests now i will do more soon

so if any one wanna try

vioplujjnsjzfg · Post by **vioplujjnsjzfg** » Fri Dec 04, 2009 4:46 pm

RogueSpear wrote:...I've yet to run into a single program where I had the problem described above. In some cases
the installs are my own modified installers and in other cases I'm using the stock download from the author.

My experience has shown that while I've never had a failure of a program to install or execute properly on a
system built with this addon, I have at least 2-3 examples of applications (MS Streets & Trips 2010 - being
one) that will install their own outdated runtimes because they were unable to detect the runtimes on a
system built with this addon. However, if I first install a runtime package similar to yours, the software is able
to detect its presence and bypass the installation of the outdated runtimes.

To restate, the issues I've raised have nothing to do with the ability of the application to detect and use the
runtimes of this addon, only the ability of the application's installer to detect their presence and bypass the
installation of older runtimes.

fajar · Post by **fajar** » Sun Feb 21, 2010 12:51 pm

Any chance for windows xp or 7 64bit version

ccl0 · Post by **ccl0** » Fri Apr 02, 2010 12:14 am

i'm guessing this is discontinued?

DaRk MaDnEsS · Post by **DaRk MaDnEsS** » Fri Apr 02, 2010 7:35 am

ccl0 wrote:i'm guessing this is discontinued?

but it's still up to date

ccl0 · Post by **ccl0** » Fri Apr 02, 2010 2:46 pm

is it? i thought kel has been updating his more often ?
and they both have many similarities

DaRk MaDnEsS · Post by **DaRk MaDnEsS** » Fri Apr 02, 2010 3:52 pm

ccl0 wrote:is it? i thought kel has been updating his more often ?
and they both have many similarities

well this is only visual runtime and if i recall it right runtimes didn't get updated in a while and kels has more stuff in his addon but the vc runtime are still up to date

yumeyao · Post by **yumeyao** » Tue May 18, 2010 4:43 am

To share:
http://rapidshare.com/files/388673237/M ... 9-Addon.7z
http://www.esnips.com/doc/a12c5a37-e3c1 ... dd1c161b26
MD5: f59179f525a1bf36b73dbf7af00c57c8

updated with VC9 9.0.30729.4974(shipped with Visual Studio 2010)

dumpydooby · Post by **dumpydooby** » Tue May 18, 2010 5:02 am

Thanks YumeYao. I like the work you do. Always top notch, similar to code65536.

bphlpt · Post by **bphlpt** » Tue May 18, 2010 8:17 am

Yes indeed, you're very highly respected YumeYao. I don't suppose you'd be willing to pick up strel's work, too, since he seems to be MIA?

Regardless, please keep up all the other great work you do.

Cheers and Regards

yumeyao · Post by **yumeyao** » Tue May 18, 2010 9:36 am

Thanks to all you.

I have limited time compared to past several years, so I probably not take up strel's work. Maintaining a script like his takes a lot of time doing tests.(you should not only do the tests on the way you want, but you'd rather do a lot of boring tests to the features or functions you don't use frequently, if ever)

code65536's works are excellent and easy for maintaining, and, most important, wanted by me. strel's work is also super but I can handle the .NET installer myself, well, as you could see in my release of .NET installers.

However I suppose people now want an "official" way to deal with .NET 4.0, I'll play with it when I'm free in time. I don't list .NET 4.0 emergency, do any of you find some apps need it?

But once I'm done, I'll write to let people know.

ricktendo64 · Post by **ricktendo64** » Tue May 18, 2010 10:43 am

YumeYao is there a stand alone installer for those runtimes or do they come embedded with the Visual Studio 2010 installer

I would like it to on Windows 7

vioplujjnsjzfg · Post by **vioplujjnsjzfg** » Fri May 28, 2010 10:41 am

ricktendo64 wrote:YumeYao is there a stand alone installer for those runtimes or do they come embedded with the Visual Studio 2010 installer

You've probably already found them by now, but just in case, here's the links to the Redistributable d/l's here:

Microsoft Visual C++ 2010 Redistributable Package (x86)

Microsoft Visual C++ 2010 Redistributable Package (x64)

______________________________________________________________________

ricktendo64 · Post by **ricktendo64** » Wed Jul 07, 2010 1:47 pm

Just in case anybody needs them here are the installers for Microsoft Visual C++ 2008 Redistributable - x84/64 v9.0.30729.4974

http://www.mediafire.com/?tdj2nmicmmy

To make the MSI's install use Orca or InstEd to delete the CA_LaunchCondition_* or run them with the USING_EXUIH=1 cmdline

geoslake · Post by **geoslake** » Thu Jul 15, 2010 3:20 am

yumeyao, do you plan to add vc++ 2010 to your pack ?

thanks

Dibya · Post by **Dibya** » Thu Nov 26, 2015 11:58 am

THANK YOU code AND YUMYAO

Zephyr · Post by **Zephyr** » Fri Jan 18, 2019 3:11 pm

Integrating the Visual C++ runtimes using an add-on pack like this is a much cleaner option than running the MSI installers one by one as long as you don't mind not being able to uninstall them using the Add Remove Programs applet. A typical install using an official MSI installer could create hundreds of registry entries as well as leaving a copy of the installer inside a package cache folder along with cab files, etc. I did an experiment that demonstrated that none of the registry entries created during the installation of a Visual C++ runtime are necessary for their operation. What I did was use Unlocker to identify the version of VC8 on my system that was locked by NOD32, and then I deleted all the registry entries associated with it. After rebooting I discovered that NOD32 was still able to connect with 8.0.5077.4053 and load into memory. I also confirmed that Visual C++ runtimes are backward compatible with earlier builds for that year and thus you only need the latest release for that year. What I did was delete all the files for 8.0.50727 and install 8.0.50727.6195. After a reboot NOD32 loaded correctly without error messages.

One interesting thing about this Addon is the way that it creates the correct folder structure inside WinSxS for VC8 and VC9 before copying their files to the appropriately named folders. During integration the files are copied to the i386 folder with subfolders like this: i386\asms\80\msft\windows\mswincrt. A public key token in mswincrt.man seems to supply a name for the folder that houses the CRT dlls, and mswincrt.cat is renamed with a filename that incorporates the public key token after being copied to WinSxS\Manifests. As there are no instructions for doing this within the addon I assume that Windows setup does all this if the asms folder and it's subfolders are detected in i386. I imagine that you would need to be a real expert to figure out all this out.

RyanVM.net Discussion Board

[Release] Microsoft Runtime Libraries 1.4.8 (32-bit)

Thanks!

kb973923

Re: [Release] Microsoft Runtime Libraries 1.4.8 (32-bit)