Yedit – The missing edit.com replacement for modern Windows

(This is a guest post by Antoni Sawicki aka Tenox)

I previously lamented about lack of a small text editor for Windows text mode console. Something simple to just edit a text, configs, .ini, .reg or .cmd/bat files. Kind of like edit.com in MSDOS and Windows 3.x/9.x. Edit.com could even run under Windows NT up until XP inside NTVDM DOS emulator. I seen plenty of people use it this way. Sadly, instead of porting it to the modern Windows it was just whacked. While there are plenty of 3rd party editors to choose from none of them is perfect. They are either expensive, overly complicated, poorly ported from Unix, VMS or TOPS20, no longer maintained or require a steep learning curve for a casual Windows user.

My cries must have been heard in Redmond circles. Malcolm Smith aka malxau (author of Yori, a super awesome command line replacement for Windows) stepped in and made a brand new, text mode editor called Yedit. By default It comes as part of Yori installer however it’s easy to separate it to a stand alone exe.

Yedit on Windows NT

There really isn’t much to talk about Yori. It has no special features. It doesn’t try to be an IDE, word processor, hex editor or an operating system. It’s just a perfect replacement for edit.com. Thank you Malcolm! I really wish that Microsoft just put it in Windows 10 now.

Yedit on Windows 10

While checking out Yedit you should also give Yori a try. It’s really a fantastic CMD replacement shell.

28 thoughts on “Yedit – The missing edit.com replacement for modern Windows

  1. I sense a subtle jab at emacs in there 🙂 It always baffled me why *nix had archaic and hard to use text editors. I mean, why does every *nix have vi installed by default, but not something like nano? (more user friendly, not quite edit.com though)

    Heck, I’ll have to get Yori a spin. I was never a fan of PowerShell. It has its place, but some of us just want the DOS-like cmd.exe on steroids (like the old 4NT, which has since been replaced with something not nearly as lightweight).

    • Why should it have nano? The thing about user friendliness being better in nano than in vi is your personal preference from your past experience. I prefer it other way around, can’t (don’t want to) use nano even for simple tasks.

      • Yeah I truly think this is just a user preference. I love vi for sysadmin and text manipulation tasks but I really don’t like writing code in it. I tend to use micro more often. I think distros should come with vi/emacs and nano as well. Emacs maybe some diet version by default.

      • Let me put it another way, interface discoverability is non-existent in vi and emacs. nano at least shows common commands at the bottom of the screen! The reason why I singled out vi and derivatives is that just about every *nix distro has it installed by default, even minimum installs.

        MS-DOS and OS/2 aren’t innocent either. They both subjected the world to the likes of EDLIN for way too long. IBM landed up dumping Microsoft’s editor for their E editor in PC-DOS 6.1, a step back in some ways.

        • I wasn’t there, but I suspect that shipping EDLIN for “way too long” was a business strategy of a) minimizing the size of DOS and the number of disks needed to distribute it and b) providing business opportunities for third parties to sell “essential” software. Things like EDIT arrived after everyone already had some other editor – who actually used EDLIN?

          I can personally attest that writing EDIT wasn’t (that) large as an undertaking – a good developer could have done it in 3-6 months.

          • Can you add a switch to yedit to replace line drawings to plain ASCII? since line drawings in CJK systems are shown in 2-character width and thus breaks display layout.

          • I pushed a change to implement this when invoked with “yedit -a”. However, note this doesn’t help if user controlled text contains double width characters, including in text, file names, directories, etc.

            You probably know this, but trying to support double width characters is extremely difficult. The width of a character isn’t just determined by the character, but also by the font used to render the character. In theory a command line program would never know what font is used to render it, and discovering the font over things like SSH is impossible.

            Doing this correctly really requires duplicating all of the logic in the terminal for resolving ambiguous width characters on a font-by-font basis. The command line program needs to predict what the terminal will do with each character, so the logic needs to be identical.

            https://github.com/microsoft/terminal/blob/1df3182865fb089bd653763cd0abbea811545365/src/types/CodepointWidthDetector.cpp

            https://github.com/microsoft/terminal/blob/525be22bd8d9375dbc7894fb2c6cda6526e2dce1/src/renderer/gdi/math.cpp

            (In IsGlyphWideByFont .)

          • “I can personally attest that writing EDIT wasn’t (that) large as an undertaking – a good developer could have done it in 3-6 months.”

            EDIT.COM was actually just QBasic with the programming elements turned off. Running the command “QBASIC /EDITOR” will prove that. That’s probably why it wasn’t possible to easily port it to 32/64-bit to enable it to run on 64-bit Windows. In Windows 9.x it was split into a separate executable that no longer required QBASIC.EXE, but was clearly still based on the same codebase (it was probably just a preprocessor flag to build EDIT.EXE instead of QBASIC.EXE).

            Of course, QBASIC was just a cut-down version of QuickBasic 4.5 designed to replace the rather archaic GW-BASIC.

            I don’t think Microsoft really “planned” to include a new editor with MS-DOS 5.0, just that it was already possible to load plain-text files into QBasic’s editor so it was “easy” to just make that a feature.

          • Stu,
            I think Microsoft DEFINITELY intended to replace edlin.com with edit. If you’ve ever used it and you think gwbasic is archaic whoo buddy.

      • Sorry, but I believe you’re at least partially wrong, I remember the first time I sat on a *nix computer in the 90s, I think it was SUSE, in any case, I open some file with nano as instructed, and the teacher went away for a moment on a phone call, and within seconds I was able to edit what I needed (a simple ls or something, I don’t remember exactly), save it and close it, because the instructions to do so where there on the screen, funny enough, the very next exercise was to do the same with vi, or vim, don’t remember, so the teacher just stood there for a solid 10 minutes watching us noobs trying to find out way around something so simple, save and quit, and from a class of about 20, do you want to know how many of us could do it? None, not a single one of us figured it out.
        I understand that for people used to it is great, I truly do, a good tool is an extension of you with enough time using it, but vi is from an era where programmers had to be aware of every bit, because resources were so scarce, that has no longer been the case for ages except very niche applications, forcing it as default for newcomers is just another way of gatekeeping, kudos to fedora for at the very least not making it default, and allowing the user to choose it…
        Peace

    • About same. I do scripts in PowerShell every now and then but the shell is a horrible and slow bloat. I started using Yori some time ago and never going back.

      As for editors that depends on a distribution. Some come with nano by default and even don’t have vi or emacs until you install.

    • If you want edit.com in linux then install “mc” or Midnight Commander, it’s a Norton Commander knockoff but it supports an editor mode by launching it as “nc -E” and optionally a filename. Really good for certain kinds of editing.

  2. The first thing I do in any debian is replacing vim with nvi, personally. VIM in Debian (and alikes) acts weird and nvi doesn’t. Oddly enough, vim isn’t a problem for me in Redhat (and alikes). Still prefer nvi, however.

    That said, I’m not sure I’ll end up using yedit much -though it looks perfect for editing system32/drivers/etc/hosts when I need to -which is more often now that I’m using WSL and virtual machines.

    I poked around his github and he’s got some interesting projects, including minicrt. He says it isn’t interesting except for programs designed for it, but the thing that is interesting is that it doesn’t use any APIs newer than NT 3.1.

    I’m playing with replacing my cmd with yori -great article, thanks!

    • Author here. Can I ask what’s interesting to you about minicrt using only NT 3.1 APIs?

      A simple C runtime is really only doing three things:
      1. Providing entrypoint code to get from the OS entrypoint to a C entrypoint;
      2. Providing arithmetic functions for things the compiler can’t implement;
      3. Providing a library of functions, mainly string or memory related, that don’t use much OS functionality, if any at all.

      Put another way, Win95/NT 3.1 shipped with quite capable C runtime libraries. They can’t support newer specifications, like the concurrency primitives that have been standardized since, but it’s plenty to support capable applications.

      Note that Yori itself also supports NT 3.1 which was a much harder task. Personally I think NT 3.1 doesn’t get nearly enough respect – it is a 1.0 release and it’s exceptionally high quality in that context. The things that were challenging are largely obscure; it used an ANSI environment block rather than a Unicode block in later releases; it messed up GetEnvironmentStrings() as a result; it supports \\.\ but not \\?\; it predates UTF-8; etc.

      I tried to support the Win95 console in other projects (sdir) but it was far more buggy than the NT 3.1 version, and the changes to support ANSI seemed quite extensive, so that’s where I drew the line in Yori.

      • >Author here. Can I ask what’s interesting to you about minicrt using only NT 3.1 APIs?

        Hi, first off thank you for what you’ve made. Secondly, I apologize in advance because you will probably find my answer to be anti-climatic.

        One of my hobbies is virtualization, and that’s mainly because I like playing (nothing serious) with older operating systems -mostly of the DOS/Windows and Unix families.

        I’m not a programmer so it isn’t so much that I can access the API, but the fact that if you support the 3.1 API that means you support running it on 3.1 -and that’s what what I find cool.

        I’m not sure how much you had to restrict yourself by supporting NT 3.1, but imagine it being at least something of a challenge, and just from an esthetics point of view it’s awesome that you could make something so useful in such a tight space.

        Again, thanks -and apologies for an under-whelming answer

        • I forgot to finish my thought (side effect of getting older): NT 3.1 is one of the OSes I play with on occasion and the Yori shell complements that (it’s nice to have a decent shell there!)

          • For what it’s worth, the immediate thing that caused me to start writing Yori was trying to work on NT 3.51 and not having tab completion 😉

            For the most part, supporting older systems wasn’t difficult, it just required run-time checking for capabilities. There’s plenty of things NT 3.1 can’t do with Yori – most importantly, it can’t install because it doesn’t have an HTTP stack and decompression DLL. I’d like to bundle a mini HTTP client and perhaps zlib to overcome this, but it’s at the bottom of the list since the installer can work on NT 3.5 by taking those two DLLs from IE and dropping them in System32, so this work is really specific to 3.1.

            The main “gotcha” with NT 3.1 and Yori is it doesn’t support long file names on FAT, which means that tab completion scripts as well as compiling from source really needs NTFS or HPFS. Without tab completion scripts, Yori behaves similarly to CMD and just does a naive file name match.

  3. > Sadly, instead of porting it to the modern Windows it was just whacked.

    That’s probably due to the fact it was based on the QBasic codebase and probably contained hand-written assembly code inherited from who-knows-when in the Microsoft BASIC timeline. Even though EDIT.EXE was separated from QBASIC.EXE in Windows 9x (in MS-DOS 5.x/6.x EDIT.COM just launched “QBASIC.EXE /EDITOR”), I wouldn’t be surprised if it still had traces of old BASIC code. I expect EDIT.EXE was built from the same source tree as QBASIC.EXE, so fully separating the two products would have been significant work.

    • Perhaps I shouldn’t have said “port it”, thats impossible of course. It would have to be a full rewrite, still I think think they should have done it. Microsoft seems to be very confused about their GUI vs CLI strategy.

    • I don’t think it’s related to BASIC – as you said, that got removed anyway.

      What I think happened is there was a shared library for text based UI which was reused by a lot of pieces of code (Works, Word 5.5-6, PWB, QuickC, etc) which was used as part of QuickBasic/QBasic/Edit. I believe it was called “COW” (Character Oriented Windows.) For people who want to see more about it, I’d recommend getting Visual Basic for DOS which lets you mess with all of the controls in a fairly ad-hoc way.

      A DOS based UI library has a few differences from a modern one. One is that the dimensions of the display are relatively fixed – Edit supported 80×25 and 80×43, but it doesn’t need to consider arbitrary sizes. The other issue is that efficiently drawing things back then meant doing things like detecting the hardware and modes available and writing to video memory. Things like mouse input in DOS are very different too, because the program has to poll the mouse driver for updates and handle these interspersed with keyboard input. It’s also real mode with segmented addressing and limited memory management. It was probably a lot of assembly too, but even if it wasn’t, a lot of these assumptions just don’t translate to running on a very different environment.

      At some point they had to decide whether to build a version of COW for Windows or not, and chose “not.” Note it’s not just edit that’s missing – there’s no TUI apps distributed with Windows.

      My main motivation here was to write something resembling COW in order to make TUI apps buildable. In the same way that notepad is a trivial application once the Windows controls are built, edit is a relatively small amount of code around a COW UI library.

    • In Chicago Build 89e, EDIT.COM is replaced with “Chicago Emergency Editor” 0.5, which is renamed to “MS-DOS Editor” in version 0.9. And from binary level look, it shares very little with old QBASIC.

Leave a Reply