Windows Command Line Blog

Another day, another Casey post dunking on my team. Hi!

This tweet misses the mark only a little bit; in a previous blog post, we apologized[1] pretty frankly to everyone involved in this discussion. I'll admit that we didn't list him by name, but neither did we list the other handful of folks involved. We should have. In turn, Casey rightly did not acknowledge it except to tell his followers that it was not a real apology[2].

This blog post is matter-of-fact, but Casey is right. However, he said himself that it was trivial to do this. Is it not acceptable that we use the same language?

Casey, I'm sorry. We made a mistake. I made a mistake! We didn't know what we didn't know, and thought we were clever enough to pass for it.

Using a texture atlas was a great idea, and we didn't know about it until you told us. We should do better to credit you.

[1]: https://devblogs.microsoft.com/commandline/windows-terminal-preview-1-13-release/#new-rendering-engine (scroll down under the image)

[2]: https://twitter.com/cmuratori/status/1489406091318349826

--

(Note: I've iteratively edited this post, as it was originally a one-sentence diatribe written in anger. I originally asked, "I just don't know what else he's asking for here. Credit? Us to die screaming?" It was not a good look. It also originally contained "I get it, Microsoft sucks, we should all be fired, rah rah rah." As the message evolved, that became more and more out-of-place.)

Neither cmd.exe nor powershell.exe are terminal emulators, rather they are both shells / scripting languages. The legacy looking crappy terminal window is usually conhost.exe.

Windows has a console interface unlike that found on Unix, using APIs rather than escape sequences to interface with the console. Also, its console implementation was historically coupled tightly with the conhost.exe application, which historically is both the terminal emulator and console endpoint simultaneously.

The blog series centered around
https://devblogs.microsoft.com/commandline/windows-command-line-inside-the-windows-console/ is the best resource I've found online that discusses Windows' legacy console support as well as some vision of how this subsystem has changed in the years since.

These changes improved OS interop, but also de-couple the legacy crap so that third party terminal emulators can be better supported on Windows generally (separating the console endpoint from the terminal display), allowing for the creation of `CreatePseudoConsole()`.

Prior to this, third party terminal emulators that wanted to support Windows apps had to run the legacy conhost.exe and shove the window way off the desktop (to hide), and then scrape the window for its contents. This is/was required so that the app has a console backed by a conhost.exe process (responding to the console apis). `CreatePseudoConsole()` fixes a lot of that mess.

I wouldn't be that enthusiastic about it. Best I can say is that it is not terrible. In simplified terms, all it does is download exe files from URL addresses that it gets from yaml metadata files, and then silently executes them; which in turn means that it leaves all of the installer's checkboxes unmodified, cluttering your desktop with icons in the process. On top of that, Windows Terminal has been failing to update on my machine as of late. I don't think this should be the standard for a first-party package manager, but I'd say it's par for the course for Microsoft.

It's also worth noting that all of Winget's code was initially taken from AppGet, without much recognition.[1] Apparently Microsoft cared just enough about that detail to mention the project they forked in passing, as part of a list of third-party package manager projects for Windows.[2] This is why, IMO, you should always first consider a copyleft license for an open source project.

[1] https://www.theverge.com/2020/5/28/21272964/microsoft-winget-windows-package-manager-appget-copied

[2] https://devblogs.microsoft.com/commandline/windows-package-manager-preview/

EDIT: fixed vertical spacing.

Even if you're not using WSL, you've always been able to turn on case sensitivity via a registry key. This has not been recommended in the past due to possible issues with windows itself as well as third party software. This history is mentioned here[0]. Everywhere that mentioned a registry key seems to be referring to windows nfs server, not to general file access, however I know that SFU (Services for Unix) installer had an option to do so, so it's certainly possible.

As of sometime in 2018, fsutil can set specific directory trees to be treated case sensitive in Windows 10 without setting it for the OS. This ability is mentioned here[1]

[0]: https://devblogs.microsoft.com/commandline/per-directory-case-sensitivity-and-wsl/
[1]: https://docs.microsoft.com/en-us/windows/wsl/case-sensitivity#changing-the-case-sensitivity-on-a-drive-mounted-to-a-wsl-distribution

For anybody wondering "why couldn't they just...", there is a lot of complexity in TTYs and PTYs. The kernel is even involved in line discipline and job control. Those Ctrl+Z or Ctrl+C keys you press? The kernel gets involved.

It may seem strange that there's a process signal for window-size changes, but that's what was needed back in 1985. There's a similar dance with the Amiga's console.device, but both Unix and Amiga TTYs are better than Windows' terminals where there was no such thing as a PTY until Windows 10, you had to make direct API calls, and even now it's still pretty slow: https://devblogs.microsoft.com/commandline/windows-command-line-introducing-the-windows-pseudo-console-conpty/

This page is a great overview pf the Unix TTY/PTY subsystem: https://www.linusakesson.net/programming/tty/

I used to use XTree Gold, which was... golden. I always heard of Midnight Commander but never really got around to using it. I should probably fix that.

What I never got was why this style of TUI (MS edit.com, qbasic, etc) isn't really carried through in modern tradition? I really enjoyed these when when I was younger... yet even textual or ratatui apps don't really bring this interface to the terminal. (Or why screen-coordinate-based terminals aren't the norm to base TUI apps upon... this aspect just seems "obvious" but in this aspect modern terminal emulates seem lightyears behind MS-DOS, of all things).

Perhaps the rewrite of edit [1] will spawn a ressurgence of this TUI style?

[1] https://devblogs.microsoft.com/commandline/edit-is-now-open-source/