为什么Windows还没有为Arm开发人员做好准备？

如果您想鼓励开发人员在 Arm 上移植适用于 Windows 的应用程序，那么交叉编译器还不够好。

在最近的一篇博文中，ZDNet 的Jason Perlow表示 Windows on Arm的主要障碍是硬件。如果只有硬件可用，我们就会有很好的体验，因为软件和开发工具都准备好了。当您考虑 Windows for Arm 上的开发人员工具状态时，这根本不是真的。

微软的官方开发者工具链在 Arm 上相当糟糕。微软不提供 Arm 版本的 Visual Studio、VS 构建工具，甚至不提供Microsoft Visual C++；他们希望 Arm 开发人员能够在 x86 主机上交叉编译 C++ 软件或模拟 x86 软件。 

Arm 对 .NET 和 VS Code 有原生支持，但这对 C++ 开发人员没有帮助。由于 MSVC 是封闭源代码，因此在 Arm 上获得对 MSVC 的本机支持的唯一方法是让 Microsoft 实现它。请参阅https://developercommunity.visualstudio.com/t/native-Arm-support-for-visual-studio/1161018

开源的情况也好不到哪里去。没有MinGW或MSYS开发环境的 Arm 实现；因此，Windows 上也没有可用的 Arm GCC或 Arm Clang 工具链。有一些功能请求可供他们添加原生 Arm 支持，但尚未准备好。如果您访问 Arm 的网站，他们有一个页面，您可以在其中下载用于 x86 设备的 MinGW GCC，以便为 Arm 设备进行交叉编译。当在 Windows 上编译您的产品的唯一方法是使用竞争对手的产品时，它确实说明了一些事情。

Windows 上另一个流行的 C++ 编译器是英特尔 C++编译器 (ICC)。由于明显的原因，这在 Arm 上不可用，并且无论如何都需要安装 Visual Studio。因此，4 个流行的 C++ 编译器中有 0 个可用于 Arm Windows。

也没有 Arm 原生 Windows 版本的 Python。但是，这可能会在今年某个时候得到解决：请参阅https://bugs.python.org/issue33125

您可能想知道为什么为编译器提供原生 Arm 支持如此重要。在为智能手机或游戏机开发软件时，许多开发人员已经从他们的计算机交叉编译到其他设备，那么为什么他们不能在 Arm Windows 设备上做同样的事情呢？他们可以，但这是二等的体验。

交叉编译不是 WINDOWS 的原生 ARM 工具链

不能在本地运行编译器并且需要另一台计算机来交叉编译二进制文件/可执行文件才能运行的 Windows 计算机与智能手机属于同一类，因为您无法在同一设备上进行开发和测试。这里的不同之处在于智能手机和游戏机并非旨在成为开发平台。在手机上编写代码是可能的，但并不常见。

假设您是一名有抱负的软件开发人员，并且去商店买了一台计算机，以便您可以学习 C++。在情况 A 中，您购买了 x86 Windows 设备，将其带回家，安装诸如 Visual Studio 之类的 IDE，编写一些 C++ 代码，点击按钮，然后您的代码就开始运行了。太好了，您正在一个具有一流支持的平台上进行开发。现在在情况 B 中，您购买了 Arm Windows 设备，将其带回家，意识到您的计算机没有 Visual Studio 或任何 C++ 编译器。所以你会怎么做？许多人会回到商店退回计算机并购买 x86 计算机。或者，在情况 C，您回到商店购买第二台 x86 计算机，带回家，安装 Visual Studio，设置交叉编译开发环境，编写一些 C++ 代码，点击按钮，并等待 10 秒以将其部署到 Arm 设备上。到那时，作为一名有抱负的开发人员，您会想知道为什么您不应该只针对 x86 进行开发，这样您只需要一台计算机就可以退回二等 Arm 设备。

Windows for Arm 的另一个缺点是不支持OpenGL或Vulkan。即使您设置了交叉编译工具链，如果您的应用程序使用 Vulkan，您也很不走运。如果您有 OpenGL 应用程序，Microsoft 的建议是使用ANGLE将 OpenGL 转换为 DirectX。 

微软的信息很明确：如果你想支持我们新的 Arm Windows 平台，你必须使用我们专有的 API。同样，PlayStation、Xbox、Switch 和 iPhone 要求开发人员使用专有的图形 API，并且没有一个可以运行编译器，因此您必须从另一台设备进行交叉编译。开发人员听到的也很清楚：Windows for Arm 是一个玩具操作系统，不能运行行业标准的图形 API 或编译器，因此不是一个严肃的开发平台，应该被视为手机或控制台。

只要在 Arm Windows 设备上开发体验较差，开发者就会选择使用 x86，因为它有一流的支持；他们永远不会为 Arm Windows 提供与 x86 相同级别的支持。 

如果消费者无论如何都必须为他们的应用程序模拟 x86，这种二等状态将导致消费者不想要 Arm 设备，这导致开发人员不关心 Arm 的反馈循环，因为它的体验很差，而且用户很少。这反过来又导致硬件制造商对制造功能强大的 Arm Windows 设备不够关心，因为很少有人愿意在二流设备上花很多钱。开始打破这个循环的唯一方法是让 Visual Studio 等主要开发人员工具支持 Arm。

相比之下，Arm 对 macOS 和 Linux 上的开发者工具的支持要好得多。GCC、Clang 和 Python 在这些操作系统上可用于 Arm 并且运行良好。您可以下载这些开发工具的本地版本，并在一台设备上本地编译它们，它的工作方式与人们希望的完全一样。 

开发人员会以不同的方式看待 APPLE 吗？

稍等片刻，我想让你想象一下，如果 Apple 在没有将Clang移植到它并且没有 OpenGL 支持的情况下发布 Arm macOS。在这种情况下，开发人员必须使用旧的 x86 Mac 进行开发并为 Arm Mac 进行交叉编译。如果发生这种情况，将会引起轩然大波，导致人们担心 Apple 正在将 macOS 转变为 iOS，它会被锁定，如果您无法编译自己的软件，那么很快您将无法运行您的软件。这会让 Arm 支持二流，人们会讨厌它。

纯粹从 C++ 开发人员的角度来看，您可能会争辩说 Linux 对 RISC-V 的支持比 Windows 对 Arm 的支持更好。RISC-V是一种非常新的开源 CPU 架构，还没有为消费者做好准备。RISC-V 上的 Linux 体验不是很好，但仍然有一个可用的编译器，因此您可以在一台设备上使用本机软件进行本机开发，而无需交叉编译。这是 Arm 相对于 Windows 的优势。

微软在 Arm 设备上的第一次尝试是 2012 年发布的原始 Surface 平板电脑，它运行 Windows RT（Windows 8 for Arm）。如果微软认真支持 Arm，他们应该早在 2012 年就将 MSVC 和 Visual Studio 移植到 Arm，类似于 Apple 在发布第一批 ARM Mac 时对 Xcode 和 Clang 的支持。回顾他们的历史，我怀疑微软是否会很快将 Visual Studio 移植到 Arm。微软直到 2022 年才将 Visual Studio 移植到同一架构的 64 位版本。那是在 2003 年发布第一个 64 位 x86 CPU 的 19 年后，即 Athlon 64。公平地说，他们确实在 2005 年左右将 MSVC 本身移植到了 64 位 x86，所以还是有希望的，但是为了获得良好的开发人员体验，他们需要将整个 Visual Studio 堆栈移植到 Arm。

我买了一台 Arm MacBook Pro 14" 在 Parallels VM 中进行 macOS 开发和 Windows 和 Linux 的 Arm 开发。我的目标是支持 Arm macOS 和 Arm Linux。但是，鉴于目前的事态，我不会付出任何额外的努力进入 Arm Windows 开发，直到微软决定它是一台真正的计算机并且有对 Visual Studio、MSVC、OpenGL 和 Vulkan 的原生 Arm 支持。我相信微软最终会到达那里，但简单的事实是，Windows for ARM 开发人员即使硬件已经准备好，工具今天也没有准备好。