Например есть консольное C++ App myconsoleapp.exe

Как я его закрываю извне.

Через EnumWindows + EnumWindowsProc + GetWindowText
нахожу hwnd (консоли надо думать) через наличие "myconsoleapp.exe" в заголовке консоли

Далее делаю код(если быть точным по циклу, пока hwnd с нужным заголовком не закончатся):

Код когда-то не особо думая стыренный, посему попутно два вопроса:
1) Надо ли проверять WS_DISABLED в стиле?
2) Надо ли посылать WS_CANCELMODE окну?

По сути то же самое я могу сделать нажав на крестик консоли, чтоб она закрылась.

Все это прекрасно работает, в смысле консоль убивается.
Мне ПО ХОРОШЕМУ надо, чтоб консольное приложение перед выходом сделало умные вещи.
Например




Приаттаченное окно я убрал, т.е. есть есть только окно самой консоли.
Да и не пойдет приаттаченное окно, есть режим сервиса через
NSSM - the Non-Sucking Service Manager
И в этом режиме механизм выхода также должен срабатывать.
Service shutdownFirst nssm will attempt to generate a Control-C event and send it to the application's console. Batch scripts or console applications may intercept the event and shut themselves down gracefully. Java applications tend to respond well to Control-C events. GUI applications do not have consoles and will not respond to this method. Not supported on Windows 2000.

Secondly nssm will enumerate all windows created by the application and send them a WM_CLOSE message. Applications may follow the convention of responding to the message by initiating a graceful exit.

Thirdly nssm will enumerate all threads created by the application and send them a WM_QUIT message, which will be received if the application has a thread message queue

As a last resort nssm can call TerminateProcess() to request that the operating system forcibly terminate the application. The TerminateProcess() call cannot be trapped or ignored, so in most circumstances the application will be killed. However, it is unlikely that it will be able to perform any cleanup operations before it exits.



Но на ctrl+C приложение с консолью также закрывается - проверял.
Т.е. дойдет ли дело до WM_CLOSE в случае сервиса? не уверен

В общем надо как-то повесить ПРОЦЕДУРЫ ВЫХОДА "на крестик".
Пока идей нет.

В настоящий момент я использую "фигню".
Т.е. грубо закрывающее приложение кладет файл stop.ext, а консольное отрабатывает остановку:


после чего закрывающее обнаружив файл stopped.ext уже посылает команду закрытия WM_CLOSE /StopNTService

В принципе я могу то же самое реализовать через mailslot-ы (этот механизм общения сейчас наладил),
но сам логический принцип здесь страдает.

Нужно реализовать событие On_я_закрываюсь (On_меня пытаются_убить) внутри C++. Вот как?

Изопропил, Dima T,

спасибо за ссылку, то что надо.

Единственное, я хочу допонять немного.

Вот сделал я:



Проверил визуально и по beep-ам:
1) При работе AsApplication у меня закрывается по CTRL_CLOSE_EVENT (собственно следует из моего VB кода)
2) При работе AsService у меня закрывается по CTRL_C_EVENT (собственно следует из описания NSSM Service shutdown)
3) Можно закрыть по CTRL_BREAK_EVENT (нажимая Ctrl+Break в открытой консоли), но реально это не используется в силу предыдущих 2-х пунктов

Я прочел документацию по этому хозяйству, несколько путано насчет закрытия приложения в зависимости от возврата TRUE/FALSE ф-цией CtrlHandler
Т.е. мне не надо нарушать нормальную процедуру закрытия, просто нужно вставить перед закрытием МОЙ КОД.
Если я делаю


то оно не закроется, если FALSE - то закроется как по дефолту

1. Вопрос #1 Правильно ли я понимаю, что для отработки МОЙ КОД перед закрытием мне надо сделать?:


2. Вопрос #2 Но мне непонятно что надо делать для случаев CTRL_LOGOFF_EVENT, CTRL_SHUTDOWN_EVENT и default
Достаточно ли написать?:

Т.е. надо ли в эти случаи вставлять МОЙ КОД (закрытия)?
И надо ли в этих случаях возвращать TRUE или FALSE?

Некий тест показал что если приложение запущено AsService, то при "Завершение сеанса" (пользователя), CTRL_LOGOFF_EVENT срабатывает дважды (2 бипа), но при этом приложение вроде как не выгружается, причем неважно возвращаю ли я TRUE либо FALSE для CTRL_SHUTDOWN_EVENT.
Ну естественно, приложение AsService не должно закрываться при выходе юзера.
Т.е. я боюсь, что наличие моей CtrlHandler и неправильный возврат TRUE/FALSE нарушит нормальную работу приложения в случаях отличных от тех, когда я явно делаю WM_CLOSE либо явно останавливаю сервис (CTRL+C как выяснили).

Какие комментарии?

Дмитрий77Некий тест показал что если приложение запущено AsService, то при "Завершение сеанса" (пользователя), CTRL_LOGOFF_EVENT срабатывает дважды (2 бипа), но при этом приложение вроде как не выгружается, причем неважно возвращаю ли я TRUE либо FALSE для CTRL_SHUTDOWN_EVENT.
Ну естественно, приложение AsService не должно закрываться при выходе юзера.

Ну, этому как раз нашел документальное объяснение (почему плюет на true/false и не закрывается):
HandlerRoutine callback function
в самом низуWhen a console application is run as a service, it receives a modified default console control handler. This modified handler does not call ExitProcess when processing the CTRL_LOGOFF_EVENT and CTRL_SHUTDOWN_EVENT signals. This allows the service to continue running after the user logs off. If the service installs its own console control handler, this handler is called before the default handler. If the installed handler calls ExitProcess when processing the CTRL_LOGOFF_EVENT signal, the service exits when the user logs off.

И далее:
CTRL_LOGOFF_EVENT 5 ... Note that this signal is received only by services. Interactive applications are terminated at logoff, so they are not present when the system sends this signal.
CTRL_SHUTDOWN_EVENT 6 ... Interactive applications are not present by the time the system sends this signal, therefore it can be received only be services in this situation.

Т.е. по сути писать МОЙ КОД в эти 2 кейса никак нельзя, ибо это приведет к сбросу ресурсов без закрытия приложения-сервиса при LofOff (получим работающее но мертвое приложение), а в случае приложения (AsApp) как следует из документации этих событий никогда не будет в принципе.

Думается мне, что надо
1) Писать МОЙ КОД только для CTRL_C_EVENT CTRL_CLOSE_EVENT CTRL_BREAK_EVENT
2) везде возвращать FALSE, дабы не нарушать стандартное поведение

Basil A. Sidorov_atexit() или обработка SIG_TERM?
Не, первый совет самое оно.
Коль скоро я убиваю его из под системы.

Дмитрий77CTRL_LOGOFF_EVENT 5 ... Note that this signal is received only by services. Interactive applications are terminated at logoff, so they are not present when the system sends this signal.

А вот и нет. При As Application + user logoff хандлится именно CTRL_LOGOFF_EVENT и именно по нему идет закрытие.
Т.е. получается, если сервис - не нужен МОЙ КОД, если не сервис - нужен МОЙ КОД.

Только консоль то не знает, сервис она или нет.
Не, я конечно могу вычислить USER али SYSTEM через СИДЫ и прочую хрень (хотя в общем случае SYSTEM != AsService), но это уж слишко большой и неправильный наворот.

Дмитрий77При As Application + user logoff хандлится именно CTRL_LOGOFF_EVENT и именно по нему идет закрытие.
И вот если здесь вернуть TRUE, то будет бяка-окно системы нехорошего вида "Невозможно закрыть приложение".

Лишний раз убеждает, что TRUE нельзя возвращать ни при каких обстоятельствах. Только FALSE.

Basil A. SidorovПо опыту работы с Apache Commons Daemon могу сказать, что события logon/logoff отражаются в его логе как Ctrl+C.
Ctrl+C посылается моей консоли (в режиме AsService) со стороны NSSM - the Non-Sucking Service Manager, который собственно и осуществляет "сервисность" консоли. Но не при logoff, а чтоб ее закрыть при команде "остановить сервис".
Но сама консоль конкретно при logoff получает CTRL_LOGOFF_EVENT, как при "под сервисом", так и "как приложение".
При этом "под сервисом" это не вызывает ее закрытие, а "как приложение" вызывает.

Реальный вред от выполнения МОЙ КОД при CTRL_LOGOFF_EVENT под сервисом (консоль не закрылась но мертвая - снял ресурсы)
на порядок больше чем
потенциальный вред от НЕ выполнения МОЙ КОД при CTRL_LOGOFF_EVENT в режиме "As Application".

Поэтому либо надо покривить душой и не выполнять МОЙ КОД при CTRL_LOGOFF_EVENT вообще.

Либо покривить по другому и использовать такой код:


И я думаю что остановлюсь на этом варианте.
Кривлю я в том, что де-факто принимаю SYSTEM == AsService
Это конечно неправильно, но для моего случая сойдет, т.к. "Сервис" конфигурируется программно и строго под LocalSystem.
Вопрос о том что это неправильно (SYSTEM == AsService)
обсуждался на многих форумах, но альтернативные коды которые там приводятся - простыни в которые завернуться и итти топиться.
Тесты с beep показывают (вернее озвучивают - эдакий beep-debug) корректное поведение кода.
Осталось написать МОЙ КОД, но это как раз не сложно.

Dimitry Sibiryakov,

Так не язви. Давай разбираться.

>вынуждены писать "МОЙ КОД".
МОЙ КОД -это всего лишь Application Specific код который приложение должно выполнить перед закрытием - типа освободить ресурсы,
а не код типа проверки на LocalSystem, по поводу чего ты видимо язвишь

>Они никогда не узнают, что CTRL_LOGOFF_EVENT посылается всем консолям при выходе любого пользователя,
Т.е. хочешь сказать что если
1) есть User1 и User2
2) myconsole.exe запущена под User1
3) User2 вышел (ну там по RDP был подключен к серверу)
то
myconsole.exe запущеная под User1 получит CTRL_LOGOFF_EVENT,
выполнится МОЙ КОД (который срелизит ресурсы)
при этом она не закроется и станет "мертвой"

ТЫ ЭТО ХОТЕЛ СКАЗАТЬ?
Я об этом не подумал.
Если так, то правильнее вообще убрать МОЙ КОД для случая CTRL_LOGOFF_EVENT

>До них никогда не дойдёт, что в интерактивном режиме их приложение
закрывается не потому, что получило CTRL_LOGOFF_EVENT, а потому что система его после
этого прибила с помощью TerminateProcess, как не ответившее.
Какой ответ ждет система?
А почему система не попыталась послать Ctrl-C /Ctrl-Break / WM_Close ?
Как мне отловить TerminateProcess?
Ну и как ты предлагаешь выполнять МОЙ КОД для этого случая?
Или хочешь сказать что МОЙ КОД вообще надо вставлять в другое место а не в CtrlHandler?
Хорошо, в какое?

>И это ещё если не вспоминать,
>что у сервисов вообще-то используется и другой механизм извещения об остановке.

Оставь сервисы в покое. NSSM корректно уведомляет консоль о том что ей надо убиться.
Речь идет о том, что консоль должна сказать "последнее слово" всякий раз перед тем как убиться.

Dimitry SibiryakovВсё что я мог бы сказать находится в двух кликах от ссылок в первом же ответе, а именно на
http://msdn.microsoft.com/en-us/library/windows/desktop/ms683242(v=vs.85).aspx

Дима, а я это читал, и даже привел цитаты двумя постами выше.
Дмитрий77Ну, этому как раз нашел документальное объяснение (почему плюет на true/false и не закрывается):
HandlerRoutine callback function
в самом низуWhen a console application is run as a service, it receives a modified default console control handler. This modified handler does not call ExitProcess when processing the CTRL_LOGOFF_EVENT and CTRL_SHUTDOWN_EVENT signals. This allows the service to continue running after the user logs off. If the service installs its own console control handler, this handler is called before the default handler. If the installed handler calls ExitProcess when processing the CTRL_LOGOFF_EVENT signal, the service exits when the user logs off.

И далее:
CTRL_LOGOFF_EVENT 5 ... Note that this signal is received only by services. Interactive applications are terminated at logoff, so they are not present when the system sends this signal.
CTRL_SHUTDOWN_EVENT 6 ... Interactive applications are not present by the time the system sends this signal, therefore it can be received only be services in this situation.


И даже это как-то осознал/учел при написании кода.
И я честно не понимаю, какого черта консоль запущенная как Application, вообще получает CTRL_LOGOFF_EVENT, т.к. это противоречит написанному в документации выше.

Мне показалось, ты другое что-то хотел сказать.

Нет проблем, счас настраиваю тест на Win2003, зайду и выйду через RDP и посмотрю что будет с локально запущенным App, т.е. получит ли оно CTRL_LOGOFF_EVENT.

Basil A. SidorovВроде, правильный вариант, зарегистрировать обработчик "при выходе" и выполнять необходимую подчистку именно там.
...
Если приложение зарегистрирует обработчик завершения, то оно будет корректно работать и приложением и сервисом.
...
Так зачем делать сложно, когда можно сделать просто?
OK, как сделать?
Я так понимаю, это другая технология.

Дмитрий77>Они никогда не узнают, что CTRL_LOGOFF_EVENT посылается всем консолям при выходе любого пользователя,
Т.е. хочешь сказать что если
1) есть User1 и User2
2) myconsole.exe запущена под User1
3) User2 вышел (ну там по RDP был подключен к серверу)
то
myconsole.exe запущеная под User1 получит CTRL_LOGOFF_EVENT,
выполнится МОЙ КОД (который срелизит ресурсы)
при этом она не закроется и станет "мертвой"

ТЫ ЭТО ХОТЕЛ СКАЗАТЬ?
Я об этом не подумал.
Если так, то правильнее вообще убрать МОЙ КОД для случая CTRL_LOGOFF_EVENT

Я провел ряд экспериментов:
1) На Win Server 2003. Один пользователь "за экраном", там запущена консоль другой входит/выходит по RDP, и наоборот консоль в терминалке, а локальный входит/выходит
2) На XP - несколько пользователей в режиме разрешенной "Смены пользователя".
Пробовал администраторов / не администраторов.

Дык вот: CTRL_LOGOFF_EVENT посылается в консоль, запущенную под THE_USER только когда LogOff делает этот самый THE_USER, после чего консоль делает exit.
В "чужую юзерскую консоль" CTRL_LOGOFF_EVENT не посылается.

Посему спорная часть кода как я ее написал имеет право на жизнь и к проблемам не приведет.

Согласно документации, повторюсь:
CTRL_LOGOFF_EVENT 5
... Note that this signal is received only by services. Interactive applications are terminated at logoff, so they are not present when the system sends this signal.
Документация врет? Свой CTRL_LOGOFF_EVENT прекрасно ловится до "terminated", а вот чужой нет.

Basil A. Sidorov, ну давай попробую с _atexit(), по документации вроде ничего сложного, вот сработает ли.
О результатах отпишусь.

Дмитрий77Basil A. Sidorov, ну давай попробую с _atexit(), по документации вроде ничего сложного, вот сработает ли.
О результатах отпишусь.
Попробовал. Не пойдет, увы.
Она не отрабатывает Ctrl+C.
А под сервисом консоль грохается у меня именно через Ctrl+C.
Все остальные варианты соответствующие WM_Close и logoff ctrl+break она отрабатывает.

Все решения (поиском по инету) ведут к методу #1 CTRL_C_EVENT
Можно конечно сгибритизировать как _atexit() + CTRL_C_EVENT, но думается это извращение.
Причем как я понимаю нет никаких гарантий что _atexit() будет стрелять гарантированно и не будет двойного выстрела вместе с CTRL_C_EVENT при каких-то обстоятельствах.
Люди на форумах жалуются на то что не работает еще и с ctrl+break (у меня работает), кто-то жалуется на какие-то краши.
Не, пусть будут сигналы.

Basil A. SidorovДмитрий77Я провел ряд экспериментов:Сделайте задание, назначенное на запуск "при загрузке" и "почуствуйте разницу".

P.S. Про Ctrl+C в логе Apache procrun при входе-выходе пользователей я ведь не от балды написал.
Я не понял что ты конкретно предлагаешь сделать и причем тут планировщик. У меня консоль - основная рабочая часть, но она запускается оболочкой либо под Current User, либо под LocalSystem как сервис под управлением NSSM - the Non-Sucking Service Manager . Я так понимаю, Apache procrun это другая подобная система, но я ее не использую, там могут быть свои внутренние глюки. Т.е. исключен запуск консоли планировщиком напрямую.

Но все одно не понимаю, что ты имеешь ввиду.