1bf4c082b4
There is going to be a very long tail of applications that will explicitly request VT SGR 40/37 when what they really want is to SetConsoleTextAttribute() with a black background/white foreground. Instead of making those applications look bad (and therefore making us look bad, because we're releasing this as an update to something that "looks good" already), we're introducing this compatibility quirk. Before the color reckoning in #6698 + #6506, *every* color was subject to being spontaneously and erroneously turned into the default color. Now, only the 16-color palette value that matches the active console background/foreground color will be destroyed, and only when received from specific applications. Removal will be tracked by #6807. Michael and I discussed what layer this quirk really belonged in. I originally believed it would be sufficient to detect a background color that matched the legacy default background, but @j4james provided an example of where that wouldn't work out (powershell setting the foreground color to white/gray). In addition, it was too heavyhanded: it re-broke black backgrounds for every application. Michael thought that it should live in the server, as a small VT parser that righted the wrongs coming directly out of the application. On further investigation, however, I realized that we'd need to push more information up into the server (so that it could make the decision about which VT was wrong and which was right) than should be strictly necessary. The host knows which colors are right and wrong, and it gets final say in what ends up in the buffer. Because of that, I chose to push the quirk state down through WriteConsole to DoWriteConsole and toggle state on the SCREEN_INFORMATION that indicates whether the colors coming out of the application are to be distrusted. This quirk _only applies to pwsh.exe and powershell.exe._ NOTE: This doesn't work for PowerShell the .NET Global tool, because it is run as an assembly through dotnet.exe. I have no opinion on how to fix this, or whether it is worth fixing. VALIDATION ---------- I configured my terminals to have an incredibly garish color scheme to show exactly what's going to happen as a result of this. The _default terminal background_ is purple or red, and the foreground green. I've printed out a heap of test colors to see how black interacts with them. Pull request #6810 contains the images generated from this test. The only color lines that change are the ones where black as a background or white as a foreground is selected out of the 16-color palette explicitly. Reverse video still works fine (because black is in the foreground!), and it's even possible to represent "black on default" and reverse it into "default on black", despite the black in question having been `40`. Fixes #6767.
37 lines
804 B
C++
37 lines
804 B
C++
/*++
|
|
Copyright (c) Microsoft Corporation
|
|
Licensed under the MIT license.
|
|
|
|
Module Name:
|
|
- ConsoleShimPolicy.h
|
|
|
|
Abstract:
|
|
- This is a helper class to identify if the client process is cmd.exe or
|
|
powershell.exe. If it is, we might need to enable certain compatibility shims
|
|
for them.
|
|
- For more info, see GH#3126
|
|
|
|
Author:
|
|
- Mike Griese (migrie) 29-Apr-2020
|
|
|
|
--*/
|
|
|
|
#pragma once
|
|
|
|
class ConsoleShimPolicy
|
|
{
|
|
public:
|
|
static ConsoleShimPolicy s_CreateInstance(const HANDLE hProcess);
|
|
|
|
bool IsCmdExe() const noexcept;
|
|
bool IsPowershellExe() const noexcept;
|
|
bool IsVtColorQuirkRequired() const noexcept;
|
|
|
|
private:
|
|
ConsoleShimPolicy(const bool isCmd,
|
|
const bool isPowershell);
|
|
|
|
const bool _isCmd;
|
|
const bool _isPowershell;
|
|
};
|