TL;DR - The MS docs state that binary compatibility between VS2015 and VS2017 libs is one-way, while I'd assumed it is necessarily two-way. Where's the catch?
First, for background:
Any MSVC++ built libraries are officially binary compatible between VS2015 and VS2017.
Specifically, you can use your VS2015 C++ app with the MSVCRT140 version from 2017. (VCRedist backwards compat)
The official documentation site states a confusing restriction.
Background / related Questions:
Is Visual-C++-2017 binary compatible with VC++-2015?
Questions about "Binary Compatibility between Visual Studio 2015 and Visual Studio 2017"
Binary compatibility between VS2017 and VS2015
The confusing restriction I find is:
There are two exceptions to this rule. Binary compatibility is not guaranteed in these cases:
...
When consuming libraries built with a toolset whose version is greater than the toolset used to compile and link the application. For example, a program that is compiled and linked with compiler version 19.12 can consume libraries that are compiled with 19.0 up through 19.12.
This caveat is, IMHO, both technically sloppy and confusing. What would the technical reason be for that?
I say it's sloppy because it is incomplete, because the interface between an executable and a DLL is pretty syymetric, but this bullet only covers "the application".
Specifially, and assuming all modules are built against the dynamic CRT version and this dynamic CRT version is the newest version available, I see the following combinations where binary compat is an issue:
my_2017.exe <-> my_2015.dll -- seemingly supported
my_2015.exe <-> my_2017.dll-- seemingly unsupported
my_2017.exe <-> my_2015.dll <-> my_2017_x.dll -- what now, in which "direction" is this supported btw DLLs?
Since binary compat - purely from the binary/interface perspective - must run both ways, I don't quite see where we suddenly could get an incompatibility here: API calls can go both ways (callbacks etc.), objects "move" both ways, even the order of DLL loading can be mixed.
This is an important point IMHO, as it means the binary compatibility as stated is severly limited:
If my application want's to consume any VC14* compiled library, I "officially" still must make sure that my application is built with the "newest version".
On the other hand, if don't build an "application", but have a DLL, I can seemingly consume any other VC14* DLL and be compatible?
With the VCRedist, we have exactly the case that is seemingly unsupported, namely we are allowed to consume a VC2017 library (CRT in this case) from a 2015 app!
Question
So, why(!) is this limited in the way it is, and how does it relate to inter-dll dependencies and also the inverted(!) CRT-dll version requirement.
Microsoft has since updated their docs, the relevant section of the current version of https://learn.microsoft.com/en-us/cpp/porting/binary-compat-2015-2017 reads:
C++ Binary Compatibility between Visual Studio 2015 and Visual Studio 2019
...
When you mix binaries built with different supported versions of the MSVC toolset,
the Visual C++ redistributable that your application runs on cannot be older
than any of the toolset versions used
to build your app or any libraries it consumes.
The diff is at https://github.com/MicrosoftDocs/cpp-docs/commit/a505dccfb31eb49c2ffece4dabd24a0a61b1fcb3#diff-d488b4c71be450b2a39cdce495c229bf
There is no direct GitHub/MS-Docs issue for this, but this limitation makes a lot more sense: It just talks about the compatibility requirements of the redistributable, and requiring a VC runtime version that is at least as current as the newest module in use.
This, of course, can make sense, as this is not only pure binary compatibility.
Of course, what I said in the question still is valid: Any (old) VS2015 application must be compatible with the (new) VS2019 redistributable, so I guess all the interface surface that VCRedist-VC14.0 ever exposed should be binary compatible.
Related
Some libraries are available to download as pre-compiled binaries, usually in specific architecture (x32 or x64) but I have also noticed that some pre-compiled binaries are splitted based on visual studio version, for example: vc17_x64. Let's assume that I use visual studio 2019. Does it mean that I have to use binaries precompiled for vc2019 or build a library from source when apropriate version is not available ? It's not clear for me because some pre-compilied binaries don't contain information about visual studio version.
If a pre-compiled library has Visual Studio version info you should use that version of Visual Studio to work with the library. This is not always the case though, as often enough happens that an older (with respect to VS version) library contains code that is a subset of the newer VS's header and runtime SDK files (.NET, C/C++, Windows SDK, etc). The other way around, when the library is newer can also work but it's far less frequent. You can try, if it doesn't work for your particular library and VS version then you should consider matching versions, rebuilding not always works for the same reasons of code changes.
If a library doesn't contain VS version info then it's reasonable to assume that it's portable/compatible up to operating system (Windows, Linux, etc) and programming language version (C++ 11, C++ 14, C# 7, C# 8, etc). However, VS version comes into play here as well, not every VS runs in every Windows, neither it supports the same runtimes, SDKs, and language(s) version. You should always check the library documentation for recommended working environment, if this info doesn't exist then it's trial and error and/or community consulting.
Is there any compatibility matrix as to what Visual Studio Versions (Say, ranging 2005 - 2017) are compatible with which Windows SDK Versions?
Should any Windows SDK be fully compatible with "any" C++ compiler, or are the different Windows SDK versions bound to certain compiler versions?
For example(!), we have a legacy C++ application that is still compiled with VS2005. We found that we'd like to use GetDpiForMonitor from this application. But to use this function, would require to use the headers+libs from at least an SDK supporting Windows 8.1 (e.g. the 8.1 SDK headers at C:\Program Files (x86)\Windows Kits\8.1\Include\um)
Generally, should a developer expect to be able to switch to a newer Windows SDK version without upgrading his compiler / Visual Studio?
Please refrain from suggesting to upgrade VS: This question tries to establish what you should do when upgrading VS is not an option for now, but you want to use stuff from (and depend on) functionality only available in newer Windows (SDK) versions.
concerning the "compatibility matrix": I don't think anybody made the effort to up to create one, also I'm not sure if this is really needed.
Rule of thumb: those API headers don't change quite often, and when they do, they are usually pretty much backward compatible.
The tricky part may be to teach your older VS to get along with a new SDK, you may need to change the VC+ include/source/lib directories for your solution/project manually.
(if it complies & links in your old VS, you should be fine)
I'm kind of lost with all these SDK windows versions.
For instance, I installed vs2013 on windows8.1, and I (also) need to link my apps against vs2008 runtime (platform toolset).
Should I install the whole VS2008 too or just the API. In the last case, what SDK do I have to install ?
You are talking about two very distinct things. The Windows SDK only covers the declarations and libraries that you need to make winapi calls. SDK v8.1 is suitable to target any modern Windows version since Vista, you select the Windows version you want to target by setting the _WIN32_WINNT macro. Note that XP requires an older SDK version, v7.1 is the last one that's still suitable and selected by setting the Platform Toolset to v120_xp.
The runtime libraries are a pure implementation detail of Visual Studio C/C++ projects and completely unrelated to the SDK. When you build such a program on VS2013 with the /MD compile option then it will have a dependency on msvcr120.dll, possibly msvcp120.dll and others. These DLLs implement the C runtime library and the C++ standard classes. And possibly MFC, ATL, OpenMP and AMP if you use those libraries.
If you still have a dependency on the VS2008 version of those libraries then you are liable to have a Really Big problem. You can obtain the release versions of those DLLs from the redist installer you can download from Microsoft. Having a dependency on the debug version requires having VS2008 installed on your machine. But having trouble linking the program and misery at runtime is highly indicated, the runtime libraries changed a great deal between VS2008 and VS2013 thanks to the new C++11 language standard. Having more than one CRT in a program is in general liable to cause lots of trouble.
You need to strongly pursue getting the library that still has the VS2008 dependency rebuilt. Contact the owner of the library if necessary to get an update.
Can I use new SDK directories that comes with VS2010 for VS2005 ?
I expect you can, but unless you need that specific version the simplest thing to do would be to download the latest Windows SDK instead:
Microsoft Windows SDK for Windows 7 and .NET Framework 4
This is more recent and can (IIRC) automatically integrate into VS2005.
If there is going to be an issue with this or with the VS2010 SDK then it will be because the .lib files are incompatible, e.g. through an object file format change or through a whole-program-optimisation intermediate representation change. However most if not all of the .libs in the SDK will just be DLL headers and so this shouldn't be an issue. (In the SDK release notes there is actually a link to a supported hotfix that improves compatibility between VS2005 and VS2008 objects but it sounds like VS2005 SP1 will usually be enough.)
There's a slim chance that the header files might not work (or might assume a different set of default defines) but in general the Windows header files are very careful with defines and version testing that I doubt this would be an issue.
If you're asking if you can use ATL + MFC from the later version then I think this is less clear cut, and may require a recompile of their sources in the older compiler. In that case I think your best option might be to upgrade to VS2010 if that's possible.
My company is always having problems with software not working because "run-times" or missing. I hear people say this a lot (you need the 32-bit run times, Microsoft run-times, etc etc).
What exactly is being referred to? DLL files? Something different? Can anyone please clarify?
Run-time is basically the time at which your code is running (as opposed to compile-time or link-time).
In the context you're seeing it, it means run-time libraries, those libraries needed to load an execute your program.
This is dynamically linked stuff (DLLs or shared objects) since statically linked code can't be missing (it's in the executable file itself).
A classic example is to depend on Microsoft's C run-time or .NET libraries but not ship them with your product. That means your executable will run on any machine that has those libraries already there (such as those with Visual Studio installed) but not necessarily every computer you want to run your code on.
I answered a question here regarding the difference between static and dynamic linking which should hopefully add to your knowledge. The dynamic linking allows you to update certain parts of the application without recompiling or relinking. You do this by dropping in a new version of the DLL. Unfortunately, having that code in a separate file means it can go missing.
That would be one cause of the problem but I suspect the most likely is just that someone didn't do their installation code very well, otherwise everything needed would have been installed.
A runtime in this context is a runtime library - a shared library (on Windows indeed a DLL), most commonly specifically referring to the one which provides basic functionality of the language. It implements the functions that are thought to be "built into" a language core. Thus, no program compiled with a compiler which requires a runtime library will run if such a library for it is not installed - or if the program is specifically statically linked (with everything needed packed into the executable).
To give you a practical example - here are some links to some common runtimes:
Microsoft Visual C++ 2008 SP1 Redistributable Package (x86) (x86 means 32-bit)
Microsoft Visual C++ 2010 Redistributable Package (x86)
Microsoft .NET Framework 4 (Web Installer)
These are system-wide installs - so any software that requires a particular runtime will be able to use it, once installed.
They are probably referring to Microsoft's 3rd party libraries and the .NET framework.
Your company's applications probably uses some 3rd party libraries such as MFC, ATL etc. in case of application's written in a .NET language e.g. C#, VB.NET, if you're developeing using Java there is a JRE (Java Runtime env) that have to be installed for the application to run.
If the required dlls/framework ween't installed/deployed on the customer's machine you'll probably get a "runtime error".
This is a deployment issue - which with the correct install process can be solved - e.g. the installer can check if the required framework is installed and if not install it as part of the installation process.