Visual C++ 2013与2017二进制兼容吗？迁移用旧第三方库可行吗？

First off, while your initial API tests are passing, you can’t fully assume these libraries will work flawlessly with your VS2017 executable long-term. Here’s why:

• Limited test coverage: Your current tests might only hit the "happy path" of the API. Edge cases, error handling flows, cross-heap memory allocations/deallocations, and multithreaded scenarios could still hide compatibility issues that only surface under specific conditions.
• CRT and STL differences: VS2013 and VS2017 use distinct versions of the C Runtime (CRT) and Standard Library implementations. If the third-party library links against the VS2013 CRT while your VS2017 project uses the VS2017 CRT, you could run into critical conflicts—for example, memory allocated via the VS2013 malloc being freed by the VS2017 free leads to undefined behavior.
• ABI changes: Visual C++ introduced breaking ABI (Application Binary Interface) updates between 2013 and 2017. VS2015 overhauled STL and CRT ABI rules, and VS2017 built on those changes. Code compiled with VS2013 doesn’t adhere to the same ABI standards as VS2017, which can cause crashes or incorrect results when passing complex types (like STL containers) between your code and the library.

Are Visual C++ 2013 and 2017 binaries compatible? #

Short answer: No, they are not guaranteed to be binary compatible. Microsoft does not promise cross-version binary compatibility for Visual C++ compilers, especially across major versions like 2013 to 2017. Key reasons include:

• CRT version mismatches: VS2013 relies on msvcr120.dll, while VS2017 uses vcruntime140.dll (and related libraries). Mixing these can trigger runtime errors, memory corruption, or crashes because each CRT maintains its own internal state and memory management logic.
• STL implementation shifts: The VS2017 Standard Library includes performance improvements, bug fixes, and C++11/14/17 feature support absent in VS2013. The memory layout of STL containers (like std::string or std::vector) may differ, meaning passing these between your VS2017 code and a VS2013-compiled library can lead to misinterpreted data.
• Compiler code generation differences: VS2017 uses a newer backend with updated optimization strategies and code generation rules. This can cause mismatches in function call handling, especially for complex signatures or inline code.

Recommendations to mitigate risks #

• Prioritize library updates: Look for official VS2017-compatible versions of the libraries. Most active projects offer updated builds for newer VS versions, which is the safest path forward.
• Compile from source (if possible): If the library is open-source, download its source code and compile it directly with VS2017. This ensures it uses the same CRT and ABI as your project, eliminating most compatibility risks.
• Expand your test suite: Add tests covering edge cases, error conditions, memory usage (use tools like Visual Studio’s Memory Diagnostics to check for leaks), and multithreaded scenarios. Pay extra attention to interactions involving memory management or STL types.
• Align CRT settings: If you must use the VS2013 library, ensure both the library and your project use the same CRT linking mode (either static linking with /MT or dynamic linking with /MD). This doesn’t eliminate all risks, but it reduces the chance of cross-CRT memory issues.

内容的提问来源于stack exchange，提问作者Maanu