Microsoft Visual Studio 2013 C++ Runtime Libraries Download

[Emir Ballard]

TheVisual C++ Redistributable installs Microsoft C and C++ (MSVC) runtime libraries. Many applications built using Microsoft C and C++ tools require these libraries. If your app uses those libraries, a Microsoft Visual C++ Redistributable package must be installed on the target system before you install your app. The Redistributable package architecture must match your app's target architecture. The Redistributable version must be at least as recent as the MSVC build toolset used to build your app. We recommend you use the latest Redistributable available for your version of Visual Studio, with some exceptions noted later in this article.

Unlike older versions of Visual Studio, which have infrequent redist updates, the version number isn't listed in the following table for Visual Studio 2015-2022 because the redist is updated frequently. To find the version number of the latest redist, download the redist you're interested in using one of the following links. Then, look at its properties using Windows File Explorer. In the Details pane, the File version contains the version of the redist.

Some of the downloads that are mentioned in this article are currently available on my.visualstudio.com. Log in using a Visual Studio Subscription account so that you can access the download links. If you're asked for credentials, use your existing Visual Studio subscription account. Or, create a free account by choosing the No account? Create one! link.

Visual Studio versions since Visual Studio 2015 share the same Redistributable files. For example, any apps built by the Visual Studio 2015, 2017, 2019, or 2022 toolsets can use the latest Microsoft Visual C++ Redistributable. However, the version of the Microsoft Visual C++ Redistributable installed on the machine must be the same or higher than the version of the Visual C++ toolset used to create your application. For more information about which version of the Redistributable to install, see Determining which DLLs to redistribute. For more information about binary compatibility, see C++ binary compatibility between Visual Studio versions.

These links download the latest available en-US Microsoft Visual C++ Redistributable packages for Visual Studio 2013.You can download other versions and languages from Update for Visual C++ 2013 Redistributable Package or from my.visualstudio.com.

These links download the latest available en-US Microsoft Visual C++ Redistributable packages for Visual Studio 2012 Update 4. You can download other versions and languages from Microsoft Visual C++ Redistributable Packages for Visual Studio 2012 Update 4 or from my.visualstudio.com.

EDIT:First, thanks for answers. I thing now I have bad idea of runtime libraries in windows. I mean, the first part, that Windows internally has its win32 API and so, that's OK, I knew it. Also, that Win32API are from kernel and user parts.

So, am I right, when I know get it that "simple" functions like printf need to be linked directly and than use only Kernel part of OS directly, and more sophisticated Windows API functions are linked as dlls, therefore ARE NOT distributed with compiler but with OS? And they subsequently access Kernel?

This is an oversimplification, but it will give you the gist. The MSVCRT is a set of DLLs that implements parts of the C++ language. Functions like printf, memcpy and the like are implemented in these DLLs.

Every program that is compiled with a particular compiler and dynamically linked to the C++ runtimes must somehow have the correct version of the CRT binaries on the target machine. As a result, applications that ship to end users are often (usually?) also shipped with a package of these DLLs. This package is called a "redistributable" (or "redist"), and there is a different one for every combination of exact compiler version and target platform. For example, there are seperate and distinct redists for each of the following:

Yes, Windows usually "comes with" some version of the CRT. However, it comes with the version(s) that it needs in order to run the apps that shipped with Windows. If Windows and all it's apps were compiled in MSVC8 SP2 and your app is compiled in MSVC10, the CRT you require won't be present on the box simply because it's running Windows.

A brief answer would be that the MSVS C/C++ runtime implements functions like malloc/free, stdio, iostream and some c++-stuff like dynamic_cast and exception handling. These differs between versions of visual studio, so there are different runtimes for different versions.

In addition, each version of Visual C++ has its own runtime installer, because with each version there are slight differences and improvements in the way all this works. There are also different verisons of the runtime for different platforms (e.g. x86 and x64)

The core Windows libraries only provide interfaces to system calls, i.e. the Win32 API, since that is all you need to build a full-featured Windows application. The VC++ libraries are mostly wrappers around this API, and are analogous to the glibc library on Linux.

Update 20 April 2018 With Visual Studio 2017 version 15.7 Preview 4 we have added a new warning, C5045, that shows what patterns in your code would have caused a mitigation to be inserted. See this post for more details.

Update 4 April 2018 With Visual Studio 2017 version 15.7 Preview 3 we have two new features to announce with regards to our Spectre mitigations. First, the /Qspectre switch is now supported regardless of the selected optimization level. Second, we have provided Spectre-mitigated implementations of the Microsoft Visual C++ libraries. See below for details.

If you are a developer whose code operates on data that crosses a trust boundary then you should consider downloading an updated version of the MSVC compiler, recompiling your code with the /Qspectre switch enabled, and redeploying your code to your customers as soon as possible. Examples of code that operates on data that crosses a trust boundary include code that loads untrusted input that can affect execution such as remote procedure calls, parsing untrusted input for files, and other local inter-process communication (IPC) interfaces. Standard sandboxing techniques may not be sufficient: you should investigate your sandboxing carefully before deciding that your code does not cross a trust boundary.

The C5045 diagnostic, added in Visual Studio 2017 version 15.7 Preview 4, shows where the compiler would insert a mitigation if the /Qspectre switch were enabled. Please see this post for more details.

In current versions of the MSVC compiler, the /Qspectre switch only works on optimized code. You should make sure to compile your code with any of the optimization switches (e.g., /O2 or /O1 but NOT /Od) to have the mitigation applied. Similarly, inspect any code that uses #pragma optimize([stg], off). Work is ongoing now to make the /Qspectre mitigation work on unoptimized code.

All versions of Visual Studio 2017 version 15.5 and all Previews of Visual Studio version 15.6 already include an undocumented switch, /d2guardspecload, that is currently equivalent to /Qspectre. You can use /d2guardspecload to apply the same mitigations to your code. Please update to using /Qspectre as soon as you get a compiler that supports the switch as the /Qspectre switch will be maintained with new mitigations going forward.

The /Qspectre switch will be available in MSVC toolsets included in all future releases of Visual Studio (including Previews). We will also release updates to some existing versions of Visual Studio to include support for /Qspectre. Releases of Visual Studio and Previews are announced on the Visual Studio Blog; update notifications are included in the Notification Hub. Visual Studio updates that include support for /Qspectre will be announced on the Visual C++ Team Blog and the @visualc Twitter feed.

Our tests show the performance impact of /Qspectre to be negligible. We have built all of Windows with /Qspectre enabled and did not notice any performance regressions of concern. Performance gains from speculative execution are lost where the mitigation is applied but the mitigation was needed in a relatively small number of instances across the large codebases that we recompiled. Codebases vary greatly so we advise all developers to evaluate the impact of /Qspectre in the context of their applications and workloads.

If you know that a particular block of your code is performance-critical (say, in a tight loop) and does not need the mitigation applied, you can selectively disable the mitigation with __declspec(spectre(nomitigation)). Note that the __declspec is not available in compilers that only support the /d2guardspecload switch.

In the above example, the code performs an array-bounds check to ensure that untrusted_index is less than the length of array1. This is needed to ensure that the program does not read beyond the bounds of the array. While this appears to be sound as written, it does not take into account microarchitectural behaviors of the CPU involving speculative execution. In short, it is possible that the CPU may mispredict the conditional branch when untrusted_index is greater than or equal to length. This can cause the CPU to speculatively execute the body of the if statement. As a consequence of this, the CPU may perform a speculative out-of-bounds read of array1 and then use the value loaded from array1 as an index into array2. This can create observable side effects in the CPU cache that reveal information about the value that has been read out-of-bounds. While the CPU will eventually recognize that it mispredicted the conditional branch and discard the speculatively executed state, it does not discard the residual side effects in the cache which will remain. This is why variant 1 exposes a speculative execution side-channel.

Software changes are required to mitigate variant 1 on all currently affected CPUs. This can be accomplished by employing instructions that act as a speculation barrier. For Intel and similar processors (including AMD) the recommended instruction is LFENCE. ARM recommends a conditional move (ARM) or conditional selection instruction (AArch64) on some architectures and the use of a new instruction known as CSDB on others. These instructions ensure that speculative execution down an unsafe path cannot proceed beyond the barrier. However, applying this guidance correctly requires developers to determine the appropriate places to make use of these instructions such as by identifying instances of variant 1.

3a8082e126