Необходимо выводить из сервиса диалоговые окна на видимый в данный момент десктоп, в том числе — на Winlogon. Поиск по многочисленным форумам не дал результатов. Сталкивался с мнением о том, что это вообще невозможно. Тем не менее, существует программка Outpost Firewall, которая каждый день демонстрирует обратное. Скриншот прилагается. (Более того, при переключении десктопов окно красиво переходит на ставший видимым в данный момент десктоп.) Мне же на десктоп Winlogon удается вывести только MessageBox, а это меня не устраивает. Быть может, кто-то знает, как решить проблему и поделится мыслями по этому поводу?
Здравствуйте, Adm, Вы писали:
Adm>Необходимо выводить из сервиса диалоговые окна на видимый в данный момент десктоп, в том числе — на Winlogon. Поиск по многочисленным форумам не дал результатов. Сталкивался с мнением о том, что это вообще невозможно. Тем не менее, существует программка Outpost Firewall, которая каждый день демонстрирует обратное. Скриншот прилагается. (Более того, при переключении десктопов окно красиво переходит на ставший видимым в данный момент десктоп.) Мне же на десктоп Winlogon удается вывести только MessageBox, а это меня не устраивает. Быть может, кто-то знает, как решить проблему и поделится мыслями по этому поводу?
Ну выводить окна вместе с окнами винлогона не проблема. Просто делаешь SetThreadDesktop и творишь с окнами чего душа пожелает.
А вот переносить окно с одного десктопа на другой вроде не положено. Тут либо хакерством нужно заниматься, либо просто схитрить. Можно, например, на всех доступных десктопах создать окно, отлавливать пользовательские манипуляции на активном десктопе и эмулировать их на всех остальных.
Здравствуйте, Demon, Вы писали:
D>Здравствуйте, Adm, Вы писали:
Adm>>Необходимо выводить из сервиса диалоговые окна на видимый в данный момент десктоп, в том числе — на Winlogon. Поиск по многочисленным форумам не дал результатов. Сталкивался с мнением о том, что это вообще невозможно. Тем не менее, существует программка Outpost Firewall, которая каждый день демонстрирует обратное. Скриншот прилагается. (Более того, при переключении десктопов окно красиво переходит на ставший видимым в данный момент десктоп.) Мне же на десктоп Winlogon удается вывести только MessageBox, а это меня не устраивает. Быть может, кто-то знает, как решить проблему и поделится мыслями по этому поводу?
D>Ну выводить окна вместе с окнами винлогона не проблема. Просто делаешь SetThreadDesktop и творишь с окнами чего душа пожелает. D>А вот переносить окно с одного десктопа на другой вроде не положено. Тут либо хакерством нужно заниматься, либо просто схитрить. Можно, например, на всех доступных десктопах создать окно, отлавливать пользовательские манипуляции на активном десктопе и эмулировать их на всех остальных.
Спасибо. Получается выводить окно на видимый десктоп из Thread. Хотелось бы вывести на Winlogon диалог, который откомпилирован как exe. При создании формы наблюдается следующая ситуация: если сервис неинтерактивный, OpenInputDesktop возвращает ошибку 1(Неверная функция), в случае интерактивного сервиса OpenInputDesktop проходит нормально, но SetThreadDesktop возвращает ошибку 170(Требуемый ресурс занят). Процесс запускается функцией CreateProcessAsUser с токеном сервисного процесса.
Здравствуйте, Adm, Вы писали:
Adm>Спасибо. Получается выводить окно на видимый десктоп из Thread. Хотелось бы вывести на Winlogon диалог, который откомпилирован как exe. При создании формы наблюдается следующая ситуация: если сервис неинтерактивный, OpenInputDesktop возвращает ошибку 1(Неверная функция),
Нормально, неинтерактивные сервисы запускаются на WindowsStation, которая вообще не имеет десктопа.
Adm>в случае интерактивного сервиса OpenInputDesktop проходит нормально, но SetThreadDesktop возвращает ошибку 170(Требуемый ресурс занят). Процесс запускается функцией CreateProcessAsUser с токеном сервисного процесса.
Хз, у меня вот так работает. Правда напрямую из сервиса.
Здравствуйте, Adm, Вы писали:
Adm>в случае интерактивного сервиса OpenInputDesktop проходит нормально, но SetThreadDesktop возвращает ошибку 170(Требуемый ресурс занят). Процесс запускается функцией CreateProcessAsUser с токеном сервисного процесса.
А ты случаем до этого не успел какое-нить окошко создать?
Здравствуйте, Demon, Вы писали:
D>Здравствуйте, Adm, Вы писали:
Adm>>в случае интерактивного сервиса OpenInputDesktop проходит нормально, но SetThreadDesktop возвращает ошибку 170(Требуемый ресурс занят). Процесс запускается функцией CreateProcessAsUser с токеном сервисного процесса. D>А ты случаем до этого не успел какое-нить окошко создать?
Есть оконное приложение, созданное в CBuilder. Перед созданием главной формы устанавливаем нужный десктоп для вывода. Тестовый сервис каждые 15 сек. запускает процесс приложения. При смене пользователя(выход на Desktop Winlogon, Fast User Switching) окно продолжает появляться на десктопе Default.
Сообщений об ошибках при этом нет.
Н-да. Снова стала стабильно проявляться ошибка SetThreadDesktop 170(Требуемый ресурс занят). После многочисленных экспериментов уже трудно упомнить, что такого сделал. Как мне подсказали выше, SetThreadDesktop срабатывает только в том случае, если до этого в потоке не было выведено ни одного окна. После этого смена десктопа для данного потока становится невозможной. Не создает ли класс Application в CBuilder какого-нибудь невидимого окна, которое появляется до создания главной формы? Впрочем, с приложением Visual C++ (MFC Application, Dialog-based) та же история. И тут тоже какое-нибудь "раннее" окно? Если да, то вопрос такой: можно ли создать полноценный диалог, чтобы сохранить его каким-то образом для дальнейшего вызова из потока в сервисе(в dll какой-нибудь или в ресурсе), и как правильно это сделать? Или дело в чем-то совсем другом? Буду благодарен за помощь.
Здравствуйте, Adm, Вы писали:
Adm>Н-да. Снова стала стабильно проявляться ошибка SetThreadDesktop 170(Требуемый ресурс занят). После многочисленных экспериментов уже трудно упомнить, что такого сделал. Как мне подсказали выше, SetThreadDesktop срабатывает только в том случае, если до этого в потоке не было выведено ни одного окна. После этого смена десктопа для данного потока становится невозможной. Не создает ли класс Application в CBuilder какого-нибудь невидимого окна, которое появляется до создания главной формы? Впрочем, с приложением Visual C++ (MFC Application, Dialog-based) та же история. И тут тоже какое-нибудь "раннее" окно? Если да, то вопрос такой: можно ли создать полноценный диалог, чтобы сохранить его каким-то образом для дальнейшего вызова из потока в сервисе(в dll какой-нибудь или в ресурсе), и как правильно это сделать? Или дело в чем-то совсем другом? Буду благодарен за помощь.
В Builder создается точно. TApplication на Create создает окно.
Остальные окна в потоке посмотрите через EnumThreadWindows
Re[7]: Service, Winlogon и диалоговые окна
От:
Аноним
Дата:
17.08.06 14:59
Оценка:
Здравствуйте, Danchik, Вы писали:
D>В Builder создается точно. TApplication на Create создает окно. D>Остальные окна в потоке посмотрите через EnumThreadWindows
Спасибо. Проверю наличие "раннего" окна и для MFC-ного приложения.
А, все же, может кто-нибудь подсказать, как лучше создать и сохранить диалог, чтобы потом вызывать его из других процессов?
Здравствуйте, Adm, Вы писали:
Adm>Необходимо выводить из сервиса диалоговые окна на видимый в данный момент десктоп, в том числе — на Winlogon. Поиск по многочисленным форумам не дал результатов. Сталкивался с мнением о том, что это вообще невозможно. Тем не менее, существует программка Outpost Firewall, которая каждый день демонстрирует обратное. Скриншот прилагается. (Более того, при переключении десктопов окно красиво переходит на ставший видимым в данный момент десктоп.) Мне же на десктоп Winlogon удается вывести только MessageBox, а это меня не устраивает. Быть может, кто-то знает, как решить проблему и поделится мыслями по этому поводу?[/url]
Во-первых, Microsoft очень не рекомендует создавать в сервисе GUI-объекты по соображениями безопасности: есть много способов атаковать программу, принимающую Windows messages, а поскольку сервис обычно выполняется с бОльшими правами доступа, чем рядовой пользователь, то это открывает путь к атаке системы. Поищи в MSDN, там написано об этом. Недаром MS запретил интерактивные сервисы в Висте. MS рекомендует в этом случае создать процесс с правами текущего пользователя и работающий на текущем десктопе, и уже в нем все делать. Варианты создания такого процесса см., например здесь (где-то я всречал и более простые примеры).
Что же касается перехода окна на другой десктоп, то, может быть, просто нужно создать новое окно (из нового процесса, если делать как выше говорится), и аккуратненько привести его в состояние старого?