Everything is 'different on Windows': Zed port delays highlight dev friction 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 …
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.
Case insensitive is annoying but tolerable for ASCII. It gets super annoying with languages where upper / lower are totally different or where transliteration is involved. e.g. if you were German you might write schloss, or schloß, or SCHLOẞ, or any other variation and the case insensitive filesystem might cope but it doesn't mean apps on top will. So I agree with Linus that file names should be unambiguous which means case sensitive and unicode. No code pages, no to upper / lower, no file name shortening / mangling.
With Unicode you also run into the problem of there being different ways to represent the same glyph; for example, ö has its own codepoint, but can also be the letter o plus a combining mark plus an umlaut. So you face the question, do you consider these different characters for filename purposes? If you do, it's confusing, and can have security repercussions. Or do you canonicalize them somehow?
> it's confusing, and can have security repercussions
Which is a very good reason for separating "identifier" (keep it in ASCII range 33 to 126, maybe leave out a few punctuation chars, even if it looks a bit ugly - fred19_532) from "display name" (full-fat UTF-8).
E.g. make your URLs unambiguous-but-icky (and include in your restrictions anything that needs to be %-encoded) but let the page title be glorious (ideograms and mixed languages/scripts).
And bring back Amiga-style description files (or metadata/alternate streams on a file) when putting icons onto the desktop: Keep Filenames Space Free (but use an entire paragraph in your display name, alongside your choice of icon - and arguments, starting directory etc - in your dot-inf equivalent file).
AFAIK there are two approaches to this: kits that come with all their own widgets and controla (Java), and others that use system ones where possible (QT). Most of it is writing stuff once per platform and keep it up to date. Of course, platform updates (Vista, Aqua, etc.) are more work but you're normally not replacing both libraries and GUI parts.
QT's been doing this for decades for paying customers like Adobe, who in turn have customers who pay for just that.
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
It's funny how we've come full circle. Back in the text console days text mode stuff was fast because the text rendering and scrolling were done in hardware. Now everything's done in graphics mode so the only way to get snappy text rendering is with a GPU.
But in Windows (and I assume most composed Linux desktops?) the drawing is being done by the GPU... by lower level libraries that are probably better written and battle tested than the code in this editor.
In Windows hardware accelerated graphics have been available since Windows 3.1. Before 3D, it was which card has the best GDI acceleration (that you could afford) that tended to drive your purchasing, as actually moving memory about yourself is slow, even to this day. (It's why the windows installer feel sluggish compared to the installed OS).
Why not? The GPU is there after all. Same question's been asked about terminal emulators, same answer; fast display updates.
One reason I am mostly on Zed these days is that, at times (less so recently), VS Code could really slow down on me.
Specifically, I think it had problems updating all the shiny chrome VS Code has all over (line number, column number, class path info, etc...) that they insist on displaying on each keystroke. I'm a touch typing and I could feel my keystrokes lagging. No idea if, in VSCode, the calculations are lagging or if it's the UI refreshing that slows. That's not something I appreciate in an editor.
Not that I think it will get done, but things like implementing XEdit / KEdit's `more`, `less`, `all` display filtering commands (which act like `grep` and `grep -v` on file contents) needs quick screen refreshes.
And, for Zed, their main value proposition seems to be multi-user simultaneous editing. Think of it as live screensharing. That's probably a good call for very low level display management.
> Why not? The GPU is there after all
And your OS/graphics subsystem doesn't already have a text renderer that takes advantage of the GPU? There is still an awful lot of text being drawn all over the screen...
(I admit to using FreeType in a Windows program, but that is when I want to do something extra weird, like rendering strangely rotated/mirrored/peculiarly-pathed text via AGG; none of which is stuff I'd want to see in a text editor)
And I'd like to note, again, that I am using CodeWright under Windows, which does line numbers, text colouring etc etc, has not been updated for decades - and I can not out-type it: well, except for End-End-End which leaps a gigabyte down to the end of the file. It *does* sometimes wait for me to pause before redrawing with better colouring, 'cos it isbn't crudely coded.
> acceleration for a text editor
I began with CRT terminals (or sometimes mechanical Teletypes) over 300 baud (or 110 baud) links. That could be slow, but mostly when we had 100+ users on a machine barely spiffier than a good 80286.
Yes, check spelling (grammar, syntax) as you go adds another lump of molasses. But that has not been a real drag for a decade.
If you need to search the whole source tree for all occurrences of 'foo' maybe use multi-thread machine or even dedicated "chores" machine?
Holding-up a release for speed issues is an old-old game, and usually a losing game.
Excellent job, Shepilov.
Keep plugging at it. You have to give this audience the impression you know something more about IT than playing minesweeper and unhappy birds.
This rust line isn't all that popular however. You get better engagement when you bitch about the LLNs. Odd, I thought rust was a big problem in machinery. Still it is important to maintain consistency on our messaging and you are a master at repeating the same thing over and over. But maybe you should take inspiration from me: "M$ sucks" and "Ballmer is sweaty" is something that has worked for years.
Remember, our agency for research on the internet has a big push going on bad EU (talking point #3) and good Trump. Oh, I see you hit them with your customary "The EU is not fit for purpose".
Yours, Ilya Abramovich.
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.
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.
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
This post has been deleted by its author
> 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?
> This sounds like a Rust issue.
Perhaps it is a "Rust issue" in that "the Rust Community" hasn't taken the view of "let's look for a well-established cross-platform library - probably in C/C++, given the ways of the world - and translate it into Rust, taking advantage of all that knowledge of how to cope with the differences".
Do a good, solid, reliable GUI-etc library and *then* build your application on top of that. But a library isn't Sexy and New, unlike an Editor That Knows LLMs.
Instead, we have a group leaping in and trying to do it all in one go - and, by the appearance of things, in the wrong order ("all the right notes, not necessarily in the right order"): so they have one platform displaying text and other UI stuff, but released before they have cross-platform. Then built on top of the single-platform, inevitably causing abstractions to leak up into the application...
If they worked more like a community, sharing tasks and doing what is needed now instead of what is individually fun, all pulling for a common goal of World Domination...
> 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.
No, they don't.
By definition low level languages make things harder, not easier, as you have to do everything. (That's the 'low level' bit).
It's well written and mature cross platform libraries that make cross platform development very easy, some of these may be written in C or C++. The good ones have been around for decades now though, and still to this day require a decent amount of maintenance as the underlying platforms evolve.
The C spec is (was?) ambiguous on many things needed for true cross platform compatibility. How big is a char? What byte ordering is that thing encoded in? What procedure calling convention are you using? How do you pack your structs? (I may want to load a data file saved on system 'A' built with toolchain 'A' on system 'B' built with a different toolchain).
That's before you get to any real platform differences, such as those hinted at here. E.g. in windows (by default) filesystems are case insensitive. They're not on Unix. Or on some systems opening a file locks it, on others it doesn't by default. That's before you get to any more subtle differences in the way the various subsystems work. (eg, windows doesn't have a 'fork'...)
Skip pulling in an irresponsible number of dependencies and bindings from crates.io perhaps?
In that case you're definitely writing it all yourself then. Or are you only allowed to use shared libraries from C/C++?
Maybe I've misremembered the days of ./configure && make && sudo make install, but it seems that when I was doing that on a BSD (i.e. not Linux), I would often end up down a rabbit hole of compiling and installing whatever shared libraries the program needed. This was much much more difficult than resolving dependencies in modern languages, especially if I encountered a version conflict with another piece of software using the same library but on a different (and incompatible) version. I still have nightmares about getting PHP compiled with the right modules for what I wanted to do.
Why are people so against decent dependency management? The fault of 'pulling in the kitchen sink' is not related to Rust as a language, it's related to the developer using the language.
I tried zed a while ago and it crashed my X11 session. Let's see if its any better now...
Ooh, now it doesn't crash my session but all I get is a plain black rectangle. No window manager decorations. Nothing. Just a black rectangle. Its doing something - if I hit Ctrl-O I get my "open folder" dialog and... another black rectangle.
Two processes have spawned, one about ten times the size of emacs and one called with --crash-handler. No messages on stdout because the trendy way now is to detach from the terminal and save the user having to "&" the command or Ctrl-Z bg (there's a --foreground arg) So I have to get the PIDs and kill them now.
309Mb in ~/.local/ as well. Which I can get back using the best of the zed command line arguments: zed --uninstall
> a next-generation code editor designed for high-performance collaboration with humans and AI.
Ok, does it do anything better than Vim, emacs or CodeWright (which runs on WINE and is stable, hasn't been updated in, oooh, 20 plus years now!) just for examples.
> Integrate upcoming LLMs into your workflow to generate, transform, and analyze code.
Um, no, ta, not too worried about that
> Chat with teammates, write notes together, and share your screen and project. All included.
Well, CodeWright did co-operative editing that back in the 1990s (and plugins exist for the other two, if you must), so nothing novel there. FWIW my lot also gave up on that in the 1990s! Great way to get annoyed at each other (your mileage may vary). There are plenty of options for sharing screens etc between remote sites (if you are on the same site, just huddle together, it gives a better result all round).
And isn't there a philosophy about making tools that do one job (or as restricted a set of *very* closely related jobs) and do it well, rather than being a jack-of-all trades (cough, emacs, cough!)? If we *don't* rely on Zed's "all included" features, Jim can use the editor he is happy with, Fred uses his and I use mine - all we care about is that they all work with that most complicated of formats, plain text.
Of course, if Zed also provides 100% emulation of all our favourites, out of the box, mayyybe...
> 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.
Steam has by and large solved the gaming conundrums. Most, not all, games run very well on Linux.
There may be other reasons to avoid Linux as a consumer, but gaming shouldn't be a primary obstacle for most people.
This post has been deleted by its author
