Everything is 'different on Windows': Zed port delays highlight dev friction

Graphics API, crash reporting and more: Making low-level code cross-platform for Windows is a challenge

Zed co-founder Max Brunsfeld has explained why the Windows port of the Rust-based editor is taking so long – illustrating the friction facing developers of cross-platform applications when including Microsoft's operating system.

The first beta release of Zed was in March 2023, but for macOS only. A published Linux build followed in June 2024. Work on a Windows port has been ongoing since early 2024, initially with contributor Junkui Zhang providing most of the commits, but Brunsfeld said that Zed has had four engineers working on the port for the past six weeks. The current status is that a Windows build is in closed alpha, or can be built from source.

Zed is in preview for all platforms, with a 1.0 release promised by the end of 2025. Windows support is part of this, according to the roadmap, though from Brunsfeld's description of its status, some sort of preview seems most likely.

Developing a cross-platform application that supports Windows is not so hard for those using frameworks such as Qt (a framework primarily for C++), but the Zed team decided to use its own GPU-accelerated UI framework for Rust, called GPUI, in order to optimize performance. This means using a graphics API to render the user interface. On macOS this is Metal and MSL (Metal Shading Language), and on Linux the Blade API which wraps Vulkan, a cross-platform graphics API from Khronos.

It is a low-level approach, unlike Microsoft's Visual Studio Code which uses a JavaScript runtime, but makes Zed distinctive for its snappy performance and lower resource usage.

The Zed team initially used Blade for Windows as well, but ran into problems on ARM64 builds of Windows. The latest code uses DirectX 11 instead, the native Windows graphics API. This runs better and with a lower memory footprint, but it means supporting three implementations of Zed's GPU shaders. Brunsfeld's post has more details.

It is not only the GPU code that is different on Windows. Brunsfeld lists other issues, including:

• Different file system operations, including the inability to overwrite a .exe file while it is running, complicating updates.
• Different crash reporting, requiring reworking of the crash reporting infrastructure.
• Different key binding expectations.
• Different file-system path conventions, impacting editing files on a remote Linux machine from a Windows client.
• Requirement for first-class support for WSL (Windows Subsystem for Linux), not relying on SSH (Secure shell) for authorization.

The build instructions for Windows show other issues such as "path too long" errors (fixable by setting longpath support).

Coding native applications that work equally well on Windows, Mac and Linux is challenging, as the experience of Zed's developers shows. It is also a reason for the stickiness of Windows in business and in gaming, as it is also hard to port in the other direction.®