Existe um programa do Windows para carregar imagens de processo filho com stdout / stderr redirecionado?

Question

Eu tenho um programa que tem stdout e stderr disponível, então ele pode e escreve uma saída importante nesses canais. Você só vê essa saída quando, por exemplo, iniciá-lo a partir de uma janela de console do Windows, por meio do interpretador de comandos ou Powershell, caso contrário, obviamente, você não tem nenhum lugar onde possa ver a saída.

Como este programa também funciona sem uma janela de console conectada e uma vez que é um aplicativo GUI, eu preferiria evitar que os usuários fiquem confusos sobre pai ou console conectado - o programa é melhor usado sem um, para todos os casos de uso, exceto depuração .

Agora, quero poder obter a saída mesmo assim, mesmo quando não há janela de console usada. Eu sou um grande vago em detalhes do gerenciamento de identificadores de arquivos de processo no Windows.

Existe algum programa disponível projetado para iniciar um programa como subprocesso, com stdout e stderr redirecionados para um arquivo ou vários arquivos?

Eu sei que o bom e velho intérprete de comandos e o Powershell permitem que você faça isso, mas eles só fazem isso com uma janela de console, e eu quero algo que não tenha essa janela. Um host de script do Visual Basic, talvez? Isso ainda é en vogue ? Alguma outra solução?

    

Answer 1

Estou um pouco intrigado sobre como esse programa consegue suportar console e GUI, já que A Microsoft projetou ambos os modos para serem mutuamente exclusivos.

O artigo da Microsoft Como fazer uma aplicação como aplicação GUI e Console? diz isso:

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.

Em seguida, lista duas soluções possíveis.

1. O truque .com versus .exe ( .com sempre encontrado antes de .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. O método de respawn

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.

Eu não sei qual método é usado pelo seu programa, e seria interessante para descobrir isso. O livre Process Monitor pode ajudá-lo a rastrear qual é o caso.

De qualquer forma, se o seu problema de iniciar o programa através de uma consola for o da consola janela preta que aparece por trás do programa, então há uma solução. Se você ativar o console como oculto, isso não afetará a exibição da GUI que ainda será visível.

Veja minha resposta no post Execute um arquivo em lote de uma maneira completamente oculta . Qualquer um das soluções descritas deve funcionar, a menos que o método escolhido pelo seu programa para suportar console e GUI consegue sabotá-lo.