问题标签 [universal-crt]

我最近升级了我从事的项目以使用新的 Visual Studio 2015 编译器（以及 SDK 10.0 和 Windows Driver Kit 10.0）。我注意到，除了对 VC Redist 合并模块的常规更改之外，现在还引入了一些额外的先决条件，用户必须安装这些先决条件才能使用我正在开发的产品。具体来说，用户必须安装与微软在此处发布的“通用 CRT”相关的 Windows 更新：

https://blogs.msdn.microsoft.com/vcblog/2015/03/03/introducing-the-universal-crt/

我注意到他们明确指出：

“通用 CRT 不会有合并模块。如果您当前使用 CRT 合并模块，但仍想集中部署 Visual C++ 库，我们建议您移至上述 Windows Update 包或 VCRedist”</p>

他们似乎建议安装人员应该简单地标记需要先决条件，但我有点担心这一点，因为我们的一些商业客户与我们达成协议，我们将支持“开箱即用”的某些 Windows 7 版本（即没有最新的更新）。有谁知道是否可以在没有合并模块的情况下在 Wix 项目中嵌入这些新的先决条件？即，也许通过包含 VCRedist 可执行文件来代替？

尝试编译简单的 hello world c++ 程序时遇到问题。

其中的错误是：
无法打开源文件“errno.h”

使用控制台 ( c:\> dir errno.h /s) 快速搜索显示该文件位于多个目录中：
C:\LegacyApp\VisualStudio2013\VC\crt\src
C:\LegacyApp\VisualStudio2013\VC\include
C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\crt\src
C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\include
C:\Program Files (x86)\Windows Kits\10\Include\10.0.10150.0\ucrt

我的项目默认属性包括以下宏： $(VC_IncludePath);$(WindowsSDK_IncludePath);

这将解析为：
C:\LegacyApp\VisualStudio2015\VC\include
C:\LegacyApp\VisualStudio2015\VC\atlmfc\include
C:\Program Files (x86)\Windows Kits\10\Include\10.0.10240.0\ucrt
C:\ Program Files (x86)\Windows Kits\8.1\Include\um
C:\Program Files (x86)\Windows Kits\8.1\Include\shared
C:\Program Files (x86)\Windows Kits\8.1\Include\winrt

C:\Program Files (x86)\Windows Kits\10\Include\10.0.10240.0\ucrt我的系统上不存在该文件夹。

好像我想将版本切换10.0.10240.0为10.0.10150.0

如何编辑宏的默认值VC_IncludePath？

这里有更明智的做法吗？

根据 Dependency Walker，为什么它们导出ucrtbase.dll的某些功能会重叠？vcruntime140.dll

免责声明：目前这对我来说纯粹是学术兴趣。

我目前正在尝试了解 Microsoft Visual-C++ CRT 相关 DLL 文件的布局。在此处查找 UCRT 的信息和一般文件：

• 介绍通用 CRT
• CRT 库功能

简而言之，对于普通的 C++ 应用程序，您在运行时拥有这些（顶级）DLL 依赖项：

• ucrtbase.dll- “编译器独立”的东西
• vcruntime<ver>.dll- “编译器依赖”的东西
• msvcp<ver>.dll- C++ 标准库

可以从该信息中突出显示的是：

从博客条目：

...将 CRT 分成两个逻辑部分： VCRuntime，其中包含进程启动和异常处理等所需的编译器支持功能...

并从 MSDN 页面：

vcruntime 库包含 Visual C++ CRT 实现特定的代码，例如异常处理和调试支持、运行时检查和类型信息、实现细节和某些扩展库函数。该库特定于所使用的编译器版本。

在使用Dependency Walker浏览 DLL 时，我注意到ucrt和 vcruntime 都导出了该函数_CxxThrowException。如果您曾经查看过 vc++ 堆栈跟踪，那么这个函数是老熟人了：

构建异常记录并调用运行环境开始处理异常。

我很惊讶地发现它是从ucrtbase.dllas 中导出的——正如上面的两个引号所表明的那样——我认为这种机器完全属于编译器特定的一面。

memcpy在写这篇文章时，我注意到了其他一些重叠：strstr虽然vcruntime140.dll我预计它们只存在于ucrtbase.

那么这里发生了什么，我可以从中学到什么？

如果我要部署使用 Visual Studio 2015 构建并动态链接到 CRT 的非托管应用程序，那么仅在目标 PC 上安装适当的 vcredist_.exe 可再发行组件就足够了吗？我问的原因是，从 VS 2015 开始，我们获得了 Universal CRT，我不确定上述可再发行包是否也已经包含 UCRT DLL。

我已阅读 2015 年 9 月 11 日对此博文的更新： https ://blogs.msdn.microsoft.com/vcblog/2015/03/03/introducing-the-universal-crt/ 。它说应用本地部署是可能的，但如果我们想采用可重新分发的方式怎么办？

有人可以确认吗？

据我了解（除了从 VS2015 切换到 VS2017 的显着例外）微软在 Visual C++ 工具链的每个版本之间进行了 ABI 重大更改。因此，如果我想分发一个库的二进制版本，我必须为我想要支持的每个新版本的 VS 分发一个单独的版本。

现在我的问题是：

• 纯 c 库也是如此吗？
• dll和静态库之间的答案是否不同？
• MS 是否有关于他们未来目标的官方政策？

（特别是考虑到 crt 的重构和稳定性）

如果这是相关的，我会满足于特定于 Win10 的答案，但我也对自 Win7（包括）以来的所有 Windows 版本感兴趣。我感兴趣的 VS Studio 版本是 VS2013/15/17 和 - 就任何预测而言 - 未来版本。

环境：Windows 10。我碰巧使用的是 MinGW 版本的链接，但如果它使事情变得更简单ld，我很乐意使用 Visual Studio 。link.exe

我在 nasm 中有以下基本程序：

它可以很好地使用

尝试将其链接到 Windows CRT (ucrt.lib) 时，出现以下错误：

好的，所以我需要将链接器指向 ucrt 库：

尝试使用 Visual Studio 链接器进行等效操作：

这提出了几个问题：

1. 为什么其中一个试图找到printf另一个，_printf？我知道有一个下划线约定，但两个链接器似乎都不理解。

2. 我曾经objdump -t查看 ucrt.lib 文件中的符号。我不会粘贴整个列表，但它包含以下条目：

[ 4](sec 1)(fl 0x00)(ty 0)(scl 2) (nx 0) 0x00000000 __imp____conio_common_vcprintf

[ 5](sec 3)(fl 0x00)(ty 0)(scl 2) (nx 0) 0x00000000 ___conio_common_vcprintf

[ 4](sec 1)(fl 0x00)(ty 0)(scl 2) (nx 0) 0x00000000 __imp____conio_common_vcprintf_p

既不printf也不_printf出现在列表中。这是否意味着它不是由该库导出的？如果没有，我应该链接哪个库？

根据这篇 MS 文章，ucrt.lib是 c 运行时和 C 标准库的事实上的库。

在尝试使用 Windows Universal C Run-Time (...\Windows Kits\10\Include\10.0.15063.0\ucrt) 在 Windows 上评估 Clang 时，我立即以未公开和意外依赖的形式面临意外的墙在微软的 Visual Studio 上。显然，一旦您包含任何标准 C 头文件，即使是最简单的 C 程序也无法立即编译，因为它们似乎最终都试图 #include vcruntime.h（这不是 UCRT 的一部分）。

我的问题是：

1. 有没有办法在没有 Visual Studio 的情况下使用 Windows Universal C RTL SDK？
2. 如果它不是有意或不可能的，那么为什么不将其称为“Microsoft VC 的 Windows CRT”-我错过了什么？

我注意到我的二进制文件将在没有SSE 支持的情况下在 CPU 上崩溃，并带有异常代码0xC000001D(STATUS_ILLEGAL_INSTRUCTION)，尽管我正在使用 option 进行编译/arch:IA32。而且我已经能够追踪到它崩溃的确切位置：无论_snprintf_s()第一次调用哪里，它都会崩溃。崩溃在ucrtbase.dll内部，而不是我自己的代码。

现在，有趣的是，当我使用编译器选项进行“完全静态”构建时，为了避免对ucrtbase.dll/MT的显式依赖，生成的二进制文件就可以了！但是，一旦我将某些代码编译为“共享”构建，使用 option ，它将在 ucrtbase.dll中再次崩溃。/MD

所以看起来UCRT的“静态”版本仍然可以在没有SSE支持的CPU上工作，但“共享”（DLL）版本不能。这种不一致对我来说显然是一个错误！

有什么想法吗？

搭建环境：

• 视窗 10 v1803
• Visual Studio 2017.8 (v15.8.1)
• Windows SDK v10.0。17134 .12
• 工具集：v141_xp
• 编译器选项：/arch:IA32

测试机（仅用于兼容性测试）：

• CPU：奔腾II
• 操作系统：带有 Service-Pack 3 的 Windows XP

注意：用于设置“共享”构建的Redist DLL ( ucrtbase.dll+ api-ms-win-*.dll) 已直接从C:\Program Files (x86)\Windows Kits\10\Redist\ucrt\DLLs\x86目录复制！据我所知，这是这些 DLL 的最新可用版本 (v10.0.17134.12)。

即使是这个最小的测试程序也会重现崩溃：

我希望能够使用 mingw-w64 来构建链接到 Visual Studio 2015+ 而不是 MSVCRT.lib 可用的通用 CRT 的二进制文件。mingw-w64 v6.0.0的发行说明包括以下内容：“感谢 Martin Storsjö，支持 UCRT 的大量新增内容”

不幸的是，我的搜索没有显示有关如何使用此支持的文档。

有谁知道我需要提供哪些选项以及在哪里提供它们？