如何检测控制台中当前是否启用了Windows 10缓冲区包装模式

有没有办法检测控制台应用程序是否在启用Windows 10新功能的情况下运行

显示

HKEY\u CURRENT\u USER\Console\ForceV2

，

HKEY\u CURRENT\u USER\Console\LineWrap

和

HKEY\u CURRENT\u USER\Console\{name}\LineWrap

控制它，但除了解析的健壮性较差之外，它可能不正确。如果用户切换到传统模式或从传统模式切换到传统模式，则在控制台重新启动之前，更改不会生效

---

如果我开发应用程序，我可以在启动时进行检查。不过，可能存在争用条件，这使得注册表检查对于任何实际用途都毫无用处。我很好奇第三方控制台窗口的解决方案是什么。

似乎没有用于此的API，但我希望在以后的SDK中会出现一个API（可能在GetConsoleMode中会出现额外的超扩展标志）

同时，下面是一个快速破解，它试图通过检查GetMinMaxInfo返回的ptMaxTrackSize.X值来检测新控制台的更广泛的调整大小功能

旧版控制台不允许将窗口的大小调整为大于屏幕缓冲区宽度，而新的控制台则允许。假设（a）控制台以全缓冲区宽度运行，即没有水平滚动条，以及（b）它尚未拉伸到全/最大屏幕宽度，则可以非常直接地检查窗口是否允许其自身调整更宽（新控制台）的大小（旧控制台）。应该注意的是，通过手动将缓冲区宽度从字符转换为像素，而不是依赖GetWindowRect，技术上可以避免假设（a），但假设（b）几乎是不可避免的

这就是代码（免责声明：快速且肮脏的概念验证，无错误检查等）

这是在新控制台中运行时的输出

chars:   wnd-size 80 25, max-wnd-size 80 71, largest-size 239 71
pixels:  wnd-size 677 443, max-tracking-size 1936 1186

...most likely a Win10 console with ForceV2 enabled

---

你为什么要知道？？这些都是对用户的方便，它们不应该更改您编写的代码。api一点也没有改变。@Hans理论上是这样的，但事实并非如此Console.BufferHeight会在用户调整窗口大小时引起问题，因为启用W10功能时，用户能够异步更改窗口宽度，从而使文本回流并更改缓冲区宽度，并在

Console.BufferHeight

中的rect get、modify和set之间产生竞争条件。更不用说其他一些问题了。我得到了不应该发生的托管和非托管异常，因为缓冲区、窗口和光标操作不是原子的，交互式调整大小确实会影响它。在我的应用程序中发生的基本情况是，输出的最后一行充当一种状态栏。它会被新消息覆盖。这不是一件不同寻常的事情。在W10上，当窗口调整大小时，它所占用的行数会发生变化，并且不再需要处理窗口、缓冲区或光标。W10之前，调整窗口阻止的控制台API操作的大小，以便不存在争用条件问题。另外：在控制台窗口宽度调整为每行少于14个字符后，执行

console.BufferHeight=20

或一些数字。有趣，对吧？如果你能发现这一点，那么这些问题突然不再是问题了？？很难相信，但只是简单地假设它是打开的。真是个问题。

chars:   wnd-size 80 25, max-wnd-size 80 71, largest-size 240 71
pixels:  wnd-size 677 443, max-tracking-size 677 1179

chars:   wnd-size 80 25, max-wnd-size 80 71, largest-size 239 71
pixels:  wnd-size 677 443, max-tracking-size 1936 1186

...most likely a Win10 console with ForceV2 enabled