早期笔记太乱了,而且很多内容过时了,稍微整理一下...
区分VS版本号??
对于VS,特别是提到MSVC时,会有三个不同的版本号,相当容易混淆...
- VS版本:VS+年份
- VC版本:VC+数字
- CL版本:编译器的版本,四个数字(代码中常用)
VS2022
比如,对于 VS2022,控制台下面,能看到下面三个版本信息:
- 2022
- v17.12
- 19.42
具体内容:
1 2 3 4 5 6 7 8 |
|
以上内容,对应的是 Visual Studio 2022 的第13个版本:
- Visual Studio 2022 version 17.12
- Visual Studio 2022 version 17.11
- Visual Studio 2022 version 17.10
- Visual Studio 2022 version 17.9
- Visual Studio 2022 version 17.8
- Visual Studio 2022 version 17.7
- Visual Studio 2022 version 17.6
- Visual Studio 2022 version 17.5
- Visual Studio 2022 version 17.4
- Visual Studio 2022 version 17.3
- Visual Studio 2022 version 17.2
- Visual Studio 2022 version 17.1
- Visual Studio 2022 version 17.0
列个表
注意:从VS2017开始,发布策略发生了改变,工具集保持兼容,小版本号开始疯狂升级。
VS | VC版本 | CL版本(_MSC_VER ) |
MSVC工具集 |
---|---|---|---|
VS2022 | vc17 | [1930,1949] | v143 |
VS2019 | vc16 | [1920,1929] | v142 |
VS2017 | vc15 | [1910,1919] | v141 |
VS2015 | vc14 | 1900 | v140 |
VS2013 | vc12 | 1800 | v120 |
VS2012 | vc11 | 1700 | v110 |
VS2010 | vc10 | 1600 | v100 |
VS2008 | vc9 | 1500 | v90 |
VS2005 | vc8 | 1400 | v80 |
VS2003 | vc7.1 | 1310 | v71 |
VS2002 | vc7 | 1300 | v70 |
VS6.0 | vc6 | 1200 | v60 |
VS97 | vc5 | 1100 | v50 |
cl编译器,在DOS时代就存在了,远比Visual Studio历史悠久。所以cl版本号和Visual Studio对应关系不是那么直观。
Windows SDK 与 Platform toolset
- 从 Windows 8 开始,Windows SDK 的版本号与操作系统版本号保持一致。例如,Windows SDK 22000 对应 Windows 11,18362 对应 Windows 10 1903。
- 在较早版本中(如 Windows 7 或 Vista),Windows SDK 通常以版本号(如 7.0A 或 6.0A)命名。
整体还是很乱
- VS2022
- Windows SDK (22000)
- Windows 10 SDK (18362, 19041, 20348) (optional)
- VS2019
- Windows 10 SDK (17763 - 19041)
- Windows 8.1 SDK Spring 2015 (optional)
- VS2017
- Windows 10 SDK (14393, 15063, 16299, or 17763)
- Windows 8.1 SDK Spring 2015 (optional)
- Windows 7.1A SDK for v141_xp Platform Toolset
- VS2015
- Windows 8.1 SDK Spring 2015
- Windows 10 SDK(optional)
- Windows 7.1A SDK for "v140_xp" Platform Toolset
- VS 2013
- Windows 8.1 SDK (VS 2013 Update 3 and Update 5 contain newer versions)
- Windows 7.1A SDK for “v120_xp” Platform Toolset
- VS 2012
- Windows 8.0 SDK
- Windows 7.1A SDK for “v110_xp” Platform Toolset (added in Update 1)
- VS 2010
- Windows SDK 7.0A
- VS 2008
- Windows SDK 6.0A
SDK和系统不是一一对应:
- Windows 10 SDK 依赖:Windows 7 SP1、Windows 8、Windows 8.1 或 Windows 10
- Windows 8.1 SDK 依赖: Windows 7 SP1、Windows 8 或 Windows 8.1
- Windows 8.0 SDK 依赖: Windows 7 或 Windows 8.x
SDK和VS关系也不是一一对应:
- Windows 10 SDK (14393 或更高版本) 支持 Visual Studio 2017。
- Windows 10 SDK (10240、10586 或 14393) 支持 Visual Studio 2015。
- Windows 8.1 SDK 支持 Visual Studio 2010 或更高版本。
- Windows 8.0 SDK 支持 Visual Studio 2010 或更高版本。
- Windows 7.1 SDK 支持 Visual Studio 2005 或更高版本。
- Platform SDK (2003 年 2 月版) 是最后一个支持 Visual Studio 6 的发行版本。
二进制兼容性
从 Visual Studio 2015 开始,MSVC 的二进制兼容性发生了显著变化,主要体现在以下几个方面:
- 跨工具集版本的二进制兼容性:v140、v141、v142 和 v143 工具集生成的二进制文件可以混合使用。
- 统一的可再发行包:一个版本的可再发行包支持所有兼容工具集生成的应用程序。
- 减少了重新编译的需求:开发者可以直接复用早期版本编译的库,而无需重新构建。
前期不兼容
在 Visual Studio 2013 及更早版本中,MSVC 编译器工具集没有保证主版本之间的二进制兼容性。这意味着,如果你使用不同版本的工具集(如 Visual Studio 2010 和 Visual Studio 2013)编译对象文件、静态库、动态库或可执行文件,它们无法直接链接或一起运行。
2015变化
在 Visual Studio 2015 及更高版本中,Microsoft 对 MSVC 编译器工具集进行了重大改进,开始支持跨版本的二进制兼容性。这一改动极大地提升了开发者的开发效率和代码复用能力。
核心改进体现在:
统一工具集主版本号:自 Visual Studio 2015 起,所有工具集版本号都以 14 开头:
- Visual Studio 2015:工具集版本为 v140
- Visual Studio 2017:工具集版本为 v141
- Visual Studio 2019:工具集版本为 v142
- Visual Studio 2022:工具集版本为 v143
这种统一的版本号体系表明,工具集的 ABI 和运行时库在主版本号范围内保持兼容。
跨版本运行时库兼容性:由 Visual Studio 2015 及更高版本生成的应用程序和运行时库可以在后续版本中直接使用,无需重新编译。例如,如果你有一个用 Visual Studio 2015 构建的第三方库,你可以直接在 Visual Studio 2017、2019 或 2022 中使用它,无需重新构建。
统一的可再发行包(Redistributable):Visual Studio 2015 及更高版本共享相同的 Microsoft Visual C++ 可再发行程序包(Redistributable)。这意味着你只需安装最新版本的可再发行包,即可运行由 Visual Studio 2015 及更高版本生成的所有应用程序。
限制
尽管 Visual Studio 2015 起的工具集支持二进制兼容性,但在某些情况下仍然存在限制。以下是需要注意的几点:
工具集版本的混合使用:
可以混合使用由不同工具集版本(如 v140 和 v141)生成的二进制文件,但必须使用新的工具集进行链接(最终生成可执行文件或动态库时)。
例如,如果你有一个由 v140 编译的库和一个由 v141 编译的库,你需要用 v141 工具集链接最终的目标文件。
可再发行包的要求:
虽然可再发行包是兼容的,但运行时库的加载依赖于安装的最新版本的可再发行包。如果目标机器没有安装最新的可再发行包,可能会导致应用程序运行失败。
全程序优化(/GL)和链接时间代码生成(/LTCG):
如果你使用 /GL(全程序优化)编译器开关编译静态库或对象文件,或者使用 /LTCG(链接时间代码生成)进行链接,这些文件在不同工具集版本之间不兼容。
这是因为 /GL 和 /LTCG 特性会将代码优化信息嵌入到二进制文件中,而这些信息在不同版本之间的格式可能并不一致。
定位MSVC
平台工具集
使用 MSVC 就是使用 MSVC 的平台工具集(Platform Toolset),它包含以下工具:
- 编译器
- 链接器
- 汇编器(ml.exe 或 ml64.exe)
平台工具集的相关工具位于如下路径中:
1 |
|
例如:
1 |
|
但从 Visual Studio 2017 开始,%VSxxxCOMNTOOLS% 环境变量被移除,工具路径需要通过其他方式查找。
查找环境脚本(VcDevCmd.bat 和 vsvars32.bat)
Visual Studio 2015 及之前版本
在 Visual Studio 2015 及更早版本中,安装程序会定义环境变量 %VSxxxCOMNTOOLS%,可以使用该变量来定位脚本位置。例如:
- 执行 vsvars32.bat 初始化开发环境:
1 |
|
- 执行 vsdevcmd.bat 初始化开发环境:
1 |
|
这些脚本的作用是配置开发环境所需的环境变量(如 PATH、INCLUDE、LIB 等)。
Visual Studio 2017 及更高版本
从 Visual Studio 2017 开始,%VSxxxCOMNTOOLS% 环境变量被移除,微软引入了新的工具 vswhere.exe,用于查找 Visual Studio 的安装路径。
vswhere.exe 的位置
默认情况下,vswhere.exe 位于:
1 |
|
使用 vswhere.exe 查找安装路径
运行以下命令可以获取当前最新版本的 Visual Studio 的安装路径:
1 |
|
示例输出:
1 |
|
查找并执行初始化脚本
可以通过以下命令调用 VsDevCmd.bat 初始化开发环境:
for /f "usebackq delims=#" %a in ("%programfiles(x86)%\Microsoft Visual Studio\Installer\vswhere" -latest -property installationPath
) do "%a\Common7\Tools\VsDevCmd.bat" -arch=amd64
VsDevCmd.bat 的使用
VsDevCmd.bat 是从 Visual Studio 2017 开始引入的新脚本,替代了 vsvars32.bat,用于配置开发环境。
VsDevCmd.bat 支持 -arch=<架构>
设置目标架构,支持的选项包括:
- x86:32 位目标架构。
- amd64:64 位目标架构。
- 其他选项如 arm 和 arm64(如果安装了相关工具集)。
示例:
1 |
|
Qt 脚本 qtenv2.bat
如果使用 Qt,可以通过 Qt 提供的脚本 qtenv2.bat 配置 Qt 环境变量。该脚本通常位于 Qt 的安装目录下,例如:
1 |
|
注意:在运行 qtenv2.bat 之前,必须先运行 VsDevCmd.bat,以确保 MSVC 的环境变量已经正确配置。
示例小结
命令行下流程
- 使用 vswhere.exe 查找 Visual Studio 的安装路径:
1 |
|
- 调用 VsDevCmd.bat 初始化开发环境:
1 |
|
- (可选)运行 Qt 的 qtenv2.bat 初始化 Qt 环境:
1 |
|
参考
- https://en.wikipedia.org/wiki/Visual_Studio
- https://en.wikipedia.org/wiki/Microsoft_Visual_C%2B%2B
- https://marcofoco.com/blog/2015/02/25/microsoft-visual-c-version-map/
- https://walbourn.github.io/a-brief-history-of-windows-sdks/
- C++ 二进制兼容性 2015-2022 | Microsoft Learn
- MSVC_TOOLSET_VERSION — CMake 3.27.5 Documentation
- Predefined macros | Microsoft Learn
- Visual Studio: environment variables (renenyffenegger.ch)
- VsDevCmd.bat (renenyffenegger.ch)