Существует ли программа Windows для загрузки изображений дочерних процессов с перенаправленным stdout/stderr?

Question

У меня есть программа, в которой доступны stdout и stderr, поэтому она может и действительно выводит важные данные на эти каналы. Вы видите этот вывод только когда вы, например, запускаете его из окна консоли Windows, обычно через интерпретатор команд или Powershell, в противном случае, очевидно, у вас нет места, где вы могли бы увидеть указанный вывод.

Так как эта программа также работает без окна подключенной консоли и, в противном случае это приложение с графическим интерфейсом, я бы предпочел не путать пользователей с родительской или подключенной консолью - программу лучше всего использовать без таковой, для всех случаев использования, кроме отладки.

Теперь я хочу получить вывод, даже если не используется консольное окно. Я сильно размышляю об особенностях управления дескрипторами файлов процесса в Windows.

Существует ли какая-либо программа, предназначенная для запуска программы в качестве подпроцесса, с перенаправлением stdout и stderr в файл или несколько файлов?

Я знаю, что старый добрый командный интерпретатор и Powershell позволяют вам это делать, но они делают это только с консольным окном, и я хочу что-то, у чего такого окна нет. Может быть, хост скриптов Visual Basic? Это все еще в моде? Любые другие решения?

Answer 1

Я немного озадачен тем, как эта программа поддерживает как консоль, так и графический интерфейс, поскольку Microsoft разработала оба режима как взаимоисключающие.

Статья Microsoft Как сделать приложение как графическим, так и консольным приложением? говорит это:

В Windows графические приложения и консольные приложения сильно различаются. Приложения с графическим интерфейсом имеют как минимум одно окно и цикл обработки сообщений, но не имеют стандартного входа / выхода / ошибки. Консольные приложения имеют стандартный ввод / вывод / ошибку, но без окна, без цикла обработки сообщений. Приложение - это приложение с графическим интерфейсом или консольное приложение, но не оба одновременно.

Некоторые люди хотят, чтобы их приложение работало по-разному в зависимости от ввода. Если есть входные данные, приложение ведет себя как консольное приложение. Если нет ввода, он ведет себя как приложение с графическим интерфейсом.

Затем перечисляются два возможных решения.

1. Трюк .com против .exe (.com всегда находился раньше .exe)

В случае VisualStudio существует два двоичных файла: devenv.com и devenv.exe. Devenv.com - консольное приложение. Devenv.exe это приложение с графическим интерфейсом. При вводе devenv из-за правила проверки Win32 выполняется devenv.com. Если нет ввода, devenv.com запускает devenv.exe и завершает свою работу. Если есть входные данные, devenv.com обрабатывает их как обычное консольное приложение.

2. Метод возрождения

В случае ildasm есть только один двоичный файл: ildasm.exe. Сначала он компилируется как приложение с графическим интерфейсом. Позже editbin.exe используется, чтобы пометить его как консольную подсистему. В своем основном методе он определяет, должен ли он работать в режиме консоли или в режиме графического интерфейса. Если необходимо запустить в режиме графического интерфейса, он перезапускается как приложение с графическим интерфейсом.

Я не знаю, какой метод используется вашей программой, и было бы интересно узнать это. Бесплатный Process Monitor может помочь вам проследить, в чем дело.

В любом случае, если вашей проблемой запуска программы через консоль является черное окно консоли, которое появляется за программой, то есть решение. Если вы запустите консоль как скрытую, это не повлияет на отображение графического интерфейса, который все еще будет виден.

Смотрите мой ответ на пост. Запустите командный файл полностью скрытым способом. Любое из описанных решений должно работать, если метод, выбранный вашей программой для поддержки как консоли, так и графического интерфейса, не может саботировать его.