当前位置: 时代头条 > 正文

Windows 将不支持 M1 Mac,球到了苹果脚下

去年秋季,苹果方面推出了搭载自研芯片 M1 的 Mac 系列产品,代表其开始尝试在桌面端摆脱对于 Intel 的依赖,并开始在这一领域拥抱 ARM 架构。而在搭载了 M1 的 Mac 系列产品陆续上市后,一个问题也随之浮出水面,那就是其是否能够支持 Windows on ARM。但针对这个问题,在 " 暧昧 " 了许久后,微软方面日前终于给出了回应。

根据海外媒体 The Register 的报道显示,微软方面近日确认在 M1 Mac 上运行 ARM 版 Windows 11 将不是 " 受支持的场景 ",Windows 11 不会通过虚拟化或其他方式为 M1 Mac 提供官方支持。

苹果 M1+Windows,曾被认为会是 " 双赢 "

作为苹果在 Mac 产品线上开始使用 ARM 架构的设备,在某种程度上也代表着其开启了生态大一统的序幕。然而,Windows 在这一市场深厚的历史底蕴以及强大的生态,还是有相当多的 Mac 用户有使用 Windows 的需求,所以在 Mac 开始陆续转换到 ARM 平台后,用户也在呼唤新的解决方案。

苹果软件工程高级副总裁 Craig Federighi 在 M1 Mac 上市后接受媒体采访时,对于 M1 Mac 的 Windows 支持做了回复,由于其使用了支持 Parallels 或 VMWare 等产品的虚拟化框架,所以 " 我们有核心技术来运行他们的 ARM 版 Windows,而后者当然支持 x86 应用程序。但这是微软必须做出的决定,授权用户在这类 Mac 上运行这项技术。但 Mac 确实很有能力做到这一点。"

事实上在 M1 Mac 上市后,与苹果关系匪浅的 Parallels Desktop 第一时间就发布了适用于 M1 机型的技术预览版。而许多在 M1 Mac 上运行 Windows 的用户,基本也都是通过 Parallels Desktop 虚拟机搭配 Windows 10 ARM 来实现的。但是使用虚拟机终究会带来更高的性能开销,特别是为了契合 M1 这种强调低功耗平台的特色,M1 Mac 本身的电池和散热就设计也非常大胆。

虚拟机所实现的支持自然不如原生来的便利,按照苹果方面当初接受媒体采访时的说法,表明这件事是由微软决定,也将皮球踢到了微软脚下。而微软为 M1 Mac 提供原生支持,也曾经被外界认为非常有可能,因为在 M1 Mac 发布一个月后,微软在去年 12 月 11 日在开发者博客上就已宣布,已通过内部开发渠道推送了 build 21277 x64 模拟 ARM64 设备的首个预览版本。

在当时的市场环境下,除了微软自己推出的 Surface Pro X 外,就只有 M1 Mac 可以用得上这一更新了。再加上,在经过了此前搭载高通主控的一系列 ARM 笔记本电脑后,Windows 上从 ARM 到 X86 效率转化糟糕的弊病也一览无余,在兼容性、效率,以及笼络开发者方面的失败,更是让 Windows on ARM 项目一蹶不振。

在这样的情况下,苹果打的小算盘就是如果微软还对于 Windows on ARM 有想法,拥抱 M1 Mac 自然就是非常现实的举措。毕竟在此前高通骁龙主控的两轮 ARM 笔记本电脑后,OEM 厂商还继续被微软 " 忽悠 " 的可能性已经不高,Windows on ARM 当下最大的潜在用户群体非 M1 Mac 莫属。所以微软为 M1 Mac 提供支持,也有利于 Windows10(ARM64)获得急缺的用户。

理想很美好,然而现实却是技术难度无比残酷

那么微软为何最终 " 拒绝 " 了苹果?显然,这是前者权衡利弊后得出的结论,M1 Mac 用户这块蛋糕虽然看起来可口,但想要吞下去却并不容易。事实上,M1 芯片采用的是 ARM 架构 CPU,使用的是 RISC 指令集,Intel/AMD 处理器则属于 x86 架构,使用的是 CISC 指令集,这是两个完全不同的平台,所以也就导致想要在 M1 Mac 上实现原生支持 Windows,有两个难关需要跨越。

首先,M1 中的 GPU 实际上对 Vulkan、OpenG、DirectX 三大主流 API 全部都不支持,macOS 在 M1 上的 OpenGL 其实是一个软件实现的 Metal 转译层。这就使得如果 Windows 想要调用到 M1 的 GPU,就需要重写驱动程序代码。

第二个难点,则是因为 Windows 是通过 ACPI 控制硬件,而 Mac 是使用 DeviceTree 来实现这一功能,但 DeviceTree 发源于 PowerPC 架构,这导致 M1 Mac 想要获得 Windows 的原生支持,就需要微软重新开发一套启动程序及匹配硬件控制逻辑。同时,由于使用 Windows 的设备都是采用 UEFI 启动,而苹果为 M1 Mac 准备的是与 iOS 一样的 iboot 作为 Bootloader。此前 Mac 使用 Intel 平台时,提供了官方的 Windows 安装工具启动转换助理(Boot Camp),靠的就是 Intel 平台支持 Windows。但这两个难点对于微软来说,就意味着巨大的工作量和庞大的人员开支,所以其权衡之后选择放弃也在情理之中。

屋漏偏逢连夜雨,M1 Mac 如今压力陡增

不过,Windows 不支持 M1 Mac 对于苹果而言,则是一个不算太好的消息了。因为在今年春季更新的 macOS Big Sur 11.2 上,苹果方面正式屏蔽了 M1 Mac 上 iOS/iPadOS 应用的侧载进程,使得 M1 Mac 不再能够通过 .ipa 文件的方式安装那些尚未在 App Store 上架的 iOS/iPadOS 应用。

要知道,当初 M1 Mac 发布时苹果方面曾表示,使用 M1 芯片的 Mac 和 Intel 平台 Mac 最大的区别,就是前者可以运行 iOS 与 iPadOS 应用,但前提是该应用的开发者支持。然而对于在 M1 Mac 上运行自家应用相当多的开发者都兴趣缺缺,且不提 Netflix、Spotify 这些与苹果不太对付的开发者,包括 Instagram、Snapchat、Ferrite Recording Studio、Tesla、MyFitnessPal、Reddit、Messenger、TikTok、Wechat 等等一大批知名应用,也都选择了退出。

因此现在的问题就是 M1 Mac 在失去了侧载能力,又没有获得原生 Windows 支持,只能使用付费的 Parallels Desktop 来虚拟化 Windows 的情况下,将使得用户可以用到的应用将受到一定的限制。这就可能会让 M1 Mac 出现当年 Windows Phone 的处境,即大量的开发者不支持、也缺乏足够的使用场景。

所以在有些观点看来,苹果的当务之急是在微软放弃这一合作,无法借助 Windows 生态的情况下,需要重新去找回退出 M1 Mac 应用的开发者,来尽快充实这一部分的内容生态。

最新文章