术语
win10SDK基于C++/WinRT进行开发，跨设备(PC,MOBILE)、跨语言(C++,C#,VB,JS等)、跨架构(Arm,x86,x64)。
-
WinRT(Windows Runtime): 是微软基于Win8 Metro下的开发框架，是面向对象、跨语言的Native库。主要使用微软的扩展语言：C++/WinRT，以前是C++/CX，以支持.Net和C++两种语言开发。与之对应的技术是： COM + C++/WINRT + WINMD
-
winmd(Windows MetaData): 库引用。引用 用于跨Native和.Net、JS交叉调用。类似于接口导出文件，即以前的.def文件，是.def文件的升级版。
-
DirectX: 作为底层渲染
-
COM： 作为系统二进制库管理方案。
-
UWP(Universal Windows Platform): 作为新的应用发布包解决方案。
-
MIDL(Microsoft Interface Definition Language): 接口定义语言，通常用于RPC接口。
-
WRL(Windows Runtime Library): Windows 运行时 C++ 模板库 (WRL) 是一个模板库，提供了一种生成和使用 Windows 运行时组件的简单方法。是Win8时代的产物，是WinRT的前一版本。与之对应的技术是： COM + C++/CX + MIDL
-
CLR(Common Language Runtime): 公共语言运行库，是整个.NET框架的核心。它实际上是驻留在内存里的一段代理代码，负责应用程序在整个执行期间的代码管理工作，比较典型的有：内存管理、线程管理、安全管理、远程管理、即使编译、代码强制安全类检查等，这些都可以成为.NET框架的生命线
题外话：以前微软将C++视为命脉语言，门面产品（Windows,Office，VisualStudio，编译器等）都用C++，并以此发明了.dll,后来面对.dll升级的版本管理(dll是二进制库，升级dll会面临二进制不兼容问题)，发明了COM组件方式，并认为COM组件是dll库升级的银弹，从此以后一发不可收拾，基本上所有的东西都走上了COM之路。
待微软发明了.NET后，几乎把自己的所有后续产品都用C#编写。回过头来如果要将C#编写的二进制dll(与C++编写的dll不同，非C ABI的二进制文件)供C++使用，或者其他语言如Javascript使用，必须得使C# dll能跨语言调用，所以发明了中间层winmd。常规的C++不能导出winmd,所以魔改了Visual Studio编译器(编译器是谁写的，谁就能夹藏私货，clang/g++/msvc都有夹藏私货)，发布了自家的C++版本——C++/WinRT，使其能导出winmd并向后兼容ISO C++(解决方法：通过读取winmd文件，生成大量标准C++template头文件)。所以当你查看Win10SDK下的一溜.dll都是C#编写时，也无足为奇，同时在References目录下，提供了完整的winmd供开发者使用。
头文件包含目录：
winrt: 是WinRT框架下的产物，主要用于向下兼容(win8?)。由.h和.idl组成。idl即MIDL文件，主要用于生成头文件。
cppwinrt/winrt: 是WinrRT框架下的C++产物，主要面向Win10。是C++头文件形式的库，大量采用C++ Template！Visual Studio编译器也会根据winmd自动生成大量cppwinrt 头文件
ucrt(Universal C Runtime): 即通用的C运行时库，包含C的头文件。对应lib为libucrt.lib,dll为ucrtbase.dll。类似于linux中的libc。/MT模式下，调用的是libucrt.lib， /MD 模式下，调用的是ucrt.lib
um(User Mode？): 应用开发下所能需要的头文件。有些头文件是有MIDL生成的。
shared： 共享的头文件目录。
标准C和C++库
C 运行时库 (CRT)
- libucrt: 通用 CRT (UCRT) 包含通过标准 C99 CRT 库导出的函数和全局函数。 UCRT 现为 Windows 组件，并作为 Windows 10 的一部分提供。 静态库、DLL 导入库和 UCRT 的头文件现在 Windows 10 SDK 中提供。 安装 Visual C++ 时，Visual Studio 安装程序将安装使用 UCRT 所需 Windows 10 SDK 的子集。 可以在 Visual Studio 2015 及更高版本支持的任何 Windows 版本上使用 UCRT。 可以使用 vcredist 重新分发它，以便支持 Windows 10 以外的 Windows 版本。
| 库 | 关联的 DLL | 特征 | 选项 | 预处理器指令 |
|---|---|---|---|---|
| libucrt.lib | 无 | 将 UCRT 静态链接到你的代码。 | /MT | _MT |
| libucrtd.lib | 无 | 用于静态链接的 UCRT 调试版本。 不可再发行。 | /MTd | _DEBUG, _MT |
| ucrt.lib | ucrtbase.dll | UCRT 的 DLL 导入库。 | /MD | _MT, _DLL |
| ucrtd.lib | ucrtbased.dll | UCRT 调试版本的 DLL 导入库。 不可再发行。 | /MDd | _DEBUG, _MT, _DLL |
- vcruntime: vcruntime 库包含 Visual C++ CRT 实现特定的代码，例如异常处理和调试支持、运行时检查和类型信息、实现的详细信息和某些扩展的库函数。 此库特定于所用编译器的版本。
| 库 | 关联的 DLL | 特征 | 选项 | 预处理器指令 |
|---|---|---|---|---|
| libvcruntime.lib | 无 | 静态链接到你的代码。 | /MT | _MT |
| libvcruntimed.lib | 无 | 用于静态链接的调试版本。 不可再发行。 | /MTd | _MT, _DEBUG |
| vcruntime.lib | vcruntime.dll | vcruntime 的 DLL 导入库。 | /MD | _MT, _DLL |
| vcruntimed.lib | vcruntimed.dll | 调试 vcruntime 的 DLL 导入库。 不可再发行。 | /MDd | _DEBUG, _MT, _DLL |
- CRT初始化和终止的库： 初始化 CRT 的代码是几个库中的一个，根据 CRT 库是采用静态或动态链接还是本机、托管或混合代码而定。 此代码处理 CRT 启动、内部逐线程数据初始化和终止。 它特定于所用编译器的版本。 此库始终采用动态链接，即使使用动态链接的 UCRT 也是如此。
库 | 特征 | 选项 | 预处理器指令 — | — | — | ———- LIBCMT.lib | 将本机 CRT 启动静态链接到你的代码。| /MT| _MT libcmtd.lib | 静态链接本机 CRT 启动的调试版本。 不可再发行。| /MTd | _DEBUG, _MT msvcrt.lib | 与 DLL UCRT 和 vcruntime 一起使用的本机 CRT 启动的静态库。| /MD | _MT, _DLL msvcrtd.lib | 与 DLL UCRT 和 vcruntime 一起使用的本机 CRT 启动调试版本的静态库。 不可再发行。| /MDd| _DEBUG, _MT, _DLL msvcmrt.lib | 与 DLL UCRT 和 vcruntime 一起使用的本机和托管混合 CRT 启动的静态库。| /clr| msvcmrtd.lib | 与 DLL UCRT 和 vcruntime 一起使用的本机和托管混合 CRT 启动调试版本的静态库。 不可再发行。| /clr| msvcurt.lib | 纯托管 CRT 的已弃用静态库。 | /clr:pure | msvcurtd.lib | 纯托管 CRT 调试版本的已弃用静态库。 不可再发行。| /clr:pure| 如果从没有编译器选项（可指定 C ++运行时库）的命令行链接程序，则链接器将使用静态链接的 CRT 库：libcmt.lib、libvcruntime.lib 和 libucrt.lib。
使用静态链接的 CRT 意味着由 C 运行时库保存的任何状态信息对于 CRT 的该实例而言是本地的。 例如，如果当使用静态链接的 CRT 时使用 strtok、_strtok_l、wcstok、_wcstok_l、_mbstok、_mbstok_l，则 strtok 分析器的位置将与链接到另一个静态 CRT 实例的同一进程（但在不同的 DLL 或 EXE 中）的代码中使用的 strtok 状态无关。 相反，动态链接的 CRT 可共享动态链接到 CRT 的进程中的所有代码的状态。 如果使用这些函数新的更安全版本，这一问题则不适用；例如， strtok_s 就不存在此问题。
由于通过链接到静态 CRT 构建的 DLL 将具有其自己的 CRT 状态，因此不建议以静态方式链接到 DLL 中的 CRT，除非特别需要和需了解这一后果。 例如，如果在加载 DLL（链接到其自己的静态 CRT）的可执行文件中调用 _set_se_translator ，则转换器将不会捕获由 DLL 中的代码生成的任何硬件异常，但会捕获由主可执行文件中的代码生成的硬件异常。
如果使用 /clr 编译器开关，则将通过静态库 msvcmrt.lib 链接代码。 静态库将提供托管的代码和本机 CRT 之间的代理。 你无法使用静态链接的 CRT（ /MT 或 /MTd 选项）和 /clr。 请改用动态链接的库（/MD 或 /MDd）。 纯托管的 CRT 库在 Visual Studio 2015 中已弃用并在 Visual Studio 2017 中不受支持。
有关将 CRT 与 /clr 配合使用的详细信息，请参阅混合（本机和托管）程序集。
若要生成你的应用程序的调试版本，则必须定义 _DEBUG 标志，并且该应用程序必须与其中一个调试版本的库链接。 有关使用调试版本的库文件的详细信息，请参阅 CRT 调试技术。
此版本的 CRT 不完全符合 C99 标准。 具体而言，不支持
C++ 标准库
| C++ 标准库 | 特征 | 选项 | 预处理器指令 |
|---|---|---|---|
| libcpmt.lib | 多线程, 静态链接 | /MT | _MT |
| libcpmtd.lib | 多线程, 静态链接 | /MTd | _DEBUG, _MT |
| msvcprt.lib | 多线程动态链接（MSVCPversion.dll 的导入库） | /MD | _MT, _DLL |
| msvcprtd.lib | 多线程动态链接（MSVCPversionD.DLL 的导入库） | /MDd | _DEBUG, _MT, _DLL |
当构建项目的发行版时，默认情况下，将链接其中一个基本 C 运行时库（libcmt.lib、msvcmrt.lib、msvcrt.lib），具体取决于你选择的编译器选项(多线程、DLL、/clr)。 如果在代码中包含其中一个 C++ 标准库标头文件，则将在编译时通过 Visual C++ 自动链接 C++ 标准库。 例如:#include <ios>
对于二进制兼容性，可通过单个导入库指定多个 DLL 文件。 版本更新可能会引入点库，点库是引入新的库功能的 单独的 Dll。 例如，Visual Studio 2017 版 15.6 引入了 msvcp140_1.dll 以支持其他标准库功能，而不会破坏由 msvcp140.dll 支持的 ABI。 适用于 Visual Studio 2017 版本 15.6 的工具集中包含的 msvcprt.lib 导入库支持两个 DLL，且此版本的 vcredist 安装两个 DLL。 传送后，点库具有固定 ABI，且不会在以后的点库中包含依赖项。 如果应用程序使用多个 CRT 版本，将存在什么问题？
每个可执行映像（EXE 或 DLL）可以具有其自己静态链接的 CRT，或可以动态链接到 CRT。 静态包括在某个映像中或某个映像动态加载的 CRT 版本取决于构建 该 CRT 时采用的工具和库。 单个进程可能会加载多个 EXE 和 DLL 映像，每个都有其自己的 CRT。 每个 CRT 可能使用不同的分配器，可能具有不同的内部结构布局，可能使用不同的存储排列方式。 这意味着，分配的内存、CRT 资源或跨 DLL 边界传递的类可能会导致内存管理、内部静态使用情况或布局解释方面的问题。 例如，如果在一个 DLL 中分配类，但将其传递给另一个 DLL 或由另一个 DLL 删除，那么使用了哪个 CRT 释放器？ 导致的错误程度可以从微小到立即致命，因此强烈建议不要直接传输此类资源。
你可以使用应用程序二进制接口 (ABI) 技术避免这些问题，因为此技术被设计成稳定且版本可控。 设计 DLL 导出接口以按值传递信息，或致力于调用方传入而非本地分配并返回给调用方的内存。 使用封送技术复制可执行映像之间的结构化数据。 本地封装资源并仅允许通过向客户端公开的句柄或函数操作。
如果进程中的所有映像全都使用相同的 CRT 动态加载版本，则也有可能避免这些问题。 若要确保所有组件都使用相同的 CRT 的 DLL 版本，请使用“/MD”选项，并使用相同的编译器工具集和属性设置进行构建。
如果程序跨 DLL 边界传递某些 CRT 资源（如文件句柄、区域设置和环境变量），即便使用的是相同版本的 CRT，那也需要注意。 有关所涉及问题以及如何解决这些问题的详细信息，请参阅跨 DLL 边界传递 CRT 对象时可能的错误。