Console: Potential Breaking Changes

Unshipped, Uningested into Windows

• Up until #13321 it was possible to treat the terminal as a strict NxM matrix of text storage. Since conhost's text renderer only used the leading half of a 2 column wide glyph (aka the COMMON_LVB_LEADING_BYTE) you could put anything you wanted to into the trailing half and "smuggle" data. This change makes this impossible and will now also ignore the trailing half when being read from console APIs. This however breaks any application that tries to read wide glyphs with ReadConsoleOutputW that were previously written with WriteConsoleOutputA, as this previously returned 2 CHAR_INFOs containing some UnicodeChar, followed by a 0xFFFF, but now will return that UnicodeChar twice. Concatenating the CHAR_INFOs into a string for instance, will now be broken. Furthermore there are 2 more minor breaking changes: ReadConsoleOutputA will now zero the high byte of UnicodeChar at all times and zero AsciiChar as well, if the conversion to the requested code page failed.
  • Introduced In: #13321
  • Ingested In: NONE YET
  • First Insider Release: NONE YET
  • Servicing Candidate: No
• #13626 extends upon #13321 and now makes it impossible to store 2 column wide glyphs into just a single column. With this change in place, text will now always be stored and rendered consistently and such usage of conhost will simply result in the request being ignored or whitespace to be stored. Due to the internal conhost architecture however, this now causes applications that used to "smuggle" data (see bullet point above) to overwrite the leading half of the glyph. In other words, WriteConsoleOutputW will now store the trailing half of wide glyphs in the console and ignore the leading half.
  • Introduced In: #13626
  • Ingested In: NONE YET
  • First Insider Release: NONE YET
  • Servicing Candidate: No
• Pull Request #14735 changes the behavior of ENABLE_VIRTUAL_TERMINAL_PROCESSING with regards to multiple screen buffers. Specifically, people who were enabling VT processing on the new buffer and then expecting it to stay enabled on the other buffer will observe that it is not enabled.
  • Introduced In: #14735
  • Ingested In: NONE YET
  • First Insider Release: NONE YET
  • Servicing Candidate: No