我的主机是我的还是从父母那里继承的？
NT 字符模式应用程序如何确定其控制台是否是从父进程继承的，而不是在 CreateProcess 中新分配的控制台？
How can NT character-mode application determine if its console has been inherited from parent process, as opposed to newly allocated console within CreateProcess?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
一些想法可能有帮助，也可能没有帮助 - 这并不是真正的答案，但它太长，无法放入注释中。*
您可以使用 GetConsoleWindow() 来确定控制台的 HWND。然后可以看看是否有其他人在分享。尝试在其上调用 GetWindowThreadProcessId - 在某些版本的 Windows 上，如果我没记错的话，这似乎会返回 CSRSS 进程的 PID - 这没有帮助。但似乎在Win7上，它返回最初拥有该窗口的进程的PID。
例如，我启动了一个CMD窗口，然后输入了more；所以我们有 cmd.exe 和 more.exe 共享同一个窗口。 Spy++ 报告 HWND 属于 cmd.exe。
但是使用“start more”，因此创建一个包含 more 的新控制台，spy++ 报告新窗口属于 more.exe。
然而，这可能是 Win7 中的新行为（或者至少在以前的版本中可能不一致）；控制台窗口实际上由一个辅助进程拥有，Win7 中为 conhost.exe，以前版本中为 csrss。 GetWindowThreadProcessId 可能会返回以前版本中这些辅助进程的 PID。谁知道它会在 Windows 的未来版本中返回什么 - 控制台窗口是“特殊的”。
--
不依赖 GetWindowThreadProcessID 的另一种方法是：
长话短说，也许可以近似这一点，但不清楚你是否真的想“在现实生活中”这样做； “如果没有参数则暂停”可能是最好的方法。
[*此答案仅供娱乐，禁止等情况无效]
Some ideas that may or may not help - this isn't really an answer, but it's too long to fit into the comments.*
You can use GetConsoleWindow() to determine the HWND of your console. Could then see if anyone else is sharing that. Try calling GetWindowThreadProcessId on it - on some versions of windows, if I recall correctly, it seems this returns the PID of the CSRSS process - which isn't helpful. But it seems that on Win7, it returns the PID of the process that initially owns that window.
For example, I started a CMD window, and typed in more; so we have cmd.exe and more.exe sharing the same window. Spy++ reports that the HWND belongs to cmd.exe.
But use "start more" so create a new console with more in it, and spy++ reports that the new window belongs to more.exe.
This may be new behavior in Win7 (or at least may not be consistent in previous versions), however; console windows are actually owned by a helper process, conhost.exe in Win7 and csrss in previous versions. It's possible that GetWindowThreadProcessId will return the PID of those helper processes on previous versions. And who knows what it will return in a future version of Windows - console windows are "special".
--
A different approach that doesn't rely on GetWindowThreadProcessID is to:
Long story short, it might be possible to approximate this, but not clear that you'd actually want to do it "in real life"; the "pause if no parameters" is likely the best way to go.
[*This answer is provided for entertainment purposes only, void where prohibited, etc.]
您可以尝试
GetConsoleProcessList，第一个进程将是询问的进程，第二个是父进程，但如果它已退出（例如start.exe），则列表链断裂，它将仅包含当前正在运行的进程。尽管当我使用 Sysinternals Process Explorer 检查进程时，它在“线程”选项卡中显示
ConEmuHk64.dll。当我正常运行我的应用程序时，该函数会报告ConEmuC64.exe <= Far.exe <= ConEmuC64.exe进程（没有第一个），或者cmd.exe或powershell.exe从标准 Windows 终端运行时。所以实际上父进程可能会退出但控制台仍然是继承的
you may try
GetConsoleProcessList, the first process will be the one that asks, the second is the parent, but if it has quit (for examplestart.exe) then the list chain breaks and it will contain only the currently running process.although when i check the process with Sysinternals Process Explorer, it shows
ConEmuHk64.dllin Threads tab. when i normally run my app that function reportsConEmuC64.exe <= Far.exe <= ConEmuC64.exeprocesses (without the first one), or eithercmd.exeorpowershell.exewhen running from the standard windows terminal.so actually the parent process may quit but the console stays inherited