Почему приложение GUI блокирует пакетный файл?

Question

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

Немногие из многих ссылок, это особенно из SO/SE:

• How can I get an MFC application to block from the command line?
• How to wait for a process to terminate to execute another process in batch file
• How do you wait for an exe to complete in batch file?
• Run a program in a batch script and wait for it to finish before continuing

Более того, я сам помню это/было правдой.

Однако, похоже, что это не так.

Я проверил это на простой пакетный файл, как:

echo Pre 
notepad 
echo Post 

Post не печатается, пока я не закрою блокнота. Почему, когда блокнот является графическим приложением?

Я тестировал это на Windows 8, 7 и XP, чтобы исключить возможность изменения поведения в последних версиях Windows. Я пытался отключить расширения команд как один из возможных виновников.

Answer 1

Потому что он ждет возвращения code.You можно использовать start команду, чтобы создать отдельный подпроцесс:

@echo pre 
@start "notepad" notepad 
@echo post 

Answer 2

Это связано с тем, как приложение, которое вы запускаете пробегов и заканчивается. Некоторые программы запускают другой процесс, а затем завершаются, другие продолжают работать. Calc.exe и Notepad.exe просто запускаются до тех пор, пока вы их не закроете. Write.exe и любую программу, которая запускается в результате ассоциации файлов (например, растровый, волновой файл, апплет панели управления и т. Д.), Фактически запускает другую программу, а затем процесс, который их запускает, завершает возврат управления обратно в пакетный файл поэтому он может выполнить следующую строку.

Вот некоторые примеры:

@echo off 

echo Starting Calc.exe 
calc.exe 
echo Calc was closed by the user 

echo Starting Notepad.exe 
Notepad.exe 
echo Notepad was closed by the user 

echo Starting WordPad.exe 
write.exe 
echo Write launched WordPad and then terminated allowing the batchfile to continue 

echo Starting Services.msc 
services.msc 
echo Windows launched MMC, opened services.msc, then returned control to the batchfile 

echo Launching WMP via Chord.wav 
c:\windows\media\chord.wav 
echo Windows launched WMP, opened Chord.wav, then returned control to the batchfile 

Процесс CMD знает Calc и Notepad все еще работает, потому что она породила их сама. Процесс CMD не знает, что остальные все еще работают, потому что промежуточный процесс завершен.

Чтобы наблюдать это, откройте Process Explorer и просмотрите процессы, отображаемые в иерархическом дереве. Calc.exe и Notepad.exe остаются как дочерние процессы CMD-процесса, которые запускают пакетный файл. Write.exe и MMC.exe (services.msc) становятся процессами верхнего уровня, а не дочерними процессами CMD. WMPlayer.exe остается дочерним процессом для svchost.exe, каким образом Windows запустила его. Процесс CMD не знает, что они все еще работают, потому что он не запускал их, как это делал другой процесс Windows. Поэтому выполнение продолжается ...

Еще один пример этого - как работает MSPaint.exe. Если вы запустите его, используя встроенную ассоциацию файлов Windows для BMP, тогда Windows запускает MSPaint.exe, и управление немедленно возвращается в пакетный файл. Однако, если вы передадите BMP в MSPaint.exe, тогда пакетный файл ждет вас, чтобы закрыть MSPaint, прежде чем продолжить. (Я на машине Dev, без ВМРА, таким образом, создать простое название C:. \ MyBitmap.bmp)

@echo off 
C:\MyBitmap.bmp 
calc.exe 
mspaint.exe C:\MyBitmap.bmp 
notepad.exe 

Calc.exe откроется сразу, Notepad.exe будет не открыто, пока закрыть второй экземпляр MSPaint.exe.

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

Answer 3

Я думаю, что ответ кроется в этом вопросе Difference between Windows and Console application.

цитату из двух ответов.

Konrad Rudolph ответил:

Единственное отличие состоит в том, что консольное приложение всегда порождает консоль, если она не запускается из одного (или консоль активно подавляется при запуске). С другой стороны, приложение Windows не создает консоль. Он все равно может прикрепляться к существующей консоли или создавать новую, используя AllocConsole.

Это делает приложения Windows более подходящими для приложений GUI или фоновых приложений, потому что вы, как правило, не хотите иметь для них оконное окно.

oefe ответил:

Консольные приложения и Windows, ведут себя по-разному при вызове в интерактивном режиме из командной строки:

При запуске консольного приложения, командная строка не возвращается, пока консоль выходы приложения. При запуске приложения Windows команда немедленно возвращается.

Это не относится к пакетным файлам; они всегда будут ждать выхода приложения.

Разница в этом bahviour между cmd и пакетом заставила вас думать, что он работал раньше.

Answer 4

Я использовал Windows с NT 3.1, и я тоже сказал бы: «cmd.exe не ждет завершения программ GUI», когда вы просто вводите имя программы (в отличие от использования команды START) , Хотя память становится тусклой, я считаю, что она изначально работала именно так. Но сегодня мое утверждение истинно интерактивно, ложно для «пакетных» файлов. Напомнив мне, я смутно думаю, что это было намеренно изменено как некоторая точка, поскольку наивный составитель партии ожидает последовательного выполнения, но я не могу быть уверенным, и я не знаю, когда.