Добрый день! Не думал что попаду в подобный тупик
Необходимо сделать так, чтобы приложение запускалось при входе пользователя в систему. Раньше я использовал ключик в реестре Windows\CurrentVersion\Run для запуска приложения, но потом начал наблюдать что у многих пользователей (видимо в зависимости от антивирусов) этот ключик то вытирался, то приложение не смотря на ключик не запускается. Решил изменить стиль запуска приложения, регистрирую службу под LocalSystem и смотрю сколько открыто десктопов и зарегистрирован ли мутекс приложения, если нет, то пускаю в Default десктопе свое приложение. Проблема в том, что службе для этого необходимо взаимодействие с рабочим столом, что оказывается новыми версиями виндоузами форсированно вычищается. Вопрос: как сделать надежный авторан приложения?

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

A>Добрый день! Не думал что попаду в подобный тупик
A>Необходимо сделать так, чтобы приложение запускалось при входе пользователя в систему. Раньше я использовал ключик в реестре Windows\CurrentVersion\Run для запуска приложения, но потом начал наблюдать что у многих пользователей (видимо в зависимости от антивирусов) этот ключик то вытирался, то приложение не смотря на ключик не запускается. Решил изменить стиль запуска приложения, регистрирую службу под LocalSystem и смотрю сколько открыто десктопов и зарегистрирован ли мутекс приложения, если нет, то пускаю в Default десктопе свое приложение. Проблема в том, что службе для этого необходимо взаимодействие с рабочим столом, что оказывается новыми версиями виндоузами форсированно вычищается. Вопрос: как сделать надежный авторан приложения?

Вирус пишем? Просто есть аксиома — если юзер НЕ хочет запуска любого приложения — приложение не запустится. Например — как вы можете заставить меня запускать вашу нетленку, да еще в авторане? Поэтому если цель топика раскрыть тему "как бороться с тупым юзверем", то никак. Юзверь всегда прав! Если он удалаяет что-то из CurrentVersion\Run — значит так надо. Насчет же

то приложение не смотря на ключик не запускается.

типа сомневаюсь. Если б это было системным являением такой бы хай стоял по всему И-нету, причем именно хай юзеров. Они же заинтересованы в автостартах...
Может просто конфликт идет с другим автостартником?

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

A>Вопрос: как сделать надежный авторан приложения?

Прекрасный способ — это записывать ярлык в Пуск-Программы-Автозагрузка.

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

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

A>>Добрый день! Не думал что попаду в подобный тупик
A>>Необходимо сделать так, чтобы приложение запускалось при входе пользователя в систему. Раньше я использовал ключик в реестре Windows\CurrentVersion\Run для запуска приложения, но потом начал наблюдать что у многих пользователей (видимо в зависимости от антивирусов) этот ключик то вытирался, то приложение не смотря на ключик не запускается. Решил изменить стиль запуска приложения, регистрирую службу под LocalSystem и смотрю сколько открыто десктопов и зарегистрирован ли мутекс приложения, если нет, то пускаю в Default десктопе свое приложение. Проблема в том, что службе для этого необходимо взаимодействие с рабочим столом, что оказывается новыми версиями виндоузами форсированно вычищается. Вопрос: как сделать надежный авторан приложения?

S>Вирус пишем? Просто есть аксиома — если юзер НЕ хочет запуска любого приложения — приложение не запустится. Например — как вы можете заставить меня запускать вашу нетленку, да еще в авторане? Поэтому если цель топика раскрыть тему "как бороться с тупым юзверем", то никак. Юзверь всегда прав! Если он удалаяет что-то из CurrentVersion\Run — значит так надо. Насчет же
S>

S>то приложение не смотря на ключик не запускается.

S>типа сомневаюсь. Если б это было системным являением такой бы хай стоял по всему И-нету, причем именно хай юзеров. Они же заинтересованы в автостартах...
S>Может просто конфликт идет с другим автостартником?

Не, приложение имеет полный администраторский доступ во время установки, и считаем что этого достаточно чтобы устроить автостарт программы.

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

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

A>>Вопрос: как сделать надежный авторан приложения?

LS>Прекрасный способ — это записывать ярлык в Пуск-Программы-Автозагрузка.

В принципе вариант, надо только сделать так, чтобы этот ярлык появлялся у всех пользователей.

arkhivania написав(ла):
> В принципе вариант, надо только сделать так, чтобы этот ярлык появлялся
> у всех пользователей.

Записать его в All Users? Что-то вроде "C:\Documents and Settings\All
Users\Start Menu\Programs\Startup"

Здравствуйте, Ромашка, Вы писали:

Р>Записать его в All Users? Что-то вроде "C:\Documents and Settings\All
Р>Users\Start Menu\Programs\Startup"

У меня оттуда тоже "пропадают" ярлыки

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

A>Проблема в том, что службе для этого необходимо взаимодействие с рабочим столом, что оказывается новыми версиями виндоузами форсированно вычищается.

Вот что сама МС предлагает для Висты:
http://msdn.microsoft.com/en-us/library/ms683502(VS.85).aspx

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

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

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

A>>Проблема в том, что службе для этого необходимо взаимодействие с рабочим столом, что оказывается новыми версиями виндоузами форсированно вычищается.

ВВ>Вот что сама МС предлагает для Висты:
ВВ>http://msdn.microsoft.com/en-us/library/ms683502(VS.85).aspx

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

так и пришлось сделать, правда пришлось поколдовать, так как сервис запускался в сессии 0, а десктопы в 1 и не так просто можно в висте сделать службу которая имеет доступ к десктопу, но получилось. Да, и в результате само приложение пользовательское тоже живет под LocalSystem эккаунтом.

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

A>так и пришлось сделать, правда пришлось поколдовать, так как сервис запускался в сессии 0, а десктопы в 1 и не так просто можно в висте сделать службу которая имеет доступ к десктопу, но получилось. Да, и в результате само приложение пользовательское тоже живет под LocalSystem эккаунтом.

А зачем создавать службу, которая имеет доступ к декстопу? Служба должна быть самой обычной неинтерактивной, раз флажок интерактивности все равно не работает. Просто данная служба после своего запуска — ну, допустим, проверив, что логон уже произошел — запускает другое приложение, опять-таки самое обычное десктопное, при этом сама никакого доступа к десктопу по-прежнему не имеет.
А потом используется это другое приложение как своего рода stdout, кидая в него нужную информацию через IPC канал.

Кстати, подобная архитектура всегда мне казалось более правильной, чем заставлять сервис делать что-то на десктопе — ну разве что кроме мессадж-боксов.

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

ВВ>Просто данная служба после своего запуска — ну, допустим, проверив, что логон уже произошел — запускает другое приложение, опять-таки самое обычное десктопное

вот для этого и надо иметь доступ к десктопу

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

A>вот для этого и надо иметь доступ к десктопу

Мне казалось, что из неинтерактивного сервиса можно создать интерактивный процесс, но, конечно, не совсем в лоб. Указываете юзер-токен и десктоп, какой-нибудь WinSta0\\Default, под которым он исполняется.
Вот, вроде, статья где что-то подобное и описываются + обходят UAC:
http://www.codeproject.com/KB/vista-security/SubvertingVistaUAC.aspx?display=Print

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

ВВ>Вот, вроде, статья где что-то подобное и описываются + обходят UAC:
ВВ>http://www.codeproject.com/KB/vista-security/SubvertingVistaUAC.aspx?display=Print

Пара слов по поводу статьи, если позволите.

Он ищет WinLogon с нужным ID сессии. А в следующем сервис паке ему имя поменяют и приехали. А то и просто доступ закроют. Да и просто время теряется на поиск. Всё прогрессивное человечество давно юзает маркер самого сервиса вкупе с SetTokenInformation.

DuplicateTokenEx — сомнительная надобность. Может на Висте что поменялось, но вряд-ли, а на предыдущих версиях ОС и без того у сервиса первичный маркер. Я вообще не припомню, чтобы OpenProcessToken когда-нибудь вернула не Primary Token. Ну может в каких-то специфичных случаях это и бывает, но только не для сервиса.

dwCreationFlags = NORMAL_PRIORITY_CLASS | CREATE_NEW_CONSOLE — Если NORMAL_PRIORITY_CLASS ёщё можно считать более-менее уместным, то зачем тут CREATE_NEW_CONSOLE, совершенно не понятно

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, Воронков Василий, Вы писали:

ВВ>>Вот, вроде, статья где что-то подобное и описываются + обходят UAC:
ВВ>>http://www.codeproject.com/KB/vista-security/SubvertingVistaUAC.aspx?display=Print

А>Пара слов по поводу статьи, если позволите.

А>Он ищет WinLogon с нужным ID сессии. А в следующем сервис паке ему имя поменяют и приехали. А то и просто доступ закроют. Да и просто время теряется на поиск. Всё прогрессивное человечество давно юзает маркер самого сервиса вкупе с SetTokenInformation.

А>DuplicateTokenEx — сомнительная надобность. Может на Висте что поменялось, но вряд-ли, а на предыдущих версиях ОС и без того у сервиса первичный маркер. Я вообще не припомню, чтобы OpenProcessToken когда-нибудь вернула не Primary Token. Ну может в каких-то специфичных случаях это и бывает, но только не для сервиса.

А>dwCreationFlags = NORMAL_PRIORITY_CLASS | CREATE_NEW_CONSOLE — Если NORMAL_PRIORITY_CLASS ёщё можно считать более-менее уместным, то зачем тут CREATE_NEW_CONSOLE, совершенно не понятно

Я использовал методы из статьи, проверил на 28 компутерах (WinXP и Vista). Удинственное что, вместо WTSGetActiveConsoleSessionId использовал енумерацию активных сессий. Всё пока работает хорошо (когда будет около 40 компутеров скажу что очень хорошо).

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

A>Здравствуйте, Аноним, Вы писали:

А>>Здравствуйте, Воронков Василий, Вы писали:

A>Я использовал методы из статьи, проверил на 28 компутерах (WinXP и Vista). Удинственное что, вместо WTSGetActiveConsoleSessionId использовал енумерацию активных сессий. Всё пока работает хорошо (когда будет около 40 компутеров скажу что очень хорошо).

Дак ведь я и не говорил, что оно не будет работать Часто одно и то-же можно получить несколькими разными путями, но не все они одинаково оптимальны. Посто он выполняет пару ненужных действий, которые немного замедляют работу и одно из них потенциально может в будущем с небольшой вероятностью привести к проблемам, только и всего. Изложенный мной сценарий тоже проверен, и не только мной. А по поводу перечисления сессий вместо WTSGetActiveConsoleSessionId — деталь вообще-то несущественная

Впрочем, вопрос отношения к оптимизации каждый решает для себя сам.