微软UWP（通用Windows平台）已经死了吗？微软对于UWP和Windows应用平台的政策变化将成为Delphi的巨大利好！

Microsoft UWP（通用Windows平台）已经死了吗？构建Windows 10桌面应用程序的重点是什么？RAD Studio如何适应这种情况？以下是我的一些想法和答案。

---

UWP和Windows应用平台

正如您可能已经看到的那样，在过去的一个月中，围绕UWP（通用Windows平台）和当前焦点或焦点的变化进行了一些讨论，以及开发人员应如何为其主流操作系统构建应用程序，Windows 10有索赔和反诉，使整个辩论非常有趣。

毋庸置疑，微软构建Windows应用程序的方向对于我们的大多数客户来说至关重要，对于Embarcadero来说也是如此，因为RAD Studio非常关注Windows开发。

有关Microsoft观点的摘要，您可以阅读Windows开发人员平台的Microsoft公司副总裁Mary Jo Foley的采访Kevin httlo：https：//www.zdnet.com/article/microsoft-wants-to-close -the-UWP-Win32的分频与窗口，应用程序/

但是，让我从一开始就重温微软的计划（以及Embarcadero如何解决这些问题）。

UWP圣杯和WinRT

几年前，当微软推出适用于台式机的Windows 10时，该公司仍对其双胞胎Windows 10 Phone操作系统寄予厚望。我们知道这款手机最终成为微软的一大失败，但当时他们对此投入了大量赌注。UWP背后的想法是创建一个新的通用API和核心操作系统基础结构，允许相同的应用程序在所有版本的Windows（包括Xbox和HoloLens）上运行。从技术上讲，Windows 10附带了一个名为WinRT的新“核心”（最初在Windows 8中引入），这是一个可以使用特定API定位的子系统。这不是.NET API，而是更多的本机C ++类型的API。

附注：事实证明，WinRT与COM“兼容”并且可以轻松映射到Delphi接口 - 这就是Embarcadero为这个新平台API提供直接支持的功能。

还有其他一些关键原则：提高安全性（因为应用程序更孤立地运行，内存管理更安全），更稳定（具有响应更快的UI和异步流程），这可以使Windows成为一个更稳定的生态系统。

那么为什么不是所有开发人员都跳到了UWP和WinRT？微软提供了各种编程语言（C＃和.NET，C ++，甚至是JavaScript），他们期望大量采用。但是，UWP带有自己的UI设计指南（宽间距控制，全屏模式）和技术规范（几乎所有代码都需要异步），这阻碍了开发。不错，现代，但与其他API，平台和UX完全不同 - 开发人员难以采用，特别是如果目标是多个平台。基本上，无论您选择何种编程语言，现有代码都无法在那里运行。并且完全重写不是开发人员（及其公司）热衷于做的事情。

过桥或留在值得信赖的一方？

在最初的惨淡采用（允许开发人员在商店上发布应用程序 - 但是一个维护得不好的商店）之后，微软开始推广一系列“桥梁”，以允许将现有代码引入新的UWP平台。在Windows Phone上有一个支持Android应用程序的桥梁，一个用于Objective-C转换，另一个用于允许Win32原生应用程序成为UWP的一部分。现在这些是非通用的UWP平台应用程序，因为它们只能在Windows 10，桌面或移动版本之一上运行。这最终只会增加混乱。

此外，微软一直表示这些网桥旨在帮助您将应用程序一次转换为新模型，一种形式和一个模块 - 而不是一次性完成。但目标仍然应该完全重写您的代码。“如果你有一百万行代码，你想随着时间的推移迁移到新平台”，微软正式表示。但显而易见的是，开发人员并不想真正重写他们的代码，将其从Windows迁移到Windows 10！考虑到所有旧应用程序保持平稳运行并且操作系统提供的全新功能相当有限。

再一次，RAD Studio（以及Visual Studio）开始提供对Desktop Bridge的支持，但我们的目标只是让开发人员只针对WinRT端的新API（如通知或BLE），并能够在Windows应用商店 - 为了便于分发，利用低佣金和额外的货币化选项（通过订阅）。

微软放弃了吗？

这将我们带到今天和微软最近的“公告”。一个有趣的POV位于：https：//mspoweruser.com/uwp-is-dead-because-windows-apps-are-dead/

该公司显然已经意识到，无论他们坚持不懈，开发人员都不会重写应用程序来定位Windows操作系统。事实上，他们继续使用WinForms和MFC（在Microsoft开发人员工具方面）或VCL（在RAD工作室上）或其他本机库。如今，微软显然将UWP视为一种开发模式。

请注意，还有报告显示XBox应用程序现在使用电子工具构建，这是一个JavaScript桌面库：https：//www.onmsft.com/news/new-electron-powered-xbox-app-leaks-hours-before -E3

Windows平台的声明开发已停止似乎相当夸张。仍然有许多针对Windows编写的业务应用程序，以及实时控制系统和游戏。虽然许多消费者应用程序转移到了网络和移动设备上，但对Windows开发的投资仍然是IT预算的重要部分 - 尽管现有应用程序的维护可能是其中的重要部分。

无论如何，这只是场景的一个方面。桌面桥的APPX模型意味着应用程序运行“部分沙盒”。它们不能通过管理员权限提升，只能访问注册表和操作系统的“视图”。当然，他们仍然可以造成损害，但商店审查程序也应该有助于过滤掉坏人。围绕UWP / APPX的概念是应用程序可以更容易隔离（并且.NET Core甚至可以拥有自己的任何所需库的副本）。它们可以在没有管理员权限的情况下安装，并且可以移除干净（或几乎完全干净）的操作系统，模仿用户在手机上的体验。

现在，这不仅仅是UWP模型的存在，而是微软在MSIX技术方面的努力加倍。这听起来像是一种“安装”技术，但它实际上是APPX的下一次互动。MSIX应用程序可以通过Windows应用商店或企业分发模型进行分发，允许额外的安全性以及微软最初所谓的“虚拟化”，现在称为“容器化” - 以捎带共同的趋势。

想法应用程序应该越来越孤立地生活在.NET级别的变化支持下，每个应用程序都应该附带自己的.NET版本，而不是依赖于.NET，这个想法（.NET Core的一个关键元素）操作系统提供的库版本 - 具有减少依赖性并允许用户更新.NET而不用担心破坏其系统上现有应用程序的巨大优势。

RAD Studio怎么样？

这就是我对Windows应用程序平台未来的理解 - 一个允许Delphi和C ++ Builder VCL应用程序与微软自己的UI库和生态系统相媲美的未来，与现有代码和投资具有更高的兼容性。

作为目标平台的Windows 10活跃且不断增长（在桌面操作系统总体内，如果不是绝对的话），VCL支持Windows API，COM​​，WinRT和APPX模型，拥有您需要的所有目标平台。我们的库以行业内无与伦比的方式集成了Windows 10功能，高DPI支持和兼容性 - 不会忘记大型第三方控件生态系统！

作者： marcocantu