Rufus作者长文痛斥UWP，微软还是十年前的香！

Rufus是一个工具能够帮助格式化和创建启动盘的工具，在Github上拥有一万五千颗星星。

这个仓库创始人对UWP的一番言论引发了广大网友的争议。

UWP 是 Universal Windows Platform （app） 的简称，是win10平台下开发可视化界面的程序，能够跨设备平台运行。

UWP应用实现了一次开发，适配不同Windows平台设备。UWP应用能根据尺寸大小自动调整布局，大大降低了开发适配的过程，提升了应用开发整体效率。

UWP应用在不同尺寸设备下的布局和操作逻辑是相近的。通过给用户一致的体验，从而降低用户学习成本。

网友的神奇提问

2020年9月12日，开发者bnainar在Rufus仓库中提出一个issue，质问作者为什么痛恨UWP，它明明看起来很有前途。

随后作者pbatard进行了长篇回复。

首先，你为什么认为我讨厌UWP呢？

我觉得它主要由以下几个问题

1、当我2011年开发Rufus时，UWP还不存在，所以当时我怎么恨他？

2、它与Windows7完全不兼容，Rufus需要在今年年初之前支持它（我仍然需要以完全非官方的方式“支持”，因为Rufus是一个允许人们从Windows7迁移出去的实用程序，因此，您确实希望Rufus继续在该平台上工作一段时间，而不管微软是否正式终止了对该平台的支持）。它与Rufus官方支持的windows8的兼容性也很有限。不是每个人都在使用Windows10。如果你只为Windows10设计应用程序，那你就是在伤害用户。

3、当涉及到应用程序可以做什么时，它的功能是非常有限的，因为微软对UWP应用程序的安全问题的答案是削弱UWP应用程序可以执行低级操作的手段，这就是为什么Windows终端团队必须花费大量时间（他们确实有一个庞大的团队和近乎无限的资源+直接访问微软内部开发人员来完成这些工作，我不知道）来最终创建一个混合UWP Windows终端应用程序。尤其是，如果你阅读官方文档building-windows-terminal-with-winui时，您会发现，使用UWP完全削弱了执行系统级操作的能力，例如在块级访问USB驱动器以及Rufus需要执行的许多其他操作。

因此，如果我们想在2018年将终端构建为一个UWP应用程序，那么我们将生成的任何shell（如cmd.exe、powershell.exe或bash）都将无法对系统执行任何操作。你能想象使用shell时不需要改变目录、读取文件内容或启动任何其他可以与之交互的进程吗？很明显，这对我们来说是不可能的。

当然还有其他的原因，作者表示我并不想谈。

换句话说，并不是因为你能够在不到5分钟的时间内创建一个简单的UWP应用程序，它不需要执行任何类型的系统访问，UWP才适合其他应用程序。只是重新设计了Rufus 3.0版的用户界面，让它看起来更“流畅”，我花了大约4个月的全职工作，它并没有什么特别之处：它只是当你采取一些看似简单的Rufus（“创建一个可引导的驱动器有多难，对吧？它只是创建一个分区，格式化它，从一个ISO复制一堆文件，对吗？”）并更新无数的元素，每当你从UI上接触任何东西时，这些元素都需要注意。而且，是的，我当时确实考虑过尝试使用UWP层，就像Windows终端的人那样，但我可以肯定地说，如果我这样做的话，我花的时间会比我花在2.x到3.x重新设计上的4个月要长得多，因为这需要我将应用程序分为多个层（是的，这在纸面上听起来很简单，但等到你真的试着这么做了），这就意味着Windows7用户会被Rufus2.x困住，即使他们的平台当时仍然得到官方支持。

所以请记住

1、不是因为某人不做某事，他们才讨厌它。

2、不要把批评（比如微软推出了另一个UI层，让老版本的Windows用户束手无策，而不是改进他们现有的一些API，这些API仍然被广泛使用，而且早就应该改进，比如引入一个完整的UTF-8层）当成是恶意的。我们可以列举许多使UWP不适用于某些任务的问题，并因此将其视为解决方案，这并不意味着“他们不使用UWP是因为他们讨厌UWP”

3、如果你没有做过适当的广泛研究，也没有研究过一项“有前途的”技术在实际应用于现有项目时可能会遇到的许多警告，那么从一种技术切换到另一种技术在纸面上可能看起来既轻松又迅速。但我恐怕已经在软件开发项目中积累了足够的经验，并且对鲁弗斯真正需要做的工作有足够的洞察力，让他知道这是不可能的。

在这个阶段，可能要到2023年（Windows8.1正式停止支持），我才能真正考虑从经过尝试和信任的（通用的）Win32/GDI过渡到其他东西，特别是考虑到微软仍在承诺，他们可能会尝试把自己的大便放在一起，允许Win32应用程序使用现代的UI-api，但这些api尚未定稿，而且还太新，无法过渡到winui3.0。实际上，应该是比UWP更好的过渡路径。

我相信我已经回答了你的问题，我将close这个issue。

随后这个问题也是被关闭掉了。

对于这么长的回复，bnainar也是表示太受宠若惊了！下面是他的回复：

哇！回答得太长了！我错了。我以为UWP是一个windows应用程序的设计系统加上一些额外的东西。比如材料设计等等，我想知道为什么你不喜欢一个设计系统。那么，微软是不是又一次绝望地试图通过告诉我们重写程序来统一平台呢？

rufus是否也适用于linux  如果没有任何类似的linux工具

把这个添加到常见问题(FAQ)中，这样你就不必一次又一次地回答像我这样的白痴了。

不知道为什么，bnainar还把问题从promising tech修改为promising thing。

既然UWP不好，那就迁移到其他系统

对于把Rufus迁移到非Windows系统上的计划，作者表示：“NO!”

我当然希望我可以，因为这听起来是一个很好的挑战，但我只是没有时间。而且，Rufus被设计成与windowsapi紧密合作，虽然应用程序看似简单，但真正发生在幕后的却绝非易事。

因此，将Rufus移植到另一个操作系统实际上比人们想象的要费劲得多。例如，我目前估计，获得一个Linux版本的Rufus，将提供至少75%的Windows版本的功能（就我而言，这甚至还不接近于我会满意地向公众发布的东西，因为它仍然会丢失太多的功能），至少4个月的全职工作。现实地说，我不可能看到自己放弃其他一切，每天花8-10个小时，持续4个月或更长时间，仅仅是为了得到一个基本的Linux版本的Rufus，它仍然缺少我认为必不可少的功能（例如创建Windows to Go图像的能力）。。。

此外，这些平台中的大多数已经具备了帮助您实现Rufus部分功能所需的工具（尽管可能不是一个方便的包）。事实上，Rufus依赖于最初在Windows以外的其他平台上设计和运行的工具，比如Syslinux、ms sys或e2fsprogs的坏块检查功能，因此至少这些功能可以在其他平台上获得。

再说一次，Rufus是免费软件，所以如果有人想尝试将它移植到另一个平台，他们非常欢迎这样做！

Reddit上掀起波澜

这个帖子时隔近一年又在Reddit上被网友翻出来了，2天时间获得了1千1百个点赞。

有网友认为UWP的最大问题就是微软都放弃他了，每次都在重写。

还有网友认为出发点是好的，但微软已经战略性放弃了。

他们从一个好的概念开始，但是半途而废(包括 windowsphone 和 Xbox) ，然后基本上放弃了它。他们本来打算跨平台的，但他们没有做到。

编辑按：本文转载至微信公众号 “新智元”, 贝壳投研经授发布