Is there a Windows program for loading child process images with redirected stdout/stderr?

Question

I have a program that has stdout and stderr available, so it can and does write important output on these channels. You only see this output when you e.g. launch it from a Windows console window, through typically the command interpreter or Powershell, otherwise obviously you don't have any place you can see said output.

Since this program also works without an attached console window and since it's otherwise a GUI application, I would rather avoid users to be confused about parent or attached console -- the program is best used without one, for all use cases except debugging.

Now, I want to be able to obtain the output nevertheless, even when there is no console window used. I am a big vague on specifics of process file handle management in Windows.

Is there any program available that is designed to launch a program as subprocess, with stdout and stderr redirected to a file or multiple files?

I know that the good old command interpreter and Powershell let you do that, but they only do that with a console window, and I want something that has no such window. A Visual Basic script host, perhaps? Is that still en vogue? Any other solutions?

Answer 1

I'm a bit puzzled about how that program manages to support both console and GUI, since Microsoft designed both modes to be mutually exclusive.

The Microsoft article How to make an application as both GUI and Console application? says this :

In Windows GUI applications and Console applications are very different. GUI applications have at least one window, and a message loop, but no standard in/out/error. Console applications have standard in/out/error, but no window, no message loop. An application is either a GUI application or Console application, but not both.

Some people want their application behaves differently depending on input. If there are inputs, the application behaves like Console application. If there is no input, it behaves like GUI applications.

It then lists two possible solutions.

1. The .com versus .exe trick (.com always found before .exe)

In VisualStudio case, there are actually two binaries: devenv.com and devenv.exe. Devenv.com is a Console app. Devenv.exe is a GUI app. When you type devenv, because of the Win32 probing rule, devenv.com is executed. If there is no input, devenv.com launches devenv.exe, and exits itself. If there are inputs, devenv.com handles them as normal Console app.

2. The respawn method

In ildasm case, there is only one binary: ildasm.exe. It is first compiled as a GUI application. Later editbin.exe is used to mark it as console subsystem. In its main method it determines if it needs to be run as console mode or GUI mode. If need to run as GUI mode, it relaunches itself as a GUI app.

I don't know which method is used by your program, and it would be interesting to find that out. The free Process Monitor can help you trace which is the case.

In any case, if your problem of launching the program via a console is the console's black window that appears behind the program, then there is a solution. If you launch the console as hidden, this does not affect the display of the GUI which will still be visible.

See my answer on the post Run a batch file in a completely hidden way. Any one from the described solutions should work, unless the method chosen by your program to support both console and GUI manages to sabotage it.