using System.ServiceProcess;
namespace WindowsService1
{
static class Program
{
static void Main()
{
ServiceBase.Run(new ServiceBase[]
{
new Service1()
});
}
}
public class Service1 : ServiceBase
{
public Service1()
{
ServiceName = "Service1";
}
protected override void OnStart(string[] args)
{
}
protected override void OnStop()
{
}
}
}
Централизованное взаимодействие процессов
Хочу написать многофункциональную программу [COLOR="#c0c0c0"]с преферансом и дамами[/COLOR].Среди всего прочего там будет взаимодействие копий программы между пользователями(для каждого пользователя,если их несколько в системе,будет запускаться своя клиентская часть),т.е. используется клиент-серверная схема взаимодействия:клиенты отправляют команды серверу,который хранит настройки,наблюдает за разными изменениями в системе и много чего ещё.И вот тут встаёт главный вопрос–как именно это организовать(всё локально,разумеется).У меня есть несколько вариантов развития событий:
[SIZE="1"][COLOR="#c0c0c0"](варианты–в порядке субъективной оптимальности)[/COLOR][/SIZE]
0.Служба–наверное,самый лучший(в общем) вариант,но немного не для меня.Со службами я как-то не работал,да и это будет лишний процесс(ведь процесс–это вам не одна DLL,а как минимум 3 модуля–он сам+Kernel32+NTDLL)
1.Загрузка одной копии DLL через AppInitDLLs.Реализацию себе представляю так:в DLLMain создаётся мьютекс,при ошибке–самовыгруз(т.е. одна копия уже есть)
2.Загрузка DLL через Winlogon\Notify.Это даже лучше,чем п.1–не надо контролировать уникальность+я получаю подписку на всякие там логоны/запуски заставок и проч.(это будет логироваться)
Собственно,вот 1й вопрос–как организовать серверную часть
2й вопрос–как наладить взаимодействие клиентов с сервером,ибо единовременно к серверу может быть подключено >1 клиента(из механизмов IPC знаю пипки,майлслоты,но не знаю,насколько они кросспользовательские)?
Собственно,пока вроде всё.Остальные вопросы появятся позже:)
[SIZE="1"][COLOR="#c0c0c0"](варианты–в порядке субъективной оптимальности)[/COLOR][/SIZE]
0.Служба–наверное,самый лучший(в общем) вариант,но немного не для меня.Со службами я как-то не работал,да и это будет лишний процесс(ведь процесс–это вам не одна DLL,а как минимум 3 модуля–он сам+Kernel32+NTDLL)
1.Загрузка одной копии DLL через AppInitDLLs.Реализацию себе представляю так:в DLLMain создаётся мьютекс,при ошибке–самовыгруз(т.е. одна копия уже есть)
2.Загрузка DLL через Winlogon\Notify.Это даже лучше,чем п.1–не надо контролировать уникальность+я получаю подписку на всякие там логоны/запуски заставок и проч.(это будет логироваться)
Собственно,вот 1й вопрос–как организовать серверную часть
2й вопрос–как наладить взаимодействие клиентов с сервером,ибо единовременно к серверу может быть подключено >1 клиента(из механизмов IPC знаю пипки,майлслоты,но не знаю,насколько они кросспользовательские)?
Собственно,пока вроде всё.Остальные вопросы появятся позже:)
Может туплю, но не понял ничего. :)
Что есть сервер? Что есть клиенты? И в чем суть их взаимодействия?
Что есть сервер? Что есть клиенты? И в чем суть их взаимодействия?
Цитата: nikitozz
Может туплю, но не понял ничего
Может быть.Или я плохо описа́л
Сервер–DLL(или служба,если Phodopus меня таки уговорит:)),которая выполняет все операции–хранит данные,ведёт логи,следит за событиями и проч.Разумеется,сервер должен быть 1
Клиенты представляют собой программу,которая запускается для каждого пользователя.Они с сервером взаимодействуют путём,допустим,пайпов(вроде самый лучший механизм),т.е. просто шлют ему команды и,если надо,отображают результат.Например,пользователь 1 хочет передать пользователю 2 какую-то информацию.Клиент п. 1 делает запрос серверу на сохранение этой информации.Затем клиент п. 2 при запуске спрашивает сервер на предмет,а не оставлял ли кто ему заметок,на что сервер радостно возвращает инфу,оставленную клиентом п. 1
Как-то так:)
А в чем, собственно, вопрос-то?
Если в организации всего хозяйства - то создаешь многопоточный сервер. Служба/не служба, сокет/пайп - это уж от твоих задач зависит. Я делал в обычном exe с именованными пайпами - меня по задачам устраивало. Создашь пул потоков клиентов, свяжешь с ними какие-то идентификаторы и некое хранилище данных.
Далее придумаешь протокол взаимодействия клиента с сервером. Например, по запросу клиента сервер выдает ему идентификаторы всех подключенных клиентов (чтоб знать, кому вообще можно отправлять данные). Затем клиент посылает данные на сервер + идентификатор клиента-получателя. Сервер принимает данные от одного клиента и посылает другому (либо сам и сразу, либо ждет запроса от второго клиента - опять же по задачам)
Как-то так, в общем ;)
Если в организации всего хозяйства - то создаешь многопоточный сервер. Служба/не служба, сокет/пайп - это уж от твоих задач зависит. Я делал в обычном exe с именованными пайпами - меня по задачам устраивало. Создашь пул потоков клиентов, свяжешь с ними какие-то идентификаторы и некое хранилище данных.
Далее придумаешь протокол взаимодействия клиента с сервером. Например, по запросу клиента сервер выдает ему идентификаторы всех подключенных клиентов (чтоб знать, кому вообще можно отправлять данные). Затем клиент посылает данные на сервер + идентификатор клиента-получателя. Сервер принимает данные от одного клиента и посылает другому (либо сам и сразу, либо ждет запроса от второго клиента - опять же по задачам)
Как-то так, в общем ;)
Так,ну механизм взаимодействия–это пока что второй вопрос.Меня пока более интересует,каким из вышеперечисленных способов организовать сервер
По поводу 2го вопроса–есть ли способ организовать взаимодействие один-ко-многим?Ибо,например,сокеты поддерживают только 1-к-1
По поводу 2го вопроса–есть ли способ организовать взаимодействие один-ко-многим?Ибо,например,сокеты поддерживают только 1-к-1
Мульикаст сокеты поддерживают один ко многим)
Итак,делаю то,что обещал(а именно,привожу возможности программы):
• Запуск цепочки программ с завершением работы по окончании их выполнения
• Напоминания о событиях(календарь)
• Список программ для быстрого запуска(с акселераторами)
• Передача оповещений между пользователями
• Автозапуск:выполнить системное действие по умолчанию(ShellExecute),только открыть,ничего не делать
Собственно,описанное мной взаимодействие требуется только для одного из пунктов(впрочем,функционал будет расширяться;можно ещё хранение настроек сервером сделать,пусть он этим заведует)–передачи оповещений
С механизмом взаимодействия >-< разобрался–сервер будет загружаться через WinLogon notification package,взаимодействие с ним–через пайпы
• Запуск цепочки программ с завершением работы по окончании их выполнения
• Напоминания о событиях(календарь)
• Список программ для быстрого запуска(с акселераторами)
• Передача оповещений между пользователями
• Автозапуск:выполнить системное действие по умолчанию(ShellExecute),только открыть,ничего не делать
Собственно,описанное мной взаимодействие требуется только для одного из пунктов(впрочем,функционал будет расширяться;можно ещё хранение настроек сервером сделать,пусть он этим заведует)–передачи оповещений
С механизмом взаимодействия >-< разобрался–сервер будет загружаться через WinLogon notification package,взаимодействие с ним–через пайпы
Итак,дабы тема не тонула,надо её обновить
За это время я даже чуть сдвинулся с места,в аттаче выложены результаты труда(разумеется,стадия ещё жутко начальная,но что поделать)–решение для VS 2005
И сразу возникает вопрос:как это отлаживать?Ведь отладить я смогу только клиента(в смысле,отредактирова код-скомпилировал-запустил).Как быть с отладкой серверной части?
За это время я даже чуть сдвинулся с места,в аттаче выложены результаты труда(разумеется,стадия ещё жутко начальная,но что поделать)–решение для VS 2005
И сразу возникает вопрос:как это отлаживать?Ведь отладить я смогу только клиента(в смысле,отредактирова код-скомпилировал-запустил).Как быть с отладкой серверной части?
А в чем принципиальная проблема с отладкой серверной части?
Дык как её отлаживать?Вот в связке с клиентом всё просто–компилируется сервер и зависимый от него клиент,и оно запускается под студийным отладчиком.Где надо,я могу поставить брэйкпоинты,посмотреть,что мне угодно…А вот когда DLL будет загружена WinLogon'ом,тут уж не знаю,как быть.И ведь просто так не внесёшь изменения,насколько я понимаю…:(
Цитата: @pixo $oft
И сразу возникает вопрос:как это отлаживать?
Ответ есть у MSDN:)
Только exeшник службы debug-версия должен быть, чтоб отладочные символы присутствовали.
Вообще у меня не служба,а Winlogon notification package,и там так просто не отладишь…И вообще,я так понял,отлаживать получится только аттачнувшись,т.е. придётся прописать чуть ли не весь код и потом искать в нём ошибки
Цитата: @pixo $oft
Вообще у меня не служба,а Winlogon notification package,и там так просто не отладишь…И вообще,я так понял,отлаживать получится только аттачнувшись,т.е. придётся прописать чуть ли не весь код и потом искать в нём ошибки
Хм, нуда... как сказал мсдн:
[quote=MSDN]
при подключении к процессу WinLogon и последующей остановке отладки произойдет остановка системы, поскольку она не может работать без данного процесса.
[/quote]
Тогда имхо только вести очень жирный лог :)
Цитата: @pixo $oft
И сразу возникает вопрос:как это отлаживать?
Запустив в виртуальной машинке.
arrjj:т.е. к процессу можно только подключиться,но не отключиться?Если да,то печально
Ramon:вот тоже на досуге об этом подумал.И даже вспомнил,что в VMWare есть сеть,а в VS–Remote debugger.Огорчает лишь то,что сеть я не знаю как правильно настроить,а уж как работать с RDbg–тем более.Буду рад советам в этом направлении
Ramon:вот тоже на досуге об этом подумал.И даже вспомнил,что в VMWare есть сеть,а в VS–Remote debugger.Огорчает лишь то,что сеть я не знаю как правильно настроить,а уж как работать с RDbg–тем более.Буду рад советам в этом направлении
Цитата: @pixo $oft
Вообще у меня не служба,а Winlogon notification package,и там так просто не отладишь…И вообще,я так понял,отлаживать получится только аттачнувшись,т.е. придётся прописать чуть ли не весь код и потом искать в нём ошибки
Зачем такое требование (работа под WinLogon-ом) откуда такая необходимость возникла?
Судя по всему задача решается банальным ком-сервером в виде сервиса.
Прошу для начала пояснить про именно COM-сервер(это ж придётся целую технологию изучить)
А возникла–потому что я избрал такой путь.Загрузка с одним из первых процессов в системе,DLL(а не .exe) и т.п.
А возникла–потому что я избрал такой путь.Загрузка с одним из первых процессов в системе,DLL(а не .exe) и т.п.
Цитата: @pixo $oft
Прошу для начала пояснить про именно COM-сервер(это ж придётся целую технологию изучить)
Дык, если не изучать, то придется изобретать собственный протокол взаимодействия клиентов и сервиса.
Цитата: @pixo $oft
А возникла–потому что я избрал такой путь.Загрузка с одним из первых процессов в системе,DLL(а не .exe) и т.п.
Выбор способа нужно уметь объяснить. Сейчас ты поимел проблемы с отладкой, а в конечном счете - с безопасностью решения как такового, т.к. winlogon сильно привилегированный системный процесс:
1) возможность прямой коммуникации с ним из любой пользовательской сессии - это потенциальная брешь в безопасности (привелегии сервиса можно настроить, да и нарушить протокол COM сложнее)
2) поломка в коде библиотеки ведет к краху процесса, что влечет за собой немедленный перезагруз системы (с сервисом такого не произойдет, он просто перезапустится)
И кстати:
[quote=MSDN]
GINA DLLs and Winlogon notification packages are ignored in Windows Vista
[/quote] :)))
[quote=MSDN]
GINA DLLs and Winlogon notification packages are ignored in Windows Vista
[/quote] :)))
Он (ТС) все это знает :)
Но ему все равно :D
Но ему все равно :D
Phodopus:
Да,знаю.И да,всё равно:)(дальше XP я и не планировал…пока)
hardcase:
Вообще,я думал над своим протоколом–не такой он сложный будет,я думаю(и строить буду на пайпах,ага;ну это отдельный разговор)
Протокол подразумевает под собой разграничение прав,поэтому брешь прорвать будет не так просто.А привилегии службы–это какие,например?
Про поломку в коде библиотеки да,знал.В общем-то,я уже почти переубедился на счёт служб,поэтому изложу свои т.зр. так,чтоб поспорить:)
Преимущества WLNP:
• одна DLL(а не целый процесс с присобаченными к нему DLL) на всю систему
• грузится раньше клиентов,а выгружается после их выгрузки(в смысле,при завершении работы)
• отсутствует внешнее управление DLL(т.е. её не остановят,если вдруг кого-то припрёт)
• функционально реализованная подписка на события logon/logoff,startup/shutdown и проч.(не знаю,как с этим у служб)
• этот же модуль используется клиентом,т.к. в нём содержатся общие функции.Иначе придётся либо писать DLL,либо реализовывать функционал в клиенте и в сервере(см. п. 1)
Преимущества службы:
• описанные тобой
• можно управлять(тоже плюс,с одной стороны)
• механизм служб поддерживается почти без изменений и после XP,в отличие от WLNP
• ещё какие-то,но всё позабыл(перед сном размышлял:))
Вот так.Интересно поспорить по этим пунктам
Да,знаю.И да,всё равно:)(дальше XP я и не планировал…пока)
hardcase:
Вообще,я думал над своим протоколом–не такой он сложный будет,я думаю(и строить буду на пайпах,ага;ну это отдельный разговор)
Протокол подразумевает под собой разграничение прав,поэтому брешь прорвать будет не так просто.А привилегии службы–это какие,например?
Про поломку в коде библиотеки да,знал.В общем-то,я уже почти переубедился на счёт служб,поэтому изложу свои т.зр. так,чтоб поспорить:)
Преимущества WLNP:
• одна DLL(а не целый процесс с присобаченными к нему DLL) на всю систему
• грузится раньше клиентов,а выгружается после их выгрузки(в смысле,при завершении работы)
• отсутствует внешнее управление DLL(т.е. её не остановят,если вдруг кого-то припрёт)
• функционально реализованная подписка на события logon/logoff,startup/shutdown и проч.(не знаю,как с этим у служб)
• этот же модуль используется клиентом,т.к. в нём содержатся общие функции.Иначе придётся либо писать DLL,либо реализовывать функционал в клиенте и в сервере(см. п. 1)
Преимущества службы:
• описанные тобой
• можно управлять(тоже плюс,с одной стороны)
• механизм служб поддерживается почти без изменений и после XP,в отличие от WLNP
• ещё какие-то,но всё позабыл(перед сном размышлял:))
Вот так.Интересно поспорить по этим пунктам
Цитата: @pixo $oft
Да,знаю.И да,всё равно:)(дальше XP я и не планировал…пока)
Каков смысл писать софт под устаревшую операционную систему? Тем более что однажды ты поставишь семерку и все перестанет работать ;)
Цитата: @pixo $oft
Вообще,я думал над своим протоколом–не такой он сложный будет,я думаю(и строить буду на пайпах,ага;ну это отдельный разговор)
И что, пайпы автоматически решают проблему, скажем, переполнения буфера?
Цитата: @pixo $oft
А привилегии службы–это какие,например?
Банально запуск от некоторого пользователя.
Цитата: @pixo $oft
Преимущества WLNP:
• одна DLL(а не целый процесс с присобаченными к нему DLL) на всю систему
Не аргумент. DLL и так грузятся единожды и проецируются в память процессов.
Цитата: @pixo $oft
• грузится раньше клиентов,а выгружается после их выгрузки(в смысле,при завершении работы)
Запуск сервиса может быть при первом обращении клиента, так что для клиента будет все равно - запустилась служба сейчас или же при старте системы.
Цитата: @pixo $oft
• отсутствует внешнее управление DLL(т.е. её не остановят,если вдруг кого-то припрёт)
Для служб это тоже решается.
Цитата: @pixo $oft
• функционально реализованная подписка на события logon/logoff,startup/shutdown и проч.(не знаю,как с этим у служб)
Точно также решается.
Цитата: @pixo $oft
• этот же модуль используется клиентом,т.к. в нём содержатся общие функции.Иначе придётся либо писать DLL,либо реализовывать функционал в клиенте и в сервере(см. п. 1)
Это вообще инвариантно любому техническому решению (статические либы в нативном коде, общие сборки в управляемом).
Итого: приемуществ у WLNP вообще нет, минус огромен - это устаревшая технология.
Цитата: hardcase
И что, пайпы автоматически решают проблему, скажем, переполнения буфера?
А в COM это решено?
Вообще,проблема переполнения буфера устраняется ручками
Цитата: hardcase
Банально запуск от некоторого пользователя
Однако,это лишние накладные расходы–создавать пользователя для службы,логиниться в нём(не,я понимаю,что это всё почти автоматом,но всё же)…Пусть служба будет как все
Цитата: hardcase
Не аргумент. DLL и так грузятся единожды и проецируются в память процессов
Я с этим уже ознакомился.Но сравни–1 DLL в роли сервера+клиент(ы) или 1 DLL+exe в роли сервера+клиент(ы).Есть всё же разница
Цитата: hardcase
Запуск сервиса может быть при первом обращении клиента, так что для клиента будет все равно - запустилась служба сейчас или же при старте системы
Не может:) Потому что сервер ещё кое-что должен будет протоколировать,вне зависимости от клиентов.Им он только по запросу будет выдавать
Цитата: hardcase
Для служб это тоже решается
Как?:)
Про уведомления прочитал,ага.Просто тогда не в курсе был
Цитата: hardcase
Это вообще инвариантно любому техническому решению (статические либы в нативном коде, общие сборки в управляемом)
Ой ли?Я ведь правильно понимаю,что статическая библиотека→увеличение размера сервера и клиента?
Цитата: hardcase
Итого: приемуществ у WLNP вообще нет, минус огромен - это устаревшая технология
Ну,плюсы-то,может,и есть.Но в целом согласен
[COLOR="#c0c0c0"](прошу не забывать,что это лишь технический спор,ставящий своей целью моё окончательное и бесповоротное просвещение ☺)[/COLOR]
Цитата: @pixo $oft
А в COM это решено?
COM вызовы строготипизированы.
Цитата: @pixo $oft
Вообще,проблема переполнения буфера устраняется ручками
Эта проблема устраняется автоматически отказом от ручного разбора буферов и введением строгой статической типизации.
Цитата: @pixo $oft
Однако,это лишние накладные расходы–создавать пользователя для службы,логиниться в нём(не,я понимаю,что это всё почти автоматом,но всё же)…Пусть служба будет как все
Это делается единожды при развертывании системы.
Цитата: @pixo $oft
Я с этим уже ознакомился.Но сравни–1 DLL в роли сервера+клиент(ы) или 1 DLL+exe в роли сервера+клиент(ы).Есть всё же разница
Для одного сервиса разницы нет никакой.
Цитата: @pixo $oft
Не может:) Потому что сервер ещё кое-что должен будет протоколировать,вне зависимости от клиентов.
Запускаешь сервис при старте системы всего делов-то.
Цитата: @pixo $oft
Я ведь правильно понимаю,что статическая библиотека→увеличение размера сервера и клиента?Ну,плюсы-то,может,и есть.
Можно и динамическую использовать. Поинт в том, что написать код, размером превышающий хотя бы страндартную библиотеку - это надо постараться.
Цитата: hardcase
Это делается единожды при развертывании системы
А нафига создавать пользователя,если он потом не используется?:) Профиль-то при запуске службы грузится каждый раз,так что…
Цитата: hardcase
Для одного сервиса разницы нет никакой
Конечно,может быть,я чего-то не понимаю,но разве может быть DLL,загруженная процессом(WinLogon в данном случа),больше,чем целый процесс(новый!)+DLL?
Цитата: hardcase
Запускаешь сервис при старте системы всего делов-то
Об этом я как бы догадался:)
Цитата: hardcase
Поинт в том, что написать код, размером превышающий хотя бы страндартную библиотеку - это надо постараться
О какой стандартной библиотеке речь?И как она сюда привязана?
Цитата: @pixo $oft
А нафига создавать пользователя,если он потом не используется?:) Профиль-то при запуске службы грузится каждый раз,так что…
Профиль может и не загружаться. Если тебе не нужен пользователь, то не создаешь.
Цитата: @pixo $oft
Конечно,может быть,я чего-то не понимаю,но разве может быть DLL,загруженная процессом(WinLogon в данном случа),больше,чем целый процесс(новый!)+DLL?
А что, код в DLL не выделяет память? :)
Цитата: @pixo $oft
О какой стандартной библиотеке речь?И как она сюда привязана?
Стандартной библиотеки языка который используешь. Я к тому, что экономить память (дисковую и оперативную) нужно лишь там, где это действительно необходимо.
Цитата: hardcase
А что, код в DLL не выделяет память? :)
А что,выделяет?:D
Я к тому,что догрузка одного модуля всё же меньше требует,чем целый процесс(с ещё одним модулем ☺),не?
Цитата: hardcase
Стандартной библиотеки языка, который используешь. Я к тому, что экономить память (дисковую и оперативную) нужно лишь там, где это действительно необходимо.
Сказывается тяжёлое прошлой человека из моей подписи;)
А стандартную библиотеку я не использую.Отвязался от CRT,такие дела
Небольшое обновление по поводу отладки[COLOR="#c0c0c0"](больше заметки для себя)[/COLOR]
Оказывается,не всё так плохо:сначала я вспомнил про DebugBreak,потом поискал по словам «DebugBreak services» и о чудо!–нашёл статью про отладку служб.Думаю,вариант с реестром можно отмести как более затратный по времени,и просто вставить DebugBreak где-нибудь в начале
Оказывается,не всё так плохо:сначала я вспомнил про DebugBreak,потом поискал по словам «DebugBreak services» и о чудо!–нашёл статью про отладку служб.Думаю,вариант с реестром можно отмести как более затратный по времени,и просто вставить DebugBreak где-нибудь в начале
Цитата: @pixo $oft
Небольшое обновление по поводу отладки[COLOR="#c0c0c0"](больше заметки для себя)[/COLOR]
Все гораздо проще. exe-шник службы для работы в режиме службы просто запускать с отдельным ключем (устанавливать).
Цитата: hardcase
запускать с отдельным ключем (устанавливать).
Не совсем понял.У меня уже в сервере(службе) реализована установка по запросу(т.е. при передаче ключа install через командную строку).В клиенте будет возможность при отсутсвии службы в системе запустить сервер,тем самым установив его
Так что не совсем понятно,к чему это.Отлаживать службу,запущенную не как службу?
Цитата: @pixo $oft
Отлаживать службу,запущенную не как службу?
Именно.
Боюсь,это не удастся по причине того,что тот же самый RegisterServiceControlHandler вернёт ошибку,что служба–не служба
А чем не устраивает вариант с DebugBreak?
А чем не устраивает вариант с DebugBreak?
Цитата: @pixo $oft
Боюсь,это не удастся по причине того,что тот же самый RegisterServiceControlHandler вернёт ошибку,что служба–не служба
Это смотря как писать :)
Цитата: @pixo $oft
А чем не устраивает вариант с DebugBreak?
Это неудобно. Гораздо удобнее запускать из студии сразу и клиента и сервер одновременно - оба под отладчиком.
Цитата: hardcase
Гораздо удобнее запускать из студии сразу и клиента и сервер одновременно - оба под отладчиком.
Согласен,что это самый удобный вариант.Но…как тогда писа́ть?:)
Цитата: @pixo $oft
Согласен,что это самый удобный вариант.Но…как тогда писа́ть?:)
Полезный код отдельно - сервисная обвязка отдельно.
Неужели ты руками пишешь этот бесполезный код (сервисной обвяхзки)?
Цитата: hardcase
Неужели ты руками пишешь этот бесполезный код (сервисной обвяхзки)?
А где его взять-то?Не втупую ж с MSDN скатать,вдруг ошибки.Ну и свою инициализацию там придётся пихнуть же
Цитата: @pixo $oft
А где его взять-то?Не втупую ж с MSDN скатать,вдруг ошибки.Ну и свою инициализацию там придётся пихнуть же
Во всех нормальных средах разработки всегда есть шаблон виндового сервиса. C++ не использую потому не знаю.
Касательно .NET, то код тут выглядит крайне примитивно (без кода инсталляции):
Код:
Соответственно вынесение серверной логики становится тривиальным.
Ну,.Net не пользую,посему придётся реализовывать иными способами…В C++ не так всё просто:)
Цитата: @pixo $oft
Ну,.Net не пользую,посему придётся реализовывать иными способами…В C++ не так всё просто:)
Я просто не понимаю где тут могут быть сложности :) И почему они тут могут возникнуть.
В написании и отладке же:) Для меня это тема совсем новая,ни разу не сталкивался.Вот теперь будет шаблон службы,будет легче
Ладно,уже оффтоп пошёл.До следующего вопроса ☺
Ладно,уже оффтоп пошёл.До следующего вопроса ☺
Вот,наконец сподобился выложить сюда то,что написал.И сразу вопросы–почему DebugBreak не работает в HandlerEx(1) и зачем там же строчка «SetSvcStatus(ssSvcStatus.dwCurrentState,0,0);»,которая аналогична предыдущей(2)?