Inside the Windows Console

With Core they are even used for new projects running on Linux.

Ah, so I'm not the only on with this issue! Thanks for the workaround.

I like the post, it seems like they are good guys doing a good work on an unrewarding application.

It is interesting the insight thet are giving with this article: - MS is improving on Windows Console only because of WSL - the design of the Windows Console was flawed since the beginning and remained unchanged to something like 30 years. Flaws includes: - using Console API instead of sending characters / cannot work remotely - the shell and the terminal are not clearly separated: the OS will open automatically a console for some kind of executables / cannot attach a shell to an arbitrary console

It seems to me that it shows a few things.

First, unix design was better as it was more flexible and lasted over time and computers evolution. Windows' design was sort of wrong since the beginning but they didn't change anything and developers were left to use one of their horrible APIs. This is similar to the difference between X Window and Win32 GUI API.

Second, MS does not care about developers except for the user of their flagship product Visual Studio. They put 30 years of developer effort solely on Visual Studio and nothing else. Compare with Apple, they at least cared of implementing an excellent terminal and contributed greatly to the wonderful LLVM compiler infrastructure.

So, okay some improvements might lands on Windows 10 at some moment but I personally don't care. At work we still use Win 7 and I think we will keep using it for a long time. The Windows Console is just horrible to use and propram for and a testament to the MS awful software and APIs that developers are forced to use because of Windows dominance.

Very appropriate comment. Last year I was tinkering with the implementation of a TUI (Text User Interface), and I wanted it to be cross-platform. I started developing it under Windows, using the Console API (sorely lacking in features, but at least it is just an API to be called from C). I had to abandon the project once I realized that it would have been too hard to harmonize this approach with the weird way you are supposed to program a Unix console.

Let's consider the difference between calling an hypotetical system API to change the text color and a raw sequence of bytes encoding. In Unix, to set the color to be used for writing characters you have to send an ESC character, some more bytes, and then an ASCII representation of the R, G, and B components (assuming your virtual terminal supports this), separated by a colon/semicolon. The terminal will then read this sequence, parse the three numbers and move the character. This approach is not precisely efficient, especially if you consider that today it is not unlikely to have full-screen terminal applications with a large resolution. For a 200x60 terminal like the one I am using right now, to color every character with a different color requires sending 500 Kb of data, compared to the 36 Kb required by a 3-byte representation of each RGB tuples.

And if you are trying to read from a terminal, every time you receive an ESC key, you are always in doubt whether the user pressed ESC, or if it is the start of an ANSI sequence. The usual trick here is to check if there is a character already available immediately after you detect an ESC byte coming from standard input: if there is, you can assume it's the beginning of a sequence.

Admittedly the virtual-terminal approach makes remote connections (through SSH) simpler than an API (you just have to send a bunch of bytes through a socket), but I wonder why in 2018 we are still relying on the old and quirky mechanism of "virtual consoles" when real consoles have long disappeared.

Edit: small fixes.