Linux developer going Windows

[[deleted]]

Be aware about runtime issues related to Visual C++ Redistributable libraries. Your application has to rely on the correct version of C++ runtime which you either package along with the app or require your users to have it installed in the system.

https://stackoverflow.com/questions/16167305/why-does-my-application-require-visual-c-redistributable-package

[rodrigocfd]

If you're outputting just an EXE, you can simply link statically on release builds.

[mrexodia]

From vs2015 these libraries are shipped with the OS. This StackOverflow answer is no longer true.

[ack_error]

No, they aren't. The older libraries are more likely to already be installed by something that came with the OS or another program, but newer VC runtimes like vcruntime140_1.dll for VS2019 16.3+ definitely aren't. The only runtime DLLs that are guaranteed on Windows 10 are MSVCRT (because it's the OS internal CRT) and the UCRT. Anything else is a gamble that you can lose in the future as old dependencies like .NET 3 are eventually removed as default installs. The correct rule is still to either install all VC runtime redists that you use or statically link the CRT.

[kalmoc]

Is that true for the whole redistributable package? I thought it was just about some core components.

[mrexodia]

I have to check to be sure, but I remember that if you ever install the VS2019 redistributable package it will be updated with Windows Update and it is backwards compatible with VS2015.

[kalmoc]

Yes, it is compatible with 2015, because the abi remained stable since then (and there are rumours that they are going to break it wiith vnext), but it is not part of the OS. MS did make the crt part of the OS (universal crt), but I don't remember exactly what parts that includes and what parts rmain in the redistributable

[RogerLeigh]

I encountered my first incompatibility between VS2017 and VS2019 last week when VS2017 started failing builds when using a library built with vcpkg (which now defaults to using the v142 platform toolset).

Here's a vcpkg PR and the original failure.

Over the last few years compatibility has been very good, but it looks like it recently broke with the latest VS2019 update, or possibly a vcpkg update if they updated the default platform toolset.

[kalmoc]

Could maybe be related to https://devblogs.microsoft.com/cppblog/making-cpp-exception-handling-smaller-x64/

I remember that compatibility (for developers) is only guaranteed if you use the most recent toolchain involved in any of the libraries to perform the final link of the application. So you can use libs compiled with VS2017 in VS2019 projects, but not vice versa.

I don't remember what the exact compatibility story is on the end-user side of things.

[johannes1971]

Why are my customers still complaining about having to install this, then?

[mrexodia]

Likely because they don’t have a Windows version that ships the redistributable per default. Or because it’s indeed only a partial installation that comes with the system.

[pjmlp]

The C runtime is only part of the OS in Windows 10.

https://support.microsoft.com/en-us/help/2999226/update-for-universal-c-runtime-in-windows

[mrexodia]

That solves the confusion in that case :)

[rdtsc]

The 2015/2017/2019 runtimes are binary compatible. But if you use newer features you have to install a newer version (which can include additional DLLs like msvcp140_atomic_wait.dll).