>>И тогда его установка приводила к тому что гуй сервиса действительно был интерактивен. Потом его сломали сервисы оказались на отдельной сессии, но подкостылили мониторингом созданмя видимых top-level окон к той сессии.
blp>Спешное гугление и чтение МСДНа. Лучше поздно, чем никогда.
Безосновательные инсенуации.

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

O>>>>Теперь сделали сервисы, привязынне к юзерской сессии. Зачем, если уже есть юзерские процессы? Чем это лучше?
blp>>>Да, действительно, зачем? Вы уже второй раз спрашиваете, сами ответить на можете, но сразу делаете вывод, чем если вам неизвестно, зачем, те, кто это сделали — идиоты.
O>>Потому что для решения их задачи был уже и не один способ помимо того чтоб сломать изначальную архитектуру.
blp>"Зачем", а не "почему". Вы не ответили пока на этот вопрос.
Я ответил. Неквалифицированные разработчики, привыкшие делать по быстрому и через жопу, и считающие что так и должно быть. Имеющегося функционала хватало на решение любой задачи. Если обладаете тайными знания — расскажите. А я расскажу как можно было это сделать не через жопу.

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

blp>>Подумайте еще немного, может быть до вас дойдет, зачем же все-таки нужна это функциональность, которую сломали, почему ее сломали и кто и зачем ее сломал.
O>Почему сломали и зачем сломали прекрасно было понятно сразу в момент сломания. Впрочем, его даже и не сломали, флаг этот продолжал работать, просто этого было не видно с первого взгляда.
Ну расскажите, поделитесь, что же вам было понятно. Флаг не работает (ну или "не так работает") начиная с Висты.

O>>>>>Теперь сделали сервисы, привязынне к юзерской сессии. Зачем, если уже есть юзерские процессы? Чем это лучше?
blp>>>>Да, действительно, зачем? Вы уже второй раз спрашиваете, сами ответить на можете, но сразу делаете вывод, чем если вам неизвестно, зачем, те, кто это сделали — идиоты.
O>>>Потому что для решения их задачи был уже и не один способ помимо того чтоб сломать изначальную архитектуру.
blp>>"Зачем", а не "почему". Вы не ответили пока на этот вопрос.
O>Я ответил. Неквалифицированные разработчики, привыкшие делать по быстрому и через жопу, и считающие что так и должно быть. Имеющегося функционала хватало на решение любой задачи. Если обладаете тайными знания — расскажите. А я расскажу как можно было это сделать не через жопу.
Ну я ж и говорю — типичный эффект Даннинга-Крюгера. Вы-то лучше всех знаете, как можно было сделать. И в вашем уютном мирке разницы между автораном и сервисами, запускаемыми в контексте юзерской сессии, нету, потому что вы ее не видите. А то, чего вы не видите, очевидно, не существует.

O>>Почему сломали и зачем сломали прекрасно было понятно сразу в момент сломания. Впрочем, его даже и не сломали, флаг этот продолжал работать, просто этого было не видно с первого взгляда.
blp>Ну расскажите, поделитесь, что же вам было понятно. Флаг не работает (ну или "не так работает") начиная с Висты.
Я дал достаточно информации чтобы тот кто знает про то как этот флаг не работает понял что я это тоже знаю. Если вы этого не поняли — значит вы тоже неквалифицированный разработчик. Ну или не разработчик вовсе — читать ваши сообщения на кывте влом. Но я дам вам второй шанс: на самом деле он "не так работает" гораздо раньше — начиная с 2000й винды так точно. Просто начиная с висты это стало видно по умолчанию.

O>>Я ответил. Неквалифицированные разработчики, привыкшие делать по быстрому и через жопу, и считающие что так и должно быть. Имеющегося функционала хватало на решение любой задачи. Если обладаете тайными знания — расскажите. А я расскажу как можно было это сделать не через жопу.
blp>Ну я ж и говорю — типичный эффект Даннинга-Крюгера. Вы-то лучше всех знаете, как можно было сделать. И в вашем уютном мирке разницы между автораном и сервисами, запускаемыми в контексте юзерской сессии, нету, потому что вы ее не видите. А то, чего вы не видите, очевидно, не существует.
Ну то есть технической информацией и пониманием сути проблемы вы не располагаете, предпочитая тонкий, как вам кажется, троллинг. Просто еще одно подтверждение вашей неквалифицированности.

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

O>>>Почему сломали и зачем сломали прекрасно было понятно сразу в момент сломания. Впрочем, его даже и не сломали, флаг этот продолжал работать, просто этого было не видно с первого взгляда.
blp>>Ну расскажите, поделитесь, что же вам было понятно. Флаг не работает (ну или "не так работает") начиная с Висты.
O>Я дал достаточно информации чтобы тот кто знает про то как этот флаг не работает понял что я это тоже знаю.
К сожалению, понять, что именно вы знаете, а что спешно нагуглили, ни по каким приведенным вам ответам нельзя. Так что особо не старайтесь.

> Если вы этого не поняли — значит вы тоже неквалифицированный разработчик.
Нет, я просто не могу поверить вам наслово, когда вы бьете себя пяткой в грудь и говорите про то, что знали про что-то 20 лет назад. Может, и правда знали, но забыли. Или знали, но не понимали нормально.

blp>>Ну я ж и говорю — типичный эффект Даннинга-Крюгера. Вы-то лучше всех знаете, как можно было сделать. И в вашем уютном мирке разницы между автораном и сервисами, запускаемыми в контексте юзерской сессии, нету, потому что вы ее не видите. А то, чего вы не видите, очевидно, не существует.
O>Ну то есть технической информацией и пониманием сути проблемы вы не располагаете
Почему не располагаю, вполне располагаю. Вот, ссылку на msdn дал для тех, кто не знал, что это за процессы. Вдумчивое чтение содержимого этой ссылки иногда приводит к просветлению, но явно не у всех.

> предпочитая тонкий, как вам кажется, троллинг.
Обожемой, да какой тут троллинг? Разве ж это троллинг...

>Просто еще одно подтверждение вашей неквалифицированности.
Ужас, буду страдать.

O>>Ну то есть технической информацией и пониманием сути проблемы вы не располагаете
blp>Почему не располагаю, вполне располагаю. Вот, ссылку на msdn дал для тех, кто не знал, что это за процессы. Вдумчивое чтение содержимого этой ссылки иногда приводит к просветлению, но явно не у всех.
В ссылке и в сервисах нет никакого ноухау. Упоминание SERVICE_INTERACTIVE_PROCESS позволяет мне предположить, что вы считаете "неинтерактивность" некоей особой привилегией сервисов, недоступной обычным процессам, но нет. SERVICE_INTERACTIVE_PROCESS просто говорит о том что процесс сервиса должен запускаться на оконной станции WinSta0, если его нет — он запускается на WinStationService-блаблабла. Так вот, _любой_ процесс может создать оконную станцию и работать в ней, вызвав SetProcessWindowStation. И стать таким же неинтерактивным как юзермодный-сервис-без-флага-SERVICE_INTERACTIVE_PROCESS.

>> предпочитая тонкий, как вам кажется, троллинг.
blp>Обожемой, да какой тут троллинг? Разве ж это троллинг...
Обычный грубый троллинг. Вот 20 лет назад в я IRC примерно так же троллил, да, правда термина тогда такого еще не было :

blp>К сожалению, понять, что именно вы знаете, а что спешно нагуглили, ни по каким приведенным вам ответам нельзя. Так что особо не старайтесь.
blp>Нет, я просто не могу поверить вам наслово, когда вы бьете себя пяткой в грудь и говорите про то, что знали про что-то 20 лет назад. Может, и правда знали, но забыли. Или знали, но не понимали нормально.

>>Просто еще одно подтверждение вашей неквалифицированности.
blp>Ужас, буду страдать.
Нет, не будете. По крайнер мере, не сейчас.

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

O>>>Ну то есть технической информацией и пониманием сути проблемы вы не располагаете
blp>>Почему не располагаю, вполне располагаю. Вот, ссылку на msdn дал для тех, кто не знал, что это за процессы. Вдумчивое чтение содержимого этой ссылки иногда приводит к просветлению, но явно не у всех.
O>В ссылке и в сервисах нет никакого ноухау. Упоминание SERVICE_INTERACTIVE_PROCESS позволяет мне предположить, что вы считаете "неинтерактивность" некоей особой привилегией сервисов, недоступной обычным процессам, но нет.
Я его упоминал в контексте "много чего еще" как реакцию на ваще сообщение про виндовые сервисы.

отличие сервисов в том, что они не привязаные к юзерской сессии. Это их суть, смысл их создания.

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

>>> предпочитая тонкий, как вам кажется, троллинг.
blp>>Обожемой, да какой тут троллинг? Разве ж это троллинг...
O>Обычный грубый троллинг.
Ну ладно, раз обычный и грубый, пусть будет троллинг.

>>>Просто еще одно подтверждение вашей неквалифицированности.
blp>>Ужас, буду страдать.
O>Нет, не будете. По крайнер мере, не сейчас.
Вот блин, и тут засада.

blp>отличие сервисов в том, что они не привязаные к юзерской сессии. Это их суть, смысл их создания.
blp>Я говорил, что человек, делающий заявление такого космического масштаба
Это не космический масштаб, это достаточно очевидная вещь.

blp>и такой космической же глупости, много про чего не в курсе.
Грубо.

blp>Вы прицепились к этому флагу и к интерактивности, но есть много чего еще, что отличает виндовые сервисы от обычных приложений.
Это вы первый прицепились к этому флагу. Я лишь объяснил что в нем нет ничего особенного. Как и в остальных особенностях сервисов. Я (будучи архитектором) разрабатывал систему user mode application virtualization которая в том числе умела запускать сервисы как процессы, эмулируя весь SCM API. Но да, это было задолго до десятки.

blp>И ряд этих вещей очень важен и влияет на то, почему не был выбран ваш наивный вариант решения "давайте просто запихнем системный код в авторан из-под юзерского аккаунта".
Я ж говорю — в тиме unistack не нашлось того кто знал как сделать в рамках своей задачи. Попросили core-team придумать чтонить этакое. Там не нашлось того что мог бы реализовать адекватным решением, добавив в таскшедулер чего им там хотелось или еще что. Сделали костыль, с сервисами с рандомно генеренными именами.

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

blp>>отличие сервисов в том, что они не привязаные к юзерской сессии. Это их суть, смысл их создания.
blp>>Я говорил, что человек, делающий заявление такого космического масштаба
O>Это не космический масштаб, это достаточно очевидная вещь.
Да я не спорю, в котексте ограниченных знаний она явно очевидна. Ссылку на статью в википедии про механизм этого эффекта я уже приводил.

blp>>Вы прицепились к этому флагу и к интерактивности, но есть много чего еще, что отличает виндовые сервисы от обычных приложений.
O>Это вы первый прицепились к этому флагу.
Я его привел для прмиера того, что не вписывается в наивную картину. Прицепились к нему вы.
>Я лишь объяснил что в нем нет ничего особенного. Как и в остальных особенностях сервисов.
Нету ничего особенного, да. Просто особенности есть. И когда в особенностях детально разбираешься, становится понятно, почему нельзя взять и запихать сервисы в авторан. А так — да, ничего особенного.

>Я (будучи архитектором) разрабатывал систему user mode application virtualization которая в том числе умела запускать сервисы как процессы, эмулируя весь SCM API. Но да, это было задолго до десятки.
Во-во. Эмуляция SCM API. Для виртуализации чего-то там, что в ряде случаев внезапно почему-то работает не так, когда виртуализируется. Впрочем по ответам было какбэ понятно.

blp>>И ряд этих вещей очень важен и влияет на то, почему не был выбран ваш наивный вариант решения "давайте просто запихнем системный код в авторан из-под юзерского аккаунта".
O>Я ж говорю — в тиме unistack не нашлось того кто знал как сделать в рамках своей задачи. Попросили core-team придумать чтонить этакое. Там не нашлось того что мог бы реализовать адекватным решением, добавив в таскшедулер чего им там хотелось или еще что. Сделали костыль, с сервисами с рандомно генеренными именами.
А, я понял. У вас LUID в качестве части видимого имени сервиса вызывает такие эмоции. Ну бывает, чо.

blp>>>И ряд этих вещей очень важен и влияет на то, почему не был выбран ваш наивный вариант решения "давайте просто запихнем системный код в авторан из-под юзерского аккаунта".
O>>Я ж говорю — в тиме unistack не нашлось того кто знал как сделать в рамках своей задачи. Попросили core-team придумать чтонить этакое. Там не нашлось того что мог бы реализовать адекватным решением, добавив в таскшедулер чего им там хотелось или еще что. Сделали костыль, с сервисами с рандомно генеренными именами.
blp>А, я понял. У вас LUID в качестве части видимого имени сервиса вызывает такие эмоции.
Само решение сделать вид сервисов, привязанных к юзерской сессии — стратегический косяк, впрочем далеко не первый в винде. А UID в имени — это тактический косяк. То есть неквалифицированные архитекты решение придумали, неквалифицированные сеньеры его реализовали. Таких комплексных косяков сложно припомнить, — обычно или задумка хреновая а реализация ок, или наоборот. Хотя я уже свалили в линухи, и не в теме новейших достижений виндостроителей. Грустно все это, за державу винду обидно. Впрочем тому тоже есть причины. Микрософту винда не нужна, но это тема уже совершенно иного срача.

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

blp>>А, я понял. У вас LUID в качестве части видимого имени сервиса вызывает такие эмоции.
O>Само решение сделать вид сервисов, привязанных к юзерской сессии — стратегический косяк
эх. Что в лоб, что по лбу.

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

>Хотя я уже свалили в линухи, и не в теме новейших достижений виндостроителей.
А, ну вот с этого и надо было начинать.

>Микрософту винда не нужна, но это тема уже совершенно иного срача.
В целом, Микрософту не нужен этот багаж liability по поддержанию совместимости с кодом и процессами, написанным 20 лет назад (и как следствие — адски сложная архитектура чего угодно внутри винды), и он стремительно от него избавляется. Но деньги МСу платят в том числе и за эту совместимость.

>>. То есть неквалифицированные архитекты решение придумали, неквалифицированные сеньеры его реализовали. Таких комплексных косяков сложно припомнить, — обычно или задумка хреновая а реализация ок, или наоборот.
blp>Комплексные косяки МСа — это фичи, например, Висты, которые дизайнились идиотами, не работали и потом были выпилены и задепрекейчены, а их архитекторы — задемоучены или совсем убраны из компании. То, что вы видите — это как раз работающая реализация чего-то, что требовало обратной совместимости и не должно было разломать существующие админские процессы.
Дада, 'оно работает', а больше ничего и не нужно, да?

>>Хотя я уже свалили в линухи, и не в теме новейших достижений виндостроителей.
blp>А, ну вот с этого и надо было начинать.
Вот в линухе как раз такого полно. Там все так пишут. В винде лучше. Было. Теперь, наверное, линуксоидов набрали на работу.

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

>>>. То есть неквалифицированные архитекты решение придумали, неквалифицированные сеньеры его реализовали. Таких комплексных косяков сложно припомнить, — обычно или задумка хреновая а реализация ок, или наоборот.
blp>>Комплексные косяки МСа — это фичи, например, Висты, которые дизайнились идиотами, не работали и потом были выпилены и задепрекейчены, а их архитекторы — задемоучены или совсем убраны из компании. То, что вы видите — это как раз работающая реализация чего-то, что требовало обратной совместимости и не должно было разломать существующие админские процессы.
O>Дада, 'оно работает', а больше ничего и не нужно, да?
Оно не просто работает, оно работает на миллионах сценариев, о существовании которых среднестатистиеский красноглазик-линуксоид, ничего кроме веб-серверов в жизни не видевший, и не подозраевает.

>>>Хотя я уже свалили в линухи, и не в теме новейших достижений виндостроителей.
blp>>А, ну вот с этого и надо было начинать.
O>Вот в линухе как раз такого полно. Там все так пишут.
В линухе всего полно.

>В винде лучше. Было. Теперь, наверное, линуксоидов набрали на работу.
В винде по-другому. Я не сказал бы, что "лучше" применимо. Это как сравнивать что лучше — БТР или Мерседес.

Здравствуйте, blp, Вы писали:
>>Я лишь объяснил что в нем нет ничего особенного. Как и в остальных особенностях сервисов.
blp>Нету ничего особенного, да. Просто особенности есть. И когда в особенностях детально разбираешься, становится понятно, почему нельзя взять и запихать сервисы в авторан. А так — да, ничего особенного.
Ну вот если вы разобрались, то напишите простым языком прямо сюда результаты ваших разборок. Ваши намёки на то, что вы знаете больше, чем собеседник, выглядят плохо.
Лучший способ бравировать знаниями — демонстрировать их. Худший — тот, что вы демонстрируете.

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

S>Ну вот если вы разобрались, то напишите простым языком прямо сюда результаты ваших разборок.
С моей точки зрения, писать очевидные после прочтения МСДН вещи довольно скучно (хотя можно).
Особенно скучно писать их людям, которые верут себя так, будто они и так лучше знают, как что нужно дизайнить.

> Ваши намёки на то, что вы знаете больше, чем собеседник, выглядят плохо.
Возможно. Собеседники сходу встающие в позу "ну посмотрите, какие криворукие это дизайнили и имплементили", выглядят по-моему, хуже.

Навскидку, некоторые отличия сервисов от "приложений из авторана" или "тасков"

1. Сервис можно создать в режиме запуска "manual" и он будет запущен не сразу, когда юзер залогинится, а после какого-то определяемого системой сбытия (например, подключение нового BT-устрйоства)
2. Сервис можно остановить/приостановить и перезапустить штатными средствами через API / GUI / sc.exe
3. Сервису можно послат сигнал штатными средствами.
4. Между сервисами возможно устанавливать зависимости (например, нельзя будет остановить сервис, пока зависящий от нео сервис не остановлен)

заметьте, ничего из того, что выше написано, не является тайными знаниями, которыми обладаю лично я которые нельзя прочитать в МСДН в разделе "сервисы".

blp>1. Сервис можно создать в режиме запуска "manual" и он будет запущен не сразу, когда юзер залогинится, а после какого-то определяемого системой сбытия (например, подключение нового BT-устрйоства)
Обычный процесс тоже можно не прописывать в авторан (любым из указанных ранее способов)

blp>2. Сервис можно остановить/приостановить и перезапустить штатными средствами через API / GUI / sc.exe
blp>3. Сервису можно послат сигнал штатными средствами.
blp>4. Между сервисами возможно устанавливать зависимости (например, нельзя будет остановить сервис, пока зависящий от нео сервис не остановлен)
Ага ага на скрине корневой мессаги очень хорошо видно как эти штатные средства работают с данными сервисами

Причем это документировано, конечно же:

You can't manage all of the per-user service templates services using normal Group Policy management methods. Because the per-user services aren't displayed in the Services management console, they're also not displayed in the Group Policy Services policy editor UI.

Как вы там

Автор: blp
Дата: 15.01.20

писали: "оно работает на миллионах сценариев"
Или вот

Автор: blp
Дата: 15.01.20

: "не должно было разломать существующие админские процессы"
И это действительно, только исходя из чтения мсдн. Какие там еще есть незадокументированные косяки в реальности . Надеюсь хотябы поддержку COM/AppID=LocalService сделали нормальную, или оно тоже глючит? Это пожалуй единственное, что могло бы слегка оправдать существование этого костылепеда.

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

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

O>Причем это документировано, конечно же:
O>

You can't manage all of the per-user service templates services using normal Group Policy management methods. Because the per-user services aren't displayed in the Services management console, they're also not displayed in the Group Policy Services policy editor UI.

O>Как вы там

Автор: blp
Дата: 15.01.20

писали: "оно работает на миллионах сценариев"
O>Или вот

Автор: blp
Дата: 15.01.20

: "не должно было разломать существующие админские процессы"

Да, представьте себе — существующих админских процессов, связаных с этими сервисами, еще нет.
Зато есть другие существующие админские процессы, в которые таски из авторана не вписываются. Но откуда про это знать людям, которые, например, никогда не админили сеть, в которой было бы хотя бы несколько десятков тысяч виндовых машин в нескольких доменах.

Здравствуйте, blp, Вы писали:
blp>Навскидку, некоторые отличия сервисов от "приложений из авторана" или "тасков"
blp>1. Сервис можно создать в режиме запуска "manual" и он будет запущен не сразу, когда юзер залогинится, а после какого-то определяемого системой сбытия (например, подключение нового BT-устрйоства)
Не вижу причины, по которой нельзя просто запустить приложение после какого-то определяемого системой события.
blp>2. Сервис можно остановить/приостановить и перезапустить штатными средствами через API / GUI / sc.exe
Ну, так-то приложения тоже можно запускать и останавливать штатными средствами.
blp>3. Сервису можно послат сигнал штатными средствами.
Как, впрочем, и приложению.
blp>4. Между сервисами возможно устанавливать зависимости (например, нельзя будет остановить сервис, пока зависящий от нео сервис не остановлен)
Ну, вот это, похоже, единственное более-менее заметное функциональное отличие приложения от сервиса
blp>заметьте, ничего из того, что выше написано, не является тайными знаниями, которыми обладаю лично я которые нельзя прочитать в МСДН в разделе "сервисы".
Ну вот видите, три из четырёх "отличий" оказываются спорными. Достаточно ли этой единственной причины для того, чтобы оправдать разработку целой отдельной категории приложений?
(Причём всунутую настолько костыльно, насколько возможно. Что не является тайными знаниями, которые нельзя прочитать в МСДН — вам уже указали на то, что с шаблонами сервисов не работает ничего из существующих процессов, кроме прямой правки реестра.)
Или, может быть, есть ещё какая-то причина, о которой просто "забыли" упомянуть в MSDN?

Вот вам после прочтения MSDN очевидны какие-то вещи. Мне (и не мне одному) именно прочтение MSDN делает очевидным то, что это решение сделано впопыхах и абы как. При этом необходимость или хотя бы польза такого решения как раз не очевидна.

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

S>Здравствуйте, blp, Вы писали:
blp>>Навскидку, некоторые отличия сервисов от "приложений из авторана" или "тасков"
blp>>1. Сервис можно создать в режиме запуска "manual" и он будет запущен не сразу, когда юзер залогинится, а после какого-то определяемого системой сбытия (например, подключение нового BT-устрйоства)
S>Не вижу причины, по которой нельзя просто запустить приложение после какого-то определяемого системой события.
Можно. Нужно будет просто переписать всю функциональность SCM, которая этом соотвествует (проверка того, что приложение уже запущено / еще запускается, зависимостей и т д)

blp>>2. Сервис можно остановить/приостановить и перезапустить штатными средствами через API / GUI / sc.exe
S>Ну, так-то приложения тоже можно запускать и останавливать штатными средствами.
это какими? Как штатно остановить "просто приложение", которое не поддерживает интерфейс работы с SCM, чтобы оно успело корректно деинициализироваться и корректно остановить шатдаун системы/логофф пока оно это не сделает? Как сделать так, чтобы на это мог/не мог повлиять юзер?

blp>>4. Между сервисами возможно устанавливать зависимости (например, нельзя будет остановить сервис, пока зависящий от нео сервис не остановлен)
S>Ну, вот это, похоже, единственное более-менее заметное функциональное отличие приложения от сервиса
Не единственное. Мой список был "навскидку", на самом деле он больше, но и того, что я привел, хватит с головой.

S>Ну вот видите, три из четырёх "отличий" оказываются спорными.
это они вашей точки зрения спорные.

>Достаточно ли этой единственной причины для того, чтобы оправдать разработку целой отдельной категории приложений?
Нет, недостаточно. Причин больше, да и привиденные мной причины отметать не получится.

S>Или, может быть, есть ещё какая-то причина, о которой просто "забыли" упомянуть в MSDN?
забыли упомянуть что? Эти новые типы сервисов (USER_OWN_PROCESS / USER_SHARE_PROCESS TEMPLATE/INSTANCE — https://github.com/processhacker/processhacker/blob/master/phlib/svcsup.c) — они недокументированные. В виндах много чего недокументированного, что именно вас удивляет?

>с шаблонами сервисов не работает ничего из существующих процессов, кроме прямой правки реестра.
шаблоны сервисов не существовали ранее — с ними, очевидно, не может работать никакой существующий инструмент. Инстансы этих шаблонов — вполне себе сервисы и с ними инструменты работают, как написано в документации.
Если весь сыр-бор от того, что МС не сделал красивый гуй для редактирования шаблонов — то да, это конечно страшная трагедия и несоменено сигнализирует о кривизне чьих-то рук.

S>Вот вам после прочтения MSDN очевидны какие-то вещи. Мне (и не мне одному) именно прочтение MSDN делает очевидным то, что это решение сделано впопыхах и абы как. При этом необходимость или хотя бы польза такого решения как раз не очевидна.
Кому очевидна, кому не очень. Вы по крайней мере не кидаетесь делать заявления космического масштаба и космической же глупости, не разобравшись.

Здравствуйте, blp, Вы писали:
blp>Можно. Нужно будет просто переписать всю функциональность SCM, которая этом соотвествует (проверка того, что приложение уже запущено / еще запускается, зависимостей и т д)
Ну конечно же нет. Даже на этом сайте есть статья о том, как сделать так, чтобы было запущено не более 1го экземпляра приложения в пользовательской сессии.
В том коде, который отвечает за старт приложения/сервиса, объём действий будет плюс-минус одинаковый.
Объём бойлерплейта, который нужно написать на стороне приложения для обработки ситуации "ой, экземпляр уже есть — дай-ка я лучше ему передам событие для обработки, а сам закроюсь", даже меньше, чем бойлерплейта для превращения приложения в сервис.

S>>Ну, так-то приложения тоже можно запускать и останавливать штатными средствами.
blp>это какими? Как штатно остановить "просто приложение", которое не поддерживает интерфейс работы с SCM, чтобы оно успело корректно деинициализироваться и корректно остановить шатдаун системы/логофф пока оно это не сделает?
Если у приложения есть UI (а если его нету, то мы можем обойтись обычным сервисом, который бегает в winsta0), то как бы есть WM_CLOSE, WM_ENDSESSION
blp>Как сделать так, чтобы на это мог/не мог повлиять юзер?
Вот я не буду ехидничать, а просто дам ссылку на MSDN: https://docs.microsoft.com/en-us/windows/win32/rstmgr/guidelines-for-applications
Если вам что-то непонятно, то спрашивайте. Я не суперэксперт по виндовой разработке, (я сервис в последний раз писал году наверное в 2003), и пникаких супер-возможностей, которые специфичны именно для сервиса по взаимодействию с шатдауном/рестартом не припомню.
blp>Не единственное. Мой список был "навскидку", на самом деле он больше, но и того, что я привел, хватит с головой.
Не убедили.
S>>Ну вот видите, три из четырёх "отличий" оказываются спорными.
blp>это они вашей точки зрения спорные.
Отож. Пока что вы не рассказали ничего интересного. Возможность рестартнуть приложение через SCM сама по себе не очень интересна — либо я чего-то не понимаю.

blp>Нет, недостаточно. Причин больше, да и привиденные мной причины отметать не получится.
Пока что получается. Пишите больше причин.

blp>забыли упомянуть что?
Забыли упомянуть, зачем они вообще нужны.
blp>Эти новые типы сервисов (USER_OWN_PROCESS / USER_SHARE_PROCESS TEMPLATE/INSTANCE — https://github.com/processhacker/processhacker/blob/master/phlib/svcsup.c) — они недокументированные. В виндах много чего недокументированного, что именно вас удивляет?
Ну как же недокументированные-то? Вот же они задокументированы: https://docs.microsoft.com/en-us/windows/application-management/per-user-services-in-windows
Это же вы привели эту ссылку. Другое дело — что релизили их настолько поспешно, что документация представлена чисто номинально.

blp>шаблоны сервисов не существовали ранее — с ними, очевидно, не может работать никакой существующий инструмент.
Очевидно, что "нормальный" порядок релизов — это допилить существующие инструменты для того, чтобы управлять вот этой кунсткамерой. Почему-то когда релизили "обычные" сервисы, никто не говорил "есть простой способ послать сигнал сервису — простая программа в 140 строк на С++ сделает вам рестарт сервиса" или "поправьте реестр, если не хотите, чтобы сервис стартовал автоматически". Их поддерживает нахрен вся инфраструктура винды — от Group policy до Windows Installer и Task Manager. Ок, хрен с ним — не успели припилить нормальный гуй. Но что мешало хотя бы error message сделать нормальный при попытке сделать configure такому сервису? Нет же, просто отдадим The parameter is incorrect и пусть жертва гадает, что это за херня приехала по интернету.

А per-user services именно что и выглядят, как нашлёпка сбоку, которую не успели встроить в винду полноценно.
blp> Инстансы этих шаблонов — вполне себе сервисы и с ними инструменты работают, как написано в документации.
blp>Если весь сыр-бор от того, что МС не сделал красивый гуй для редактирования шаблонов — то да, это конечно страшная трагедия и несоменено сигнализирует о кривизне чьих-то рук.
Весь сыр-бор — из-за того, что банальная штука "сделать, чтобы сервис не стартовал при каждом логине", работает для всех сервисов, кроме вот этих новых. То есть даже с инстансом шаблона не выйдет работать как с обычным сервисом.
Далее — "обычные" сервисы можно программно идентифицировать по их короткому имени, как обычно и делается при скриптинге. У этих сервисов имена генерятся рандомно — покажите мне скрипт, который рестартит сервис WpnUserService на машине топикстартера. Заодно поймёте, почему ваше утверждение "такие сервисы лучше обычных приложений, потому что работают штатные способы управления сервисами" является заблуждением.

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

_>а воду из трубы например от непонятных добавок очищаю фильтром

Вы всё ещё кипятите?