D>Странненько... Проверь попадает ли в WndProc метод.

Да попадает.

D>Кажется я таки понял в чем твоя проблема. Timer — это те же Windows сообщения, соответственно их нужно обрабатывать, и причем в том же потоке где Timer был создан. Так как предложенный мною поток имеет реализацию обработки сообщений — то тебе абсолютно ничего не надо дописывать. Но одно но — создавать все Модули и стартовать плагины нужно именно в Execute. Конструктор Create потока для этих целей не подходит.

Т.е. мне необходимо иметь клас плагина, коий нужно экспортировать из DLL, причем незнаю как, и который создавать на Execute потока, а уже реализацию создания этого класса можно(нужно) делать в самой DLL плагина. Верно я понял? Или может лучше в этом случае плагины писать как потоки, но каждый плагин это один поток. Т.е. реализацию DLL делать как поток? А по событию останова сервиса вызывать функцию DLL, которая будет глушить этот поток.

Еще. А нужнен ли TDllThread.MyMessage2, ведь как только Execute отработает автматом будет вызван TDllThread.DoTerminate, может более коректно на нем производить остановку и выгрузку DLL, т.е. вместо

procedure TDllThread.MyMessage2(var Message: TMessage);
begin
  if HandleDLL <> 0 then StopPluggin;
  Terminate;
  FreeLibrary(HandleDLL);
end;

procedure TService1.ServiceStop(Sender: TService; var Stopped: Boolean);
begin
  if DllThread <> nil then
    SendMessage (DllThread.WndHandle, MY_MESSAGE2, 0, 0);
  Stopped := True;
end;

сделать просто

procedure TDllThread.DoTerminate;
begin
  if HandleDLL <> 0 then StopPluggin;
  FreeLibrary(HandleDLL);
end;

что скажешь?

D>Думаю что все таки один сервис лучше Не будеш же ты из-за каждого плагина регистрить новый сервис

Поэтому и хотел смотреть в сторону плагинов к сервису. А что касаеться производительности там, загрузки проца и прочее, я понимаю, что щас это не критично, но все же? Так — что называеться для в общеобразовательных целях?