微软公司最近接连出台四项举措，允许开发人员将Web、iOS、Android以及遗留Windows应用移植到Windows Store当中——不过值得注意的是，遗留Windows问题仍然难以得到解决。
就在本周早些时候，微软公司发布了关于其Universal Windows Platform Bridge的更多细节信息——这是一整套技术方案，旨在将现有Win32应用、Android应用、iOS应用以及Web应用全部转化为Universal Windows，也就是通用Windows应用。
所谓通用Windows应用——也就是那些专门设计运行在全部搭载有Windows 10系统的设备上的程序——正是微软公司在其***版本操作系统当中引入的关键性规划。不过遗留Windows应用可能需要依托于更多工具包才能实现这一由陈旧版本向新版本的跨越。
一条四车道大桥
相关工具包于今年早些时候召开的微软Build大会上露过一面，其中四条移植“车道”虽然有所提及，但却未披露更多细节信息。Centennial项目负责将“经典”Windows应用程序（即Win32与.Net应用）推向通用交付；Islandwood项目允许将由Objective-C编写而成的iOS应用移植至Windows平台——具体来讲，该项目能够将Xcode项目导入Visual Studio当中。
Astoria项目负责利用一套“微软互操作库将微软服务整合至应用内部，同时保证不对应用作出过多修改”，并由此实现Android应用的Windows转化。***的Westminster项目于昨天曝出大量细节，能够让各类Web应用——包括在线与离线Web应用——被封装在通用Windows应用当中。
Astoria与Westminster两个项目似乎主要面向那些已经选定了自己开发堆栈的受众群体。在Westminster项目的相关博文当中，微软公司介绍了程序员如何将自己的编辑器、库以及部署服务加以结合。同样的，Astoria项目也允许程序员利用自己的“常用IDE”完成这项工作。
但目前仍有车道尚未开放
通过对现有应用程序进行轻松——至少可以说是较为轻松——地移植，而无需从头开始重新编写，微软公司制定出两项发展目标。其一是让Windows 10应用程序的开发工作能够在生态系统当中拥有更为广阔的实现渠道，其二则是让Windows Store成功扭转长久以来应用数量有限、质量低下的固有印象。
对现有iOS以及Android应用进行移植确实颇具现实意义，不过真正具有新意的其实是看微软——而非第三方应用开发平台——如何实现这个过程。也就是说，我们高度关注的其实是微软自身如何应对在将遗留Windows应用程序移植到Store当中时所带来的回报及风险。
处理这项工作确实会带来一定程度的风险，特别是某些遗留Windows应用在设计与运行方式上显得同全新通用体系格格不入。Brian Madden就曾指出，在Centennial项目当中，对遗留应用的移植需要首先解决权限评估——也就是UAC授权——这个难题，而Windows Store并不允许这样的变更。考虑到上述局限，任何使用自有内核层级组件或者设备驱动程序的应用都将无法通过Store实现交付。
微软公司对于Store应用作出的限制对于重新编写的应用程序来说则应该不会造成什么麻烦。不过除非所有遗留Windows应用都能够有效通过Store加以交付，否则Windows用户——以及系统管理员——将继续面对在应用程序安装与管理经验方面的脱节状况。
原文链接：
http://www.infoworld.com/article/2945382/microsoft-windows/microsoft-builds-bridges-from-ios-android-into-windows-app-store.html
原文标题：Microsoft to devs: We want your iOS and Android apps
核子可乐译
