1

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?

Armen Michaeli
  • 2,544

1 Answers1

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.

  1. 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.

Community
  • 1
harrymc
  • 480,290
  • I am pretty sure the program is a Windows Desktop (GUI) application that just calls printf or some other system function that attempts to write to the standard output file. Since the handle isn't normally set up for GUI applications the output does not go anywhere, but that doesn't mean the program doesn't otherwise work -- the calls to printf do not throw an exception or anything. I've just written a small GUI application that calls printf -- nothing appears anywhere but the program isn't halted. If I attach a valid standard output handle, I should at least capture the output. – Armen Michaeli Sep 06 '18 at 10:59
  • If it doesn't respawn, then it might be a console program that starts up a GUI, which is entirely possible. The hidden cmd method should still work if it doesn't conflict with whatever it does. – harrymc Sep 06 '18 at 11:05
  • I think the cited Microsoft "article" (which is just a Q&A post) is an oversimplification. There's nothing that prevents a SUBSYSTEM:WINDOWS program from writing to stdout/stderr (they just don't go anywhere by default). Nor is there anything preventing a SUBSYSTEM:CONSOLE program from calling CreateWindow and running its own GetMessage loop. Those subsystems basically control some default behaviors. Also see https://stackoverflow.com/questions/2627900/what-can-explain-stdcout-not-to-display-anything/2628025#2628025 – jamesdlin Feb 15 '19 at 19:25
  • @jamesdlin: Not too much of an oversimplification: A GUI program can create a console and attach it, but a console program wouldn't have a message pump for GUI. Everything missing can still be done by emulating the initialization code in the Windows library, but it's too much work to bother with. – harrymc Feb 15 '19 at 20:40
  • @harrymc Again, that's not true. You can have a SUBSYSTEM:CONSOLE program that calls GetMessage/TranslateMessage/DispatchMessage in a loop itself. There's nothing magical about the message pump. Or as another example, you can just run editbin.exe on a Windows program to change it from SUBSYSTEM:WINDOWS to SUBSYSTEM:CONSOLE and see no difference other than it now attaches to a console. – jamesdlin Feb 15 '19 at 20:42
  • @jamesdlin: Yes you can, but Windows API isn't as simple as you think. – harrymc Feb 15 '19 at 20:44