首先简单介绍Windows 10 S Mode，Windows在该模式下，只能跑MS Store里的软件，不能通过其他方式安装。好处是安全有保障，杜绝一切国产流氓软件。就像iOS一样，APP进商店都需审核，同时APP在沙盒环境下，以普通用户权限运行，不能偷偷摸摸地干坏事，抢占资源的情况也不会发生，自然体验流畅，系统性能提升。一切都是那么的美好，但Windows S Mode就是没有人用……
这个悲剧真是不好说，也许是用户习惯，也许是违背人性，同时侵犯了厂商（要审核，要分成）和用户的利益（很多软件、游戏装不了，D版软件更不用想）。再考虑到MS Store本身就不太丰富的APP，哎妈我也不想去用什么S Mode……
但是你要想嘛，某软当初是有手机的，还有XBOX也能运行UWP APP的（越说越生气）。现在惨是惨了点，但保不准10月2日又蹦出来什么奇葩设备，ARM的只能UWP，或者低功耗设备只能MS Store，于是再续一秒……还有传输中的折叠设备，Windows Core OS等等，所以确保一个APP能在Windows 10 S Mode下运行，也许还是有那么一丢丢的意义（强行洗地）……
因为这个系列的主题是迁移桌面程序到MS Store，而纯UWP本就可以在S Mode运行，所以本篇我们要讨论的，是通过APPX With Desktop Extension的方式，将已有的桌面程序在S Mode运行。
接下来我们来说如何进行S Mode下的测试，因为并不是只要通过desktop bridge的方式打包成APPX，就一定可以成功在S Mode运行。
除了专门弄一台Windows 10 S Mode的机器来测试以外，根据官方文档，我们还可以在Window 10 Pro通过配置来模拟S Mode。
https://docs.microsoft.com/zh-cn/windows/msix/desktop/desktop-to-uwp-test-windows-s
文档中描述了审核模式（Audit mode policy），生产模式（Production mode policy）和自签名生产模式（Product mode policy with self-signed apps）。后两者是真的把你的Windows 10 Pro设置成S Mode，所以我们先看审核模式，通过文档上的链接下载审核模式的策略文件SiPolicy_Audit.p7b，重命名为SIPolicy，然后贴到C:WindowsSystem32CodeIntegrity， 重启系统。
完成后，就可以测试将要在S Mode运行的APP，然后去Event Viewer里查看是否有错误信息。
可以在下图中看到，系统认为Firefox.exe不符合S Mode的要求，但因为是审核模式，所以allowed to load。
接下来我准备闷声作大死，把SiPolicy_Enforced.p7b拷贝过去应用生产模式。在更新文件名并重启后，我试图点击《迁移桌面程序到MS Store（9）——APPX With Desktop Extension》中包含的DotNetConsoleApp.exe，惨遭系统拒绝执行。
如果我们从商店下载包含DotNetConsoleApp.exe的AppxWithDesktopExSample1的话，则可以顺利运行。
下图可以看到Console的窗口标题指出了DotNetConsoleApp.exe的绝对路径。
本篇我们简单介绍了Windows 10 S Mode，并讨论了如何在S Mode下测试APP运行状态。后续我们会尝试如何在S Mode要求管理员权限。
GitHub地址：
https://github.com/manupstairs/AppxWithDesktopExtension
MS Store：