Live data from Hacker News

Zed for Windows: What's Taking So Long?

zed.dev

11–20 of 83 posts

Re: Zed for Windows: What's Taking So Long?

#11
post #5

Why dx11 and not 12? No one should care about win7 in 2025.

Think about the customer base: the sorts of users who want a high-performance text editor are exactly the kind of people who will run Windows 7 until it's pried from their cold, dead fingers, and who will flood the support forums with complaints if you limit support to operating systems released in the last 15 years. Because of their target market, Zed probably has implicit support requirements which wouldn't apply t…

Similarly, the Mac version is for MacOS 10.15 (from 2019) or later, and has an x64 version.

Re: Zed for Windows: What's Taking So Long?

#12

As a Windows dev... > but we got reports from users that Zed didn't run on their machines due to the Vulkan dependency This single sentence is abstracting a lot of detail. Vulkan runs on Windows, and quite well. Looking at the bug reports, especially the last one[1]... > Rejected for device extension "VK_KHR_dynamic_rendering" not supported Aha, ambitious devs >:) The dynamic rendering extension is pretty new, releas…

The Zed spirit is definitely to prefer a platform native solution.

You're right that we may be able to get rid of our WGSL implementation, and instead use the HLSL one via SPIR-V. But also, at some point we plan to port Zed to run in a web browser, and will likely build on WebGPU, where WGSL is the native shading language. Honestly, we don't change our graphics primitives that frequently, so the cost of having the three implementations going forward isn't that terrible. We definitely would not use MoltenVK on macOS, vs just using Metal directly.

Good point that we should publish a symbol server.

Re: Zed for Windows: What's Taking So Long?

#14

As a Windows dev... > but we got reports from users that Zed didn't run on their machines due to the Vulkan dependency This single sentence is abstracting a lot of detail. Vulkan runs on Windows, and quite well. Looking at the bug reports, especially the last one[1]... > Rejected for device extension "VK_KHR_dynamic_rendering" not supported Aha, ambitious devs >:) The dynamic rendering extension is pretty new, releas…

Yeah, I maintain a Vulkan backend, and this immediately triggered my internal "what?" alarm. Modern Direct3D is almost indistinguishable from Vulkan, on the other hand. So it shouldn't be difficult for them to add. I also agree with your HLSL comment. It sounds like these guys don’t have much prior graphics or game development experience.

I'd been thinking about it, and I added another paragraph above. I get a feeling they've been targeting Vulkan 1.3 with dynamic rendering from the beginning, so porting to D3D12 would be roughly as complex as rewriting to target older Vulkan.

Re: Zed for Windows: What's Taking So Long?

#15
post #4

This is why you don’t make your own cross platform toolkit.

while I would agree in general, there could theoretically be SOME applications where the range of UI controls (and systems) is small enough where it could pay off. But things tend to expand in surface area...

So with that, this presents a HUGE opportunity for someone to build something akin to Zed, but not with the baggage that their technical strategy brings.

Re: Zed for Windows: What's Taking So Long?

#16
post #5

Why dx11 and not 12? No one should care about win7 in 2025.

I've written a response below, but the summary is that mapping from Vulkan 1.3 with dynamic rendering to D3D11 is easier than targeting the lower-level D3D12. The latter does have some form of dynamic rendering too, but I suspect the authors woud've had to re-think their CPU code much more than what has currently been done. Getting Windows Vista and 7 support is a freebie.

Re: Zed for Windows: What's Taking So Long?

#18

Entirely unrelated, but the sections, toolbars, and controls in that RenderDoc app are so cleanly separated compared to modern dev tools. I wish more apps still looked like this.

I have my macOS set up that all buttons have borders etc

If I switch no vanilla macOS, it’s basically unusable

Clean, but unusable

Re: Zed for Windows: What's Taking So Long?

#19

As a Windows dev... > but we got reports from users that Zed didn't run on their machines due to the Vulkan dependency This single sentence is abstracting a lot of detail. Vulkan runs on Windows, and quite well. Looking at the bug reports, especially the last one[1]... > Rejected for device extension "VK_KHR_dynamic_rendering" not supported Aha, ambitious devs >:) The dynamic rendering extension is pretty new, releas…

The Zed spirit is definitely to prefer a platform native solution. You're right that we may be able to get rid of our WGSL implementation, and instead use the HLSL one via SPIR-V. But also, at some point we plan to port Zed to run in a web browser, and will likely build on WebGPU, where WGSL is the native shading language. Honestly, we don't change our graphics primitives that frequently, so the cost of having the th…

Did you consider using wgpu instead of writing a new dx11 renderer? It has metal, vulkan and dx12 backends so could have been used for a single renderer for macOS windows and Linux. (And webgpu in the future)

Re: Zed for Windows: What's Taking So Long?

#20
post #4

This is why you don’t make your own cross platform toolkit.

You'd rather see another crappy, slow editor packaging an entire browser? Because that seems like what people are using for "cross platform toolkits" these days. I'm glad Zed is being ambitious, it's truly a joy to use because it feels native. And to be honest, it's Windows, who cares. If you are a developer you should have switched to Linux years ago anyway.
Post reply on HN