Программирование служб Windows на Delphi

← →
Леонид Федьков (2006-08-14 14:47) [0]

Уважаемые знатоки!
Подскажите, если кто занимался:
1. Где можно посмотреть
программирование служб Windows на Delphi с примерами?
Может у вас есть пример?
2. Есть приложение с формой. Как из него сделать службу?

С благодарностью Леонид Федьков.

← →
Сергей М. © (2006-08-14 14:50) [1]

> приложение с формой. Как из него сделать службу?

А смысл ?

← →
Леонид Федьков (2006-08-14 14:53) [2]

Сергею.
Для вывода и просмотра определённых данных, собираемых службой.

← →
Сергей М. © (2006-08-14 15:04) [3]

Это делается не так.
Реализуется отдельное приложение-служба (безо всяких форм), манипулирующая некими данными.
Реализуется приложение-апплет панели управления (с нужными формами), для вывода и просмотра тех самых "определённых данных".
Взаимодействие между сервисом и апплетом осуществляется любым подходящим и удобным способом - NamedPipes, TCP/IP, MMF, win-сообщения

← →
Сергей М. © (2006-08-14 15:05) [4]

Переделывать же "одним махом" готовое GUI-приложение в сервис не только нежелательно, но и зачастую невозможно.

← →
novill © (2006-08-14 15:12) [5]

Вот те пример. File->New->Other->Service application

unit Unit1; interface uses Windows, Messages, SysUtils, Classes, Graphics, Controls, SvcMgr, Dialogs; type TService1 = class(TService) procedure ServiceExecute(Sender: TService); private { Private declarations } public function GetServiceController: TServiceController; override; { Public declarations } end; var Service1: TService1; implementation {$R *.DFM} procedure ServiceController(CtrlCode: DWord); stdcall; begin Service1.Controller(CtrlCode); end; function TService1.GetServiceController: TServiceController; begin Result := ServiceController; end; {на событие OnExecute повесь след процедуру} procedure TService1.ServiceExecute(Sender: TService); begin while not Self.Terminated do begin ServiceThread.ProcessRequests(False); {твои процедуры} end; end; end; end.

С использованием форм будет много проблем. Почему - RTFM.
Лучше пусть просмотром занимается самостоятельная прога.

← →
Леонид Федьков (2006-08-14 16:56) [6]

Всем спасибо!

← →
Чапаев © (2006-08-14 19:57) [7]

> win-сообщения

А вот как бы с минимальными усилиями обмениваться сообщениями с делфовым service application? Я ничего лучше не придумал, чем сотворить невидимое окно и ему сообщения слать...

← →
Сергей М. © (2006-08-15 08:09) [8]

> Чапаев © (14.08.06 19:57) [7]

> ничего лучше не придумал, чем сотворить невидимое окно и
> ему сообщения слать

Не нужно никаких окон.
Сообщение м.б. послано не только окну, но и нити.
См. PostThreadMessage().
Единственное ограничение - асинхронность вышеупомянутой ф-ции.

← →
Чапаев © (2006-08-15 09:36) [9]

> Не нужно никаких окон.
> Сообщение м.б. послано не только окну, но и нити.
> См. PostThreadMessage().
> Единственное ограничение - асинхронность вышеупомянутой
> ф-ции.

В теории я это знаю, а вот на практике... Как получить хэндл потока службы? Как в обработчик сообщений потока вставить реакцию на пользовательское событие? Речь идёт не о "службе с нуля", а о делфовом service application.

> Единственное ограничение - асинхронность вышеупомянутой
> ф-ции.

Немножко не понял... А оконная функция -- синхронна?

← →
Сергей М. © (2006-08-15 09:51) [10]

> Как получить хэндл потока службы?

Для отправки сообщения нити требуется не хендл, а ID нити.

Нить сервиса может записать свой ID, например, в MMF.

> Как в обработчик сообщений потока вставить реакцию на пользовательское
> событие?

цикл следует организовать примерно так (как вариант) :

while not Terminated do begin
WaitMessage;
if PeekMessage(Msg, -1, TM_FIRST_MSG, TM_TM_LAST_MSG, PM_REMOVE) then
Dispatch(Msg.Message)
else
ProcessRequests(False);
end;

> оконная функция -- синхронна?

Не оконная ф-ция, а ф-ция SendMessage().
Она вернет управление после обработки целевым окном посылаемого ему сообщения, в то время как PostThreadMessage() посылает сообщение и тут же возвращает управление.

← →
Ketmar © (2006-08-15 09:55) [11]

интересно, почему так усиленно игноритуют сокеты, при помощи которых можно очень удобно реализовать это самое общение? плюс -- при желании -- даже удалённое администрирование сервиса?

← →
Чапаев © (2006-08-15 10:09) [12]

> Нить сервиса может записать свой ID, например, в MMF.

Так. А MMF -- это что?

> цикл следует организовать примерно так

Это понятно. Но как к этому добраться в Service Application?

> Не оконная ф-ция, а ф-ция SendMessage().

Понял. Не сообразил сразу, к чему синхронность относится.

← →
Сергей М. © (2006-08-15 10:14) [13]

> MMF -- это что?

Memory Mapped File

см. CreateFilemapping() + MapViewOfFile()

> как к этому добраться в Service Application?

Подобный цикл должен фигурировать в обработчике TService.OnExecute

← →
Сергей М. © (2006-08-15 10:19) [14]

> Ketmar © (15.08.06 09:55) [11]
>
> интересно, почему так усиленно игноритуют сокеты

Если не требуется удаленное взаимодействие с сервисом, то сокеты тут вряд ли оправданы.

А если и требуется, то при условии гомогенной сет.опер.среды разумнее использовать NamedPipes. Да и в гетерогенной пайпы тоже можно юзать - *nix-системы поддерживают пайп-технологию.

← →
Чапаев © (2006-08-15 10:27) [15]

> Memory Mapped File

Ясно. Просто с аббревиатурой не сталкивался. Только вот MMF в данном случае... Не из пушки по воробьям?

> Подобный цикл должен фигурировать в обработчике TService.OnExecute

Ага... Попробую, спасибо.

← →
Сергей М. © (2006-08-15 10:36) [16]

> MMF в данном случае... Не из пушки по воробьям?

Может и так ..
Но в прогр.реализации это проще, чем иные способы "публикования" подобного рода инф-ции.

Вот еще вариант "публикования" : для главного окна сервис-приложения установить св-во (см. SetProp), являющее собой строку с текстовым представлением ID нити сервиса. Тогда любой процесс того же десктопа может найдя интересующее окно прочитать это св-во (GetProp). Но это оправдано лишь в случае когда сервис-приложение реализует один-единственный сервис, а не множество сервисов (что вполне нормально).

← →
Сергей М. © (2006-08-15 10:39) [17]

> Чапаев

Я бы таки настоятельно рекомендовал для интерпроцессного взаимодействия использовать не механизм win-сообщений, а именованые пайпы.

← →
Чапаев © (2006-08-15 11:01) [18]

> [17] Сергей М. © (15.08.06 10:39)

Ага. Мне это сразу понравилось, просто раньше не мог додуматься, как в службе читать-писать в канал. Теперь, благодаря твоему примеру, всё прояснилось. :-)

← →
Ketmar © (2006-08-15 14:55) [19]

> [14] Сергей М. © (15.08.06 10:19)
да пофигу -- что пнём об сову, что совой об пень... для одной и той же машины сокеты сеть не дёргают, так что ничем не хуже пайпов. это вопрос скорее личного вкуса. %-)

← →
Сергей М. © (2006-08-15 15:01) [20]

> для одной и той же машины сокеты сеть не дёргают

Пайпы тоже не "дергают". Зато не тратят время на работу отнюдь не самых быстрых транспортных протоколов на базе IP

← →
Чапаев © (2006-08-15 15:37) [21]

В XP, знаю, TCP/IP есть всегда. А в более ранних системах? В 2000, например?

← →
Ketmar © (2006-08-15 15:38) [22]

> [20] Сергей М. © (15.08.06 15:01)
где-то я читал (точно не скажу уже, где), что вся работа сокетов для локалхоста ограничивается копированием буферов. не уверен, на, кажется, так.

> [21] Чапаев © (15.08.06 15:37)
у меня -- есть. %-)

← →
Rouse_ © (2006-08-15 16:19) [23]

> Ketmar © (15.08.06 14:55) [19]
> > [14] Сергей М. © (15.08.06 10:19)
> да пофигу -- что пнём об сову, что совой об пень... для
> одной и той же машины сокеты сеть не дёргают, так что ничем
> не хуже пайпов. это вопрос скорее личного вкуса. %-)

На машине отсутствуют сетевые карты и MSLoopback, или присутствуют, но вместо TCP стоит IPX. Что в данном случае делать будешь?
Я как пару раз наткнулся на такие варианты, сразу отказылся от использования сокетов. Причем такие варианты стояли и в солидных конторах, которые у нас сразу по несколько десятков а то и сотен экземпляров ПО закупили, таким не скажешь - "да у вас админы тупые, настраивайте как надо", это они говорят - мы за что вам такие бешенные деньги платили, за то чтоб еще под ваши требования потом конфигурировать ПО?

← →
Ketmar © (2006-08-15 18:12) [24]

> [23] Rouse_ © (15.08.06 16:19)
нет, если пишешь за большие деньги и для кого-то -- то лучше делать вообще несколько вариантов. TCP, IPX, Pipes (MailSlots? %-). а если для себя -- то сокеты рулят. %-)

← →
pasha_golub © (2006-08-15 18:35) [25]

> Ketmar © (15.08.06 18:12) [24]

трубы рулят. :0)

> то лучше делать вообще несколько вариантов

Лучше один сделать.

> трубы рулят. :0)

Пока не оказывается, что прога и на 98 винде работать должна... :-(

> [29] Ketmar © (15.08.06 18:53)

Нету, конечно. Просто как-то раз, помнится, написал красивое такое взаимодействие клиента и сервера через трубы, а тут -- бац! -- выясняется, что под 98 это не идёт... Пришлось через сокеты делать...

> Чапаев © (15.08.06 19:10) [30]

> такое взаимодействие клиента и сервера через трубы, а тут
> -- бац! -- выясняется, что под 98 это не идёт...

Дык, его надо б было через безымянную трубу брать.

--
Regards, LVT.

> Дык, его надо б было через безымянную трубу брать.

Что ж... Если ещё такая оказия случится -- буду знать. :-)

> Чапаев © (15.08.06 19:10) [30]

> выясняется, что под 98 это не идёт

Win9x не реализует лишь серверный пайп-механизм, а пайп-клиенты там работают вполне успешно.

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

Программирование служб Windows на Delphi Найти похожие ветки