Everything is 'different on Windows': Zed port delays highlight dev friction
- Reference: 1755858307
- News link: https://www.theregister.co.uk/2025/08/22/everything_is_different_on_windows/
- Source link:
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 [1]roadmap , though from Brunsfeld's description of its status, some sort of preview seems most likely.
[2]
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 [3]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 [4]Blade API which wraps [5]Vulkan , a cross-platform graphics API from Khronos.
[6]
[7]
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.
[8]VS Code previews chat checkpoints for unpicking careless talk
[9]LibreOffice still kicking at 40, now with browser tricks and real-time collab
[10]Fresh programmer's editor on Linux lies Zed ahead
[11]Mozilla's midlife crisis has taken it from web pioneer to Google's weird neighbor
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 [12]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 [13]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.®
Get our [14]Tech Resources
[1] https://zed.dev/roadmap
[2] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/oses&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2aKiUHtyrcYQB0dTHxTcS_wAAAIY&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0
[3] https://github.com/zed-industries/zed/tree/main/crates/gpui
[4] https://lib.rs/crates/blade
[5] https://www.vulkan.org
[6] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/oses&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44aKiUHtyrcYQB0dTHxTcS_wAAAIY&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[7] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/oses&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33aKiUHtyrcYQB0dTHxTcS_wAAAIY&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[8] https://www.theregister.com/2025/08/12/vs_code_previews_chat_checkpoints/
[9] https://www.theregister.com/2025/02/13/libreoffice_wasm_zetaoffice/
[10] https://www.theregister.com/2024/07/15/zed_editor_arrives_on_linux/
[11] https://www.theregister.com/2023/09/29/mozilla_asleep_at_wheel/
[12] https://zed.dev/blog/windows-progress-report
[13] https://github.com/zed-industries/zed/blob/main/docs/src/development/windows.md
[14] https://whitepapers.theregister.com/
OB Linus
https://www.phoronix.com/news/Linus-Torvalds-Anti-Case-Fold
Bcache gets a mention.
..the Zed team decided to use its own GPU-accelerated UI framework for Rust, called GPUI, in order to optimize performance.
WTF? You need graphics acceleration for a text editor now?
I had exactly the same thought. I assume it's not mandatory as that would be silly. Unless they don't mean a dedicated GPU and just whatever generic display thingy you have.
It's called NIH (not invented here), or making a rod for your own back, see also Gnome. QT solves most of the problems and has decades of experience dealing with the cross-platform stuff.
People who write a cross-platform UI library find out the hard way they have to make it cross platform.
Tried it, out of curiosity...back on Vim.
I’ve never seen the need to look at any other editor for years now
There must be a list of mistakes people make time and time again... writing your own 'framework' must be on this list by now surely? Did no-one learn from Winamp 3?
GPU acceleration for an editor?
Exactly the same question was asked the last time this editor featured on the Reg
Apparently having GPU acceleration is a “feature”. I strongly suspect that in reality it’s a bodge to mitigate what must be truly horribly inefficient code. No other explanation makes sense
It really is beyond lunacy. Idiotic even
"Zed co-founder Max Brunfield has explained why the Windows port of the Rust -based editor is taking so long..."
Take as long as you like. No rush.
It is part of the Microsoft business plan
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.®
Making platform agnostic/portable applications hard to do is a way of locking users into their ecosystem.
Re: It is part of the Microsoft business plan
I don't think this sort of thing is intentional so much as that Windows is the last mainstream non-Unix OS remaining. And why should it be required to be a Unix?
Re: It is part of the Microsoft business plan
Just a gentle reminder that Windows and X are roughly the same age - Project Athena predates Windows by about a year, but Windows was around for a couple of years before X settled at version 11. Sun's initial GUI offering - around the same time - was SunView which was slated to be replaced with NeWS (based on PostScript) but both were gradually phased out in favour of X. The Common Desktop Environment which emerged for Unix (and OpenVMS) was proprietary.
Also, System V Unix used STREAMS for networking I/O (amongst other things) and there were all sorts of other differences (shared memory, IPC...) with BSD-like systems that made porting programs between different Unix variants challenging.
There always were a lot of incompatible systems and porting has always been a nightmare. Once you have a platform that has been widely used, it's important that future versions remain compatible with the previous ones if you're not going to have a lot of disgruntled users - so systems that start off different have a tendency to diverge further as new features are twisted to match established practice.
Re: It is part of the Microsoft business plan
Microsoft have consistently done things in a way that doesn’t match any current standards. In order to “innovate” as MS people used to be very fond of saying.
In reality, of course, it was always to lock customers in. Get sick of Outlook? Then just move to a standard email clien…. Oh.
Fast forward a few decades and Windows (in fact pretty much all MS slop) has an awful lot of non-standard baggage with it
> Graphics API, crash reporting and more: Making low-level code cross-platform for Windows is a challenge
No. This sounds like a Rust issue. Other low-level languages such as C or C++ make cross platform very easy.
Perhaps rewrite it in C or C++? Skip pulling in an irresponsible number of dependencies and bindings from crates.io perhaps?
These are all issues that a lot of *nix oriented ports face.
I remember when I was trying to get Git used by my company and the very first ports of Git for Windows were very hit and miss because they encountered random issues with locked files, long paths, case sensitivity, line endings etc. That said, OS X also has case insensitive files and weird file matching rules so weird platform issues exist elsewhere.