Создание петли сообщений

[Daniloff]

Проблема такая: имеется пример сервиса из microsoft SDK. Это консольное приложение. Я добавляю в него функции создания окна и петлю сообщений. При запуске в режиме простого приложения окно создается и собщения принимает. При запуске в качестве службы (с одступом к десктопу) создается висячее окно, никаких собщений не получающее. И при запуске в качестве службы под правами пользователя вообще не создается окно, хотя процесс в памяти болтается. В чем может быть прикол?

[npak]

А ты точно уверен, что тебе нужен сервис с GUI?

Сколько я видел сервисов, которые позволяют себе вести диалоги с пользователем, они все построены по клиент-серверной архитектуре. То есть собственно сервис, без интерактивных фич (как ты сказал - болтается в памяти) и клиентское приложение, которое с сервисом взаимодействует через интерфейс (сокеты, COM/DCOM, rpc ...)

Более того, в MSDN написано, что элементы GUI в случае сервисов работать не должны.

Windows Service applications run in a different window station than the interactive station of the logged-on user. A window station is a secure object that contains a Clipboard, a set of global atoms, and a group of desktop objects. Because the station of the Windows service is not an interactive station, dialog boxes raised from within a Windows service application will not be seen and may cause your program to stop responding.

[Daniloff]

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

[npak]

Сделай через COM.  В пределах одной машины он не не пользуется сокетами.

[Dimka]

Сколь мне известно, сервисы вообще не имеют доступа к GUI (по крайней мере в NT-версиях Windows). Сервис работает вне зависимости от того, какой пользователь (и сколько пользователей для Server-версий) залогинено в систему. Прикладное приложение получает доступ к GUI только тогда, когда запущено от имени какого-либо зашедшего в систему пользователя, имеющего desktop и всё прочее, что ему полагается иметь. Сервис в общем случае не знает, с каким (и чьим) desktop-ом ему работать. Кроме того не гарантируется, что вообще какой-нибудь desktop будет иметься в данный момент в системе.

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

[Dimka]

О, npak уже это написал .

[Daniloff]

Сколь мне известно, сервисы вообще не имеют доступа к GUI (по крайней мере в NT-версиях Windows).

У сервиса есть атрибут - доступ к десктопу. Если он включен - сервис может себя проявлять на рабочем столе текущего  юзера... Если отключен - то не может. А мне не нужно ничего демонстрироваь. Достаточно скрытого окна - которому можно сообщение передать...

[npak]

посмотри вот здесь http://www.dotnet247.com/247reference/msgs/36/184244.aspx

[Serg79]

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

[Daniloff]

Serg79, а по каналу данные разве не UDP-сокетом передаются?

[Serg79]

Если Ты будешь открывать именнованный канал открытый для прослушивания на другой машине, то ты прав, будет использоваться UDP. Если же канал открыт для прослушивания на локальной машине, то используется проецируемый в память файл.
С таким же успехом твое приложение может запускать чужие консольные приложения и перенапровлять его потоки (stdio, stdout) в именнованный канал открытый тобой раннее, в этом случае даже консольное окно запускаемого приложения на экране не появляется. А твое приложение будет иметь возможность получать и отправлять данный дочерному процессу.

[Serg79]

Кстати, можешь также использовать проецируемый в памяти файл. То же выход.

[Daniloff]

Спасибо, не знал таких особенностей. Попробую воспользоваться каналом. Надеюсь, скорость обмена будет выше, чем при использовании обмена через файл.