微软商店中MSI/EXE应用的隔离级别及互操作性技术问询

微软近年放开了MSI/EXE格式应用上架微软商店的通道，这类应用基于**桌面桥（Desktop Bridge）**框架打包，最终会转换为MSIX格式上架，属于带轻量隔离的桌面应用。下面针对你关心的几个核心问题逐一说明：

注册表访问与虚拟化 #

• 这类应用能访问Windows注册表，但有明确的虚拟化隔离规则：
  • 对HKCU（当前用户注册表）的修改会被自动重定向到应用专属的沙箱路径，其他应用看不到这些变更，卸载应用时这部分虚拟注册表会被一并删除；
  • 对HKLM（本地机器注册表）默认只有只读权限，若要修改需在打包时申请对应权限，且修改内容同样会被虚拟化，不会影响系统全局的HKLM键值；
  • 系统级的注册表项（如HKCR）仅能读取部分公共信息，修改操作会被限制或重定向到沙箱内。

COM/DCOM调用支持 #

• COM调用：大部分标准系统COM组件可以正常使用，但有隔离限制：
  • 应用自身注册的COM组件会被虚拟化，只能被当前应用的进程访问，其他应用无法调用；
  • 系统全局注册的COM组件（比如系统自带的COM对象）可以正常调用，但其他未适配的桌面应用注册的COM组件，沙箱内的应用通常无法访问；
• DCOM调用：支持度有限，跨机器的DCOM请求默认受沙箱网络隔离限制，需要额外配置权限才能正常发起或接收，一般不建议依赖此特性。

命名管道可用性 #

• 命名管道可以使用，但默认仅限沙箱内进程访问：
  • 应用创建的命名管道，同一沙箱里的进程能正常读写；
  • 若要和沙箱外的进程通信，必须在打包时声明特定的权限规则，明确允许访问的外部进程或系统服务，否则跨沙箱的命名管道交互会被拦截。

整体隔离级别总结 #

微软商店里的MSI/EXE应用采用轻量级沙箱隔离，核心特性如下：

• 文件系统和注册表的修改默认被虚拟化重定向，不会污染系统全局环境，卸载时能彻底清理；
• 网络、进程间通信（IPC）默认受限制，需要显式申请权限才能与外部系统或其他应用交互；
• 隔离强度介于传统桌面应用和UWP应用之间：既保留了桌面应用的大部分原有功能，又通过沙箱机制提升了安全性，避免应用随意篡改系统；
• 整个隔离机制依托MSIX打包技术实现，把应用的依赖、配置和系统环境做了分离。

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