Аннотация:
В переписке с одним из членов RSDN Team я как-то неосторожно заявил, что не пишу сервисы направо и налево, подразумевая, что пишу я их очень редко. Да, я ошибался. Случилось так, что я был вынужден за достаточно короткий срок написать несколько сервисов – сначала один, и затем, спустя совсем небольшое время, еще парочку. Приступив к написанию второго, я вдруг почувствовал острое ощущение бессмысленности траты времени на тупое копирование типового кода. А впереди ведь ожидал еще и третий проект… Поэтому работа над вторым сервисом была отложена в сторону (по принципу «лучше день потерять, зато потом за пять минут долететь»), и был написан код, впоследствии легший в основу SFL.
Здравствуйте, 0rc, Вы писали:
0rc>Здравствуйте, Igor Vartanov, Вы писали:
0rc>Какой ужасть... ведь можно было и проще, 0rc>зачем так сложно-то?
Простите, а какой сложности сервисы Вы писали? Пробую переписать свои сервисы с использованием SFL — я в восторге — учтено практически все (в отличие моего собственного класса). Поэтому: это не так сложно, а так универсально!.
Кроме того, в коде текущей версии используется технология переходников – исполняемого кода, располагаемого в секции данных. Это естественным образом ограничивает применение библиотеки – код будет выполняться лишь на iX86-архитектурах, поскольку только для нее и реализованы переходники.
Только давайте уже отказываться от таких решений. Место кода — в секции кода. Новые системы имеют защиту от выполнения кода из непредназначенного для него места — Data Execution Prevention (DEP) называется, и отключение этой функции для сервисного приложения (!) — открытая дыра в систему.
Ссылки по теме:
[1] A detailed description of the Data Execution Prevention (DEP) feature in Windows... [2] Changes to Functionality in Microsoft Windows XP Service Pack 2. Part 3: Memory Protection Technologies [3] Wikipedia: NX bit [4] Intel's Execute Disable Bit functionality
Здравствуйте, gugle, Вы писали:
0rc>>Какой ужасть... ведь можно было и проще, 0rc>>зачем так сложно-то?
G>Простите, а какой сложности сервисы Вы писали?
От прослушивания realtime устройст до обслуживагия многомиллионого оператора сотовой связи. В целом опыт написания сервисов — 10 лет.
G>Пробую переписать свои сервисы с использованием SFL — я в восторге — учтено практически все (в отличие моего собственного класса). Поэтому: это не так сложно, а так универсально!.
А впрочем о вкусах не спорят, для меня универсальность — это возможность запустить ЭТО на Unix
Здравствуйте, fuurin, Вы писали:
F>Только давайте уже отказываться от таких решений. Место кода — в секции кода.
Давайте-давайте, никто же не против. Код открыт — берите и доделывайте.
F>Новые системы имеют защиту от выполнения кода из непредназначенного для него места — Data Execution Prevention (DEP) называется, и отключение этой функции для сервисного приложения (!) — открытая дыра в систему.
Про новые системы я говорил — как только получу в руки другое железо, тогда и начну думать про "место кода — в секции кода". А пока вся архитектура IA32 была, есть и останется навсегда (?) "открытой дырой в систему". И почему это никого не смущает?
F>>Новые системы имеют защиту от выполнения кода из непредназначенного для него места — Data Execution Prevention (DEP) называется, и отключение этой функции для сервисного приложения (!) — открытая дыра в систему.
ИВ> Про новые системы я говорил — как только получу в руки другое железо, тогда и начну думать про "место кода — в секции кода".
Игорь, я не думаю, что это хороший и правильный подход. Писать приложения, а уж тем более выкладываемую в свободный доступ библиотеку следует с оглядкой на использование на современных системах, тем более что DEP поддерживается уже давно и широко. Я не то чтобы против thunks, но мысли по поводу
1. В этом случае они совсем не нужны. Насколько я понимаю, экземпляр приложения CxxxApp у нас один, каждый сервис CxxService тоже в единственном экземпляре. Поэтому вся задача — обеспечить формирование статических экземпляров СхххService соответствующими макросами. Возможно, я чего не понял, но необходимости в thunks я тут совсем не вижу.
2. Если уж так хочется thunks — то надо пользовать ATL, для ATL m$ сделали послабление с DEP.
ИВ>А пока вся архитектура IA32 была, есть и останется навсегда (?) "открытой дырой в систему". И почему это никого не смущает?
Сильное, но ничем не обоснованное заявление. Архитектура IA32 имеет вполне неплохую организацию в плане защиты (кстати, частично заимствованную от IBM370).
Здравствуйте, Andrew S, Вы писали:
F>>>Новые системы имеют защиту от выполнения кода из непредназначенного для него места — Data Execution Prevention (DEP) называется, и отключение этой функции для сервисного приложения (!) — открытая дыра в систему.
ИВ>> Про новые системы я говорил — как только получу в руки другое железо, тогда и начну думать про "место кода — в секции кода".
AS>Игорь, я не думаю, что это хороший и правильный подход. Писать приложения, а уж тем более выкладываемую в свободный доступ библиотеку следует с оглядкой на использование на современных системах, тем более что DEP поддерживается уже давно и широко.
Начнем с того, что версия библиотеки — 1.0, т.е. она сырая до невозможности.
К software DEP у меня есть мое собственное личное отношение, которое я ни с кем не собираюсь обсуждать. Но, принимая во внимание вашу реакцию, я безусловно подумаю в этом направлении.
Hardware DEP не имеет к нашему случаю никакого отношения, и потому не рассматривается.
Выкладывание открытого кода для меня есть способ обмена мыслями в интересующем меня направлении. Тот, у кого есть собственное мнение (а также время и желание), всегда может ответить собственной реализацией, которая и выразит его мнение. Кроме того, мнением будет также и квалифицированный баг-репорт. Собственно, для этого исходники и выкладываются в свободный доступ.
AS>Я не то чтобы против thunks, но мысли по поводу AS>1. В этом случае они совсем не нужны. Насколько я понимаю, экземпляр приложения CxxxApp у нас один, каждый сервис CxxService тоже в единственном экземпляре. Поэтому вся задача — обеспечить формирование статических экземпляров СхххService соответствующими макросами. Возможно, я чего не понял, но необходимости в thunks я тут совсем не вижу.
Необходимость в них та же, что и в ATL. Читайте код.
AS>2. Если уж так хочется thunks — то надо пользовать ATL, для ATL m$ сделали послабление с DEP.
No comments.
ИВ>>А пока вся архитектура IA32 была, есть и останется навсегда (?) "открытой дырой в систему". И почему это никого не смущает?
AS>Сильное, но ничем не обоснованное заявление.
И причем в большей степени не мое, но господина F. Моего здесь — лишь личное отношение к software DEP.
Здравствуйте, Odi$$ey, Вы писали:
OE>Здравствуйте, 0rc, Вы писали:
0rc>>А впрочем о вкусах не спорят, для меня универсальность — это возможность запустить ЭТО на Unix
OE>windows service на unix?
Нет, но аналогии можно провести service(win32)<->daemons(unix).
ИВ>К software DEP у меня есть мое собственное личное отношение, которое я ни с кем не собираюсь обсуждать. Но, принимая во внимание вашу реакцию, я безусловно подумаю в этом направлении. ИВ>Hardware DEP не имеет к нашему случаю никакого отношения, и потому не рассматривается.
Что значит программный и аппаратный? В данном случае это комбинация программно-аппаратных возможностей. В современных процессорах IA32 есть дополнительный бит дескриптора страницы, который запрещает выполнение кода (ранее exdecutive просто совпадал с read-write).
AS>>Я не то чтобы против thunks, но мысли по поводу AS>>1. В этом случае они совсем не нужны. Насколько я понимаю, экземпляр приложения CxxxApp у нас один, каждый сервис CxxService тоже в единственном экземпляре. Поэтому вся задача — обеспечить формирование статических экземпляров СхххService соответствующими макросами. Возможно, я чего не понял, но необходимости в thunks я тут совсем не вижу.
ИВ>Необходимость в них та же, что и в ATL. Читайте код.
Игорь, в ATL у нас возможно несколько экземпляров сущностей (окон) одного типа, поэтому мы вынуждены привязать функцию к экземпляру класса, тем или иным способом. У вас же только один экземпляр класса конкретного типа (ака синглтон), посему переходник тут смысла не имеет. Ну или скажем так — я не вижу смысла экземплярам сервиса быть не синглтонами. А параметризировать тип можно и строкой — пример приведен в моей статье. Т.о. когда количество экземпляров известно на этапе компиляции + не требуется динамического создания объектов, переходники не нужны.
AS>>2. Если уж так хочется thunks — то надо пользовать ATL, для ATL m$ сделали послабление с DEP.
ИВ> No comments.
А зря. Почитайте обсуждение DEP в блогах — наверняка найдете для себя много интересного Например, то, что для программ, написаных с использованием ATL исключения по защите выполнения обрабатываются особым способом. Также наверняка будут интересны способы эмуляции DEP без аппаратной поддержки оного с использованием теневого набора регистров.
Здравствуйте, Andrew S, Вы писали:
AS>Игорь, в ATL у нас возможно несколько экземпляров сущностей (окон) одного типа, поэтому мы вынуждены привязать функцию к экземпляру класса, тем или иным способом. У вас же только один экземпляр класса конкретного типа (ака синглтон), посему переходник тут смысла не имеет. Ну или скажем так — я не вижу смысла экземплярам сервиса быть не синглтонами. А параметризировать тип можно и строкой — пример приведен в моей статье. Т.о. когда количество экземпляров известно на этапе компиляции + не требуется динамического создания объектов, переходники не нужны.
Да, в этих замечаниях действительно есть рациональное зерно.
Действительно, мне удалось переписать SFL без переходников. Версия 2.0 смотрится для меня намного более приятной — при том что клоны все же удалось сохранить. Спасибо за настойчивость, Andrew.
Читая статью, а затем просматривая исходники появилось несколько вопросов-пожеланий:
1. Все обработчики событий выполняются в теле фунцкии HandlerEx (которая выполняется в основном потоке приложения, а основной поток выполняет функции HandlerEx всех служб). Возможно есть смысл переноса этих функций в соответствующие функции ServiceMain или хотя бы акцентирование внимания пользователя на том, что эти функции должны быть максимально короткими.
2. Прототип функции обработчика события OnStop выглядит так:
DWORD OnStop(DWORD& dwWin32Err, DWORD& dwSpecificErr, BOOL& bHandled)
{
bHandled = TRUE;
return SERVICE_STOPPED;
}
Мне кажется возвращаемое значение несколько избыточно, т.к. возможно довольно странное поведение сервиса, если вернуть из функции OnStop SERVICE_RUNNING и при этом выставить bHandled в TRUE.
Может быть лучше оставить только bHandled (в качестве параметра или возвращаемого значения), а по нему уже определять переходить в нужное состояние или нет. Т.е., если функция OnStop возвращает TRUE, то автоматом переходить в SERVICE_STOPPED, а иначе сообщать об ошибках и не переходить в новое состояние.
Здравствуйте, Serrega, Вы писали:
S>Читая статью, а затем просматривая исходники появилось несколько вопросов-пожеланий:
Это хорошо.
S>1. Все обработчики событий выполняются в теле фунцкии HandlerEx (которая выполняется в основном потоке приложения, а основной поток выполняет функции HandlerEx всех служб). Возможно есть смысл переноса этих функций в соответствующие функции ServiceMain или хотя бы акцентирование внимания пользователя на том, что эти функции должны быть максимально короткими.
Все обработчики управляющих кодов изначально выполняются в Handler-функции — такова архитектура сервисов. Перенос их куда-либо возможен только созданием отдельного потока (поток ServiceMain в SFL завершается сразу же после выхода из ServiceMain — что бы там ни писал Рихтер) и немедленным возвратом соответствующего pending-статуса. Не понимаю, зачем этим должна заниматься SFL? Хотя мне все же надо будет подумать над этим вопросом, возможно в SFL v2.0 что-то изменится.
Акцентированием внимания на том, что эти функции должны быть максимально короткими, успешно занимается и MSDN, и Рихтер — не представляю, как можно писать сервис, не прочитав "первоисточники". Потому я и предупредил в самом начале статьи — ликбеза не будет.
S>2. Прототип функции обработчика события OnStop выглядит так: S>DWORD OnStop(DWORD& dwWin32Err, DWORD& dwSpecificErr, BOOL& bHandled) S> { S> bHandled = TRUE; S> return SERVICE_STOPPED; S> } S>Мне кажется возвращаемое значение несколько избыточно, т.к. возможно довольно странное поведение сервиса, если вернуть из функции OnStop SERVICE_RUNNING и при этом выставить bHandled в TRUE.
Можно подробнее про странное поведение, если вернуть из OnStop статус SERVICE_RUNNING?
S>Может быть лучше оставить только bHandled (в качестве параметра или возвращаемого значения), а по нему уже определять переходить в нужное состояние или нет. Т.е., если функция OnStop возвращает TRUE, то автоматом переходить в SERVICE_STOPPED, а иначе сообщать об ошибках и не переходить в новое состояние.
Из OnStop нормальным образом можно перейти как в SERVICE_STOPPED, так и в SERVICE_STOP_PENDING (то же можно сказать и всех о прочих обработчиках). Собственно, для этого и сделана подобная схема возврата двух значений — значения статуса и признака обработки.
Насчет "не переходить в новое состояние" — MSDN однозначно говорит:
Writing a Control Handler Function
The MyServiceCtrlHandler function in the following example is the Handler function. When this function is called by the dispatcher thread, it handles the control code passed in the Opcode parameter and then calls the SetServiceStatus function to update the service's status. Every time a Handler function receives a control code, it is appropriate to return status with a call to SetServiceStatus regardless of whether the service acts on the control.
Спасибо за фидбек. Хотел бы все же услышать о "странном поведении".
Здравствуйте, Игорь Вартанов, Вы писали:
ИВ>Все обработчики управляющих кодов изначально выполняются в Handler-функции — такова архитектура сервисов. Перенос их куда-либо возможен только созданием отдельного потока (поток ServiceMain в SFL завершается сразу же после выхода из ServiceMain — что бы там ни писал Рихтер) и немедленным возвратом соответствующего pending-статуса. Не понимаю, зачем этим должна заниматься SFL? Хотя мне все же надо будет подумать над этим вопросом, возможно в SFL v2.0 что-то изменится.
Но ведь довольно просто сделать, чтобы ServiceMain() не завершалась сразу же, а ждала "сообщений" от Handler-функции о том, что пришел управляющий код от SCP (подробности ниже).
S>>2. Прототип функции обработчика события OnStop выглядит так: S>>DWORD OnStop(DWORD& dwWin32Err, DWORD& dwSpecificErr, BOOL& bHandled) S>> { S>> bHandled = TRUE; S>> return SERVICE_STOPPED; S>> } S>>Мне кажется возвращаемое значение несколько избыточно, т.к. возможно довольно странное поведение сервиса, если вернуть из функции OnStop SERVICE_RUNNING и при этом выставить bHandled в TRUE.
ИВ>Можно подробнее про странное поведение, если вернуть из OnStop статус SERVICE_RUNNING?
Я только что из своей службы на команду SERVICE_CONTROL_STOP вернул статус SERVICE_RUNNING, при этом получил интересное сообщение: "Не удалось остановить службу MyService на Локальном компьютере. Эта служба не возвращала ошибки. Возможно это внутренняя ошибка Windows или службы."
Не сказать, что сильно странное сообщение (и поведение), но ведь подобных вещей впринципе можно избежать и при этом упростить пользователю SFL создание функций обработчиков.
Подумай над таким предложением:
Cигнатура обработчика сообщения выглядит так:
BOOl OnEvent(DWORD &dwWin32Err, DWORD &dwSpecificErr);
В функции обработчике сообщения перевести состояние сервиса в соответствующее pending состояние (например SERVICE_STOP_PENDING на управляющий код SERVICE_CONTROL_STOP) и передать управление ServiceMain.
В функции ServiceMain() вызвать пользовательскую функцию обработки сообщения (OnStop).
При успешном выполнении функции обработки сообщения перевести состояние сервиса в новое устойчивое состояние (SERVICE_STOPPED).
В случае ошибки — передать коды ошибок SCM.
Мне кажется такое поведение несколько понятнее и проще для пользователя библиотеки.
Да, кстати, еще: зачем в библиотеке нужна функция OnInterrogate. Нет, я знаю зачем она нужна в принципе и что она должна делать, но зачем ее давать определять пользователю? Ведь ее нужно реализовывать каждый раз, да и библиотека ведь всегда знает, в каком состоянии находится сервис, можно вполне переложить реализацию этой функции на библиотеку?
ИВ>Спасибо за фидбек. Хотел бы все же услышать о "странном поведении".
Для начала подумайте о необходимости переходников здесь вообще. Игорь вроде как потом со мной в этом согласился. Т.е. необходимости привязывать экземпляр объекта к callback функции тут вроде бы и нет, поскольку все объекты — синглтоны (кстати, приведенный в статье пример thunk очень непрактичен. Во-первых, занимает много места, во-вторых, используются регистры). На мой взгляд, thunk в данном случае, когда нет "ненужного" параметра, должен делать нечто вроде:
pop DWORD PTR [esp + 8] // перемещаем адрес возврата на нужное место
push DWORD PTR this
sub esp, 4
jmp callback
Очевидно, в этом случае callback функция будет с одним дополнительным первым параметром, который и будет определять контекст вызова. Получается и проще, и дешевле чем то, что в статье.
А то что в статье по данной вами ссылке... кратко я могу это охарактеризовать лишь так — БРЕД.
Например, можно помедитировать над тем, что автор статьи предлагает делать, когда нет возможности передать UserData в callback функцию (когда она есть, все конечно тривиально и рассматривать этот случай вообще смысла не имеет). Имхо, thunk в этом случае в разы лучшее решение. Не говоря уже о том, что _declspec(thread) фактически убивает возможность использования подобного решения в dll. В общем, та статья никак не претендует на то, что она представляет удобоваримое решение описываемой в ней же проблемы. По-крайней мере, на мой взгляд.
Есть знакомая функция VOID WINAPI ServiceMain(DWORD dwArgc, PTSTR* pszArgv);
Цель — чтобы в качестве callback-функции была вызвана функция-член класса.
AS>Очевидно, в этом случае callback функция будет с одним дополнительным первым параметром, который и будет определять контекст вызова. Получается и проще, и дешевле чем то, что в статье.
Хотелось бы увидеть реализацию
Мне кажется, что одним дополнительным аргументом здесь не обойтись и идея из статьи по данной ссылке мне кажется очень ничего(по поводу __declspec(thread) я согласен, у меня с этим не заработало).
В статье предлагается такой подход (ниже приведен частный случай):
class MyService //не будем забывать о целях обсуждения
{
public:
MyService()
{
MyService::_this = this;
};
static VOID WINAPI _ServiceMain(DWORD dwArgc, PTSTR* pszArgv)
{
return _this->ServiceMain(dwArgc, pszArgv);
}
VOID WINAPI ServiceMain(DWORD dwArgc, PTSTR* pszArgv)
{
//вот мы попали в функцию член
}
private:
static MyService* _this;
};
MyService *MyService::_this = NULL;
У себя в тестовом проекте я добавил запись в файл в функции VOID WINAPI ServiceMain(...). Заработало
Кстати этот подход работает только в том случае, если у каждого экземпляра класса будет только ОДИН экземпляр (что обсуждалось ранее и удоавлетворяет постановке задачи).
AS>А то что в статье по данной вами ссылке... кратко я могу это охарактеризовать лишь так — БРЕД.
Я еще раз хочу подчеркнуть, что вышеприведенный код — это частный случай адаптера StaticCB2. И мне это бредом совсем не кажется. Кроме того, альтернативы я не знаю. Если у кого есть идеи — милости просим
Ну про то и речь. В моем варианте thunk эта функция будет иметь вид:
VOID WINAPI ServiceMain(void *pThis, DWORD dwArgc, PTSTR* pszArgv);
S>Кстати этот подход работает только в том случае, если у каждого экземпляра класса будет только ОДИН экземпляр (что обсуждалось ранее и удоавлетворяет постановке задачи).
Если у класс один экземпляр, то thunks не нужны, что и требовалось доказать. Собственно, из этой статьи все очевидно. Как и какие-либо другие извращения для получения _this, кстати. Обычный синглтон майера решит все наши проблемы. Мы будем иметь доступ к нему в любом месте программы путем вызова CMyServive::GetInstance. Да и он тут по сути дела не нужен. Обычная глобальная переменная решит все наши проблемы. Приведенное решение из статье — ровно то же самое, но другими словами, просто глобальная переменная.
Вероятно, можно представить ситуацию, когда нужно зачем то более чем один одинаковый сервис (т.е. экземпляров объекта CMyService больше чем один), но и в этом случае есть вариант для каждого экземпляра сформировать переходники на этапе компиляции (например, специализировав шаблон, содержащий callback и являющийся финальным классом, который и будет инстанцироваться как глобальная переменная, счетчиками времени компиляции). В общем, еще раз повторюсь — если необходимости динамически создавать экземпляры объектов сервиса нет (а эту необходимость я себе представить ну совсем не могу), то никакие thunks тут не нужны.
AS>>А то что в статье по данной вами ссылке... кратко я могу это охарактеризовать лишь так — БРЕД. S>Я еще раз хочу подчеркнуть, что вышеприведенный код — это частный случай адаптера StaticCB2. И мне это бредом совсем не кажется. Кроме того, альтернативы я не знаю. Если у кого есть идеи — милости просим
Мысль я вам привел. Реализация (путем простейшей модификации atl::thunk) тривиальна. Защита от XP sp2 — выделять thunk из специального пула, как сделано в ATL 7.0. Все просто и логично — чего ж вам боле? (это я безотносительно применения переходников в данном функционале)
К сожалению, пока не доступна — на соответствующую статью, сопровождающую код, просто нету времени. Хотя в частном порядке могу отдать без проблем, милости прошу в мыло.
