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, ...).
porcoda · 1h ago
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.
criddell · 19m ago
Microsoft has recently said AI writes 30% of their code. Reimplementing things isn’t as expensive as it once was.
dymk · 9m ago
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.
walterbell · 10m ago
s/Reimplementing/Washing/
01HNNWZ0MV43FF · 2h ago
I'd say the windows crate is even technically first-party since the OS vendor publishes it
arghwhat · 4h ago
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.
zozbot234 · 1h ago
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).
Y_Y · 15m ago
What on earth needs hundreds of megabytes to describe its grammar?
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 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.
6c696e7578 · 1h ago
I am truly behind the times. I didn't know you can ssh into a Windows system.
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
yjftsjthsd-h · 2h ago
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.
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.
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
dijit · 2h ago
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.
toast0 · 2h ago
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).
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!
avestura · 23m ago
It was very interesting to me that you liked Zig the most. Thank you for making this!
90s_dev · 3h ago
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!
dbuxton · 3h ago
I can't wait for the Rust port of QBasic Gorillas
red_admiral · 2h ago
This is a denial-of-service attack on my productivity :)
I fondly remember the times of editing the explosion radius to "tactical nuclear banana".
zerr · 52m ago
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.
trinix912 · 3h ago
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.
tadfisher · 3h ago
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.
90s_dev · 3h ago
Did they cancel it because dosbox exists? If so, that's smart.
kmeisthax · 2h ago
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.
Interestingly, they also recommend using DOSBox for DOS apps.
EvanAnderson · 1h ago
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).
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.
kmeisthax · 1h ago
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.
zozbot234 · 2h ago
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.
TZubiri · 12m ago
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
tored · 3h ago
Oh nice! Can't wait to replace nano. Plugin support in lua?
90s_dev · 3h ago
I hope someone adds typed Lua support and sends a PR!
bitbasher · 29m ago
It's 2025 and Windows got what *nix got in the 1970s. Better late than never!
andrewstuart · 4h ago
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.
sedatk · 3h ago
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.
Ericson2314 · 3h ago
Will the old one from DOS be replaced entirely with this?
fredoralive · 2h ago
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.
Ericson2314 · 2h ago
Didn't know 32-bit Windows was completely gone.
croes · 1h ago
And again a case of bad naming from MS because it’s too basic to be distinguishable.
GuinansEyebrows · 3h ago
cute. extremely NIH in a field with many existing options, but very cute :)
mixmastamyk · 3h ago
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.)
QuiCasseRien · 4h ago
> Open Source, writen and build at Microsoft.
Oh yeah, i will get some C# or C++ code !
> Rust
Fucked. Why Why Why ?
lblume · 4h ago
I can see why people don't like to write Rust. It is more tedious, harder because of the ownership model, and has a very steep learning curve.
What I don't get is what people have against programs written in Rust from the bottom up. They are safer to use, introduce far fewer vulnerabilities, and you can even locally reason about the code much better than in typical 'unsafe' languages like C++.
eikenberry · 3h ago
It seems like your first paragraph answers the question in the second. If it is harder to use and learn then that reduces the value of free software released using it as that software is then harder to modify, fix, contribute to, etc. The tradeoff for Rust being hard should be more security and fewer bugs. The additional cost here, and the one that the OP is probably annoyed with, is that it moves away from the languages/platforms that MS has traditionally used and that developers who work on that platform expect.
koakuma-chan · 3h ago
Is Rust harder than C++?
haiku2077 · 31m ago
It's harder to do simple things and easier to do complicated things.
amenhotep · 8m ago
No.
eikenberry · 1h ago
If the OP already knows C++ then it would obviously be harder for them. Given the nature of their post, this was my interpretation.
npalli · 2h ago
Yes.
Guekka · 1h ago
That answer lacks some nuance
Yes, it is harder to get a Rust program to compile. But it also is easier to accomplish the desired task safely
90s_dev · 3h ago
> and you can even locally reason about the code much better than in typical 'unsafe' languages like C++.
Do you have an example of this? I'm just a TypeScript guy who never had a fair chance to use C++ or Rust for long, so I'd be curious how what you say is true.
lblume · 1h ago
One of the strongest example for me is newtypes. I strongly believe in Parse, don't validate (https://news.ycombinator.com/item?id=21476261) and think Rust's newtype pattern is able to really enforce this strongly.
When writing a Rust program, I can often basically express it as a single value (the input) being sequentially converted in type. The typestates, if you choose this name, allow great compile-time verification of most desired properties. You are really forced to describe the way the core logic flows in a modular way.
However this is just one and likely not even the most prominent aspect making Rust so great. Local reasoning also becomes easier via explicit opt-in mutability, and function signatures always being the only relevant source of truth when regarding their compile-time evaluatability (especially compared to C++ templates). No accessing uninitialized memory, a very simple implied notion of a constructor as merely a method without a self parameter, soundness of all received types, likely much more...
teddyh · 3h ago
The non-stable ABI, forcing all-statically linked binaries, is also a thing.
tadfisher · 3h ago
Which has next to zero impact on Windows applications, which ship their own DLLs anyway (besides stuff like DirectX).
free_bip · 4h ago
What's wrong with a terminal app being written in Rust?
They could just have packaged nano, but oh well.
Even the hundreds of kilobytes used in the official grammars seems bulky to me. https://github.com/tree-sitter/tree-sitter-java/releases
I tried discussing it here a few months ago but it did not took off: https://news.ycombinator.com/item?id=41289773
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.
https://news.ycombinator.com/item?id=15904265
You can use nano over wsl if you want
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.
[0]: https://github.com/antirez/kilo/
[0]: https://github.com/zyedidia/micro
Calling it: 2025 will be the year of Windows on the server. /s
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.
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...
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!
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!
I fondly remember the times of editing the explosion radius to "tactical nuclear banana".
I wish they have implemented the same color theme as well.
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.
[0] https://github.com/leecher1337/ntvdmx64
Notepad had recently become infected with ai features and logins and tabs which I just hate, win some lose some ig
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.
(Someone mentioned ssh, which leads me to believe this one is using ansi instead of the console API.)
Oh yeah, i will get some C# or C++ code !
> Rust
Fucked. Why Why Why ?
What I don't get is what people have against programs written in Rust from the bottom up. They are safer to use, introduce far fewer vulnerabilities, and you can even locally reason about the code much better than in typical 'unsafe' languages like C++.
Do you have an example of this? I'm just a TypeScript guy who never had a fair chance to use C++ or Rust for long, so I'd be curious how what you say is true.
When writing a Rust program, I can often basically express it as a single value (the input) being sequentially converted in type. The typestates, if you choose this name, allow great compile-time verification of most desired properties. You are really forced to describe the way the core logic flows in a modular way.
However this is just one and likely not even the most prominent aspect making Rust so great. Local reasoning also becomes easier via explicit opt-in mutability, and function signatures always being the only relevant source of truth when regarding their compile-time evaluatability (especially compared to C++ templates). No accessing uninitialized memory, a very simple implied notion of a constructor as merely a method without a self parameter, soundness of all received types, likely much more...
Less memory overhead and no runtime dependencies?