在Windows上，控制台窗口所有权如何工作？ [英] On Windows, how does console window ownership work?

问题描述

当从其他控制台应用程序启动控制台应用程序时，控制台所有权如何工作？

When a console application is started from another console application, how does console ownership work?

我看到四种可能性：

1. 第二个应用程序从第一个应用程序的生命周期继承控制台，控制台在退出时返回到原始所有者。


2. 有自己的控制台。 Windows然后以某种方式将两者的内容合并到用户可见的控制台
。

3. 第二个应用程序获得属于第一个应用程序的控制台的句柄。


4. 将控制台放置在共享内存中，并且两个应用程序都具有相同的所有权。

1. The second application inherits the console from the first application for its lifetime, with the console returning to the original owner on exit.
2. Each application has its own console. Windows then somehow merges the content of the two into what the "console" visible to the user
3. The second application get a handle to the console that belongs to the first application.
4. The console is placed into shared memory and both applications have equal "ownership"

错过了什么，这四个选项没有一个充分描述了Windows使用其控制台。

It's quite possible that I missed something and none of these four options adequately describe what Windows does with its consoles.

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

If the answer is close to option 4. My follow-up question is which of the two processes is responsible for managing the window? (Handling graphical updates when the screen needs to be refreshed / redrawn, etc)

一个具体的例子：运行CMD。然后，使用CMD，运行[控制台应用程序]。

A concrete example: Run CMD. Then, using CMD, run [console application]. The [console application] will write to what appears to be the same console window that CMD was using.

推荐答案

您的四个控制台窗口可能性实际上是这种情况，并且您的后续问题这两个过程中哪一个负责管理窗口的答案是不是进程负责。 TUI程序根本不必知道任何窗口，并且，在封面下，不一定都连接到GUI。

None of your four possibilities is actually the case, and the answer to your follow-on question, "Which of the two processes is responsible for managing the window?", is that neither process is responsible. TUI programs don't have to know anything about windows at all, and, under the covers, aren't necessarily even plumbed in to the GUI.

控制台是对象，通过句柄访问，就像文件，目录，管道，进程和线程。单个进程不通过它的句柄拥有控制台，而不是一个进程拥有其具有打开句柄的任何文件。子进程从其父进程处继承到控制台的句柄与所有其他（可继承）句柄相同。你的TUI应用程序，由CMD产生，只是继承标准句柄，CMD说，它应该继承，当它调用 CreateProcess（）—这通常是CMD的标准输入，输出和错误（除非命令行告诉CMD使用一些其他句柄作为孩子的标准输入，输出和错误）。

Consoles are objects, accessed via handles just like files, directories, pipes, processes, and threads. A single process doesn't "own" a console via its handle to it any more than a process "owns" any file that it has an open handle to. Handles to consoles are inherited by child processes from their parents in the same way that all other (inheritable) handles are. Your TUI application, spawned by CMD, simply inherits the standard handles that CMD said that it should inherit, when it called CreateProcess() — which are usually going to be CMD's standard input, output, and error (unless the command-line told CMD to use some other handles as the child's standard input, output, and error).

控制台不依赖于CMD。它们存在，只要有（a）控制台的输入或输出缓冲区的任何打开的句柄或（b）任何附加到控制台的进程。所以在你的例子中，你可以杀死CMD，但只有当你终止子进程也将控制台实际被销毁。

Consoles aren't dependent upon CMD. They exist as long as there are (a) any open handles to the console's input or output buffers or (b) any processes otherwise "attached" to the console. So in your example you could kill CMD, but only when you terminated the child process too would the console actually be destroyed.

负责显示GUI提供控制台的窗口是在版本6.1之前的Windows NT中，CSRSS，客户机服务器运行时子系统。窗口处理代码在WINSRV.DLL中，其中包含控制台服务器下盖Win32程序执行控制台I / O使LPC调用。在Windows NT 6.1中，此功能由于由Raymond Chen ，从CSRSS迁移到CSRSS产生的较少特权的进程。

The process that is in charge of displaying the GUI windows in which consoles are presented is, in Windows NT prior to version 6.1, CSRSS, the Client-Server Runtime SubSystem. The window handling code is in WINSRV.DLL, which contains the "console server" that — under the covers — Win32 programs performing console I/O make LPC calls to. In Windows NT 6.1, this functionality, for reasons covered by Raymond Chen, moved out of CSRSS into a less-privileged process that CSRSS spawns.

这篇关于在Windows上，控制台窗口所有权如何工作？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！