“目前世界上存在1600万种Win32或者.NET应用程序。在构建通用Windows平台时，我们需要将其彻底抛弃。这种作法非常愚蠢。”微软杰出工程师John Sheehan在2016年Build大会上如是说。
微软通用Windows平台（简称UWP）基于WinRT。WinRT拥有数项既定目标：其一，通过用户界面设计的触控操作，而将Windows带入平板电脑设备市场；其二为允许用户更为轻松且彻底地安装及移除应用程序——具体可通过Windows Store或者定制化业务门户实现；其三，WinRT安全性更高，因为每款应用程序都拥有自己的沙箱环境，且独立于操作系统及其它应用之外。并且只有一个Windows API的安全子集，负责以隔离化应用专属区域的受限方式同文件系统交互，或者在用户同意之下使用文件及图片等位置明确的访问对象。
其长远规划似乎是逐步推动用户适应新的Store应用并摆脱原有桌面应用程序，直到大多数常用Windows应用皆过渡至新模式，届时微软将锁定操作系统并将其推向更接近苹果iOS的发展道路，即安全漏洞更少且能够阻止第三方软件对用户体验的负面影响。
遗憾的是，开发者们对于构建Store应用明显缺乏兴趣，而用户们则继续使用传统桌面应用程序，因为这正是他们使用Windows系统的理由所在。由于使用者规模实在太过有限，Windows团队在保障Windows 8 Store应用环境安全方面做出的努力基本付之东流。
Windows 10则承载了微软发展战略的一次重要转变。Store应用环境仍然得到保留，但这次换成了新的实现方式，应用可以运行在桌面窗口当中。微软方面还将PC、移动、Xbox、HoloLens以及Windows IoT Core等应用平台加以统一，并将其统称为UWP。
在本次Build大会上，微软方面明显指出UWP的安全工作优先级应当让位于兼容性。Centennial项目，或者叫桌面应用转换器，将随Windows 10年度更新版一同亮相，以期让开发者们能适应桌面应用程序，并轻松实现Store以及通知、Live Tiles乃至后台任务等UWP API。这些应用程序亦不会采用沙箱机制。“我们认为，虽然可以对其进行限制及锁定，但最终只会影响到应用程序的生命力。”Sheehan在会议上表示。
微软还打算进一步增加UWP应用程序的可用Windows API。“大家可以期待Store应用SDK的不断扩展及增长，除了新API之外，我们还将添加更多此前曾被清除的API选项。”Sheehan表示。
笔者曾在Build大会上同Centennial项目组的几位成员进行过探讨，他们给出的观点非常简单：由于用户所下载并运行的Win32应用程序往往存在恶意代码或者不良元素，因此由UWP进行安全交付能够轻松解决这一问题。
微软目前的方案是将UWP标准所使用的AppX安装文件普及到各类Windows应用程序当中。其也可以看作是下一代Windows Installer。AppX在交付时会由受信数字化证书提供签名，用户则能够通过Store获取以及网站下载的方式进行获取，并双击该文件实现安装（Build大会与会者们以欢呼做出回应）。“大家再也不用手动编写安装器了，”Sheehan强调称。
同样的技术亦适用于Windows Server，在这一平台上此方案被称为Windows Server App（简称WSA）。其将首先出现在即将推出的Nano Server上，但同时亦将受到Server Core以及完整版Windows Server 2016的支持。“WSA能够将Windows Server特定扩展添加至AppX当中，从而实现各类服务器应用的安装流程，例如支持NT Service安装。作为AppX安装器的一套扩展集，WSA并不支持定制化操作，因此不会像MSI那样带来可靠性与卸载问题，”微软公司服务器团队指出。MSI属于经典Windows Installer文件，Nano Server无法支持此类部署，因为其中存在关联性机制。
开发者们编写的新应用将无需使用Centennial项目的桌面应用转换器即可利用MSI创建AppX，因为商用InstallShield以及开源WiX等安装构建器都能够直接生成AppX文件。
在此次大会上，微软还披露了桌面应用转换器的具体工作方式。其初始点为支持静默安装的MSI文件。大家可以利用命令行运行该转换器，其会启动一套Docker容器并在其中运行安装器，同时捕捉面向文件系统与注册表的各项变更。在部署其生成的AppX时，全部变更都将与应用程序文件夹相隔离，API则遵循限制条件以保证该应用程序只能够读取及写入注册表条目或者被安装在Windows系统文件夹中的文件——换言之，这些元素为该应用程序所专有。
根据Sheehan的说法，这套方案能够显著提升Windows的可靠性与性能水平。应用程序的添加与移除操作不再会导致注册表膨胀，亦消除了DLL（即动态链接库）版本问题所带来的风险——因为每款应用都拥有自己安装的库副本。
当然，并非所有应用都能够轻松实现转换。转换之后用户需要进行测试，而且多数情况下开发者还需要对其安装器或者应用代码进行修改以保证成功。
与原生UWP应用程序不同，Centennial应用能够以完全受信且无限制方式访问Windows API。它们无法安装驱动程序，但可以使用现有驱动程序以访问硬件、SQL Server或其它数据库以及网络API。
使用Centennial项目，开发者能够编写出同时运行在Windows 7乃至更早版本以及Windows 10当中的Store应用。也就是说，Centennial项目生成的AppX要求配合Windows 10年度更新版，因此用户必须及时进行升级；而该项目的另一项作用就是普及微软提出的“Windows即服务”概念。
微软公司仍然鼓励开发者们将应用程序陆续迁移至UWP当中。大家可以在编写应用程序时要求其同时运行两个进程，其一在UWP内、其二则在桌面内。各进程能够激活对方，而且两个进程可以通过名为App Service的UWP功能实现通信。这意味着经过转换的桌面应用将能够接入UWP功能，例如在PC处于休眠状态下仍在执行的后台任务（即‘连接待命’）。Sheehan设想传统应用将逐步把更多功能添加至UWP当中，直到最终彻底完成迁移并能够运行在其它UWP平台之上——例如Windows 10 Mobile或者Xbox。
尽管微软的发展战略在安全层面似乎无甚想法，至少与Windows 8时代相比是如此，但Centennial项目仍然能够潜在提升Windows用户的使用体验。AppX技术意味着应用程序可以实现清洁安装与卸载，而通过Windows Store进行桌面应用程序部署则能够提供一定程度的安全保护——因为其在向Store进行提交时需要接受审核。
本文转自d1net（转载）