Привет.

Я запускаю процесс через функцию shellexecute. Собственно в моей задаче это могут быть один из 4х браузеров IE, firefox, opera или chrome. Например так:

ShellExecute (NULL, _T("open"), _T("C:\\Program Files\\Opera\\opera.exe"), NULL, NULL, SW_MAXIMIZE);

Как правильно получить указатель на запущенный процесс и закрыть его? Может есть какое-то более изящное решение для запущенных браузеров?

Спасибо

Здравствуйте, egvos4, Вы писали:

E>Как правильно получить указатель на запущенный процесс и закрыть его? Может есть какое-то более изящное решение для запущенных браузеров?

Использовать ShellExecuteEx

Здравствуйте, egvos4, Вы писали:

E>Как правильно получить указатель на запущенный процесс и закрыть его?

Не понятно что за вопрос: как закрыть или как правильно закрыть?

Как (правильно получить указатель) и (закрыть его)?
или
Как правильно (получить указатель и закрыть его)?

А если он будет сопротивляться? MessageBox какой-нибудь?

Здравствуйте, VladFein, Вы писали:

VF>Здравствуйте, egvos4, Вы писали:

E>>Как правильно получить указатель на запущенный процесс и закрыть его?

VF>Не понятно что за вопрос: как закрыть или как правильно закрыть?

VF>Как (правильно получить указатель) и (закрыть его)?
VF>или
VF>Как правильно (получить указатель и закрыть его)?

VF>А если он будет сопротивляться? MessageBox какой-нибудь?

Вот нужное мне решение в упрощенном виде:

// Запуск IE
SHELLEXECUTEINFO sei;
ZeroMemory(&sei,sizeof(sei));
sei.cbSize = sizeof(sei);
sei.lpFile = _T("IEXPLORE.EXE");
sei.lpVerb = _T("open");
sei.fMask = SEE_MASK_NOCLOSEPROCESS;
sei.nShow = SW_MAXIMIZE;
ShellExecuteEx(&sei);
// Ждем 7 сек
Sleep (7000);
// Закрываем процесс
TerminateProcess (sei.hProcess, 0);
AfxMessageBox (_T("Закрыли!"));

Здравствуйте.

Возник еще один вопрос по этой же теме.

Как пишет Джефри Рихтер, не желательно принудительно уничтожать процесс из другого процесса путем вызова TerminateProcess. Желательно, чтобы сам первоначальный процесс вызвал у себя ExitProcess и корректно завершился. Соответственно вопрос в том как правильно передать команду процессу, в моем случае одному из четырех запущенных браузеров для их корректного закрытия. Например как-то передать WM_CLOSE? Есть идеи?

Спасибо.

Здравствуйте, egvos4, Вы писали:

E>Как пишет Джефри Рихтер, не желательно принудительно уничтожать процесс из другого процесса путем вызова TerminateProcess. Желательно, чтобы сам первоначальный процесс вызвал у себя ExitProcess и корректно завершился. Соответственно вопрос в том как правильно передать команду процессу, в моем случае одному из четырех запущенных браузеров для их корректного закрытия. Например как-то передать WM_CLOSE? Есть идеи?

WM_CLOSE эквивалентен нажатию на кнопку "закрыть" в правом углу окна.
Что еще вовсе не означает завершение всей программы. Например, браузер запустился и
показывает пользователю диалог: "данная программа не является браузером по умолчанию",
предлагая сделать ее таковой. WM_CLOSE закроет это окно, а основное окно останется висеть.

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

Здравствуйте, okman, Вы писали:

O>Здравствуйте, egvos4, Вы писали:

E>>Как пишет Джефри Рихтер, не желательно принудительно уничтожать процесс из другого процесса путем вызова TerminateProcess. Желательно, чтобы сам первоначальный процесс вызвал у себя ExitProcess и корректно завершился. Соответственно вопрос в том как правильно передать команду процессу, в моем случае одному из четырех запущенных браузеров для их корректного закрытия. Например как-то передать WM_CLOSE? Есть идеи?

O>WM_CLOSE эквивалентен нажатию на кнопку "закрыть" в правом углу окна.
O>Что еще вовсе не означает завершение всей программы. Например, браузер запустился и
O>показывает пользователю диалог: "данная программа не является браузером по умолчанию",
O>предлагая сделать ее таковой. WM_CLOSE закроет это окно, а основное окно останется висеть.

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

WM_CLOSE
WM_SYSCOMMAND + wParam==SC_CLOSE
WM_DESTROY

Хотя как писал ниже okman, это не гарантия закрытия процесса. Процесс может иначе обработать эти сообщения и не завершаться. Хотя в 99 из 100 как правило скорее всего завершиться. Но это не из логики вытекает, а из традиций. Что вряд ли процесс останется работать после таких "просьб". Но опять же — это традиции и только, ничто не мешает абстрактному процессу игнорировать эти сообщения в том или ином случае.

PS: Примеров прямо противоположных именно традиций сотни. "Традиций" в том смысле что в абстрактном софте Икс сделано незавершение по нажатию на крестик (WM_CLOSE | WM_SYSCOMMAND+SC_CLOSE) не из абстрактной "вредности", а по смыслу. Ну, например, настройки типа "сворачивать в трей" при нажатии на крест, много где такие настройки используются. Соответственно, процесс как работал так и будет работать.

Здравствуйте, Carc, Вы писали:

C>

C>WM_CLOSE
C>WM_SYSCOMMAND + wParam==SC_CLOSE
C>WM_DESTROY
C>

C>Хотя как писал ниже okman, это не гарантия закрытия процесса. Процесс может иначе обработать эти сообщения и не завершаться. Хотя в 99 из 100 как правило скорее всего завершиться. Но это не из логики вытекает, а из традиций. Что вряд ли процесс останется работать после таких "просьб". Но опять же — это традиции и только, ничто не мешает абстрактному процессу игнорировать эти сообщения в том или ином случае.

C>PS: Примеров прямо противоположных именно традиций сотни. "Традиций" в том смысле что в абстрактном софте Икс сделано незавершение по нажатию на крестик (WM_CLOSE | WM_SYSCOMMAND+SC_CLOSE) не из абстрактной "вредности", а по смыслу. Ну, например, настройки типа "сворачивать в трей" при нажатии на крест, много где такие настройки используются. Соответственно, процесс как работал так и будет работать.

Спасибо за комментарии.

Могли бы объяснить или дать ссылки как реализовать на практике передачу этих команд на закрытие от моего приложения, запущенным мною приложениям (в моем случае одному из 4х браузеров)?
При учете, что у меня есть только указатель запущенного мной процесса, через ShellExecuteEx.

Здравствуйте, egvos4, Вы писали:

E>Здравствуйте, Carc, Вы писали:

C>>

C>>WM_CLOSE
C>>WM_SYSCOMMAND + wParam==SC_CLOSE
C>>WM_DESTROY
C>>

C>>Хотя как писал ниже okman, это не гарантия закрытия процесса. Процесс может иначе обработать эти сообщения и не завершаться. Хотя в 99 из 100 как правило скорее всего завершиться. Но это не из логики вытекает, а из традиций. Что вряд ли процесс останется работать после таких "просьб". Но опять же — это традиции и только, ничто не мешает абстрактному процессу игнорировать эти сообщения в том или ином случае.

C>>PS: Примеров прямо противоположных именно традиций сотни. "Традиций" в том смысле что в абстрактном софте Икс сделано незавершение по нажатию на крестик (WM_CLOSE | WM_SYSCOMMAND+SC_CLOSE) не из абстрактной "вредности", а по смыслу. Ну, например, настройки типа "сворачивать в трей" при нажатии на крест, много где такие настройки используются. Соответственно, процесс как работал так и будет работать.

E>Спасибо за комментарии.

E>Могли бы объяснить или дать ссылки как реализовать на практике передачу этих команд на закрытие от моего приложения, запущенным мною приложениям (в моем случае одному из 4х браузеров)?
E>При учете, что у меня есть только указатель запущенного мной процесса, через ShellExecuteEx.
Копать в сторону GetWindowThreadProcessId + SendMessageTimeout

Здравствуйте, Carc, Вы писали:

C>Копать в сторону GetWindowThreadProcessId + SendMessageTimeout

Функция GetWindowThreadProcessId получает указатель на окно, а возвращает указатель процесса. Думаю, нужно наоборот ))

Здравствуйте, egvos4, Вы писали:

E>Здравствуйте, Carc, Вы писали:

C>>Копать в сторону GetWindowThreadProcessId + SendMessageTimeout

E>Функция GetWindowThreadProcessId получает указатель на окно, а возвращает указатель процесса. Думаю, нужно наоборот ))
Возвращает на указатель, а ID.
Сценарий примерно такой: перечисляем все окна верхнего уровня каким-нить EnumWindows, и ищем нужное окно по ID запущенного через ShellExecuteEx процесса браузера. Как из SHELLEXECUTEINFO::hProcess получить ID процесса это надо местных парней поспрошать: того же okman, omonim, x64 — они спецы в подобных вопросах, что-нить подскажут.

PS: только не забываем про права на процесс. Windows может и не разрешить так запросто отсылать окну чужого процесса какие-то сообщения. Но это уже детали (хотя и важные, вплоть до неработоспособности конкретного кода в конкретной ситуации). В конце концов можно как-то иначе попробовать завершить процесс... Ну я не знаю, попробовать внедрить в него свою DLL через какую нить SetWinEventHook, а уж из внедренной DLL слать сообщения (хотя и тут я не уверен, сдается мне проблема с правами доступа все равно останется и в этом случае).

Здравствуйте, Carc, Вы писали:

C>Здравствуйте, egvos4, Вы писали:

E>>Здравствуйте, Carc, Вы писали:

C>>>Копать в сторону GetWindowThreadProcessId + SendMessageTimeout

E>>Функция GetWindowThreadProcessId получает указатель на окно, а возвращает указатель процесса. Думаю, нужно наоборот ))
C>Возвращает на указатель, а ID.
C>Сценарий примерно такой: перечисляем все окна верхнего уровня каким-нить EnumWindows, и ищем нужное окно по ID запущенного через ShellExecuteEx процесса браузера. Как из SHELLEXECUTEINFO::hProcess получить ID процесса это надо местных парней поспрошать: того же okman, omonim, x64 — они спецы в подобных вопросах, что-нить подскажут.
Пропупил. Всё проще — GetProcessId

Здравствуйте, Carc, Вы писали:

C>PS: только не забываем про права на процесс. Windows может и не разрешить так запросто отсылать окну чужого процесса какие-то сообщения.

Это такая conspiracy theory?

Здравствуйте, VladFein, Вы писали:

VF>Здравствуйте, Carc, Вы писали:

C>>PS: только не забываем про права на процесс. Windows может и не разрешить так запросто отсылать окну чужого процесса какие-то сообщения.

VF>Это такая conspiracy theory?
Нет, это такая security theory

Здравствуйте, Carc, Вы писали:

C>>>PS: только не забываем про права на процесс. Windows может и не разрешить так запросто отсылать окну чужого процесса какие-то сообщения.

VF>>Это такая conspiracy theory?
C>Нет, это такая security theory

Я, конечно, НЕ эксперт в security theory.
Не могли бы вы набросать сценарий в котором топик стартер запускает процесс с помощью ShellExecute(), и не может послать SendMessage() ему?

Здравствуйте, VladFein, Вы писали:

VF>Я, конечно, НЕ эксперт в security theory.
VF>Не могли бы вы набросать сценарий в котором топик стартер запускает процесс с помощью ShellExecute(), и не может послать SendMessage() ему?

Например: исходный процесс запускается от обычного пользователя, а дочерний при запуске
запрашивает повышение прав до уровня администратора (elevation). В результате процессы получат
разные Integrity Levels и оконные сообщения от первого второму будут блокироваться.