fileapifromapp.h中API的设计用途是什么？与CreateFile2有何差异？

问题背景 #

SDK头文件 fileapifromapp.h 中共包含11个函数，但其配套官方文档未说明该组API的存在意义，也未介绍其针对解决的具体问题。以CreateFileFromAppW为例，其文档标注的功能为：

创建或打开文件或I/O设备。该函数的行为与CreateFile完全一致，唯一区别是本函数遵循通用Windows平台（UWP）应用安全模型。

从说明来看，它的功能与CreateFile相近，支持在UWP应用中调用，这一点并不难理解。但令人困惑的是：Windows 8推出的CreateFile2，设计目标本就是实现这一能力。为何现在会出现两个功能看似完全相同的API？

目前CreateFileFromAppW的官方文档未关联CreateFile2的文档说明二者差异，CreateFile2的文档也未提及相关内容，现有公开资料无法解答以下两个问题：

• 既然Windows 8时期就已经提供了CreateFile2，为何Windows 10 1803版本还要新增CreateFileFromAppW？
• 与CreateFile2相比，CreateFileFromAppW是否提供了不同的功能特性？

回答 #

核心结论 #

两个API不存在功能重复，二者的设计场景、适配对象、调用兼容性有本质区别，fileapifromapp.h下的整组API都是为了适配Windows 10之后的打包桌面应用场景推出的兼容层接口。

具体差异说明 #

• CreateFile2是Windows 8时期为初代UWP（当时称Metro风格应用）设计的专属文件API：它在传统CreateFileW的基础上裁剪了所有UWP沙箱不支持的参数、访问标志，调用时会严格按照UWP应用的能力声明、显式授权的文件范围做权限校验。它的函数签名、参数语义和传统Win32文件API不兼容，原有Win32文件操作代码如果要切换到CreateFile2，需要重写几乎所有传参、返回值处理逻辑。
• CreateFileFromAppW是Windows 10 1803版本随MSIX打包桌面应用（含Desktop Bridge转制Win32应用）场景推出的兼容API：它的函数签名、参数规则、错误码返回逻辑和传统CreateFileW完全一致，原有Win32代码不需要修改任何文件操作的业务逻辑，只需要替换调用的函数名，就能自动适配打包应用的安全模型——系统会在函数内部按照打包应用的权限规则做访问校验，不会出现直接调用CreateFileW时被沙箱强制拦截的问题。

fileapifromapp.h头文件的整体定位 #

这个头文件下的11个函数全部遵循同一设计逻辑：保持和对应传统Win32文件API完全一致的调用方式，内置打包应用的安全校验规则，最大程度降低传统桌面应用转打包格式的改造成本。它和UWP专属的CreateFile2面向完全不同的开发场景：

• CreateFile2服务于从零开始开发的纯UWP应用
• CreateFileFromAppW及同头文件下的其他API服务于需要适配打包格式的存量Win32应用

官方文档未明确标注二者差异属于文档疏漏，并非API设计冗余。

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