Terminal: 在默认的WSL终端中键入内容感觉很棒，为什么它比其他所有应用程序都要好？

我真的不介意有人来决定决定告诉我们我们在某些方面做得很好。 我们每天都听到如此多的投诉，这样的帖子让人呼吸新鲜。 感谢您的感谢！

另外，很高兴与您讨论这个问题，直到您完全厌倦了阅读它。 请询问您想要的任何后续步骤。 我热衷于对自己的工作之以鼻。 ：P

如果我不得不经过有根据的猜测，那么是什么让我们比Windows上的任何其他应用程序都要快，所以在屏幕上显示文字时的速度...我要说的是，因为这实际上是我们唯一的工作！ 也可能是因为我们在Windows必须完成的最旧和最低级别的API附近使用darn。

当您开始谈论Electron和Javascript时，您列出的几乎所有其他内容都涉及某种层或框架，或者涉及许多层和框架。 我们没有。

我们有一个裸露的超级非特殊窗口，没有附加任何控件。 假设我们是从窗口消息而不是从某种事件框架来处理密钥，而这些密钥只是从内核之上馈送给我们的，而不是从某种事件框架（除了WPF，WinForms，UWP，电子）。 然后，我们将使用GDI的PolyTextOut将文本直接转储到窗口表面，而不会出现多余的装饰。

甚至notepad.exe至少在其窗口上具有多个控件，并且可能（我没有看过）在edit控件中使用某种库框架来确定其文本布局（可能正在使用其他库）国际化支持框架...）

当然，这也意味着我们需要权衡取舍。 我们不像其他所有应用程序一样支持完全国际化的文本。 RTL？ 现在没有进入区域。 代理对和表情符号？ 我们到了那里，但还没有到那儿。 印度脚本？ 不。

我们为什么这样？ 例如， conhost.exe已经很脏了。 它必须使用所有内容的裸机底层，因为它是在创建其他大多数框架之前创建的。 而且，它保持尽可能低/最低的级别，因为在拥有框架之类的所有好东西或这些框架需要什么之前，当提出新的操作系统版本或设备时，这几乎是第一件事操作。 而且它是用C / C ++编写的，它尽可能地低和裸露。

UI增强功能是否可以用于Windows上的其他应用程序？ 几乎可以肯定。 他们的事情太多了，这既是好事也是坏事。 我嫉妒他们能够以一种简单的方式以任何一种语言调用一种方法和布局文本，而无需手动计算像素或关心它们的字体采用什么样式的能力。 但是我的手动像素计算，脏区数学，滚动区疯狂等等使得我们比他们更快。 我也很嫉妒，当有人说“嘿，您可以在窗口底部添加一个状态栏”时，他们可以使用UI框架将其几乎单击并拖动到适当的位置，并且它可以像我们一样在任何地方工作永远都是积压的项目，让我为实施该计划而心痛。

我们会尝试阻止它回归吗？ 是! 现在，这有点像手动过程。 我们确定有些东西变慢了，然后我们进行WPR检查并开始进行跟踪。 我们盯着热门的道路，尝试找出正在发生的事情，然后加以改进。 例如，在上一个或两个周期中，我们将堆分配作为主要领域，可以提高端到端性能，将大量代码更改为在基础请求上使用堆栈构造的类似迭代器的外观，这是我们的重点缓冲区，而不是针对每个处理级别将其转换并分配到新的堆空间中。

顺便说一句，

如果您还有其他想知道的信息，请告诉我。 我可以整天去。 在发布之前，我从此回复中删除了15条切线。

说到低级Windows API，我发现控制台（conhost.exe，cmd.exe ...）和WSL（wsl.exe，LxssManager.dll ...）的每个_user mode_组件都大量使用C ++ _STL_。 例如，在字符串操作，内存分配，虚拟表等中。如果仅使用C，性能会有所改善吗？

我不会认为这些是“极大地”使用C ++ STL。 他们肯定使用了一些集合，也许在这里或那里使用了一些字符串操作和算法。 我觉得STL的功能远不止这些。

但是无论如何……您描述的大多数内容都是前一段时间直接用C语言编写的。 我们一直在选择性地使用C ++和STL作为有意识的折衷方案。 只要我们充分了解模板的功能，并认真使用正确的模板，我们通常只会牺牲很少的性能，同时获得大量的安全性和编程便利性。

安全实际上是我们使用STL模板而不是尝试尽可能构建自己的结构的主要原因。 将STL模板用于集合和字符串通常会为我们提供边界检查，否则将必须以容易出错的方式手动完成（或根本不需要！）

同样，我也不是很确定在C语言时，在控制台代码中拥有17种不同的排队和链接列表实现，总体而言，它们的性能比今天使用std :: queue和std :: list更好。 对于每个单独的实现，它可能会占用更多的磁盘空间，这是性能问题的另一种类型（存储和页面加载I / O）。

非常感谢您抽出宝贵的时间写此回复，也没有对赞美有任何疑问。

在过去的几个月中，我一直在寻找一个不错的终端设置，并且我认为使用tmux的ubuntu.exe与我们今天拥有的工具一样接近完美。 ubuntu.exe终端本身正在迅速发展，tmux为您提供了各种生活必需品（选项卡，拆分窗格，缓冲区搜索等）。

非常期待将来的发行版，这些发行版可以使颜色主题更加兼容，并具有与属性相关的增强功能，例如用于缩放字体大小+/-的热键。

@miniksa ：感谢您的有趣帖子！

我们在Windows必须完成的最老和最低级别的API附近使用darn。

我一直对此感到好奇。 您似乎是在指各种Win32 API（USER32 / GDI32）。 最近，我不确定它们是否仍处于最新版本的Windows（8.0及更高版本）所能达到的低水平，或者这些API是否已被静默转换为位于其他功能之上（例如Direct2D， DirectWrite等）。 旧的API与新的API有何关系？ 如果您能澄清一下，我会很喜欢的！

@stakx ，我指的是USER32和GDI32。

我会粗略地概述我所了解的内容，而无需花费数小时来确认细节。 因此，其中一些需要手动操作，可能略有不正确，但可能方向正确。 将每条声明视为我对世界如何运转以及存在见解或错误的个人认识。

对于流水线（GDI32）的图形部分，GDI的用户模式部分相当低。 该应用程序调用GDI32，在用户模式端的DLL中完成了一些工作，然后内核调用跳转到内核并进行绘制。

您正在考虑的有关“悄悄地转换为位于其他内容之上”的部分可能是，一旦我们执行了内核调用，一堆内核GDI内容往往会在与其他内容相同的内容之上重新平台化DirectX实际上是由NVIDIA / AMD / Intel / etc处理的。 图形驱动程序和位于堆栈底部的GPU。 我认为这是随Windows Vista WDDM附带的图形驱动程序重新架构而发生的。 那里有一个文档，说明在GDI中哪些调用仍然非常快，而由于重新平台化而导致调用速度变慢。 上次我找到该文档并进行检查时，我们使用的是快速文档。

在GDI之上，我相信有类似Common Controls或comctl32.dll之类的东西，在我们有了更好的声明性框架之前，它们为人们提供了可重用的按钮和元素集，以使其UI成为可能。 我们实际上并没有在控制台中使用它们（除非在右键单击菜单的属性表中使用）。

至于DirectWrite，D2D，D3D和DXGI本身，它们是一组单独的命令和路径，它们在用户和内核模式下完全与GDI无关。 它们之间没有真正的关系，只是两者之间有一些互操作性条款。 不过，我们大多数其他UI框架都倾向于建立在DirectX堆栈之上。 XAML是肯定的。 我认为WPF是。 不确定WinForms。 而且我相信合成堆栈和窗口管理器也都使用DirectX。

至于流水线（USER32）的输入/交互部分，我倾向于发现大多数其他较新的东西（至少对于台式机而言）是建立在已有东西之上的。 USER32的主要概念是窗口和窗口句柄，所有内容都发送到窗口句柄。 只要您使用台式机（或便携式计算机或其他任何设备，……我指的是经典的Windows驱动的计算机），就会涉及一个窗​​口句柄，并且消息四处飘荡，这意味着我们在谈论USER32。

窗口消息队列只是在窗口处于前台时发生的与该窗口相关的任何输入的向上（或多或少）的FIFO FIFO（向上或向下），以及系统中其他组件向该窗口发送的任何输入。

较新的技术和框架，例如XAML和WPF和WinForms，倾向于以一种或另一种方式从窗口消息队列接收消息，并对其进行处理，并将其转换为事件回调，以回调它们在其世界范围内提供的各种对象。

但是，也可以在其他非桌面平台（例如XAML）上运行的较新技术也具有处理完全不同的非USER32堆栈中内容的能力。 USER32有一个单独的并行堆栈，其中包含我们在输入和交互方式上如何进行的所有新的创新和实现，它们并不能完全以相同的方式处理经典的消息队列和窗口句柄。 这是整个Core *系列产品，例如CoreWindow和CoreMessaging。 他们还有一个不同的概念：“什么是用户”，并不是在屏幕前的滚动椅子上，而是在桌子上有键盘和鼠标的情况下，围绕着屁股。

现在，如果您使用的是XAML或其他框架之一，那么所有这些复杂性都会为您处理。 XAML找出了如何为您使用DirectX的方法，并代表您与合成器和窗口管理器进行协商以获得漂亮的效果。 它确定是从USER32还是从Core *获取输入事件，还是根据平台透明地获取输入事件，并且输入堆栈可以统一地处理笔，触摸，键盘，鼠标等。 它内嵌了一些规定，可以执行各种全球化，可访问性，输入交互等操作，使您的生活变得轻松。 但是您可以选择直接进入低层并自行处理，也可以跳过不关心的内容。

诀窍是GDI32和USER32是为有限的命令集而设计的。 台式电脑是唯一存在的东西，一个键和鼠标的单一用户，将简单的图形输出到VGA监视器。 因此，像conhost一样直接在“低级”使用它们非常容易。 新平台可以“低级”使用，但它们要复杂几个数量级，因为它们现在可以考虑20多年来个人计算所发生的一切，例如不同的外形尺寸，多个活跃用户，多个图形适配器，并持续不断。 因此，在使用新内容时，您倾向于使用框架，这样您的头脑就不会爆炸。 他们为您处理，但处理能力比以往任何时候都要高，因此它们在某种程度上要慢一些。

那么GDI32和USER32是否比新产品“低”？ 有点。
您能用更新的东西降到这么低吗？ 通常是的，但是您可能不应该也不想。
新的是旧的还是旧的？ 有时和/或部分。
基本上……就像对任何软件的答案一样……“这是一场不容置疑的灾难，如果我们退后一步，我们应该对它完全起作用感到惊讶。” ：P

无论如何，一个早晨就够了。 希望这能回答您的问题，并为您提供更多的见解。

希望这能回答您的问题，并为您提供更多的见解。

@miniksa ，的确的！ 也很有意义。 非常感谢您抽出宝贵的时间编写全部内容！ ：+1：

我现在要解决这个问题。 感谢您的询问，我很高兴您喜欢这些信息。