From d1e66858f61ed43f61dc23f50e629443fd69599b Mon Sep 17 00:00:00 2001 From: TylerMSFT Date: Thu, 7 Mar 2024 14:46:59 -0800 Subject: [PATCH 01/15] fixes #5290 --- docs/porting/binary-compat-2015-2017.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/porting/binary-compat-2015-2017.md b/docs/porting/binary-compat-2015-2017.md index 636e0f31f9a..9ac254ea763 100644 --- a/docs/porting/binary-compat-2015-2017.md +++ b/docs/porting/binary-compat-2015-2017.md @@ -1,7 +1,7 @@ --- title: "C++ binary compatibility 2015-2022" description: "Describes how binary compatibility works between compiled C++ files in Visual Studio 2015, 2017, 2019, and 2022. One Microsoft Visual C++ Redistributable package works for all three versions." -ms.date: 10/22/2021 +ms.date: 03/07/2024 helpviewer_keywords: ["binary compatibility, Visual C++"] --- # C++ binary compatibility between Visual Studio versions @@ -14,7 +14,7 @@ We've changed this behavior in Visual Studio 2015 and later versions. The runtim There are three important restrictions on binary compatibility between the v140, v141, v142, and v143 toolsets and minor numbered version updates: -- You can mix binaries built by different versions of the v140, v141, v142, and v143 toolsets. However, you must link by using a toolset at least as recent as the most recent binary in your app. Here's an example: you can link an app compiled using any 2017 toolset (v141, versions 15.0 through 15.9) to a static library compiled using, say, Visual Studio 2019 version 16.2 (v142). You just have to link them by using a version 16.2 or later toolset. You can link a version 16.2 library to a version 16.4 app as long as you use a 16.4 or later toolset. +- Binaries created with different versions of the v140, v141, v142, and v143 toolsets can be combined. The key rule is that the linker must be as recent as, or more recent than, the newest toolset used to build any binary in the app. This means the linker should only work with inputs built by toolsets that are either earlier or the same version as itself, and should never receive inputs built by a newer toolset. For example, an app compiled with a 2017 toolset (v141, versions 15.0 to 15.9) can be linked to a static library compiled with Visual Studio 2019 version 16.2 (v142). But the linking must be done using a version 16.2 or later toolset. Similarly, a version 16.2 library can be linked to a version 16.4 app, but only if you use the 16.4 or later toolset. If your apps and libraries (including both static libraries and import libraries for [implicitly linked](../build/linking-an-executable-to-a-dll.md#implicit-linking) DLLs) are built using VS 2015, 2017, or 2019, then they can be linked together. But the linking must be done using a version of the toolset that is as recent as, or more recent than, the most recent toolset used to build any of the binaries. For example, if you have three binaries built with toolsets from VS 2015 version 14.3, VS 2017 version 15.1, and VS 2017 version 15.6, you can link them using any toolset version that is 15.6 or later. In some cases, this will also work for import libraries--especially if the import library strictly uses extern"C" for the imports/exports. - The Redistributable your app uses has a similar binary-compatibility restriction. When you mix binaries built by different supported versions of the toolset, the Redistributable version must be at least as new as the latest toolset used by any app component. From 9b84ec507859491d4bd560bbc38b4278daeb1bc1 Mon Sep 17 00:00:00 2001 From: TylerMSFT Date: Thu, 7 Mar 2024 14:53:21 -0800 Subject: [PATCH 02/15] use bullets --- docs/porting/binary-compat-2015-2017.md | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/docs/porting/binary-compat-2015-2017.md b/docs/porting/binary-compat-2015-2017.md index 9ac254ea763..478215e22db 100644 --- a/docs/porting/binary-compat-2015-2017.md +++ b/docs/porting/binary-compat-2015-2017.md @@ -14,7 +14,13 @@ We've changed this behavior in Visual Studio 2015 and later versions. The runtim There are three important restrictions on binary compatibility between the v140, v141, v142, and v143 toolsets and minor numbered version updates: -- Binaries created with different versions of the v140, v141, v142, and v143 toolsets can be combined. The key rule is that the linker must be as recent as, or more recent than, the newest toolset used to build any binary in the app. This means the linker should only work with inputs built by toolsets that are either earlier or the same version as itself, and should never receive inputs built by a newer toolset. For example, an app compiled with a 2017 toolset (v141, versions 15.0 to 15.9) can be linked to a static library compiled with Visual Studio 2019 version 16.2 (v142). But the linking must be done using a version 16.2 or later toolset. Similarly, a version 16.2 library can be linked to a version 16.4 app, but only if you use the 16.4 or later toolset. If your apps and libraries (including both static libraries and import libraries for [implicitly linked](../build/linking-an-executable-to-a-dll.md#implicit-linking) DLLs) are built using VS 2015, 2017, or 2019, then they can be linked together. But the linking must be done using a version of the toolset that is as recent as, or more recent than, the most recent toolset used to build any of the binaries. For example, if you have three binaries built with toolsets from VS 2015 version 14.3, VS 2017 version 15.1, and VS 2017 version 15.6, you can link them using any toolset version that is 15.6 or later. In some cases, this will also work for import libraries--especially if the import library strictly uses extern"C" for the imports/exports. +- Binaries created with different versions of the v140, v141, v142, and v143 toolsets can be combined. The key rule is that the linker must be as recent as, or more recent than, the newest toolset used to build any binary in the app. That is: + - The linker must be as recent as, or more recent than, the newest toolset used to build any binary in the app. In other words, the linker should only work with inputs built by toolsets that are either earlier or the same version as itself. For example: + - An app compiled with a 2017 toolset (v141, versions 15.0 to 15.9) can be linked to a static library compiled with Visual Studio 2019 version 16.2 (v142), but the linking must be done using a version 16.2 or later toolset. + - A version 16.2 library can be linked to a version 16.4 app, but only if you use the 16.4 or later toolset. + - Apps and libraries built using VS 2015, 2017, or 2019 can be linked together, but the linking must be done using a version of the toolset that is as recent as, or more recent than, the most recent toolset used to build any of the binaries. + - If you have three binaries built with toolsets from VS 2015 version 14.3, VS 2017 version 15.1, and VS 2017 version 15.6, you can link them using any toolset version that is 15.6 or later. +In some cases, this will also work for import libraries, especially if the import library strictly uses extern “C” for the imports/exports. - The Redistributable your app uses has a similar binary-compatibility restriction. When you mix binaries built by different supported versions of the toolset, the Redistributable version must be at least as new as the latest toolset used by any app component. From cf8f92514160ca06c476ce38061e0001c05e3d02 Mon Sep 17 00:00:00 2001 From: TylerMSFT Date: Thu, 7 Mar 2024 15:13:13 -0800 Subject: [PATCH 03/15] wording --- docs/porting/binary-compat-2015-2017.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/porting/binary-compat-2015-2017.md b/docs/porting/binary-compat-2015-2017.md index 478215e22db..8d82743d622 100644 --- a/docs/porting/binary-compat-2015-2017.md +++ b/docs/porting/binary-compat-2015-2017.md @@ -14,13 +14,13 @@ We've changed this behavior in Visual Studio 2015 and later versions. The runtim There are three important restrictions on binary compatibility between the v140, v141, v142, and v143 toolsets and minor numbered version updates: -- Binaries created with different versions of the v140, v141, v142, and v143 toolsets can be combined. The key rule is that the linker must be as recent as, or more recent than, the newest toolset used to build any binary in the app. That is: - - The linker must be as recent as, or more recent than, the newest toolset used to build any binary in the app. In other words, the linker should only work with inputs built by toolsets that are either earlier or the same version as itself. For example: +- Binaries created with different versions of the v140, v141, v142, and v143 toolsets can be combined. The key rule is that the linker should only work with inputs built by toolsets that are either earlier or the same version as itself. For example: - An app compiled with a 2017 toolset (v141, versions 15.0 to 15.9) can be linked to a static library compiled with Visual Studio 2019 version 16.2 (v142), but the linking must be done using a version 16.2 or later toolset. - A version 16.2 library can be linked to a version 16.4 app, but only if you use the 16.4 or later toolset. - Apps and libraries built using VS 2015, 2017, or 2019 can be linked together, but the linking must be done using a version of the toolset that is as recent as, or more recent than, the most recent toolset used to build any of the binaries. - If you have three binaries built with toolsets from VS 2015 version 14.3, VS 2017 version 15.1, and VS 2017 version 15.6, you can link them using any toolset version that is 15.6 or later. -In some cases, this will also work for import libraries, especially if the import library strictly uses extern “C” for the imports/exports. + + In some cases, this will also work for import libraries, especially if the import library strictly uses extern “C” for the imports/exports. - The Redistributable your app uses has a similar binary-compatibility restriction. When you mix binaries built by different supported versions of the toolset, the Redistributable version must be at least as new as the latest toolset used by any app component. From b361b21482203cd1e95ceae455cc54723d163815 Mon Sep 17 00:00:00 2001 From: TylerMSFT Date: Thu, 7 Mar 2024 15:26:19 -0800 Subject: [PATCH 04/15] wording --- docs/porting/binary-compat-2015-2017.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/porting/binary-compat-2015-2017.md b/docs/porting/binary-compat-2015-2017.md index 8d82743d622..c32645205d4 100644 --- a/docs/porting/binary-compat-2015-2017.md +++ b/docs/porting/binary-compat-2015-2017.md @@ -17,7 +17,7 @@ There are three important restrictions on binary compatibility between the v140, - Binaries created with different versions of the v140, v141, v142, and v143 toolsets can be combined. The key rule is that the linker should only work with inputs built by toolsets that are either earlier or the same version as itself. For example: - An app compiled with a 2017 toolset (v141, versions 15.0 to 15.9) can be linked to a static library compiled with Visual Studio 2019 version 16.2 (v142), but the linking must be done using a version 16.2 or later toolset. - A version 16.2 library can be linked to a version 16.4 app, but only if you use the 16.4 or later toolset. - - Apps and libraries built using VS 2015, 2017, or 2019 can be linked together, but the linking must be done using a version of the toolset that is as recent as, or more recent than, the most recent toolset used to build any of the binaries. + - Apps and libraries (including both static libraries and import libraries for [implicitly linked](../build/linking-an-executable-to-a-dll.md#implicit-linking) built using VS 2015, 2017, or 2019 can be linked together, but the linking must be done using a version of the toolset that is as recent as, or more recent than, the most recent toolset used to build any of the binaries. - If you have three binaries built with toolsets from VS 2015 version 14.3, VS 2017 version 15.1, and VS 2017 version 15.6, you can link them using any toolset version that is 15.6 or later. In some cases, this will also work for import libraries, especially if the import library strictly uses extern “C” for the imports/exports. From 8cd4b4e2053667ceff846c51628da4100f7772aa Mon Sep 17 00:00:00 2001 From: TylerMSFT Date: Thu, 7 Mar 2024 15:35:16 -0800 Subject: [PATCH 05/15] wording --- docs/porting/binary-compat-2015-2017.md | 8 +++----- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/docs/porting/binary-compat-2015-2017.md b/docs/porting/binary-compat-2015-2017.md index c32645205d4..d37a8c9bb00 100644 --- a/docs/porting/binary-compat-2015-2017.md +++ b/docs/porting/binary-compat-2015-2017.md @@ -14,13 +14,11 @@ We've changed this behavior in Visual Studio 2015 and later versions. The runtim There are three important restrictions on binary compatibility between the v140, v141, v142, and v143 toolsets and minor numbered version updates: -- Binaries created with different versions of the v140, v141, v142, and v143 toolsets can be combined. The key rule is that the linker should only work with inputs built by toolsets that are either earlier or the same version as itself. For example: +- Binaries created with different versions of the v140, v141, v142, and v143 toolsets can be combined. The key rule is that the linker should only work with inputs built by toolsets that are either earlier or the same version as itself. This linking applies to apps and libraries, including static libraries. In some cases it also applies to import libraries for [implicitly linked](../build/linking-an-executable-to-a-dll.md#implicit-linking) DLLs, especially if the import library strictly uses extern “C” for the imports/exports. For example: - An app compiled with a 2017 toolset (v141, versions 15.0 to 15.9) can be linked to a static library compiled with Visual Studio 2019 version 16.2 (v142), but the linking must be done using a version 16.2 or later toolset. - A version 16.2 library can be linked to a version 16.4 app, but only if you use the 16.4 or later toolset. - - Apps and libraries (including both static libraries and import libraries for [implicitly linked](../build/linking-an-executable-to-a-dll.md#implicit-linking) built using VS 2015, 2017, or 2019 can be linked together, but the linking must be done using a version of the toolset that is as recent as, or more recent than, the most recent toolset used to build any of the binaries. - - If you have three binaries built with toolsets from VS 2015 version 14.3, VS 2017 version 15.1, and VS 2017 version 15.6, you can link them using any toolset version that is 15.6 or later. - - In some cases, this will also work for import libraries, especially if the import library strictly uses extern “C” for the imports/exports. + - Apps and libraries built using VS 2015, 2017, or 2019 can be linked together, but the linking must be done using a version of the toolset that is as recent as, or more recent than, the most recent toolset used to build any of the binaries. + - Given three binaries built with toolsets from VS 2015 version 14.3, VS 2017 version 15.1, and VS 2017 version 15.6, you can link them using any toolset version that is 15.6 or later. - The Redistributable your app uses has a similar binary-compatibility restriction. When you mix binaries built by different supported versions of the toolset, the Redistributable version must be at least as new as the latest toolset used by any app component. From d5588ea4066c68af0e2f12d44bce9417cec36700 Mon Sep 17 00:00:00 2001 From: TylerMSFT Date: Thu, 7 Mar 2024 15:40:48 -0800 Subject: [PATCH 06/15] wording --- docs/porting/binary-compat-2015-2017.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/porting/binary-compat-2015-2017.md b/docs/porting/binary-compat-2015-2017.md index d37a8c9bb00..a8ecbdb5512 100644 --- a/docs/porting/binary-compat-2015-2017.md +++ b/docs/porting/binary-compat-2015-2017.md @@ -14,7 +14,7 @@ We've changed this behavior in Visual Studio 2015 and later versions. The runtim There are three important restrictions on binary compatibility between the v140, v141, v142, and v143 toolsets and minor numbered version updates: -- Binaries created with different versions of the v140, v141, v142, and v143 toolsets can be combined. The key rule is that the linker should only work with inputs built by toolsets that are either earlier or the same version as itself. This linking applies to apps and libraries, including static libraries. In some cases it also applies to import libraries for [implicitly linked](../build/linking-an-executable-to-a-dll.md#implicit-linking) DLLs, especially if the import library strictly uses extern “C” for the imports/exports. For example: +- Binaries created with different versions of the v140, v141, v142, and v143 toolsets can be combined. The key rule is that the linker should only work with inputs built by toolsets that are the same version, or earlier, as itself. This linking applies to apps and libraries, including static libraries. In some cases it also applies to import libraries for [implicitly linked](../build/linking-an-executable-to-a-dll.md#implicit-linking) DLLs, especially if the import library strictly uses `extern "C"` for the imports/exports. Here are some examples of what this means: - An app compiled with a 2017 toolset (v141, versions 15.0 to 15.9) can be linked to a static library compiled with Visual Studio 2019 version 16.2 (v142), but the linking must be done using a version 16.2 or later toolset. - A version 16.2 library can be linked to a version 16.4 app, but only if you use the 16.4 or later toolset. - Apps and libraries built using VS 2015, 2017, or 2019 can be linked together, but the linking must be done using a version of the toolset that is as recent as, or more recent than, the most recent toolset used to build any of the binaries. From b76b25de89ef1b10b1885ec4f1878b1b39b71994 Mon Sep 17 00:00:00 2001 From: TylerMSFT Date: Thu, 7 Mar 2024 15:45:08 -0800 Subject: [PATCH 07/15] formatting --- docs/porting/binary-compat-2015-2017.md | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/docs/porting/binary-compat-2015-2017.md b/docs/porting/binary-compat-2015-2017.md index a8ecbdb5512..5171ba88b0e 100644 --- a/docs/porting/binary-compat-2015-2017.md +++ b/docs/porting/binary-compat-2015-2017.md @@ -14,14 +14,12 @@ We've changed this behavior in Visual Studio 2015 and later versions. The runtim There are three important restrictions on binary compatibility between the v140, v141, v142, and v143 toolsets and minor numbered version updates: -- Binaries created with different versions of the v140, v141, v142, and v143 toolsets can be combined. The key rule is that the linker should only work with inputs built by toolsets that are the same version, or earlier, as itself. This linking applies to apps and libraries, including static libraries. In some cases it also applies to import libraries for [implicitly linked](../build/linking-an-executable-to-a-dll.md#implicit-linking) DLLs, especially if the import library strictly uses `extern "C"` for the imports/exports. Here are some examples of what this means: +- Binaries created with different versions of the v140, v141, v142, and v143 toolsets can be combined. The key rule is that the linker should only work with inputs built by toolsets that are the same version, or earlier, as itself. This linking applies to apps and libraries, including static libraries. In some cases, it also applies to import libraries for [implicitly linked](../build/linking-an-executable-to-a-dll.md#implicit-linking) DLLs, especially if the import library strictly uses `extern "C"` for the imports/exports. Here are some examples of what this means: - An app compiled with a 2017 toolset (v141, versions 15.0 to 15.9) can be linked to a static library compiled with Visual Studio 2019 version 16.2 (v142), but the linking must be done using a version 16.2 or later toolset. - A version 16.2 library can be linked to a version 16.4 app, but only if you use the 16.4 or later toolset. - Apps and libraries built using VS 2015, 2017, or 2019 can be linked together, but the linking must be done using a version of the toolset that is as recent as, or more recent than, the most recent toolset used to build any of the binaries. - Given three binaries built with toolsets from VS 2015 version 14.3, VS 2017 version 15.1, and VS 2017 version 15.6, you can link them using any toolset version that is 15.6 or later. - - The Redistributable your app uses has a similar binary-compatibility restriction. When you mix binaries built by different supported versions of the toolset, the Redistributable version must be at least as new as the latest toolset used by any app component. - - Static libraries or object files compiled using the [`/GL` (Whole program optimization)](../build/reference/gl-whole-program-optimization.md) compiler switch or linked using [`/LTCG` (Link-time code generation)](../build/reference/ltcg-link-time-code-generation.md) *aren't* binary-compatible across versions, including minor version updates. All object files and libraries compiled using **`/GL`** and **`/LTCG`** must use exactly the same toolset for the compile and the final link. For example, code built by using **`/GL`** in the Visual Studio 2019 version 16.7 toolset can't be linked to code built by using **`/GL`** in the Visual Studio 2019 version 16.8 toolset. The compiler emits [Fatal error C1047](../error-messages/compiler-errors-1/fatal-error-c1047.md). ## Upgrade the Microsoft Visual C++ Redistributable from Visual Studio 2015 and later From 4fcbd4460d689e38a692574a1e54afc7318c5156 Mon Sep 17 00:00:00 2001 From: TylerMSFT Date: Thu, 7 Mar 2024 15:51:15 -0800 Subject: [PATCH 08/15] wording --- docs/porting/binary-compat-2015-2017.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/docs/porting/binary-compat-2015-2017.md b/docs/porting/binary-compat-2015-2017.md index 5171ba88b0e..eb2838e8e5c 100644 --- a/docs/porting/binary-compat-2015-2017.md +++ b/docs/porting/binary-compat-2015-2017.md @@ -14,11 +14,13 @@ We've changed this behavior in Visual Studio 2015 and later versions. The runtim There are three important restrictions on binary compatibility between the v140, v141, v142, and v143 toolsets and minor numbered version updates: -- Binaries created with different versions of the v140, v141, v142, and v143 toolsets can be combined. The key rule is that the linker should only work with inputs built by toolsets that are the same version, or earlier, as itself. This linking applies to apps and libraries, including static libraries. In some cases, it also applies to import libraries for [implicitly linked](../build/linking-an-executable-to-a-dll.md#implicit-linking) DLLs, especially if the import library strictly uses `extern "C"` for the imports/exports. Here are some examples of what this means: +- Binaries created with different versions of the v140, v141, v142, and v143 toolsets can be combined. The key rule is that the linker should only work with inputs built by toolsets that are the same version, or earlier, as itself. This linking applies to apps, libraries, import libraries, and static libraries. In some cases, an import library for [implicitly linked](../build/linking-an-executable-to-a-dll.md#implicit-linking) DLLs built using a later version of the toolset can be linked using an earlier version of the toolset, especially if the import library strictly uses `extern "C"` for the imports/exports. Here are some examples of what this means: - An app compiled with a 2017 toolset (v141, versions 15.0 to 15.9) can be linked to a static library compiled with Visual Studio 2019 version 16.2 (v142), but the linking must be done using a version 16.2 or later toolset. - A version 16.2 library can be linked to a version 16.4 app, but only if you use the 16.4 or later toolset. - Apps and libraries built using VS 2015, 2017, or 2019 can be linked together, but the linking must be done using a version of the toolset that is as recent as, or more recent than, the most recent toolset used to build any of the binaries. - Given three binaries built with toolsets from VS 2015 version 14.3, VS 2017 version 15.1, and VS 2017 version 15.6, you can link them using any toolset version that is 15.6 or later. + - An example of linking an import library built by a later version of the toolset that can be succesfully linked using an earlier version of the toolset is what happens when you install a newer windows SDK, but build with an older toolset. The import library for the newer SDK can be linked using the older toolset, as long as the import library strictly uses `extern "C"` for the imports/exports. + - The Redistributable your app uses has a similar binary-compatibility restriction. When you mix binaries built by different supported versions of the toolset, the Redistributable version must be at least as new as the latest toolset used by any app component. - Static libraries or object files compiled using the [`/GL` (Whole program optimization)](../build/reference/gl-whole-program-optimization.md) compiler switch or linked using [`/LTCG` (Link-time code generation)](../build/reference/ltcg-link-time-code-generation.md) *aren't* binary-compatible across versions, including minor version updates. All object files and libraries compiled using **`/GL`** and **`/LTCG`** must use exactly the same toolset for the compile and the final link. For example, code built by using **`/GL`** in the Visual Studio 2019 version 16.7 toolset can't be linked to code built by using **`/GL`** in the Visual Studio 2019 version 16.8 toolset. The compiler emits [Fatal error C1047](../error-messages/compiler-errors-1/fatal-error-c1047.md). From 217f33641470fbd298dbc1518e796369cde22783 Mon Sep 17 00:00:00 2001 From: TylerMSFT Date: Thu, 7 Mar 2024 15:58:42 -0800 Subject: [PATCH 09/15] wording --- docs/porting/binary-compat-2015-2017.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/porting/binary-compat-2015-2017.md b/docs/porting/binary-compat-2015-2017.md index eb2838e8e5c..b7252b74677 100644 --- a/docs/porting/binary-compat-2015-2017.md +++ b/docs/porting/binary-compat-2015-2017.md @@ -14,7 +14,7 @@ We've changed this behavior in Visual Studio 2015 and later versions. The runtim There are three important restrictions on binary compatibility between the v140, v141, v142, and v143 toolsets and minor numbered version updates: -- Binaries created with different versions of the v140, v141, v142, and v143 toolsets can be combined. The key rule is that the linker should only work with inputs built by toolsets that are the same version, or earlier, as itself. This linking applies to apps, libraries, import libraries, and static libraries. In some cases, an import library for [implicitly linked](../build/linking-an-executable-to-a-dll.md#implicit-linking) DLLs built using a later version of the toolset can be linked using an earlier version of the toolset, especially if the import library strictly uses `extern "C"` for the imports/exports. Here are some examples of what this means: +- Binaries created with different versions of the v140, v141, v142, and v143 toolsets can be combined. The key rule is that the linker should only work with inputs built by toolsets that are the same version (or earlier) as itself. This linking applies to apps, libraries, import libraries, and static libraries. In some cases, an import library for an [implicitly linked](../build/linking-an-executable-to-a-dll.md#implicit-linking) DLL built using a later version of the toolset can be linked using an earlier version of the toolset--especially if the import library strictly uses `extern "C"` for the imports/exports. Here are some examples of what this means: - An app compiled with a 2017 toolset (v141, versions 15.0 to 15.9) can be linked to a static library compiled with Visual Studio 2019 version 16.2 (v142), but the linking must be done using a version 16.2 or later toolset. - A version 16.2 library can be linked to a version 16.4 app, but only if you use the 16.4 or later toolset. - Apps and libraries built using VS 2015, 2017, or 2019 can be linked together, but the linking must be done using a version of the toolset that is as recent as, or more recent than, the most recent toolset used to build any of the binaries. From 908e6b72e30e6851862cd8cb0d1401454ccc8037 Mon Sep 17 00:00:00 2001 From: TylerMSFT Date: Thu, 7 Mar 2024 16:11:27 -0800 Subject: [PATCH 10/15] wording --- docs/porting/binary-compat-2015-2017.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/porting/binary-compat-2015-2017.md b/docs/porting/binary-compat-2015-2017.md index b7252b74677..2a60afc292c 100644 --- a/docs/porting/binary-compat-2015-2017.md +++ b/docs/porting/binary-compat-2015-2017.md @@ -14,12 +14,12 @@ We've changed this behavior in Visual Studio 2015 and later versions. The runtim There are three important restrictions on binary compatibility between the v140, v141, v142, and v143 toolsets and minor numbered version updates: -- Binaries created with different versions of the v140, v141, v142, and v143 toolsets can be combined. The key rule is that the linker should only work with inputs built by toolsets that are the same version (or earlier) as itself. This linking applies to apps, libraries, import libraries, and static libraries. In some cases, an import library for an [implicitly linked](../build/linking-an-executable-to-a-dll.md#implicit-linking) DLL built using a later version of the toolset can be linked using an earlier version of the toolset--especially if the import library strictly uses `extern "C"` for the imports/exports. Here are some examples of what this means: +- Binaries created with different versions of the v140, v141, v142, and v143 toolsets can be combined. The key rule is that the linker should only work with inputs built by toolsets that are the same version (or earlier) as itself. This linking applies to apps, import libraries, and static libraries. In some cases, an import library for an [implicitly linked](../build/linking-an-executable-to-a-dll.md#implicit-linking) DLL built by a later version of the toolset can be linked by an earlier version of the toolset--especially if the import library strictly uses `extern "C"` for the imports/exports. Here are some examples of what this all means: - An app compiled with a 2017 toolset (v141, versions 15.0 to 15.9) can be linked to a static library compiled with Visual Studio 2019 version 16.2 (v142), but the linking must be done using a version 16.2 or later toolset. - A version 16.2 library can be linked to a version 16.4 app, but only if you use the 16.4 or later toolset. - Apps and libraries built using VS 2015, 2017, or 2019 can be linked together, but the linking must be done using a version of the toolset that is as recent as, or more recent than, the most recent toolset used to build any of the binaries. - Given three binaries built with toolsets from VS 2015 version 14.3, VS 2017 version 15.1, and VS 2017 version 15.6, you can link them using any toolset version that is 15.6 or later. - - An example of linking an import library built by a later version of the toolset that can be succesfully linked using an earlier version of the toolset is what happens when you install a newer windows SDK, but build with an older toolset. The import library for the newer SDK can be linked using the older toolset, as long as the import library strictly uses `extern "C"` for the imports/exports. + - An example of using an earlier version of the toolset to link an import library built by a later version is what happens when you install a newer windows SDK but then build using an older toolset. The import library for the newer SDK can likely be linked using the older toolset, especially if the import library strictly uses `extern "C"` for its imports/exports. - The Redistributable your app uses has a similar binary-compatibility restriction. When you mix binaries built by different supported versions of the toolset, the Redistributable version must be at least as new as the latest toolset used by any app component. - Static libraries or object files compiled using the [`/GL` (Whole program optimization)](../build/reference/gl-whole-program-optimization.md) compiler switch or linked using [`/LTCG` (Link-time code generation)](../build/reference/ltcg-link-time-code-generation.md) *aren't* binary-compatible across versions, including minor version updates. All object files and libraries compiled using **`/GL`** and **`/LTCG`** must use exactly the same toolset for the compile and the final link. For example, code built by using **`/GL`** in the Visual Studio 2019 version 16.7 toolset can't be linked to code built by using **`/GL`** in the Visual Studio 2019 version 16.8 toolset. The compiler emits [Fatal error C1047](../error-messages/compiler-errors-1/fatal-error-c1047.md). From d22a6b306716bf1efd364e2f87ccdbbc3aeb966b Mon Sep 17 00:00:00 2001 From: TylerMSFT Date: Thu, 7 Mar 2024 16:21:37 -0800 Subject: [PATCH 11/15] wording --- docs/porting/binary-compat-2015-2017.md | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/docs/porting/binary-compat-2015-2017.md b/docs/porting/binary-compat-2015-2017.md index 2a60afc292c..6918be33f9e 100644 --- a/docs/porting/binary-compat-2015-2017.md +++ b/docs/porting/binary-compat-2015-2017.md @@ -14,13 +14,12 @@ We've changed this behavior in Visual Studio 2015 and later versions. The runtim There are three important restrictions on binary compatibility between the v140, v141, v142, and v143 toolsets and minor numbered version updates: -- Binaries created with different versions of the v140, v141, v142, and v143 toolsets can be combined. The key rule is that the linker should only work with inputs built by toolsets that are the same version (or earlier) as itself. This linking applies to apps, import libraries, and static libraries. In some cases, an import library for an [implicitly linked](../build/linking-an-executable-to-a-dll.md#implicit-linking) DLL built by a later version of the toolset can be linked by an earlier version of the toolset--especially if the import library strictly uses `extern "C"` for the imports/exports. Here are some examples of what this all means: +- Binaries created with different versions of the v140, v141, v142, and v143 toolsets can be combined. The key rule is that the linker should only work with inputs built by toolsets that are the same version (or earlier) as itself. This applies to apps, import libraries, and static libraries. In some cases, an import library for an [implicitly linked](../build/linking-an-executable-to-a-dll.md#implicit-linking) DLL built by a later version of the toolset can be linked by an earlier version of the toolset--especially if the import library strictly uses `extern "C"` for the imports/exports. Here are some examples of what this all means: - An app compiled with a 2017 toolset (v141, versions 15.0 to 15.9) can be linked to a static library compiled with Visual Studio 2019 version 16.2 (v142), but the linking must be done using a version 16.2 or later toolset. - A version 16.2 library can be linked to a version 16.4 app, but only if you use the 16.4 or later toolset. - Apps and libraries built using VS 2015, 2017, or 2019 can be linked together, but the linking must be done using a version of the toolset that is as recent as, or more recent than, the most recent toolset used to build any of the binaries. - Given three binaries built with toolsets from VS 2015 version 14.3, VS 2017 version 15.1, and VS 2017 version 15.6, you can link them using any toolset version that is 15.6 or later. - - An example of using an earlier version of the toolset to link an import library built by a later version is what happens when you install a newer windows SDK but then build using an older toolset. The import library for the newer SDK can likely be linked using the older toolset, especially if the import library strictly uses `extern "C"` for its imports/exports. - + - An example of using an earlier version of the toolset to link an import library built by a later version of the toolset is what happens when you install a newer Windows SDK but then build using an older toolset. It might be possible to link the import library for the newer SDK using an older toolset, especially if the import library strictly uses `extern "C"` for its imports/exports. - The Redistributable your app uses has a similar binary-compatibility restriction. When you mix binaries built by different supported versions of the toolset, the Redistributable version must be at least as new as the latest toolset used by any app component. - Static libraries or object files compiled using the [`/GL` (Whole program optimization)](../build/reference/gl-whole-program-optimization.md) compiler switch or linked using [`/LTCG` (Link-time code generation)](../build/reference/ltcg-link-time-code-generation.md) *aren't* binary-compatible across versions, including minor version updates. All object files and libraries compiled using **`/GL`** and **`/LTCG`** must use exactly the same toolset for the compile and the final link. For example, code built by using **`/GL`** in the Visual Studio 2019 version 16.7 toolset can't be linked to code built by using **`/GL`** in the Visual Studio 2019 version 16.8 toolset. The compiler emits [Fatal error C1047](../error-messages/compiler-errors-1/fatal-error-c1047.md). From 4f46efd7cf81bfce64395d0ae1c205a4cb9eeb64 Mon Sep 17 00:00:00 2001 From: TylerMSFT Date: Thu, 7 Mar 2024 16:29:29 -0800 Subject: [PATCH 12/15] wording --- docs/porting/binary-compat-2015-2017.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/porting/binary-compat-2015-2017.md b/docs/porting/binary-compat-2015-2017.md index 6918be33f9e..a99cdde5960 100644 --- a/docs/porting/binary-compat-2015-2017.md +++ b/docs/porting/binary-compat-2015-2017.md @@ -14,12 +14,12 @@ We've changed this behavior in Visual Studio 2015 and later versions. The runtim There are three important restrictions on binary compatibility between the v140, v141, v142, and v143 toolsets and minor numbered version updates: -- Binaries created with different versions of the v140, v141, v142, and v143 toolsets can be combined. The key rule is that the linker should only work with inputs built by toolsets that are the same version (or earlier) as itself. This applies to apps, import libraries, and static libraries. In some cases, an import library for an [implicitly linked](../build/linking-an-executable-to-a-dll.md#implicit-linking) DLL built by a later version of the toolset can be linked by an earlier version of the toolset--especially if the import library strictly uses `extern "C"` for the imports/exports. Here are some examples of what this all means: +- Binaries created with different versions of the v140, v141, v142, and v143 toolsets can be combined. The key rule is that the linker should only work with inputs built by toolsets that are the same version (or earlier) as itself. This applies to apps, import libraries, and static libraries. In some cases, an import library for an [implicitly linked](../build/linking-an-executable-to-a-dll.md#implicit-linking) DLL built by a later version of the toolset can be linked using an earlier version--especially if the import library strictly uses `extern "C"` for the imports/exports. Here are some examples of what this all means: - An app compiled with a 2017 toolset (v141, versions 15.0 to 15.9) can be linked to a static library compiled with Visual Studio 2019 version 16.2 (v142), but the linking must be done using a version 16.2 or later toolset. - A version 16.2 library can be linked to a version 16.4 app, but only if you use the 16.4 or later toolset. - Apps and libraries built using VS 2015, 2017, or 2019 can be linked together, but the linking must be done using a version of the toolset that is as recent as, or more recent than, the most recent toolset used to build any of the binaries. - Given three binaries built with toolsets from VS 2015 version 14.3, VS 2017 version 15.1, and VS 2017 version 15.6, you can link them using any toolset version that is 15.6 or later. - - An example of using an earlier version of the toolset to link an import library built by a later version of the toolset is what happens when you install a newer Windows SDK but then build using an older toolset. It might be possible to link the import library for the newer SDK using an older toolset, especially if the import library strictly uses `extern "C"` for its imports/exports. + - An example of using an earlier version of the toolset to link an import library built by a later version is what happens when you install a newer Windows SDK but then build using an older toolset. It might be possible to link the import library for the newer SDK using an older toolset, especially if the import library strictly uses `extern "C"` for its imports/exports. - The Redistributable your app uses has a similar binary-compatibility restriction. When you mix binaries built by different supported versions of the toolset, the Redistributable version must be at least as new as the latest toolset used by any app component. - Static libraries or object files compiled using the [`/GL` (Whole program optimization)](../build/reference/gl-whole-program-optimization.md) compiler switch or linked using [`/LTCG` (Link-time code generation)](../build/reference/ltcg-link-time-code-generation.md) *aren't* binary-compatible across versions, including minor version updates. All object files and libraries compiled using **`/GL`** and **`/LTCG`** must use exactly the same toolset for the compile and the final link. For example, code built by using **`/GL`** in the Visual Studio 2019 version 16.7 toolset can't be linked to code built by using **`/GL`** in the Visual Studio 2019 version 16.8 toolset. The compiler emits [Fatal error C1047](../error-messages/compiler-errors-1/fatal-error-c1047.md). From 3501e41fb189572b68adc116a6fe1a5563751180 Mon Sep 17 00:00:00 2001 From: TylerMSFT Date: Thu, 7 Mar 2024 17:01:25 -0800 Subject: [PATCH 13/15] wording --- docs/porting/binary-compat-2015-2017.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/porting/binary-compat-2015-2017.md b/docs/porting/binary-compat-2015-2017.md index a99cdde5960..babb0bacde1 100644 --- a/docs/porting/binary-compat-2015-2017.md +++ b/docs/porting/binary-compat-2015-2017.md @@ -14,7 +14,7 @@ We've changed this behavior in Visual Studio 2015 and later versions. The runtim There are three important restrictions on binary compatibility between the v140, v141, v142, and v143 toolsets and minor numbered version updates: -- Binaries created with different versions of the v140, v141, v142, and v143 toolsets can be combined. The key rule is that the linker should only work with inputs built by toolsets that are the same version (or earlier) as itself. This applies to apps, import libraries, and static libraries. In some cases, an import library for an [implicitly linked](../build/linking-an-executable-to-a-dll.md#implicit-linking) DLL built by a later version of the toolset can be linked using an earlier version--especially if the import library strictly uses `extern "C"` for the imports/exports. Here are some examples of what this all means: +- Binaries created with different versions of the v140, v141, v142, and v143 toolsets can be combined. The key rule is that the linker should only work with inputs built by a toolset that is the same version (or earlier) as itself. This applies to apps, import libraries, and static libraries. In some cases, an import library for an [implicitly linked](../build/linking-an-executable-to-a-dll.md#implicit-linking) DLL built by a later version of the toolset can be linked using an earlier version--especially if the import library strictly uses `extern "C"` for the imports/exports. Here are some examples of what this all means: - An app compiled with a 2017 toolset (v141, versions 15.0 to 15.9) can be linked to a static library compiled with Visual Studio 2019 version 16.2 (v142), but the linking must be done using a version 16.2 or later toolset. - A version 16.2 library can be linked to a version 16.4 app, but only if you use the 16.4 or later toolset. - Apps and libraries built using VS 2015, 2017, or 2019 can be linked together, but the linking must be done using a version of the toolset that is as recent as, or more recent than, the most recent toolset used to build any of the binaries. From 9013cef31131930a5142b7f26e82286838ba19c0 Mon Sep 17 00:00:00 2001 From: TylerMSFT Date: Fri, 8 Mar 2024 11:50:13 -0800 Subject: [PATCH 14/15] tech review --- docs/porting/binary-compat-2015-2017.md | 10 ++++------ 1 file changed, 4 insertions(+), 6 deletions(-) diff --git a/docs/porting/binary-compat-2015-2017.md b/docs/porting/binary-compat-2015-2017.md index babb0bacde1..112a736a149 100644 --- a/docs/porting/binary-compat-2015-2017.md +++ b/docs/porting/binary-compat-2015-2017.md @@ -14,12 +14,10 @@ We've changed this behavior in Visual Studio 2015 and later versions. The runtim There are three important restrictions on binary compatibility between the v140, v141, v142, and v143 toolsets and minor numbered version updates: -- Binaries created with different versions of the v140, v141, v142, and v143 toolsets can be combined. The key rule is that the linker should only work with inputs built by a toolset that is the same version (or earlier) as itself. This applies to apps, import libraries, and static libraries. In some cases, an import library for an [implicitly linked](../build/linking-an-executable-to-a-dll.md#implicit-linking) DLL built by a later version of the toolset can be linked using an earlier version--especially if the import library strictly uses `extern "C"` for the imports/exports. Here are some examples of what this all means: - - An app compiled with a 2017 toolset (v141, versions 15.0 to 15.9) can be linked to a static library compiled with Visual Studio 2019 version 16.2 (v142), but the linking must be done using a version 16.2 or later toolset. - - A version 16.2 library can be linked to a version 16.4 app, but only if you use the 16.4 or later toolset. - - Apps and libraries built using VS 2015, 2017, or 2019 can be linked together, but the linking must be done using a version of the toolset that is as recent as, or more recent than, the most recent toolset used to build any of the binaries. - - Given three binaries built with toolsets from VS 2015 version 14.3, VS 2017 version 15.1, and VS 2017 version 15.6, you can link them using any toolset version that is 15.6 or later. - - An example of using an earlier version of the toolset to link an import library built by a later version is what happens when you install a newer Windows SDK but then build using an older toolset. It might be possible to link the import library for the newer SDK using an older toolset, especially if the import library strictly uses `extern "C"` for its imports/exports. +- Binaries created with different versions of the v140, v141, v142, and v143 toolsets can be combined. The key rule is that the linker should only work with inputs built by a toolset that is the same version (or earlier) as itself. This applies to apps, import libraries, static libraries, and other files as described in [LINK input files](../build/reference/link-input-files.md). In some cases, an import library for an [implicitly linked](../build/linking-an-executable-to-a-dll.md#implicit-linking) DLL built by a later version of the toolset can be linked using an earlier version of the toolset--especially if the import library strictly uses `extern "C"` for the imports/exports. Here are some examples of what this all means: + - An app compiled with a 2017 toolset (v141, versions 15.0 to 15.9) can be linked to a static library compiled with Visual Studio 2022 version 17.8 (v143), but the linking must be done using a version 17.8 or later toolset. + - Apps and libraries built using VS 2015, 2017, 2019, or 2022 can be linked together, but the linking must be done using a version of the toolset that is as recent as, or more recent than, the most recent toolset used to build any of the binaries you pass to the linker. For example, given three binaries built with toolsets from VS 2015 version 14.3, VS 2017 version 15.9, and VS 2019 version 16.11, you can link them using any toolset version that is 16.11 or later. + - If a DLL is built with a newer toolset, the import library can sometimes be used with older toolsets if all of the exports follow the C language calling convention (`extern "C"`). However, the only officially supported case is consuming a newer windows SDK with an older toolset. - The Redistributable your app uses has a similar binary-compatibility restriction. When you mix binaries built by different supported versions of the toolset, the Redistributable version must be at least as new as the latest toolset used by any app component. - Static libraries or object files compiled using the [`/GL` (Whole program optimization)](../build/reference/gl-whole-program-optimization.md) compiler switch or linked using [`/LTCG` (Link-time code generation)](../build/reference/ltcg-link-time-code-generation.md) *aren't* binary-compatible across versions, including minor version updates. All object files and libraries compiled using **`/GL`** and **`/LTCG`** must use exactly the same toolset for the compile and the final link. For example, code built by using **`/GL`** in the Visual Studio 2019 version 16.7 toolset can't be linked to code built by using **`/GL`** in the Visual Studio 2019 version 16.8 toolset. The compiler emits [Fatal error C1047](../error-messages/compiler-errors-1/fatal-error-c1047.md). From 91c3993818a8aba52b4ba113b75244b5a8e6cefc Mon Sep 17 00:00:00 2001 From: TylerMSFT Date: Fri, 8 Mar 2024 13:36:27 -0800 Subject: [PATCH 15/15] fix user feedback 227131 --- docs/standard-library/file-clock-class.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/standard-library/file-clock-class.md b/docs/standard-library/file-clock-class.md index ebb53bbfff0..fe87f0ce9ea 100644 --- a/docs/standard-library/file-clock-class.md +++ b/docs/standard-library/file-clock-class.md @@ -1,7 +1,7 @@ --- description: "Learn more about: file_clock class" title: "file_clock class" -ms.date: 08/19/2021 +ms.date: 3/8/2024 f1_keywords: ["chrono/std::chrono::file_clock", "chrono/std::chrono::file_clock::now", "chrono/std::chrono::file_clock::to_utc", "chrono/std::chrono::file_clock::from_utc", "chrono/std::chrono::file_clock::is_steady Constant"] --- @@ -12,7 +12,7 @@ This clock can represent the range and resolution of file time values used in th ## Syntax ```cpp -using file_clock = std::filesystem::_File_time_clock. // C++20 +using file_clock = std::filesystem::_File_time_clock; // C++20 ``` ## Remarks