Сообщение Re[21]: Windows захватили инопланетяне? от 16.01.2020 18:24
Изменено 16.01.2020 18:34 blp
Re[21]: Windows захватили инопланетяне?
Здравствуйте, Sinclair, Вы писали:
blp>>Можно. Нужно будет просто переписать всю функциональность SCM, которая этом соотвествует (проверка того, что приложение уже запущено / еще запускается, зависимостей и т д)
S>Ну конечно же нет. Даже на этом сайте есть статья о том, как сделать так, чтобы было запущено не более 1го экземпляра приложения в пользовательской сессии.
Читаем внимательно: надо не просто сделать запуск одной копии приложения. Надо еще написать всю остальную функциональность, которая уже есть для сервисов. Например, запуск зависимых сервисов, перезапуск сервиса, если он внезапно завершился, правильная очередность остановки и т. д. — по сути вся функциональность SCM. Я понимаю, что в вашем уютном мире ничего, кроме запуска одной копии сервиса и его остановки, не нужно, но в реальном мире не так.
S>В том коде, который отвечает за старт приложения/сервиса, объём действий будет плюс-минус одинаковый.
S>Объём бойлерплейта, который нужно написать на стороне приложения для обработки ситуации "ой, экземпляр уже есть — дай-ка я лучше ему передам событие для обработки, а сам закроюсь", даже меньше, чем
Вы забыли, что таких "приложений" у нас много — получается что весь этот код нам теперь придется тащить в каждое приложение вместо того, чтобы держать его снаружи (как сейчас в SCM). Это создает проблемы с поддержкой и патчами — поэтому адекватные люди, дизайнящие ОС, так не делают.
>бойлерплейта для превращения приложения в сервис.
Добавьте туда еще то, что код per-user сервисов — это отрефактореный код существующих сервисов и драйверов (виндовые драйвера больше поохожи на виндовые сервисы в плане организации кода и интеграции с SCM). Ваше предложение предполагает взять существующие сервисы/драйвера и поменять их архитекутуру, сделав просто приложениями, да еще ивпилить в каждое из них кусок логики SCMа для запуска/перезапуска. Улавливаете?
blp>>это какими? Как штатно остановить "просто приложение", которое не поддерживает интерфейс работы с SCM, чтобы оно успело корректно деинициализироваться и корректно остановить шатдаун системы/логофф пока оно это не сделает?
S>Если у приложения есть UI (а если его нету, то мы можем обойтись обычным сервисом, который бегает в winsta0), то как бы есть WM_CLOSE, WM_ENDSESSION
blp>>Как сделать так, чтобы на это мог/не мог повлиять юзер?
S>Вот я не буду ехидничать, а просто дам ссылку на MSDN: https://docs.microsoft.com/en-us/windows/win32/rstmgr/guidelines-for-applications
S>Если вам что-то непонятно, то спрашивайте.
Мне как раз все понятно. Это опять эффект Даннинга-Крюгера.
Когда сервис останавливается, он может заблокировать shtdown/logoff на время, которое он определяет сам. В этом случае юзер на экране видит спиннер и ждет — может ждать минуту или две, пока, например, данные на диск не запишутся устройство не размонтируется. Ничего подобного для приложений просто нет и никогда не было. Если приложение блокирует shutdown/logoff об этом уведомляют юзера и предлагаю юзеру пойти разобраться, что там приложению надо (это еще и не всегда работает) и продолжить shutdown/logoff. С сервисами, над которымы юзеру давать контроль нельзя, такой фокус не работает. Это одно из отличий сервисов от приложений.
читаю МСДН, дорого:
https://docs.microsoft.com/en-us/windows/win32/api/winsvc/ns-winsvc-service_preshutdown_info
https://docs.microsoft.com/en-us/previous-versions/windows/desktop/ms700677(v=vs.85)
>Я не суперэксперт по виндовой разработке, (я сервис в последний раз писал году наверное в 2003), и пникаких супер-возможностей, которые специфичны именно для сервиса по взаимодействию с шатдауном/рестартом не припомню.
Ну вот, еще один. Писал что-то там 17 лет назад, не помнит специфики, следовательно ее нет. Скучно.
blp>>Не единственное. Мой список был "навскидку", на самом деле он больше, но и того, что я привел, хватит с головой.
Печально. А вроде выглядели адекватно.
S>Ну как же недокументированные-то? Вот же они задокументированы: https://docs.microsoft.com/en-us/windows/application-management/per-user-services-in-windows
еще раз — недокументированы новые типы сервисов, как их например самому писать. Тупо эти константы, которые передаются в CreateService в MSDN не описаны. Сами сервисы, что они делают — документированы. Чтобы адекватные люди могли понять, что это за сервисы и как себя ведут.
blp>>шаблоны сервисов не существовали ранее — с ними, очевидно, не может работать никакой существующий инструмент.
S>Очевидно, что "нормальный" порядок релизов — это допилить существующие инструменты для того, чтобы управлять вот этой кунсткамерой.
Существующие инструменты прекрасно управляют тем, что есть и вписывается в набор сущностей, которыми они управляют. Я же сказал — отсутсвие красивого красивого GUI для темплейтов серивсов никак не относится к инструментам работы с самими сервисами. Сервисы (не темплейты) так же можно, например, запускать и останавливать, зная их имя. Можно получать список имен сервисов и т. д.
> покажите мне скрипт, который рестартит сервис WpnUserService на машине топикстартера.
Какой именно из "сервис WpnUserService на машине топикстартера"? Их на машине может быть больше одного. А может быть 0, если на машину топкстартера никто не залогинен. Ответьте на этот вопрос, может быть просветление снизойдет на вас.
>Заодно поймёте, почему ваше утверждение "такие сервисы лучше обычных приложений, потому что работают штатные способы управления сервисами" является заблуждением.
Скучно.
blp>>Можно. Нужно будет просто переписать всю функциональность SCM, которая этом соотвествует (проверка того, что приложение уже запущено / еще запускается, зависимостей и т д)
S>Ну конечно же нет. Даже на этом сайте есть статья о том, как сделать так, чтобы было запущено не более 1го экземпляра приложения в пользовательской сессии.
Читаем внимательно: надо не просто сделать запуск одной копии приложения. Надо еще написать всю остальную функциональность, которая уже есть для сервисов. Например, запуск зависимых сервисов, перезапуск сервиса, если он внезапно завершился, правильная очередность остановки и т. д. — по сути вся функциональность SCM. Я понимаю, что в вашем уютном мире ничего, кроме запуска одной копии сервиса и его остановки, не нужно, но в реальном мире не так.
S>В том коде, который отвечает за старт приложения/сервиса, объём действий будет плюс-минус одинаковый.
S>Объём бойлерплейта, который нужно написать на стороне приложения для обработки ситуации "ой, экземпляр уже есть — дай-ка я лучше ему передам событие для обработки, а сам закроюсь", даже меньше, чем
Вы забыли, что таких "приложений" у нас много — получается что весь этот код нам теперь придется тащить в каждое приложение вместо того, чтобы держать его снаружи (как сейчас в SCM). Это создает проблемы с поддержкой и патчами — поэтому адекватные люди, дизайнящие ОС, так не делают.
>бойлерплейта для превращения приложения в сервис.
Добавьте туда еще то, что код per-user сервисов — это отрефактореный код существующих сервисов и драйверов (виндовые драйвера больше поохожи на виндовые сервисы в плане организации кода и интеграции с SCM). Ваше предложение предполагает взять существующие сервисы/драйвера и поменять их архитекутуру, сделав просто приложениями, да еще ивпилить в каждое из них кусок логики SCMа для запуска/перезапуска. Улавливаете?
blp>>это какими? Как штатно остановить "просто приложение", которое не поддерживает интерфейс работы с SCM, чтобы оно успело корректно деинициализироваться и корректно остановить шатдаун системы/логофф пока оно это не сделает?
S>Если у приложения есть UI (а если его нету, то мы можем обойтись обычным сервисом, который бегает в winsta0), то как бы есть WM_CLOSE, WM_ENDSESSION
blp>>Как сделать так, чтобы на это мог/не мог повлиять юзер?
S>Вот я не буду ехидничать, а просто дам ссылку на MSDN: https://docs.microsoft.com/en-us/windows/win32/rstmgr/guidelines-for-applications
S>Если вам что-то непонятно, то спрашивайте.
Мне как раз все понятно. Это опять эффект Даннинга-Крюгера.
Когда сервис останавливается, он может заблокировать shtdown/logoff на время, которое он определяет сам. В этом случае юзер на экране видит спиннер и ждет — может ждать минуту или две, пока, например, данные на диск не запишутся устройство не размонтируется. Ничего подобного для приложений просто нет и никогда не было. Если приложение блокирует shutdown/logoff об этом уведомляют юзера и предлагаю юзеру пойти разобраться, что там приложению надо (это еще и не всегда работает) и продолжить shutdown/logoff. С сервисами, над которымы юзеру давать контроль нельзя, такой фокус не работает. Это одно из отличий сервисов от приложений.
читаю МСДН, дорого:
https://docs.microsoft.com/en-us/windows/win32/api/winsvc/ns-winsvc-service_preshutdown_info
https://docs.microsoft.com/en-us/previous-versions/windows/desktop/ms700677(v=vs.85)
in a critical shutdown, where the user has clicked the Shut down now button in the new Windows UI and applications will no longer be allowed to block shutdown
Best Practices for Handling Shutdown in Windows Vista
...
Applications should not block shutdown
>Я не суперэксперт по виндовой разработке, (я сервис в последний раз писал году наверное в 2003), и пникаких супер-возможностей, которые специфичны именно для сервиса по взаимодействию с шатдауном/рестартом не припомню.
Ну вот, еще один. Писал что-то там 17 лет назад, не помнит специфики, следовательно ее нет. Скучно.
blp>>Не единственное. Мой список был "навскидку", на самом деле он больше, но и того, что я привел, хватит с головой.
Печально. А вроде выглядели адекватно.
S>Ну как же недокументированные-то? Вот же они задокументированы: https://docs.microsoft.com/en-us/windows/application-management/per-user-services-in-windows
еще раз — недокументированы новые типы сервисов, как их например самому писать. Тупо эти константы, которые передаются в CreateService в MSDN не описаны. Сами сервисы, что они делают — документированы. Чтобы адекватные люди могли понять, что это за сервисы и как себя ведут.
sc create X_Test binPath= "..." type= userown obj= X
sc qc TrustedInstaller_Test
[SC] QueryServiceConfig SUCCESS
SERVICE_NAME: X_Test
TYPE : 50 USER_OWN_PROCESS TEMPLATE
...
blp>>шаблоны сервисов не существовали ранее — с ними, очевидно, не может работать никакой существующий инструмент.
S>Очевидно, что "нормальный" порядок релизов — это допилить существующие инструменты для того, чтобы управлять вот этой кунсткамерой.
Существующие инструменты прекрасно управляют тем, что есть и вписывается в набор сущностей, которыми они управляют. Я же сказал — отсутсвие красивого красивого GUI для темплейтов серивсов никак не относится к инструментам работы с самими сервисами. Сервисы (не темплейты) так же можно, например, запускать и останавливать, зная их имя. Можно получать список имен сервисов и т. д.
> покажите мне скрипт, который рестартит сервис WpnUserService на машине топикстартера.
Какой именно из "сервис WpnUserService на машине топикстартера"? Их на машине может быть больше одного. А может быть 0, если на машину топкстартера никто не залогинен. Ответьте на этот вопрос, может быть просветление снизойдет на вас.
>Заодно поймёте, почему ваше утверждение "такие сервисы лучше обычных приложений, потому что работают штатные способы управления сервисами" является заблуждением.
Скучно.
Re[21]: Windows захватили инопланетяне?
Здравствуйте, Sinclair, Вы писали:
blp>>Можно. Нужно будет просто переписать всю функциональность SCM, которая этом соотвествует (проверка того, что приложение уже запущено / еще запускается, зависимостей и т д)
S>Ну конечно же нет. Даже на этом сайте есть статья о том, как сделать так, чтобы было запущено не более 1го экземпляра приложения в пользовательской сессии.
Читаем внимательно: надо не просто сделать запуск одной копии приложения. Надо еще написать всю остальную функциональность, которая уже есть для сервисов. Например, запуск зависимых сервисов, перезапуск сервиса, если он внезапно завершился, правильная очередность остановки и т. д. — по сути вся функциональность SCM. Я понимаю, что в вашем уютном мире ничего, кроме запуска одной копии сервиса и его остановки, не нужно, но в реальном мире не так.
S>В том коде, который отвечает за старт приложения/сервиса, объём действий будет плюс-минус одинаковый.
S>Объём бойлерплейта, который нужно написать на стороне приложения для обработки ситуации "ой, экземпляр уже есть — дай-ка я лучше ему передам событие для обработки, а сам закроюсь", даже меньше, чем
Вы забыли, что таких "приложений" у нас много — получается что весь этот код нам теперь придется тащить в каждое приложение вместо того, чтобы держать его снаружи (как сейчас в SCM). Это создает проблемы с поддержкой и патчами — поэтому адекватные люди, дизайнящие ОС, так не делают.
>бойлерплейта для превращения приложения в сервис.
Добавьте туда еще то, что код per-user сервисов — это отрефактореный код существующих сервисов и драйверов (виндовые драйвера больше поохожи на виндовые сервисы в плане организации кода и интеграции с SCM). Ваше предложение предполагает взять существующие сервисы/драйвера и поменять их архитекутуру, сделав просто приложениями, да еще и впилить в каждое из них кусок логики SCMа для запуска/перезапуска. Улавливаете?
blp>>это какими? Как штатно остановить "просто приложение", которое не поддерживает интерфейс работы с SCM, чтобы оно успело корректно деинициализироваться и корректно остановить шатдаун системы/логофф пока оно это не сделает?
S>Если у приложения есть UI (а если его нету, то мы можем обойтись обычным сервисом, который бегает в winsta0), то как бы есть WM_CLOSE, WM_ENDSESSION
blp>>Как сделать так, чтобы на это мог/не мог повлиять юзер?
S>Вот я не буду ехидничать, а просто дам ссылку на MSDN: https://docs.microsoft.com/en-us/windows/win32/rstmgr/guidelines-for-applications
S>Если вам что-то непонятно, то спрашивайте.
Мне как раз все понятно. Это опять эффект Даннинга-Крюгера.
Когда сервис останавливается, он может заблокировать shtdown/logoff на время, которое он определяет сам. В этом случае юзер на экране видит спиннер и ждет — может ждать минуту или две, пока, например, данные на диск не запишутся устройство не размонтируется. Ничего подобного для приложений просто нет и никогда не было. Если приложение блокирует shutdown/logoff об этом уведомляют юзера и предлагаю юзеру пойти разобраться, что там приложению надо (это еще и не всегда работает) и продолжить shutdown/logoff. С сервисами, над которымы юзеру давать контроль нельзя, такой фокус не работает. Это одно из отличий сервисов от приложений.
читаю МСДН, дорого:
https://docs.microsoft.com/en-us/windows/win32/api/winsvc/ns-winsvc-service_preshutdown_info
https://docs.microsoft.com/en-us/previous-versions/windows/desktop/ms700677(v=vs.85)
>Я не суперэксперт по виндовой разработке, (я сервис в последний раз писал году наверное в 2003), и пникаких супер-возможностей, которые специфичны именно для сервиса по взаимодействию с шатдауном/рестартом не припомню.
Ну вот, еще один. Писал что-то там 17 лет назад, не помнит специфики, следовательно ее нет. Скучно.
blp>>Не единственное. Мой список был "навскидку", на самом деле он больше, но и того, что я привел, хватит с головой.
>Не убедили.
Печально. А вроде выглядели адекватно.
S>Ну как же недокументированные-то? Вот же они задокументированы: https://docs.microsoft.com/en-us/windows/application-management/per-user-services-in-windows
еще раз — недокументированы новые типы сервисов, как их например самому писать. Тупо эти константы, которые передаются в CreateService в MSDN не описаны. Сами сервисы, что они делают — документированы. Чтобы адекватные люди могли понять, что это за сервисы и как себя ведут.
blp>>шаблоны сервисов не существовали ранее — с ними, очевидно, не может работать никакой существующий инструмент.
S>Очевидно, что "нормальный" порядок релизов — это допилить существующие инструменты для того, чтобы управлять вот этой кунсткамерой.
Существующие инструменты прекрасно управляют тем, что есть и вписывается в набор сущностей, которыми они управляют. Я же сказал — отсутсвие красивого красивого GUI для темплейтов серивсов никак не относится к инструментам работы с самими сервисами. Сервисы (не темплейты) так же можно, например, запускать и останавливать, зная их имя. Можно получать список имен сервисов и т. д.
> покажите мне скрипт, который рестартит сервис WpnUserService на машине топикстартера.
Какой именно из "сервис WpnUserService на машине топикстартера"? Их на машине может быть больше одного. А может быть 0, если на машину топкстартера никто не залогинен. Ответьте на этот вопрос, может быть просветление снизойдет на вас.
>Заодно поймёте, почему ваше утверждение "такие сервисы лучше обычных приложений, потому что работают штатные способы управления сервисами" является заблуждением.
Скучно.
blp>>Можно. Нужно будет просто переписать всю функциональность SCM, которая этом соотвествует (проверка того, что приложение уже запущено / еще запускается, зависимостей и т д)
S>Ну конечно же нет. Даже на этом сайте есть статья о том, как сделать так, чтобы было запущено не более 1го экземпляра приложения в пользовательской сессии.
Читаем внимательно: надо не просто сделать запуск одной копии приложения. Надо еще написать всю остальную функциональность, которая уже есть для сервисов. Например, запуск зависимых сервисов, перезапуск сервиса, если он внезапно завершился, правильная очередность остановки и т. д. — по сути вся функциональность SCM. Я понимаю, что в вашем уютном мире ничего, кроме запуска одной копии сервиса и его остановки, не нужно, но в реальном мире не так.
S>В том коде, который отвечает за старт приложения/сервиса, объём действий будет плюс-минус одинаковый.
S>Объём бойлерплейта, который нужно написать на стороне приложения для обработки ситуации "ой, экземпляр уже есть — дай-ка я лучше ему передам событие для обработки, а сам закроюсь", даже меньше, чем
Вы забыли, что таких "приложений" у нас много — получается что весь этот код нам теперь придется тащить в каждое приложение вместо того, чтобы держать его снаружи (как сейчас в SCM). Это создает проблемы с поддержкой и патчами — поэтому адекватные люди, дизайнящие ОС, так не делают.
>бойлерплейта для превращения приложения в сервис.
Добавьте туда еще то, что код per-user сервисов — это отрефактореный код существующих сервисов и драйверов (виндовые драйвера больше поохожи на виндовые сервисы в плане организации кода и интеграции с SCM). Ваше предложение предполагает взять существующие сервисы/драйвера и поменять их архитекутуру, сделав просто приложениями, да еще и впилить в каждое из них кусок логики SCMа для запуска/перезапуска. Улавливаете?
blp>>это какими? Как штатно остановить "просто приложение", которое не поддерживает интерфейс работы с SCM, чтобы оно успело корректно деинициализироваться и корректно остановить шатдаун системы/логофф пока оно это не сделает?
S>Если у приложения есть UI (а если его нету, то мы можем обойтись обычным сервисом, который бегает в winsta0), то как бы есть WM_CLOSE, WM_ENDSESSION
blp>>Как сделать так, чтобы на это мог/не мог повлиять юзер?
S>Вот я не буду ехидничать, а просто дам ссылку на MSDN: https://docs.microsoft.com/en-us/windows/win32/rstmgr/guidelines-for-applications
S>Если вам что-то непонятно, то спрашивайте.
Мне как раз все понятно. Это опять эффект Даннинга-Крюгера.
Когда сервис останавливается, он может заблокировать shtdown/logoff на время, которое он определяет сам. В этом случае юзер на экране видит спиннер и ждет — может ждать минуту или две, пока, например, данные на диск не запишутся устройство не размонтируется. Ничего подобного для приложений просто нет и никогда не было. Если приложение блокирует shutdown/logoff об этом уведомляют юзера и предлагаю юзеру пойти разобраться, что там приложению надо (это еще и не всегда работает) и продолжить shutdown/logoff. С сервисами, над которымы юзеру давать контроль нельзя, такой фокус не работает. Это одно из отличий сервисов от приложений.
читаю МСДН, дорого:
https://docs.microsoft.com/en-us/windows/win32/api/winsvc/ns-winsvc-service_preshutdown_info
https://docs.microsoft.com/en-us/previous-versions/windows/desktop/ms700677(v=vs.85)
in a critical shutdown, where the user has clicked the Shut down now button in the new Windows UI and applications will no longer be allowed to block shutdown
Best Practices for Handling Shutdown in Windows Vista
...
Applications should not block shutdown
>Я не суперэксперт по виндовой разработке, (я сервис в последний раз писал году наверное в 2003), и пникаких супер-возможностей, которые специфичны именно для сервиса по взаимодействию с шатдауном/рестартом не припомню.
Ну вот, еще один. Писал что-то там 17 лет назад, не помнит специфики, следовательно ее нет. Скучно.
blp>>Не единственное. Мой список был "навскидку", на самом деле он больше, но и того, что я привел, хватит с головой.
>Не убедили.
Печально. А вроде выглядели адекватно.
S>Ну как же недокументированные-то? Вот же они задокументированы: https://docs.microsoft.com/en-us/windows/application-management/per-user-services-in-windows
еще раз — недокументированы новые типы сервисов, как их например самому писать. Тупо эти константы, которые передаются в CreateService в MSDN не описаны. Сами сервисы, что они делают — документированы. Чтобы адекватные люди могли понять, что это за сервисы и как себя ведут.
sc create X_Test binPath= "..." type= userown obj= X
sc qc TrustedInstaller_Test
[SC] QueryServiceConfig SUCCESS
SERVICE_NAME: X_Test
TYPE : 50 USER_OWN_PROCESS TEMPLATE
...
blp>>шаблоны сервисов не существовали ранее — с ними, очевидно, не может работать никакой существующий инструмент.
S>Очевидно, что "нормальный" порядок релизов — это допилить существующие инструменты для того, чтобы управлять вот этой кунсткамерой.
Существующие инструменты прекрасно управляют тем, что есть и вписывается в набор сущностей, которыми они управляют. Я же сказал — отсутсвие красивого красивого GUI для темплейтов серивсов никак не относится к инструментам работы с самими сервисами. Сервисы (не темплейты) так же можно, например, запускать и останавливать, зная их имя. Можно получать список имен сервисов и т. д.
> покажите мне скрипт, который рестартит сервис WpnUserService на машине топикстартера.
Какой именно из "сервис WpnUserService на машине топикстартера"? Их на машине может быть больше одного. А может быть 0, если на машину топкстартера никто не залогинен. Ответьте на этот вопрос, может быть просветление снизойдет на вас.
>Заодно поймёте, почему ваше утверждение "такие сервисы лучше обычных приложений, потому что работают штатные способы управления сервисами" является заблуждением.
Скучно.