Fails to mention missing support for UTF-8 input; fails to consider a whole class of applications.

[alf-p-steinbach]

[Enter feedback here]

The Windows API does not yet support UTF-8 console input of other than ASCII characters (i.e. English alphabet). The application just receives nullbytes for e.g. input of Norwegian characters. The author is clearly aware of this and expertly avoids mentioning it.

The article fails to differentiate between keyboard input and text output. In particular, a console application can need access to non-text keys such as arrow and function keys, and (less common but) a console application can need undecoded keyboard input. Terminals of old produced escape sequences for e.g. arrow keys but AFAIK Microsoft's list of console escape sequences does not include input escape sequences.

The article fails to consider the class of “screen oriented” console applications that need undecoded keyboard input (the need for that was a key learning point in the Smalltalk project in the late 1970's), and that need efficient output of rectangular areas of text.

Summing up, the document argues insidiously for severely limiting the console i/o functionality, by omitting to mention areas of functionality that will be dropped, or (UTF-8 input) that is as yet not even supported at all in Windows.

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: 44cf7611-4b34-27e3-d889-07a2278700af
• Version Independent ID: 4f664c66-8043-0e24-f6cc-8cc6698d452e
• Content: Classic Console APIs versus Virtual Terminal Sequences - Windows Console
• Content Source: docs/classic-vs-vt.md
• Product: console
• GitHub Login: @miniksa
• Microsoft Alias: miniksa