Edit is now open source(devblogs.microsoft.com)
devblogs.microsoft.com
Edit is now open source
https://devblogs.microsoft.com/commandline/edit-is-now-open-source/
190 comments
I’d love to hear about the use of nightly features. I haven’t had time to dig into the usage, but that was something I was surprised by!
Up until around 2 months ago the project actually built with stable Rust. But as I had to get the project ready for release it became a recurring annoyance to write shims for things I needed (e.g. `maybe_uninit_fill` to conveniently fill the return value of my arena allocator). My breaking point was the aforementioned `LinkedList` API and its lack of cursors in stable Rust. I know it's silly, but this, combined with the time pressure, and combined with the lack of `allocator_api` in stable, just kind of broke me. I deleted all my shims the same day (or sometime around it at least), switched to nightly Rust and called it a day.
It definitely helped me with my development speed, because I had a much larger breadth of APIs available to me all at once. Now that the project is released, I'll probably stay with the nightly version for another few months until after `let_chains` is out in stable, because I genuinely love that quality-of-life feature so much and just don't want to live without it anymore. Afterward, I'll make sure it builds in stable Rust. There's not really any genuine reason it needs nightly, except for... time.
Apropos custom helpers, I think it may be worth optimizing `Vec::splice`. I wrote myself a custom splice function to reduce the binary size: https://github.com/microsoft/edit/blob/e8d40f6e7a95a6e19765f...
The differences can be quite significant: https://godbolt.org/z/GeoEnf5M7
It definitely helped me with my development speed, because I had a much larger breadth of APIs available to me all at once. Now that the project is released, I'll probably stay with the nightly version for another few months until after `let_chains` is out in stable, because I genuinely love that quality-of-life feature so much and just don't want to live without it anymore. Afterward, I'll make sure it builds in stable Rust. There's not really any genuine reason it needs nightly, except for... time.
Apropos custom helpers, I think it may be worth optimizing `Vec::splice`. I wrote myself a custom splice function to reduce the binary size: https://github.com/microsoft/edit/blob/e8d40f6e7a95a6e19765f...
The differences can be quite significant: https://godbolt.org/z/GeoEnf5M7
Thank you!
> I know it's silly,
Nah, what's silly is LinkedList.
> I think it may be worth optimizing `Vec::splice`.
If this is upstream-able, you should try! Generally upstream is interested in optimizations. sort and float parsing are two things I remember changing significantly over the years. I didn't check to see what the differences are and how easy that actually would be...
> I know it's silly,
Nah, what's silly is LinkedList.
> I think it may be worth optimizing `Vec::splice`.
If this is upstream-able, you should try! Generally upstream is interested in optimizations. sort and float parsing are two things I remember changing significantly over the years. I didn't check to see what the differences are and how easy that actually would be...
The quirkiness of Zig is real. I'd love for Zig to win out but it's just too weird, and it's not progressing in a consistent direction. I can appreciate you falling back to Rust.
> it's not progressing in a consistent direction
I've maintained a project in zig since either 0.4 or 0.5 and i dont think this is the case at all. supporting 0.12 -> 0.13 was no lines of code, iirc, and 0.13->0.14 was just making sure my zig parser could handle the new case feature (that lets you write a duff's device).
zig may seem quirky but it's highly internally consistent, and not far off from C. every difference with c was made for good reasons (e.g. `var x:u8` vs `char x` gives you context free parsing)
i would say my gripes are:
1. losing async
2. not making functions const declarations like javascript (but i get why they want the sugar)
I've maintained a project in zig since either 0.4 or 0.5 and i dont think this is the case at all. supporting 0.12 -> 0.13 was no lines of code, iirc, and 0.13->0.14 was just making sure my zig parser could handle the new case feature (that lets you write a duff's device).
zig may seem quirky but it's highly internally consistent, and not far off from C. every difference with c was made for good reasons (e.g. `var x:u8` vs `char x` gives you context free parsing)
i would say my gripes are:
1. losing async
2. not making functions const declarations like javascript (but i get why they want the sugar)
Thanks for this. Don't ask why but i just defaulted to Edit on Linux.
I noticed there's no locking for edited files. Not even a notification saying "This file has been modified elsewhere since you opened it. Do you still want to save"
Can you confirm this? Is it some thing you intend to add? Curious to know why, if the answer is no
Can you confirm this? Is it some thing you intend to add? Curious to know why, if the answer is no
I checked the git history to see if you included the Zig version but looks like first revision is rust...
In the Zig version did you use my zigwin32 project or did you go with something else? Also, how did you like the Zig build system vs rusts?
In the Zig version did you use my zigwin32 project or did you go with something else? Also, how did you like the Zig build system vs rusts?
Back then (a year ago?) I simply included the Windows.h header into a Zig file. Is that not possible anymore? It worked great back then for me IIRC!
Overall, I liked the build system. What I found annoying is that I had to manually search for the Windows SDK path in build.zig just so I can addIncludePath it. I needed that so I can add ICU as a dependency.
The only thing that bothered me apart from that was that producing LTO'd, stripped release builds while retaining debug symbols in a separate file was seemingly impossible. This was extra bad for Windows, where conventionally debug information is always kept in a separate file (a PDB). That just didn't work and it'd be great if that was fixed since back then (or in the near term).
Overall, I liked the build system. What I found annoying is that I had to manually search for the Windows SDK path in build.zig just so I can addIncludePath it. I needed that so I can add ICU as a dependency.
The only thing that bothered me apart from that was that producing LTO'd, stripped release builds while retaining debug symbols in a separate file was seemingly impossible. This was extra bad for Windows, where conventionally debug information is always kept in a separate file (a PDB). That just didn't work and it'd be great if that was fixed since back then (or in the near term).
> Since Zig is not internally supported at Microsoft just yet (chain of trust, etc.)
Is there something about Zig in particular that makes this the case, or is it just an internal politics thing?
Is there something about Zig in particular that makes this the case, or is it just an internal politics thing?
I don't know why, but I'm quite certain it's neither of the two. If anything, it has probably to do with commitment: When a company as large as MS adopts a new language internally, it's like spinning up an entire startup internally, dedicated to developing and supporting just that new language, due to the scale at which things are run across so many engineers and projects.
1. What do you like about Zig more than Rust?
2. How did you ensure your Zig/C memory was freed properly?
3. What do you not like about Rust?
2. How did you ensure your Zig/C memory was freed properly?
3. What do you not like about Rust?
> What do you like about Zig more than Rust?
It's been quite a while now, but:
- Great allocator support
- Comptime is better than macros
- Better interop with C
- In the context of the editor, raw byte slices work way better than validated strings (i.e. `str` in Rust) even for things I know are valid UTF8
- Constructing structs with .{} is neat
- Try/catch is kind of neat (try blocks in Rust will make this roughly equivalent I think, but that's unstable so it doesn't count)
- Despite being less complete, somehow the utility functions in Zig just "clicked" better with me - it somehow just felt nice reading the code
There's probably more. But overall, Zig feels like a good fit for writing low-level code, which is something I personally simply enjoy. Rust sometimes feels like the opposite, particularly due to the lack of allocators in most of its types. And because of the many barriers in place to write performant code safely. Example: The `Read` trait doesn't work on `MaybeUninit<u8>` yet and some people online suggest to just zero-init the read buffer because the cost is lower than the syscall. Well, they aren't entirely wrong, yet this isn't an attitude I often encounter in the Zig area.
> How did you ensure your Zig/C memory was freed properly?
Most allocations happened either in the text buffer (= one huge linear allocator) or in arenas (also linear allocators) so freeing was a matter of resetting the allocator in a few strategical places (i.e. once per render frame). This is actually very similar to the current Rust code which performs no heap allocations in a steady state either. Even though my Zig/C code had bugs, I don't remember having memory issues in particular.
> What do you not like about Rust?
I don't yet understand the value of forbidding multiple mutable aliases, particularly at a compiler level. My understanding was that the difference is only a few percent in benchmarks. Is that correct? There are huge risks you run into when writing unsafe Rust: If you accidentally create aliasing mutable pointers, you can break your code quite badly. I thought the language's goal is to be safe. Is the assumption that no one should need to write unsafe code outside of the stdlib and a few others? I understand if that's the case, but then the language isn't a perfect fit for me, because I like writing performant code and that often requires writing unsafe code, yet I don't want to write actual literal unsafe code. If what I said is correct, I think I'd personally rather have an unsafe attribute to mark certain references as `noalias` explicitly.
Another thing is the difficulty of using uninitialized data in Rust. I do understand that this involves an attribute in clang which can then perform quite drastic optimizations based on it, but this makes my life as a programmer kind of difficult at times. When it comes to `MaybeUninit`, or the previous `mem::uninit()`, I feel like the complexity of compiler engineering is leaking into the programming language itself and I'd like to be shielded from that if possible. At the end of the day, what I'd love to do is declare an array in Rust, assign it no value, `read()` into it, and magically reading from said array is safe. That's roughly how it works in C, and I know that it's also UB there if you do it wrong, but one thing is different: It doesn't really ever occupy my mind as a problem. In Rust it does.
Also, as I mentioned, `split_off` and `remove` from `LinkedList` use numeric indices and are O(n), right? `linked_list_cursors` is still marked as unstable. That's kind of irritating if I'm honest, even if it's kind of silly to complain about this in particular.
In all fairness, what bothers me the most when it comes to Zig is that the language itself often feels like it's being obtuse for no reason. Loops for instance read vastly different to most other modern languages and it's unclear to me why that's useful. Files-as-structs is also quite confusing. I'm not a big fan of this "quirkiness" and I'd rather use a language that's more similar to the average.
At the end of the day, both Zig and Rust do a fine job in their own right.
It's been quite a while now, but:
- Great allocator support
- Comptime is better than macros
- Better interop with C
- In the context of the editor, raw byte slices work way better than validated strings (i.e. `str` in Rust) even for things I know are valid UTF8
- Constructing structs with .{} is neat
- Try/catch is kind of neat (try blocks in Rust will make this roughly equivalent I think, but that's unstable so it doesn't count)
- Despite being less complete, somehow the utility functions in Zig just "clicked" better with me - it somehow just felt nice reading the code
There's probably more. But overall, Zig feels like a good fit for writing low-level code, which is something I personally simply enjoy. Rust sometimes feels like the opposite, particularly due to the lack of allocators in most of its types. And because of the many barriers in place to write performant code safely. Example: The `Read` trait doesn't work on `MaybeUninit<u8>` yet and some people online suggest to just zero-init the read buffer because the cost is lower than the syscall. Well, they aren't entirely wrong, yet this isn't an attitude I often encounter in the Zig area.
> How did you ensure your Zig/C memory was freed properly?
Most allocations happened either in the text buffer (= one huge linear allocator) or in arenas (also linear allocators) so freeing was a matter of resetting the allocator in a few strategical places (i.e. once per render frame). This is actually very similar to the current Rust code which performs no heap allocations in a steady state either. Even though my Zig/C code had bugs, I don't remember having memory issues in particular.
> What do you not like about Rust?
I don't yet understand the value of forbidding multiple mutable aliases, particularly at a compiler level. My understanding was that the difference is only a few percent in benchmarks. Is that correct? There are huge risks you run into when writing unsafe Rust: If you accidentally create aliasing mutable pointers, you can break your code quite badly. I thought the language's goal is to be safe. Is the assumption that no one should need to write unsafe code outside of the stdlib and a few others? I understand if that's the case, but then the language isn't a perfect fit for me, because I like writing performant code and that often requires writing unsafe code, yet I don't want to write actual literal unsafe code. If what I said is correct, I think I'd personally rather have an unsafe attribute to mark certain references as `noalias` explicitly.
Another thing is the difficulty of using uninitialized data in Rust. I do understand that this involves an attribute in clang which can then perform quite drastic optimizations based on it, but this makes my life as a programmer kind of difficult at times. When it comes to `MaybeUninit`, or the previous `mem::uninit()`, I feel like the complexity of compiler engineering is leaking into the programming language itself and I'd like to be shielded from that if possible. At the end of the day, what I'd love to do is declare an array in Rust, assign it no value, `read()` into it, and magically reading from said array is safe. That's roughly how it works in C, and I know that it's also UB there if you do it wrong, but one thing is different: It doesn't really ever occupy my mind as a problem. In Rust it does.
Also, as I mentioned, `split_off` and `remove` from `LinkedList` use numeric indices and are O(n), right? `linked_list_cursors` is still marked as unstable. That's kind of irritating if I'm honest, even if it's kind of silly to complain about this in particular.
In all fairness, what bothers me the most when it comes to Zig is that the language itself often feels like it's being obtuse for no reason. Loops for instance read vastly different to most other modern languages and it's unclear to me why that's useful. Files-as-structs is also quite confusing. I'm not a big fan of this "quirkiness" and I'd rather use a language that's more similar to the average.
At the end of the day, both Zig and Rust do a fine job in their own right.
The design intent of unsafe Rust is that its usage should be rare and well-encapsulated, but supported in any domain. Alleviating a performance bottleneck is a fine reason to use unsafe, as long as it only appears at the site of the bottleneck and doesn't unnecessarily leak into the rest of the codebase.
The most basic reason why you can't have unrestricted mutable aliasing is because then the following code, which contains a use-after-free bug, would be legal:
The "few percent in benchmarks" thing sounds like it's referring to the rule that it's UB to use unsafe code to make aliased &mut references even if you don't actually use those references in a problematic way. Lifting that rule would preclude certain compiler optimizations, and as per above would not fix the real problem; you still couldn't have unrestricted mutable aliasing. It would only alleviate the verbosity cost, and that could be done in a different way without the performance cost (like by adding special concise syntax for UnsafeCell) if it were deemed important enough.
The uninitialized-memory situation is pretty widely agreed to be unsatisfactory. Unfortunately it is hard to fix. Ideally the compiler would do flow-control analysis so that you can read from memory that was uninitialized only if it has definitely been written to since then. Unfortunately this would be a big complicated difficult-to-implement type system feature, and the need to make it unwind-safe (analogous to the concept of exception safety in C++) adds much, much more complication and difficulty on top of that. You could imagine an intermediate solution, wherein reading from uninitialized memory gets you a valid-but-unspecified value of the applicable type instead of UB, but that also has some difficulties, such as unsoundness in conjunction with MADV_FREE; see https://internals.rust-lang.org/t/freeze-maybeuninit-t-maybe... if you're curious for more details.
Again, the point here is not "the current design is optimal", it's "improving on the current design is a difficult engineering problem that no one has solved yet".
I think people who need cursors over linked lists use a third-party library from crates.io for this, but it's quite reasonable to think that the standard library should have this. Most of the time when a smallish feature like that remains unstable it's because nobody has cared enough about it to shepherd it through the stabilization process (perhaps because it's not a hard blocker if you can use the third-party library instead). Possibly that process is too slow and heavyweight, but of course enacting a big process change in a massively multiplayer engineering project that's governed by consensus is an even harder problem.
The most basic reason why you can't have unrestricted mutable aliasing is because then the following code, which contains a use-after-free bug, would be legal:
let mut val = Some("Hello".to_owned());
let outer_mut = &mut val;
let inner_mut = val.as_mut().unwrap();
*outer_mut = None;
println!("{}", inner_mut);
The "few percent in benchmarks" thing sounds like it's referring to the rule that it's UB to use unsafe code to make aliased &mut references even if you don't actually use those references in a problematic way. Lifting that rule would preclude certain compiler optimizations, and as per above would not fix the real problem; you still couldn't have unrestricted mutable aliasing. It would only alleviate the verbosity cost, and that could be done in a different way without the performance cost (like by adding special concise syntax for UnsafeCell) if it were deemed important enough.
The uninitialized-memory situation is pretty widely agreed to be unsatisfactory. Unfortunately it is hard to fix. Ideally the compiler would do flow-control analysis so that you can read from memory that was uninitialized only if it has definitely been written to since then. Unfortunately this would be a big complicated difficult-to-implement type system feature, and the need to make it unwind-safe (analogous to the concept of exception safety in C++) adds much, much more complication and difficulty on top of that. You could imagine an intermediate solution, wherein reading from uninitialized memory gets you a valid-but-unspecified value of the applicable type instead of UB, but that also has some difficulties, such as unsoundness in conjunction with MADV_FREE; see https://internals.rust-lang.org/t/freeze-maybeuninit-t-maybe... if you're curious for more details.
Again, the point here is not "the current design is optimal", it's "improving on the current design is a difficult engineering problem that no one has solved yet".
I think people who need cursors over linked lists use a third-party library from crates.io for this, but it's quite reasonable to think that the standard library should have this. Most of the time when a smallish feature like that remains unstable it's because nobody has cared enough about it to shepherd it through the stabilization process (perhaps because it's not a hard blocker if you can use the third-party library instead). Possibly that process is too slow and heavyweight, but of course enacting a big process change in a massively multiplayer engineering project that's governed by consensus is an even harder problem.
I think files as struct makes lots of sense. As it doesnt have to treat files in any special way then.
i had been dreaming about files as structs for about a two decades and Zig made it happen.
i will say the struct files (files which are not a namespace struct.. that is, they have field values) are a bit weird, but at least the syntax is consistent with an implicit surrounding bracket.
i will say the struct files (files which are not a namespace struct.. that is, they have field values) are a bit weird, but at least the syntax is consistent with an implicit surrounding bracket.
I wonder if you used GitHub Copilot or some other LLM-based code generation tool to write any of the code. If not, that's a lot of code to write from scratch while presumably under pressure to ship, and I'm impressed.
I did use Copilot a lot, just not its edit/agent modes. I found that they perform quite poorly on this type of project. What I use primarily is its autocompletion - it genuinely cured my RSI - and sometimes the chat to ask a couple questions.
What you expressed is a sentiment I've seen in quite a few places now. I think people would be shocked to learn how much time I spent on just the editing model (= cursor movement and similar behavior that's unique to this editor = a small part of the app) VS everything else. It's really not all that difficult to write a few FFI abstractions, or a UI framework, compared to that. "Pressure to ship" is definitely true, but it's not like Microsoft is holding a gun to my chest, telling me to complete the editor in 2 months flat. I also consider it important to not neglect one's own progress at becoming more experienced. How would one do that if not by challenging oneself with learning new things, right? Basically, I think I struck a balance that was... "alright".
What you expressed is a sentiment I've seen in quite a few places now. I think people would be shocked to learn how much time I spent on just the editing model (= cursor movement and similar behavior that's unique to this editor = a small part of the app) VS everything else. It's really not all that difficult to write a few FFI abstractions, or a UI framework, compared to that. "Pressure to ship" is definitely true, but it's not like Microsoft is holding a gun to my chest, telling me to complete the editor in 2 months flat. I also consider it important to not neglect one's own progress at becoming more experienced. How would one do that if not by challenging oneself with learning new things, right? Basically, I think I struck a balance that was... "alright".
It was very interesting to me that you liked Zig the most. Thank you for making this!
Thanks for undertaking this project, as well as making WT such an awesome app!
I already expressed my appreciation on the repo, but was promptly shushed by your colleague for Incitement Of A Language War, hehe.
I'm impressed by the architecture and implementation choices, especially the gap buffer and cursor movement. It seems we've independently arrived at the same kinds of conclusions on how to min-max a text editor: minimal concepts with maximal functionality.
Others have asked about Zig. I would love to hear more about the work you did in C. Did you start in C? What are some reasons why you didn't continue with C? If you had continued in C, with hindsight, what would have been most annoying? What was clearly better in C? Again, with hindsight, what would have been the best parts of following through with C? I see that you are C-cultured as well (Chris Wellons' blog) and some of the upsides of Zig that you mention I would have guessed you could have elegantly solved in C using Chris' insights. I'm very curious how with such expert advice available you still sought elsewhere and preferred it. Looking forward to hear about the C-side of the story.
Good luck with the project, and see you on the repo :)
I already expressed my appreciation on the repo, but was promptly shushed by your colleague for Incitement Of A Language War, hehe.
I'm impressed by the architecture and implementation choices, especially the gap buffer and cursor movement. It seems we've independently arrived at the same kinds of conclusions on how to min-max a text editor: minimal concepts with maximal functionality.
Others have asked about Zig. I would love to hear more about the work you did in C. Did you start in C? What are some reasons why you didn't continue with C? If you had continued in C, with hindsight, what would have been most annoying? What was clearly better in C? Again, with hindsight, what would have been the best parts of following through with C? I see that you are C-cultured as well (Chris Wellons' blog) and some of the upsides of Zig that you mention I would have guessed you could have elegantly solved in C using Chris' insights. I'm very curious how with such expert advice available you still sought elsewhere and preferred it. Looking forward to hear about the C-side of the story.
Good luck with the project, and see you on the repo :)
Can you say more about the chain of trust issue? Does Rust also not have that problem? Or are you using mrustc to bootstrap rustc?
Indeed, we have our own bootstrapped Rust toolchain internally. I think this has to do with (legal) certifications, but I'm not entirely sure about that.
BTW, are you aware of the Bootstrappable Builds folks achievements? Starting with only an MBR worth of commented machine code, plus a ton of source code, they build up to a Linux distro.
https://bootstrappable.org/ https://lwn.net/Articles/983340/ https://github.com/fosslinux/live-bootstrap/blob/master/part... https://stagex.tools/
https://bootstrappable.org/ https://lwn.net/Articles/983340/ https://github.com/fosslinux/live-bootstrap/blob/master/part... https://stagex.tools/
I'm really glad this wasn't killed off with the recent Microsoft layoffs!
Why not webassembly ABI?
I'm not familiar with that, so I can't say. If you have any links on that topic, I'd appreciate it.
Generally speaking, the requirement on my end is that whatever we use is as minimal as it gets: Minimal binary size overhead and minimal performance overhead. It also needs to be cross-platform of course. This for instance precludes the widely used WinRT ABI that's being used nowadays on Windows.
Generally speaking, the requirement on my end is that whatever we use is as minimal as it gets: Minimal binary size overhead and minimal performance overhead. It also needs to be cross-platform of course. This for instance precludes the widely used WinRT ABI that's being used nowadays on Windows.
Maybe something like https://www.codecentric.de/en/knowledge-hub/blog/plug-in-arc... ?
Webassembly is the binary spec for the web. But now everyone is using that because it's portable and lightweight.
The idea is you can create plugin using any language that compiles into webassembly. C, Rust, Pascal, Go, C++. Compile once and it should work in Windows, Linux and Mac. No need to compile to multiple architecture.
Performance should be great near native, but I guess there's going to be a problem with the added webassembly runtime size. Here is a runtime with estimated sizes: https://github.com/bytecodealliance/wasm-micro-runtime
And it's sandboxed too, so should be secure.
Webassembly is the binary spec for the web. But now everyone is using that because it's portable and lightweight.
The idea is you can create plugin using any language that compiles into webassembly. C, Rust, Pascal, Go, C++. Compile once and it should work in Windows, Linux and Mac. No need to compile to multiple architecture.
Performance should be great near native, but I guess there's going to be a problem with the added webassembly runtime size. Here is a runtime with estimated sizes: https://github.com/bytecodealliance/wasm-micro-runtime
And it's sandboxed too, so should be secure.
And I guess forcing FFI for plugins is going to be a headache for many plugin authors.
What I imagined is that people could load runtimes like node.js as a plugin itself in order to then load plugins written in non-native languages (JavaScript, Lua, etc.; node.js being an extreme example). I wonder if WASM could also be one such "adapter plugin"?
But plugins are still a long way off. Until then, I updated the issue to include your suggestion (thank you for it!): https://github.com/microsoft/edit/issues/17
But plugins are still a long way off. Until then, I updated the issue to include your suggestion (thank you for it!): https://github.com/microsoft/edit/issues/17
Yeah the choice usually js or lua. Webassembly is just a new option.
Why Rust over a compiled .NET lang? (e.g. C#)
Pretty much exclusively binary size. Even with AOT C# is still too large. Otherwise, I wouldn't have minded using it. I believe SIMD is a requirement for writing a performant editor, but outside of that, it really doesn't need to be a language like C or Rust.
Is there any context in which .NET runtime wouldn't be available on Windows (even if an older version, e.g. 4.x)? Because when you can rely on that and thus you don't need to do AOT, the .exe size for C# would likely be an order of magnitude smaller.
I intended for this editor to be cross-platform and didn't want to take on a large runtime dependency that small Docker images or similar may not be willing to bundle.
Will you implement theming?
> So, why not have fun learning something new, writing most things myself? I definitely learned tons working on this, which I can now use in other projects as well.
Because presumably you should have been doing it mostly for the benefit of Windows users, and wasting time because it’s a fun personal learning exercise means those users would suffer getting an underpowered app
Because presumably you should have been doing it mostly for the benefit of Windows users, and wasting time because it’s a fun personal learning exercise means those users would suffer getting an underpowered app
Fun-shaming a passionate developer who, beyond their job description, delivered an editor that checks all the required boxes (small binary, fast, ssh-support, etc.) in just 4 months, while working on weekends and even Christmas, and calling it "wasting time" is incredibly upsetting. I'm grateful to work with people who value that kind of initiative.
You're making it all up, he's a terminal product manager, so it is not beyond job description.
Of course the app doesn't check all boxes, plenty of features other editors have had years to add simply couldn't be added even if you work on Christmas (by the way, is also entirely driven by the NIH decision to write from scratch and not than that doing a 3 language mock)
And I'm not shaming the fun, I'm saying that that's not a good justification for shipping a worse app to the millions in a professional setting
Of course the app doesn't check all boxes, plenty of features other editors have had years to add simply couldn't be added even if you work on Christmas (by the way, is also entirely driven by the NIH decision to write from scratch and not than that doing a 3 language mock)
And I'm not shaming the fun, I'm saying that that's not a good justification for shipping a worse app to the millions in a professional setting
Wow, what a disheartening comment. Did GP not explain why they did what they did? This is an open-source project, the author expressed joy in working on it, and you have the heart to tell him off. This is far below what I expect of HN.
Did the comment not explain what the issue with that explanation is?
But maybe if you didn't misrepresent the situation so much you wouldn't lose your heart. This is not some tiny personal open source project where fun can be the only valid reason, but "will ship as part of Windows 11!", so millions of devices in a professional OS. Are your expectations so poorly calibrated that you have none in both cases? Why are they higher re. a forum comment?
But maybe if you didn't misrepresent the situation so much you wouldn't lose your heart. This is not some tiny personal open source project where fun can be the only valid reason, but "will ship as part of Windows 11!", so millions of devices in a professional OS. Are your expectations so poorly calibrated that you have none in both cases? Why are they higher re. a forum comment?
What led you to say that the author did not have users' interests at heart? What led you to imply that there's something wrong with reimplementing something or having fun or whatever it is you disliked you so much? What leads you think that a person working on something delivered with Windows 11 deserves less respect than a person working on a less used system? Or, do you consider what you said neutral, well argued criticism?
What led you to continue to misrepresent... everything?
Why did you make up a point about a person deserving respect and pass it as my thought? Could you not come up with a more coherent difference between those two situations yourself?
Why are you asking a question about the motivation if you don't even understand "whatever" it is I disliked?
Why did you make up the implication that rejects having fun?
Why are you making it personal in the first place?
How can criticism be neutral when it's... critical?
What kind of well argued thing do you expect in a... single sentence to even ask such a question?
Again, why is there such a huge mismatch in your expectations re. a comment and a professional app?
Why did you make up a point about a person deserving respect and pass it as my thought? Could you not come up with a more coherent difference between those two situations yourself?
Why are you asking a question about the motivation if you don't even understand "whatever" it is I disliked?
Why did you make up the implication that rejects having fun?
Why are you making it personal in the first place?
How can criticism be neutral when it's... critical?
What kind of well argued thing do you expect in a... single sentence to even ask such a question?
Again, why is there such a huge mismatch in your expectations re. a comment and a professional app?
I didn't intentionally misrepresent your comment, but I am open to having misunderstood it. Also, me answering with questions didn't help.
> > So, why not have fun learning something new, writing most things myself? I definitely learned tons working on this, which I can now use in other projects as well. > > Because presumably you should have been doing it mostly for the benefit of Windows users, and wasting time because it’s a fun personal learning exercise means those users would suffer getting an underpowered app
Would you care to elaborate on what intention you understood the author to have, which aspect of author's work you deemed as a waste of time, and why do you think the resulting app is underpowered for Windows 11 users?
I would also be interested in what mismatch you saw in my expectations as regards your original comment and a professional app.
I realise that we got off on a bad foot, but, if you care to, we can try and restart the conversation.
> > So, why not have fun learning something new, writing most things myself? I definitely learned tons working on this, which I can now use in other projects as well. > > Because presumably you should have been doing it mostly for the benefit of Windows users, and wasting time because it’s a fun personal learning exercise means those users would suffer getting an underpowered app
Would you care to elaborate on what intention you understood the author to have, which aspect of author's work you deemed as a waste of time, and why do you think the resulting app is underpowered for Windows 11 users?
I would also be interested in what mismatch you saw in my expectations as regards your original comment and a professional app.
I realise that we got off on a bad foot, but, if you care to, we can try and restart the conversation.
At the same time I think some of the most brilliant things to come from Microsoft are products of individual initiative, and when the project ends up compromised for some reason I get the idea that it's some kind of institutional higher-ups that do the damage after the fact.
Maybe just some residual instinct left over from times past when more people like Ballmer were still prominent, and they were not as user-enabling as today in some ways?
Maybe just some residual instinct left over from times past when more people like Ballmer were still prominent, and they were not as user-enabling as today in some ways?
It not only written in Rust, but they avoid basically any dependencies to third-party crates (beside the obligatory windows-sys/libc), optimizing probably for binary size.
To achieve this, they seem to re-implement considerable parts of the rust ecosystem (own TUI library implementation, own unicode handling, own arena implementation, ...).
I’m guessing this isn’t just to optimize for binary size. If you have the resources to avoid third party dependencies you eliminate the burden of having to build a trust case for the third party supply chain. That is the number one reason we sometimes reimplement things instead of using third party packages where I work: the risk from dependencies along with the effort required to establish that we can trust them is sometimes (not always) greater than just replacing it in house.
Microsoft has recently said AI writes 30% of their code. Reimplementing things isn’t as expensive as it once was.
That was absolutely not what was said. The way it was phrased indicates it only applies to a subset of projects, plus there were weasel words to indicate that maybe it's not actually quite that high, plus AI was not explicitly mentioned and it easily could include a lot of traditionally-generated code.
I ran across the dashboard where I work that is tracking Copilot usage. According to the dashboard 22% of suggestions are accepted. I assume Microsoft is quoting a similar stat. This is VERY misleading, as more often than not, the suggestion is trash, but has 1 thing in it I want for reference to look up something that might actually help me. I accept the suggestion, which increases that stat, but AI didn’t ultimately write the resulting code that went to production.
I took a glance around this project, and it seems to be really high quality Rust. I would be shocked if it was AI-generated to any significant degree, given my own less-than-impressive results trying to get LLMs to write Rust.
Edit: I see the author isn’t very familiar with Rust, which makes it even more impressive.
Edit: I see the author isn’t very familiar with Rust, which makes it even more impressive.
Maybe a tenth the total cost is getting the code into the terminal, the other nine tenths is maintaining way more code than you'd otherwise have to.
How much cost reduction does 30% ai written code translate to? It's easy to imagine that ai doesn't write the most expensive lines of code. So it might correspond to 10% cost reduction.
10% is nothing to scoff at, but I don't think it should factor into the decision to rewrite existing packages or trust third parties if you're very security minded.
10% is nothing to scoff at, but I don't think it should factor into the decision to rewrite existing packages or trust third parties if you're very security minded.
AI-writing has the cost of human orchestration, debugging, review. Code is now cheap to write, but for there to be a net efficiency gain, those other tasks have to not bloat too much.
Microsoft has no metric to track this and I can guarantee you that statement is for marketing purposes.
[deleted]
I'd guess legal reasons
I'd say the windows crate is even technically first-party since the OS vendor publishes it
Yay for finally having a default text editor that works over ssh. Managing windows servers over ssh is a bit of a pain without.
They could just have packaged nano, but oh well.
They could just have packaged nano, but oh well.
I wholeheartedly agreee. Nano is quite awesome, it is battle-tested and already has more features than needed for a basic text editor. Actually, Nano is too often frowned upon as too-basic, but is actually has a few advanced features that basic editors do not have (e.g., keyboard macros). I'd argue that Nano is simple rather than basic :).
I tried discussing it here a few months ago but it did not took off: https://news.ycombinator.com/item?id=41289773
I tried discussing it here a few months ago but it did not took off: https://news.ycombinator.com/item?id=41289773
I love nano and used it as my terminal editor on Linux.
Edit seems super approachable to newbies with it's mouse support in the menus. I love that and would love to see it in nano.
Edit seems super approachable to newbies with it's mouse support in the menus. I love that and would love to see it in nano.
Try micro
I was about to say, I use nano regularly, both locally and over ssh (to machines which have it installed, which is pretty much all of them). This looks nice and I love old-style console UIs, I fondly remember EDIT.COM and NC.EXE, and still use `mc` regularly with one pane pointing at a sshfs.
Ages ago I had to maintain a .BAT file, editing in EDIT.COM, that threw stuff at EDLIN.COM (roughly MS version of `ed`). Those where the ... not-so-good old days.
These days, with windows versions of `nano` and `busybox` you have some power tools without a full linux install.
Ages ago I had to maintain a .BAT file, editing in EDIT.COM, that threw stuff at EDLIN.COM (roughly MS version of `ed`). Those where the ... not-so-good old days.
These days, with windows versions of `nano` and `busybox` you have some power tools without a full linux install.
This could be a great text-mode IDE with the addition of some LSP, tree-sitter and DAP support. There is already an open issue about possibly adding support for tree-sitter grammars for fast syntax highlighting, but they do mention that this requires some sort of optional plugin system to avoid bloating up the codebase severely (for example, the tree-sitter grammars within the Helix editor take up hundreds of megabytes, which is obviously unacceptable here).
That just feels like scope creep. Notepad would also be neat with some better keybinding support, plugins, lsp, ... - but then it wouldn't be notepad, and theres countless not notepads out there.
Tools like nano (well, pico) exist to provide a reliable and always available minimum feature set. If you expand it, then you end up with something that is neither the minimum nor capable enough to sensibly compete with fully fledged alternatives.
Tools like nano (well, pico) exist to provide a reliable and always available minimum feature set. If you expand it, then you end up with something that is neither the minimum nor capable enough to sensibly compete with fully fledged alternatives.
Well, Notepad is introducing AI support which already feels like scope creep to me…
https://support.microsoft.com/en-us/windows/enhance-your-wri...
https://support.microsoft.com/en-us/windows/enhance-your-wri...
No, it would still be notepad, but a higher quality one where especially users who don’t know better wouldn’t have to suffer as much from bad/lacking functionality
There are already: Notepad3 (https://sourceforge.net/projects/notepad3/) or metapad (https://liquidninja.com/metapad/).
But they aren't part of Windows, so "users who don’t know better" continue to suffer!
More features ≠ higher quality.
But lack of useful features = lower quality, so you're just arguing for a permanent state of poor quality for some strange change-resisting reason and the fact that alternatives exist (so? why should that stop your alternative from becoming better?)
No. Adding superfluous features to an intentionally minimal baseline program defacto reduces it's quality by making it less suitable for its task and more likely to have defects.
There's decades worth of options for fatter editors out there. Tools like nano (and now edit) is ubiquitous because they are not such editors, and people need a reliable baseline without such features.
There's decades worth of options for fatter editors out there. Tools like nano (and now edit) is ubiquitous because they are not such editors, and people need a reliable baseline without such features.
What on earth needs hundreds of megabytes to describe its grammar?
Even the hundreds of kilobytes used in the official grammars seems bulky to me. https://github.com/tree-sitter/tree-sitter-java/releases
Even the hundreds of kilobytes used in the official grammars seems bulky to me. https://github.com/tree-sitter/tree-sitter-java/releases
I am truly behind the times. I didn't know you can ssh into a Windows system.
Since windows 10/windows server 2019 afaik.
https://news.ycombinator.com/item?id=15904265
https://news.ycombinator.com/item?id=15904265
Thanks! It always bugged me that Windows didn't have a sshd, since it's so popular outside of Windows. I thought the reason for it not being added would be admitting a failure somewhere - RDP not winning or something. Seemed odd to prevent a way into Windows Server.
No. It was a fundamental conceptual difference in the operating system. After Xenix, Microsoft did not use a terminal paradigm in its operating systems. They all had a "console" paradigm, where instead directly attached VDUs, keyboards, and mice had explicit API support as first-class devices. Because they targetted "personal computers" where one knew from the firmware up that the machine had a VDU, a keyboard, and (possibly) a mouse.
* https://jdebp.uk/FGA/tui-console-and-terminal-paradigms.html
For a long time, so long that I had a widely used 2 decades old Frequently Given Answer about it, Windows NT had no way to capture console I/O, no way of waiting on consoles for buffer changes and to inject back-end input events. No way to do what a SSH server would need to do in order to capture and send/receive that I/O over a network.
Then along came Windows Terminal, and I finally got to change the answer in 2018.
* https://jdebp.uk/FGA/capture-console-win32.html
* https://jdebp.uk/FGA/tui-console-and-terminal-paradigms.html
For a long time, so long that I had a widely used 2 decades old Frequently Given Answer about it, Windows NT had no way to capture console I/O, no way of waiting on consoles for buffer changes and to inject back-end input events. No way to do what a SSH server would need to do in order to capture and send/receive that I/O over a network.
Then along came Windows Terminal, and I finally got to change the answer in 2018.
* https://jdebp.uk/FGA/capture-console-win32.html
RDP is still the best remote desktop protocol - so much so that Gnome on Linux uses it for desktop sharing.
But, of course, it's a remote desktop protocol. Meanwhile Windows Server has been steadily moving onto command line & PowerShell for system administration for the past 12 years or so. The bespoke solution for remote admin has been remote PowerShell for a while, so ssh is arguably competing with that.
But, of course, it's a remote desktop protocol. Meanwhile Windows Server has been steadily moving onto command line & PowerShell for system administration for the past 12 years or so. The bespoke solution for remote admin has been remote PowerShell for a while, so ssh is arguably competing with that.
You can also run a ssh server in WSL2. You'll need to proxy connections to it or run a vpn though to have it visible from the outside. I use tailscale.
Ah, that makes sense then; I was really confused at first because I couldn't figure out why Windows would want a built-in text-mode editor. I suppose if folks are seriously using SSH to access Windows machines ... then I have other questions about why not RDP, but if that's a real thing people are doing then adding a built-in editor for them makes sense.
SSH is ubiquitous, lightweight, and now works for all machines equally.
SSH is integrated with everything and can be used to manage, transfer files/mount remote folders, forward ports in either direction, or proxy any network traffic through the remote end for debugging/access. You can open a remote folder directly in vscode, Zed or similar over SSH.
RDP to a standard Windows server (this was previously called "core" - having a desktop environment is a non-default add-on now) is silly as you're RDP'ing to solely see a cmd.exe window that asks you to use console-based configuration (sconfig.exe).
RDP to a windows server with "Desktop Experience" is silly because it is comparatively sluggish, streaming a (likely unaccelerated) video feed of heavier GUI applications vs. sending just a few text strings back and forth during editing.
Not to mention that containerized windows has no graphical stack and requires a text-centric workflow.
SSH is integrated with everything and can be used to manage, transfer files/mount remote folders, forward ports in either direction, or proxy any network traffic through the remote end for debugging/access. You can open a remote folder directly in vscode, Zed or similar over SSH.
RDP to a standard Windows server (this was previously called "core" - having a desktop environment is a non-default add-on now) is silly as you're RDP'ing to solely see a cmd.exe window that asks you to use console-based configuration (sconfig.exe).
RDP to a windows server with "Desktop Experience" is silly because it is comparatively sluggish, streaming a (likely unaccelerated) video feed of heavier GUI applications vs. sending just a few text strings back and forth during editing.
Not to mention that containerized windows has no graphical stack and requires a text-centric workflow.
This might be the most obvious use case: https://learn.microsoft.com/en-us/windows-server/administrat...
I'm a powershell bigot and spend most of my windows admin life in a terminal (or vscode) so my take is to simply use psremoting but ssh is there if you need.
I'm a powershell bigot and spend most of my windows admin life in a terminal (or vscode) so my take is to simply use psremoting but ssh is there if you need.
I prefer SSH because it fits into a standard workflow with far larger ecosystem (my file manager and editors can browse SSH directly, traffic can easily be routed over SSH in either direction), and is already what I'd use for the majority of servers and machines.
psremoting would be limited specifically to remote PowerShell on windows, which is comparatively limited. Even if I was purely a Windows admin I'd consider the SSH approach more powerful.
psremoting would be limited specifically to remote PowerShell on windows, which is comparatively limited. Even if I was purely a Windows admin I'd consider the SSH approach more powerful.
Understood and SSH figures heavily into any admin's workflow, but PSRemote brings some advantages when you're using powershell. Much like you can execute remote commands in SSH, I can do that w/ psremote while keeping the full object pipeline intact, whereas ssh just squashes all output to a single text string like most unix-native tooling.
Posh remoting works well because it's posh and you get all the nice object-oriented things that come from that. You do miss features like tunneling so I have SSH to fall back on where needed (and also for non-windows workloads etc). Right tool for the job and all that, and if you're not a heavy posh user the ssh option makes a lot more sense.
Posh remoting works well because it's posh and you get all the nice object-oriented things that come from that. You do miss features like tunneling so I have SSH to fall back on where needed (and also for non-windows workloads etc). Right tool for the job and all that, and if you're not a heavy posh user the ssh option makes a lot more sense.
Or kilo[1]
[0]: https://github.com/antirez/kilo/
[0]: https://github.com/antirez/kilo/
Or Micro[0]
[0]: https://github.com/zyedidia/micro
[0]: https://github.com/zyedidia/micro
Micro is nice because it is a single-file, stand-alone executable that has mouse support, macro record/playback and syntax highlighting. (I haven't checked Nano recently). It is great for making quick edits to json configs, shell scripts, python scripts, etc. Syntax highlighting and line numbering are key. If I need to make a really quick edit, it is much faster to use this than waiting for VS Code or PyCharm to load. You also stay focused. By this I mean, your eyes don't leave the terminal window that you are currently working in. This allows me to more quickly complete the task at hand.
I was impressed that they actually looked at other editors in the ecosystem, I wasn't expecting that. Aside from WSL stuff does Windows distribute any other 3rd party utilities?
openssh, curl, bsdtar (also Windows built in archive support is libarchive)
It's such a simple program that it's better to roll a proprietary program that is well integrated with windows
You can use nano over wsl if you want
You can use nano over wsl if you want
> You can use nano over wsl if you want
No, not when ssh'ing to a server to manage it. Pulling in a Linux VM to get a simple text editor also makes no sense.
There is also nothing to integrate - it's a basic text editor for a terminal with no fancy features. It either edits text or it doesn't.
No, not when ssh'ing to a server to manage it. Pulling in a Linux VM to get a simple text editor also makes no sense.
There is also nothing to integrate - it's a basic text editor for a terminal with no fancy features. It either edits text or it doesn't.
you gotta make sure that hotkeys get passed in every keyboard configuration. Ctrl, CTRL Shift, Ctrl Caps, Alt, how do tabs work? Etc..
That something looks simple but is actually difficult is an error we all make
That something looks simple but is actually difficult is an error we all make
This is a console application, it does not manage the keyboard directly and there is nothing windows specific here.
All existing editors do these things well already, nothing that required writing yet another editor.
All existing editors do these things well already, nothing that required writing yet another editor.
Actually, there is Windows-specific stuff in the new EDIT. When built for Windows, it uses a one-foot-in-each-camp mixture of high-level and low-level console I/O, high-level for output and low-level for input.
https://github.com/microsoft/edit/blob/main/src/sys/windows....
https://github.com/microsoft/edit/blob/main/src/sys/windows....
They could've just shipped YEdit, which is open source: http://www.malsmith.net/edit/ but there is NIH syndrome in MS.
Yedit actually was written by a Microsoft employee :P
It had some problems however with handling unicode (iirc). Basically, shipping yedit would have required a huge re-write of its underlying text buffer. In the end the discussions we had with Malcom concluded that just writing a new one was probably easier and more maintainable in the long run.
It had some problems however with handling unicode (iirc). Basically, shipping yedit would have required a huge re-write of its underlying text buffer. In the end the discussions we had with Malcom concluded that just writing a new one was probably easier and more maintainable in the long run.
Now that they have a text editor that can be used in a terminal:
Calling it: 2025 will be the year of Windows on the server. /s
Calling it: 2025 will be the year of Windows on the server. /s
Aside from Windows being... "windows" (IE; graphical) and the whole "we will do our own paradigm for nearly everything including file paths (UUNC included) and encoding..." Windows is actually pretty stellar if you're writing high performance software.
You can go really far with IOCP and it's so nice to write compared to the contemporary kqueue (BSD) or epoll. I will admit to not trying IO_Uring myself though.
Also the Windows system probes predate any kind of bpf and are easier to use than dtrace.
This is the maximum amount of love I will ever send in Windows' direction though. Everything else is ball-busting.
You can go really far with IOCP and it's so nice to write compared to the contemporary kqueue (BSD) or epoll. I will admit to not trying IO_Uring myself though.
Also the Windows system probes predate any kind of bpf and are easier to use than dtrace.
This is the maximum amount of love I will ever send in Windows' direction though. Everything else is ball-busting.
It's not my idea of a good time, but Windows pioneered some stuff that's really handy for servers.
Receive side scaling[1] is super handy at high volume, and it came from Windows. And Windows has better apis for it than I saw in FreeBSD or Linux when I needed it (I didn't look too closely at Linux though, so maybe it was there).
[1] https://learn.microsoft.com/en-us/windows-hardware/drivers/n...
Receive side scaling[1] is super handy at high volume, and it came from Windows. And Windows has better apis for it than I saw in FreeBSD or Linux when I needed it (I didn't look too closely at Linux though, so maybe it was there).
[1] https://learn.microsoft.com/en-us/windows-hardware/drivers/n...
There are more windows servers than linux desktops
Nitpick - this is a text user oriented (TUI) or a screen editor, not a CLI editor. A CLI editor is ed(1), or ex(1), or EDLIN for MS-DOS lineage.
I can't wait for the Rust port of QBasic Gorillas
This is a denial-of-service attack on my productivity :)
I fondly remember the times of editing the explosion radius to "tactical nuclear banana".
I fondly remember the times of editing the explosion radius to "tactical nuclear banana".
Edit for DOS was my favorite editor.
All the keys worked as you expect. You could select text with shift. It had find and a replace. That’s a lot more than most editors give you without config fiddling and arcane key commands.
Those simple things get almost everything I need for operating system maintenance.
Edit was the pure distilled essence of an editor.
It was a work of art really.
All the keys worked as you expect. You could select text with shift. It had find and a replace. That’s a lot more than most editors give you without config fiddling and arcane key commands.
Those simple things get almost everything I need for operating system maintenance.
Edit was the pure distilled essence of an editor.
It was a work of art really.
It was okay when it came out because the alternative was EDLIN (DOS version of ed). But IIRC, it had a 64KB file size limitation which was a problem.
It came out with MS-DOS 5, and by that time there were loads of alternatives already available. There were ports of Unix and Big Iron editor programs.
There were loads of native PC text editors, too. SemWare's QEdit had been around since 1985, for example. DR-DOS had had EDITOR for a while, which might indeed have spurred Microsoft into action.
Boxer was a contemporary with MS-DOS EDIT, but that name was a pun on the name of an earlier widespread DOS text editor named Brief, also around for years before EDIT came along.
There were loads of native PC text editors, too. SemWare's QEdit had been around since 1985, for example. DR-DOS had had EDITOR for a while, which might indeed have spurred Microsoft into action.
Boxer was a contemporary with MS-DOS EDIT, but that name was a pun on the name of an earlier widespread DOS text editor named Brief, also around for years before EDIT came along.
Interesting how we always go in circles.
edit.cmd was one of the first programs I ever used.
Now it's back rewritten as a Windows 10+ program in Rust?
Yet it looks and works just the same as 30 years ago!
edit.cmd was one of the first programs I ever used.
Now it's back rewritten as a Windows 10+ program in Rust?
Yet it looks and works just the same as 30 years ago!
You probably mean edit.com, which is what I thought of when I saw this post.
https://en.m.wikipedia.org/wiki/MS-DOS_Editor
https://en.m.wikipedia.org/wiki/MS-DOS_Editor
And it is, according to their GH page, an homage to EDIT.COM.
I wonder what prevented them from porting the ms-dos EDIT.COM to 64bit Windows back then. There's still EDLIN.COM in the 32bit version.
They canceled the 64-bit port of NTVDM (virtual DOS machine), which is what handles all those INT 21h syscalls from DOS applications. Without that, there's honestly not much to port, and it's easier to just make a new NT-native CLI app.
Did they cancel it because dosbox exists? If so, that's smart.
Most likely because Microsoft didn't consider it a valuable use of engineering time in general.
AMD's 64-bit extensions explicitly forbade dropping to 16-bit code. Once you enter 64-bit mode you lose access to all the modes which NTVDM needs to run MS-DOS or 3.x apps.
AFAIK the virtualization extensions added in 64-bit (known as VT-x etc) do allow 16-bit code, but that would require rebuilding NTVDM as a Hyper-V client (ala WSL2) instead of using 32-bit protected mode as a way to virtualize 16-bit code. However, these extensions didn't exist until way later and they didn't get support for booting 16-bit guests until later than that.
You could software emulate x86 to do NTVDM stuff. In fact, there's a FOSS program that does this, called WineVDM[0]. The MIPS/Alpha/PPC ports of NT used software emulation in NTVDM, so it is feasible.
[0] https://github.com/otya128/winevdm
Interestingly, they also recommend using DOSBox for DOS apps.
AMD's 64-bit extensions explicitly forbade dropping to 16-bit code. Once you enter 64-bit mode you lose access to all the modes which NTVDM needs to run MS-DOS or 3.x apps.
AFAIK the virtualization extensions added in 64-bit (known as VT-x etc) do allow 16-bit code, but that would require rebuilding NTVDM as a Hyper-V client (ala WSL2) instead of using 32-bit protected mode as a way to virtualize 16-bit code. However, these extensions didn't exist until way later and they didn't get support for booting 16-bit guests until later than that.
You could software emulate x86 to do NTVDM stuff. In fact, there's a FOSS program that does this, called WineVDM[0]. The MIPS/Alpha/PPC ports of NT used software emulation in NTVDM, so it is feasible.
[0] https://github.com/otya128/winevdm
Interestingly, they also recommend using DOSBox for DOS apps.
NTVDM has been unofficially built for x64[0] and it works (or rather, worked until MSFT started ripping-out USER32 APIs that are necessary for running Win16 apps).
[0] https://github.com/leecher1337/ntvdmx64
[0] https://github.com/leecher1337/ntvdmx64
It looks like you can switch the processor back to true 32-bit protected mode (not just 32-bit "compatibility mode" within long mode) https://forum.osdev.org/viewtopic.php?t=43127 which in turn gives you access to the old virtual 16-bit mode - but this involves running kernel code too in 32-bit mode, which is kind of a no-go in a modern OS. Using the virtualization extensions will be a lot easier.
Interesting - though one other hurdle coming up for this sort of thing is that Intel was threatening to drop real/protected/v8086 entirely and release processors that boot to long mode and don't let you drop out of it. Dunno if they still plan to go through with it or backed down.
DOS-era codebases are just terrible in a modern context, they would have to rewrite it from scratch anyway. The TUI IDE included within FreePascal is basically bitrotting due to this very reason.
The new Microsoft Edit is good. It's not as good as EDIT.COM,
but it gets the job done.
A couple of peeves: it lacks word count (which would be very useful), and there is no way to escape to shell (which would render it more usable for light scripting tasks).
I don't mind it too much, but I dislike how it hijacks the selected terminal font in Windows Terminal, how you can't hit Esc to close the menus in a Linux terminal, and how not all functions can be accessed using the keyboard with direct shortcuts.
For example, to change which file you're editing, you have to select View > Focus Statusbar, press the left arrow, hit Enter to select the list of edited files, select the file you want to switch to, and press enter. I wonder why there's no shortcut for that, which would be a common use case.
For a side project, it's very nice all around. If these issues were to be fixed, it would be a perfectly adequate editor.
Then the only feature missing would be an embedded Lisp interpreter used for automation and extensibility. :)
Edit: It has no telemetry, right?
A couple of peeves: it lacks word count (which would be very useful), and there is no way to escape to shell (which would render it more usable for light scripting tasks).
I don't mind it too much, but I dislike how it hijacks the selected terminal font in Windows Terminal, how you can't hit Esc to close the menus in a Linux terminal, and how not all functions can be accessed using the keyboard with direct shortcuts.
For example, to change which file you're editing, you have to select View > Focus Statusbar, press the left arrow, hit Enter to select the list of edited files, select the file you want to switch to, and press enter. I wonder why there's no shortcut for that, which would be a common use case.
For a side project, it's very nice all around. If these issues were to be fixed, it would be a perfectly adequate editor.
Then the only feature missing would be an embedded Lisp interpreter used for automation and extensibility. :)
Edit: It has no telemetry, right?
Why is it not as good as EDIT.COM?
I have to say, I really miss MS-DOS TUI apps like edit, the qbasic editor, and xtree-gold.
The linux-terminal based ones just seem a bit off in comparison. Maybe it's mouse and keyboard support in terminals (shift-enter support, anyone?) aren't great? People have different aesthetics? I don't know...
Next stop: VS-EDIT would be pretty cool :) (This with LSPs)
The linux-terminal based ones just seem a bit off in comparison. Maybe it's mouse and keyboard support in terminals (shift-enter support, anyone?) aren't great? People have different aesthetics? I don't know...
Next stop: VS-EDIT would be pretty cool :) (This with LSPs)
It's definitely for that reason. It is amazingly hard to portably do something as trivial in the DOS world as recognize [Shift]+[Ins]. The terminal paradigm is very different to the console paradigm in some areas.
In the days when a Tektronix terminal was a real physical thing that one sat in front of, the TUIs that one used didn't look at all like the ones in the contemporary personal computer world. Ironically, an old Tektronix or DEC VT user transported into the future would be very at ease with what you get in the Linux-based operating system world today.
All that said, the Windows Terminal people have worked pretty hard to get even some of the obscure ECMA-48, ITU T-416, DEC VT, and XTerm stuff into Windows Terminal, so at least TUI applications writers who are prepared to write all of the bizarre hooplah to have things like recognition of [Control]+[Home] and correctly operating reverse video, actually will get them.
In the days when a Tektronix terminal was a real physical thing that one sat in front of, the TUIs that one used didn't look at all like the ones in the contemporary personal computer world. Ironically, an old Tektronix or DEC VT user transported into the future would be very at ease with what you get in the Linux-based operating system world today.
All that said, the Windows Terminal people have worked pretty hard to get even some of the obscure ECMA-48, ITU T-416, DEC VT, and XTerm stuff into Windows Terminal, so at least TUI applications writers who are prepared to write all of the bizarre hooplah to have things like recognition of [Control]+[Home] and correctly operating reverse video, actually will get them.
DOS was the golden age for TUI apps because its ultimate API was both simple and powerful: direct video memory access in text mode. So you just get a linear chunk of memory where each character on screen corresponds to two bytes: one for the glyph, one for foreground/background color (4 bits each). For input you had some BIOS helper interrupts, but then again it was easy enough to read scancodes directly (and they were standardized on PC).
So you can handle any key or key combo however you want, and you can put any characters anywhere you want without weird corner cases like autoscrolling.
So you can handle any key or key combo however you want, and you can put any characters anywhere you want without weird corner cases like autoscrolling.
[deleted]
Weird choice of name for their new software, given there is already a pretty prominent editor from Microsoft named "edit".
https://en.wikipedia.org/wiki/MS-DOS_Editor
They seem to have given it the same name because they want to preserve the command. But the headline is... misleading.
https://en.wikipedia.org/wiki/MS-DOS_Editor
They seem to have given it the same name because they want to preserve the command. But the headline is... misleading.
I love that it has a toolbar with shortcut keys highlighted at the top. I wish more TUI programs had that, especially vim!
Zellij is a good example of a tui with shortcuts in the UI. Helped me learn them way better than I would have otherwise
Yes! GUI menus with keyboard shortcuts written on the menu items are a great way to explore and learn new software.
> While it is relatively simple to learn the magic exit incantation, it’s certainly not a coincidence that this often turns up as a stumbling block for new and old programmers.
What’s even simpler is changing the awful defaults and adding the menu to make this a non-issue at a tiny fraction of the time it would take to write a new editor.
> we decided that we wanted a modeless editor for Windows (versus a modal editor where new users would have to remember different modes of operation and how to switch between them)
New users could do everything in insert mode with the power of modes always in the background. Also you don’t need to remember how to switch as you can just show those key binds in either your menu or status bar if you think it’s very important, there is plenty of space looking at the screenshots
Such a wasted opportunity to use something powerful and extensible for rather flimsy reasons
What’s even simpler is changing the awful defaults and adding the menu to make this a non-issue at a tiny fraction of the time it would take to write a new editor.
> we decided that we wanted a modeless editor for Windows (versus a modal editor where new users would have to remember different modes of operation and how to switch between them)
New users could do everything in insert mode with the power of modes always in the background. Also you don’t need to remember how to switch as you can just show those key binds in either your menu or status bar if you think it’s very important, there is plenty of space looking at the screenshots
Such a wasted opportunity to use something powerful and extensible for rather flimsy reasons
New users accidentally end up in the wrong mode because they press the wrong key, and then get stuck because they don't know what a "mode" is.
There's really no reason for a basic lightweight text editor to have modes. If you as a power user want one, Vim can be installed as needed.
There's really no reason for a basic lightweight text editor to have modes. If you as a power user want one, Vim can be installed as needed.
> they press the wrong key
No they wouldn't, if you believe there are so many terminal editor users that can't be taught what modes are, you simply guard it via settings so that unless you enable it explicitly you can't press the wrong key
> There's really no reason for a basic lightweight text editor to have modes
There is - having the power in every single Windows installation, including all the VMs and other people's machines.
No they wouldn't, if you believe there are so many terminal editor users that can't be taught what modes are, you simply guard it via settings so that unless you enable it explicitly you can't press the wrong key
> There's really no reason for a basic lightweight text editor to have modes
There is - having the power in every single Windows installation, including all the VMs and other people's machines.
And again a case of bad naming from MS because it’s too basic to be distinguishable.
Distinguishable from the tool of that name, that came with the operating system (and prior Microsoft ones) for many years, that it is deliberately intended to provide a rough workalike 64-bit replacement for?
If it’s not the same then it’s a bad idea to give it the same name.
Imagine searching for a tutorial or a bug fix.
Imagine searching for a tutorial or a bug fix.
One would be in nothing more than the very same situation, which apparently has been problematic in your way for pretty much no-one, of Microsoft's various different programs all named CHKDSK. There have been at least 3, one of which we were told for years was superseded, which was not true for the next two, and the third of which has had four different flavours in the past 30 years.
Or command names that are common words like MORE, BREAK, DATE, CALL, IF, MODE, MOVE, PROMPT, SORT, TIME, COPY, and PATH for that matter.
What you are telling us is that the only way that you can think of to look this stuff up is by putting single words into a general-purpose WWW search engine. Instead of the intelligent way of finding the index of a command reference for Microsoft operating systems and looking up the EDIT command there. Microsoft has published its own command reference for decades, and there have been many others, including entire books on commands in Microsoft operating systems, for even longer.
Or command names that are common words like MORE, BREAK, DATE, CALL, IF, MODE, MOVE, PROMPT, SORT, TIME, COPY, and PATH for that matter.
What you are telling us is that the only way that you can think of to look this stuff up is by putting single words into a general-purpose WWW search engine. Instead of the intelligent way of finding the index of a command reference for Microsoft operating systems and looking up the EDIT command there. Microsoft has published its own command reference for decades, and there have been many others, including entire books on commands in Microsoft operating systems, for even longer.
>What you are telling us is that the only way that you can think of to look this stuff up is by putting single words into a general-purpose WWW search engine.
Like most people do.
>Or command names that are common words like MORE, BREAK, DATE, CALL, IF, MODE, MOVE, PROMPT, SORT, TIME, COPY, and PATH for that matter.
Same problem
>Microsoft has published its own command reference for decades
And changes the URLs to that references multiple time. More than one old links lead to nowhere now
>including entire books on commands in Microsoft operating systems, for even longer.
Books with a hefty price tag
Like most people do.
>Or command names that are common words like MORE, BREAK, DATE, CALL, IF, MODE, MOVE, PROMPT, SORT, TIME, COPY, and PATH for that matter.
Same problem
>Microsoft has published its own command reference for decades
And changes the URLs to that references multiple time. More than one old links lead to nowhere now
>including entire books on commands in Microsoft operating systems, for even longer.
Books with a hefty price tag
Very nice, I'll unironically add it to my repertoire of main code editing tools: nano and notepad.
Notepad had recently become infected with ai features and logins and tabs which I just hate, win some lose some ig
Notepad had recently become infected with ai features and logins and tabs which I just hate, win some lose some ig
I have, as they say in the theatre, notes. Lots of notes. Possibly beginning with a request to stop calling these "VT" sequences. Quite a lot of this wouldn't work on an actual DEC Video Terminal.
One of the questions I haven't yet answered from research is whether it supports [Control]+[P]. That's another of the non-secret secrets of the original EDIT.
One of the questions I haven't yet answered from research is whether it supports [Control]+[P]. That's another of the non-secret secrets of the original EDIT.
> Possibly beginning with a request to stop calling these "VT" sequences. Quite a lot of this wouldn't work on an actual DEC Video Terminal.
That is incredibly pedantic even by your standards.
That is incredibly pedantic even by your standards.
And that is a personal attack, which I'm sure Thomas Dickey would not appreciate being the target of, since this is M. Dickey's oft-made point.
Read https://invisible-island.net/ncurses/ncurses.faq.html#vt100_... and learn.
Read https://invisible-island.net/ncurses/ncurses.faq.html#vt100_... and learn.
Is there anything in EDIT.EXE for MS-DOS that inherently hinders porting to x64?
I wish they have implemented the same color theme as well.
I wish they have implemented the same color theme as well.
There is no EDIT.EXE. If you have an EDIT.EXE you probably need to check for malware. (-:
It was EDIT.COM, and in the days of long ago that was just a way of invoking QBASIC with the /EDIT command-line option. At which point the project becomes one of porting an old MS-DOS full programming IDE to 64-bit Windows, just for its text editor part.
Also, much of MS-DOS was written in 16-bit 8086 assembly language; so porting MS-DOS programs is not a mere matter of compiling a high level language with a compiler that targets the new platform and processor architecture and tweaking whatever breaks.
It was EDIT.COM, and in the days of long ago that was just a way of invoking QBASIC with the /EDIT command-line option. At which point the project becomes one of porting an old MS-DOS full programming IDE to 64-bit Windows, just for its text editor part.
Also, much of MS-DOS was written in 16-bit 8086 assembly language; so porting MS-DOS programs is not a mere matter of compiling a high level language with a compiler that targets the new platform and processor architecture and tweaking whatever breaks.
Sure about that? So in 32bit Windows where we still have EDIT, do we also have QBASIC?
Yes. In those days of long ago, I saw the .COM extension with my own eyes and ran QBASIC /EDIT directly just for kicks.
Once upon a time, this knowledge was one of those non-secret secrets that made it onto the letters pages of the computer magazines and into every "MS-DOS secrets" book out there. (-:
And yes, Windows NT 4 had the MS-DOS QBASIC.
Once upon a time, this knowledge was one of those non-secret secrets that made it onto the letters pages of the computer magazines and into every "MS-DOS secrets" book out there. (-:
And yes, Windows NT 4 had the MS-DOS QBASIC.
On well, now I have to roll out a 32bit Win7 vm to confirm this :)
Who knows?
Can't imagine anyone here using 32bit Windows and limiting themselves to 4GB of RAM.
Are there even any cheap laptops sold with that little nowadays?
Can't imagine anyone here using 32bit Windows and limiting themselves to 4GB of RAM.
Are there even any cheap laptops sold with that little nowadays?
What happened to shipping yedit? From the yori project, which I recommend to everyone on windows. Why wait when it has been available for years?
(Someone mentioned ssh, which leads me to believe this one is using ansi instead of the console API.)
(Someone mentioned ssh, which leads me to believe this one is using ansi instead of the console API.)
Will the old one from DOS be replaced entirely with this?
64 bit Windows, the only sort now with W11, doesn’t have MS-DOS support, so doesn’t have the old edit to start with.
Didn't know 32-bit Windows was completely gone.
It's not even that 32-bit Windows is gone. It's that NTVDM is (years ago) gone. See discussion elsewhere on this very page.
AFAIK all 32-bit x86 versions of Windows 10 have NTVDM as an option, it's the dropping of 32-bit kernel Windows with Windows 11 that finally killed it.
DOS was extended to 16-bit. ;-)
Pretty cool, at least much more user friendly and doesn't lag when opening large files.
And more features than notepad.
Why didn't they make this a package available ia winget? Did it have to be part of the OS?
It is available via winget https://github.com/microsoft/winget-pkgs/tree/master/manifes...
Could be installed with
Could be installed with
winget install Microsoft.EditThank you. I looked and failed to find it in the Edit repo
Yes, one use case is crash recovery.
And here I was hoping for the original MS-DOS Editor of Windows 95.
cute. extremely NIH in a field with many existing options, but very cute :)
does it support vim motions?
"Edit". Really? Was that the only name available? I am sick of these companies repurposing very common computing terms for their mediocre products.
"edit" has historically been the command used to invoke the built-in editor in Microsoft operating systems since DOS 5.0. Why should it suddenly change?
That's irrelevant. That was a command and a program and this is a product.
QuiCasseRien(3)
It's 2025 and Windows got what *nix got in the 1970s. Better late than never!
The ironic thing is that people said the same as you just did when EDIT originally came along in the 1990s. DR-DOS had had EDITOR for a while, and there was also a healthy shareware trade in DOS text editors, including even some DOS ports of Stevie. It was late then. But the computer magazines fawned over it.
To respond to some of the questions or those parts I personally find interesting:
The custom TUI library is so that I can write a plugin model around a C ABI. Existing TUI frameworks that I found and were popular usually didn't map well to plain C. Others were just too large. The arena allocator exists primarily because building trees in Rust is quite annoying otherwise. It doesn't use bumpalo, because I took quite the liking to "scratch arenas" (https://nullprogram.com/blog/2023/09/27/) and it's really not that difficult to write such an allocator.
Regarding the choice of Rust, I actually wrote the prototype in C, C++, Zig, and Rust! Out of these 4 I personally liked Zig the most, followed by C, Rust, and C++ in that order. Since Zig is not internally supported at Microsoft just yet (chain of trust, etc.), I continued writing it in C, but after a while I became quite annoyed by the lack of features that I came to like about Zig. So, I ported it to Rust over a few days, as it is internally supported and really not all that bad either. The reason I didn't like Rust so much is because of the rather weak allocator support and how difficult building trees was. I also found the lack of cursors for linked lists in stable Rust rather irritating if I'm honest. But I would say that I enjoyed it overall.
We decided against nano, kilo, micro, yori, and others for various reasons. What we wanted was a small binary so we can ship it with all variants of Windows without extra justifications for the added binary size. It also needed to have decent Unicode support. It should've also been one built around VT output as opposed to Console APIs to allow for seamless integration with SSH. Lastly, first class support for Windows was obviously also quite important. I think out of the listed editors, micro was probably the one we wanted to use the most, but... it's just too large. I proposed building our own editor and while it took me roughly twice as long as I had planned, it was still only about 4 months (and a bit for prototyping last year).
As GuinansEyebrows put it, it's definitely quite a bit of "NIH" in the project, but I also spent all of my weekends on it and I think all of Christmas, simply because I had fun working on it. So, why not have fun learning something new, writing most things myself? I definitely learned tons working on this, which I can now use in other projects as well.
If you have any questions, let me know!