问题
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?
回答1:
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.
来源：https://stackoverflow.com/questions/4866352/what-are-the-effects-of-the-pe-header-subsystem-field