PE报头“子系统”有什么作用？场地？
我有几个关于PE“子系统”领域的问题，这些问题可能在某种程度上有重叠。为了避免分别向这个地方发送垃圾邮件每个问题，我想我应该一起问他们，然后分别重新询问任何没有得到解决的问题。希望这没问题...
我知道 IMAGE_SUBSYSTEM_WINDOWS_CUI 使操作系统将进程“预附加”到控制台，无论是其父进程还是在必要时创建新控制台。 IMAGE_SUBSYSTEM_WINDOWS_GUI 不会这样做。
在现代版本的 Windows 中，这两者之间还有其他区别吗？过去还有更多吗？
那么其他值呢？Windows 使用它们只是为了拒绝 EXE，还是导致 Windows 模拟不同的 API？这个“模拟”过程是否可以由最终用户扩展，或者是否硬植到操作系统中？
I have several questions about the PE "subsystem" field, which may overlap to some extent. To avoid spamming this place with each question separately, I thought I'd ask them together and then re-ask separately anything that doesn't get addressed. Hope this is OK...
I know that IMAGE_SUBSYSTEM_WINDOWS_CUI makes the OS "pre-attach" the process to a console, either of its parent process or creating a new console if necessary. IMAGE_SUBSYSTEM_WINDOWS_GUI doesn't do that.
Are there any other differences between these two in a modern version of Windows? Have there been more in the past?
What about the other values, are they used by Windows merely to reject an EXE, or do they cause Windows to emulate a different API? Is this "emulation" process extensible by end-users or is this hard-baked into the OS?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
是的，预连接控制台似乎是当前唯一的区别。如果没记错的话，基于 16 位的 Windows 版本 (95/98/SE/Me) 的情况并非如此。
旧版本的 NT 接受 POSIX 和 OS/2 子系统的其他值。
理论上，您也许能够使用 NT Native API 编写自己的子系统。尽管有大量相关文档（如果您查看的话），但我完全不确定它是否足以完成此任务。无论如何，Win32 子系统始终具有相当“特殊”的地位，现在其他子系统都消失了，我根本不确定他们是否尝试过确保可以集成其他子系统。在 NT 4 上（举个例子），我会说“困难但几乎肯定是可能的”。在当前版本的 Windows 上，我想说，对内核进行一些更改会阻止其工作的可能性大约为偶数，而当前可用的文档能够完成除 MS 之外的任何人的任务的可能性要低得多。实现一个子系统。
Yes, pre-attaching a console seems to be the only current difference. If memory serves, that wasn't so much the case with the 16-bit based versions of Windows though (95/98/SE/Me).
Older versions of NT accepted other values for the POSIX and OS/2 subsystems.
In theory, you might be able to write your own subsystem using the NT Native API. Although there's a fair amount of documentation around for that if you look, I'm not at all sure it's sufficient to this task. The Win32 subsystem has always had rather a "special" status anyway, and now that the other subsystems are gone, I'm not at all sure they've even tried to assure that other subsystems can be integrated. On NT 4 (for one example) I'd have said "difficult but almost certainly possible". On a current version of Windows, I'd say there's about even odds that some change to the kernel would prevent it from working -- and much lower than even odds that the currently-available documentation would be up to the task of anybody but MS implementing a subsystem.