windows - 在 Windows 上，控制台窗口所有权如何运作？

Question

当一个控制台应用程序从另一个控制台应用程序启动时，控制台所有权如何运作？

我看到四种可能性:

1. 第二个应用程序在其生命周期内从第一个应用程序继承控制台，控制台在退出时返回给原始所有者。
2. 每个应用程序都有自己的控制台。 Windows 然后以某种方式将两者的内容合并为用户可见的“控制台”
3. 第二个应用程序获得属于第一个应用程序的控制台的句柄。
4. 控制台放置在共享内存中，两个应用程序具有相同的“所有权”

我很可能错过了一些东西，这四个选项都没有充分描述 Windows 使用其控制台的功能。

如果答案接近选项 4。我的后续问题是这两个进程中的哪一个负责管理窗口？ (当屏幕需要刷新/重绘等时处理图形更新)

一个具体的例子:运行CMD。然后，使用 CMD，运行 [控制台应用程序]。 [控制台应用程序] 将写入看起来与 CMD 使用的控制台窗口相同的内容。

Answer 1

您的四种可能性都不是实际情况，您的后续问题“这两个进程中的哪一个负责管理窗口？”的答案是两个进程都不是负责任的。 TUI 程序根本不需要了解有关窗口的任何信息，而且，在幕后，甚至不一定深入了解 GUI。

控制台是对象，可以像文件、目录、管道、进程和线程一样通过句柄访问。单个进程不会通过其句柄“拥有”控制台，就像进程“拥有”它具有打开句柄的任何文件一样。控制台的句柄由子进程从其父进程继承，方式与所有其他(可继承的)句柄相同。你的 TUI 应用程序，由 CMD 产生，简单地继承了 CMD 说它应该继承的标准句柄，当它调用 CreateProcess() - 通常是 CMD 的标准输入，输出和错误(除非命令行告诉 CMD 使用一些其他句柄作为 child 的标准输入、输出和错误)。

控制台不依赖于 CMD。只要存在 (a) 控制台输入或输出缓冲区的任何打开句柄或 (b) 以其他方式“附加”到控制台的任何进程，它们就存在。因此，在您的示例中，您可以终止 CMD，但只有当您也终止子进程时，控制台才会真正被销毁。

在 6.1 版之前的 Windows NT 中，负责显示显示控制台的 GUI 窗口的进程是 CSRSS，即客户端-服务器运行时子系统。窗口处理代码在 WINSRV.DLL 中，它包含“控制台服务器”——在幕后——执行控制台 I/O 的 Win32 程序向 LPC 调用。在 Windows NT 6.1 中，此功能，原因 covered by Raymond Chen ，从 CSRSS 移出到 CSRSS 产生的特权较低的进程中。