Enable Windows GUI apps to be resources
Summary of the new feature / enhancement
Windows differentiates GUI and console apps where GUI apps don't have a corresponding console created and thus dsc can't talk to it via STDIN, STDOUT, STDERR.
Proposed technical implementation details (optional)
Whatever communication mechanism we create, we need to ensure it's secure in the sense that an attacker can't squat on it and become a "man-in-the-middle" or pretend to be either side of the conversation. This means, for example, a well-known named pipe won't work.
It might simply require GUI apps to explicitly allocate a console when used as a resource: https://learn.microsoft.com/en-us/windows/console/allocconsole
One thought is that we can introduce a new communication kind in the manifest (default is still standardIO) called namedPipe. The named pipe would be created by dsc and passed as an argument or env var to the child process. The problem with passing as arg is that the command line args to a process can be discovered while the env vars cannot (assuming different user, same user can always attach a debugger anyways). There would be a single pipe that the child process connects to. With this transport, the child process would have to adhere to only sending JSON and any JSON that isn't progress or a trace message is considered output.