в котором что-то достойное бывает не каждую неделю
Что ж, если Вы так считаете, то почему бы Вам лично статью на данной платформе не написать? Почему нет? Расскажите о решении какой-нибудь задачи из области системного или прикладного программирования, напишите хорошую статью так, как Вы её видите. Покажите своим примером как нужно статьи писать)
Ведь рассуждать так любой горазд мол "унылое болото", "платформа скатилась" и т.д. и т.п., но почему-то показать своим примером "как надо делать" не у каждого получается. Или Вы только потребитель? Посмотрел на Ваши статьи в профиле и там нет ни одной публикации после 2015 года, зато комментируете другие статьи до сих пор. А оценки то у статей неплохие, почему бы Вам не продолжить публиковать материалы? Чем больше технического контента на платформе, тем лучше.
Ладно бы если эти комментарии были не критикой ради критики, а несли в себе что-то действительно важное, что можно подчерпнуть и добавить в само содержимое статьи (от этого, повторюсь, выигрывают все), но конкретно Ваша критика мне видится очень субъективной и по сути просто критика ради критики, типа хобби, а вот конкретно к коду никаких замечаний у Вас нет (кроме холиварной темы "что есть Си, а что есть C++", которую продолжать я не хочу, поскольку у каждого своё мнение на этот счёт и я останусь при своём).
Станьте тем автором Хабра, который будет писать "достойные статьи", покажите как надо) Желательно каждую неделю) Буду лично читать Ваши статьи и набираться опыта того, как надо писать такие статьи на темы системного программирования) (не сарказм, уверен у Вас есть чему поучиться).
Даже если Вы искренне в это верите, то это, к сожалению, лишь иллюзия. То, что Вы способны писать пространные тексты и собирать в кучу обрывки разнородных материалов, не имеет отношения ни к качеству, ни к углублению знаний.
Вообще, любая вера, можно сказать, иллюзия. Но это уже плоскость философии, так что согласен. Кто на что горазд, так скажем)
Я собираю не обрывки, а описываю полноценный процесс создания служб, не более. А вот уж каким образом я углубляю знания - Вам навряд ли известно. Лично я разобрался в теме настолько, насколько требовалось и попытался до читателя донести усвоенный самим собой материал. Успешна эта попытка или нет - покажет время.
Если не хотите, чтобы над Вами смеялись - или углубляйте знания перед тем, как излагать их на публике, или излагайте только то, в чем уже достаточно глубоко разобрались и имеете опыт.
Спасибо за совет, но я сам лучше для себя решу что мне делать - публиковать материал или нет. Я не чувствую, что надо мной тут "смеются", скорее у читателей могут быть идеи по улучшению статьи, чему я всегда рад.
А если даже кто-то и смеётся, то это моя проблема или проблема тех, кто смеётся? :)))
Я свой уровень и свои возможности прекрасно знаю, есть ещё куда расти)
Даже если бы я был ИИ, то зачем мне это? Зачем мне писать эту статью с помощью ИИ или сгенерировать её полностью самим ИИ?
У меня ведь даже мотивации толком нет, чтобы генерировать статьи, польза от которых и для меня (человека), и для читателей (вот тут уже сложно - может быть и человек, а может быть и ИИ) может быть минимальна. Я наоборот стремлюсь к качеству материала и углублению как своих знаний, так и знаний читателя.
Плюс не рассмотрены кейсы когда требуются ретраии и случаи когда функции SCM зависают и нужно делать асинхронные вызовы.
Не могли бы Вы подробнее описать данную проблему, которая может возникнуть? Хотелось бы её подробнее изучить. Если скинете ещё и ссылки на материал - будет вообще замечательно) Не совсем просто понимаю, когда функции SCM могут зависнуть и что имеется ввиду под "асинхронными вызовами" (понятно что это такое, но в контексте SCM'а - непонятно)
О том и речь, что автор взял на себя задачу, адекватно вывезти которую он не в состоянии. Ему еще учиться и учиться до того, как учить кого-то другого.
Ну, у меня отличные помощники в комментариях ;)
Читатель может узнать о том, куда глубже копнуть или что лучше изучить на основе критики, а это конечно отлично скажется на понимании материала или его дополнении, что безусловно только плюс)
Вы посмотрите сколько Вы уже всего написали в комментариях. Может быть это и критика ради критики, но, кого-то да направит на "путь истинный" :)
Если автор отличает Си от C++ по расширению, да ещё утверждает, что hpp якобы используется для исходников на чистом Си
Да ошибся я, ну не могу поправить комментарий) Расширение hpp не используется для исходников на чистом Си)
Работа и вправду проделана большая, но выставленный автором высокий уровень сложности совершенно не соответствует действительности. Это, несмотря на размер, достаточно простая статья, причём весьма низкого качества. Я бы категорически не рекомендовал её использовать будущим читателям как учебное пособие или что-то в этом роде.
Можете пожалуйста подробнее раскрыть суть предложения "причём весьма низкого качества"? Я бы хотел эту статью улучшить, если она действительно получилась не очень хорошего качества. Почему она низкого качества и чего в ней не хватает? Что бы Вы хотели видеть в данной статье, чего ещё нет? Любые предложения по её улучшению принимаются)
Простая статья может быть для конкретно Вас, но тех, кто в первый раз работает с такой задачей - это может быть сложно. Я не из-за размера её уровень поставил, а из-за содержимого, потому как посчитал его сложным. Но, это уже моё субъективное мнение) Оценка сложности - дело индивидуальное
Что могу сказать (потому что спорить немного надоело) - это полностью Ваше мнение. Правильно оно или нет - покажет время. Может быть через года опыта я приду к тому, что этот туториал содержит в себе некорректные подходы и с радостью его поправлю. Но пока никакой конкретики от Вас я не увидел
Но что-то, правда, заставляет меня сомневаться, что автор статьи писал слово "высокоуровневый", понимая все это, а не просто с намерением простыми, универсальными, но малозначащими словами отделаться от критики (ну, или его ИИ набрался таких словечек во всяких интернетах).
Про протокол DCE RPC (AFAIK) я не слышал, но знаю, что RPC обозначает удалённый вызов процедур. Где-то об этом уже читал (конкретно об использовании RPC в SCM), но действительно не углублялся в такие особенности.
С WinAPI я знаком на поверхностном уровне достаточном для решения прикладной задачи, не более. Я не утверждал, что я эксперт в WinAPI, я лишь понимаю на высоком уровне что это, в широком смысле, набор функций для работы с элементами Windows.
И я не ИИ. (и тут у кого-нибудь закралась мысль, что я всё это пишу с ИИ, потому что только ИИ будет отрицать что он ИИ :))
Фишка в том, что мало-мальски опытный программист таких ляпов не допустит, это где-то на уровне подкорки.
Ну, это Ваше мнение, как и всё прочее. Вы знаете как работает мозг на уровне "подкорки"? Расскажите об этом. Интересны Ваши знания в области нейрохирургии) Вдруг Вы бывший нейрохирург и отлично знаете как работает мозг программиста? Всё может быть)
И таких пространных объяснений мало-мальски опытный программист тоже давать не будет. Это порождает сомнения в том, что Вы сколько-нибудь хорошо знаете что C, что C++, и что у Вас есть мало-мальски приличный опыт их использования.
Вообще, поделюсь своим опытом использования C++ (не смотря на Ваше субъективное мнение он у меня есть): с данным языком программирования я знаком ещё со школы. В школьные годы писал свою текстовую базу данных, простые приложения на WinAPI (преимущественно связанные с графикой), пробовал писать компилятор под Pascal и сделал дюжину консольных игр (для обычной консоли, терминала).
После школы учился в университете, где C++ использовал, к сожалению, крайне мало. В основном приложения на Qt, какие-то лабораторки, ну а затем и вовсе перешёл на Java/C#/JavaScript/Python, а о нём вспомнил только пару месяцев назад, когда потребовалось разобраться в вычислениях на CUDA. Ну и по работе появились задачи, которые с этим языком необходимо решать, а опыт его использования у меня есть.
Вообще этот язык мне очень импонирует и я с ним, можно сказать, мечтал "серьёзно" поработать. В общем-то сейчас я с ним и работаю "серьёзно"). Не зря же я читал кучу литературы об этом языке в своё время) А так я больше программировал на JavaScript/TypeScript последние пару лет.
Если программист успешно работает с каким-то одним языком программирования, то перейти на другой язык программирования (тем более с которым он работал ранее) будет не так трудно. Ведь программист уже не новичок и понимает как строятся программы. Я не новичок, в программировании уже довольно давно и это моё дело. Я его выбрал, я им занимаюсь, я в нём со временем расту.
По тексту комментариев или статьи очень сложно понять какой у программиста уровень, потому что словесное изложение мыслей это не тоже самое, что извергать код на интуитивно понятном уровне, который решает определённым образом задачу через какой-то алгоритм. Не знаю, как Вы этот уровень оцениваете.
Опубликовав статью на тему системного программирования, без предисловия в стиле "я вообще-то токарь, но вот почитал того-сего, и решил свести воедино, больно не бейте, если налажал", Вы заявили о себе, как о квалифицированном специалисте. Допуская в комментариях откровенные ляпы, Вы и палитесь.
Да, я квалифицированный специалист из области программной инженерии. Я не палюсь, а допускаю ошибки - это нормально. Даже если эти ошибки "откровенные ошибки". И я не стану писать "больно не бейте, если налажал" чтобы получить какого-то "снисхождения" (думаю Вы это имели ввиду) потому что если налажал - исправлю, если будут "бить" могу "стукнуть" в ответ. Всё довольно просто.
Вы действительно полагаете, что типичный дилетант в системном программировании, на которого ориентирована Ваша статья, даже не то, чтобы поймет, а вообще заметит эту ремарку?
Моя статья ориентирована не на дилетантов, а на тех, кто более менее уже разбирается в программировании на C++ :) Посмотрите на уровень сложности статьи. Там стоит - "Сложный". Содержание соответствует уровню.
Беда в том, что Вы этого не понимаете (как и ряда других вещей), однако берете на себя функцию обучающего, а не обучаемого.
Я допускаю, что у меня есть пробелы в знаниях, но при выявлении этих пробелов я их успешно ликвидирую со временем. Я писал статью не только для того, чтобы предоставить материал по которому можно службы написать, но ещё и сам повторял уже изученные элементы и укреплял о них своё понимание. Так что я и обучающийся, и обучающий. Для кого как. Всё субъективно.
Элементарно: служба, которую по Вашему туториалу напишет дилетант, скорее всего, будет работать с файлами и/или реестром. Если он, замыслив удалить со всем содержимым какой-нибудь временный каталог или созданную им ветку реестра, перепутает пути, и сделает это с системными путями, то в обычном непривилегированном приложении он получит отлуп, а в службе этот код исправно отработает.
Я ну искренне не понимаю, причём тут данный туториал? Вы утверждали, что в коде есть проблемы с надёжностью и безопасностью в своём комментарии выше:
Вероятность использования этого материала для создания сколько-нибудь адекватной и полезной службы, не создающей проблем с надежностью и безопасностью, стремится к нулю.
Я же правильно всё понял? Или Вы что-то другое имели ввиду?
Я попросил Вас - укажите на мои ошибки. Неоднократно это делал, однако так и не дождался конкретики, сплошная теория. И сейчас Вы пишите мол "ошибка будет тогда, когда какой-нибудь программист напишет то и то, вот тогда будет беда", а про конкретно текущий код у Вас нет претензий, я правильно понимаю? Я что-то уже запутался если честно) Какая-то критика ради критики)
Если у Вас есть конкретные предложения по улучшению статьи - предлагайте, с радостью это сделаю. Если их у Вас нет (с каждым комментарием я в этом только убеждаюсь), то ок - зачем тогда критика? Ради критики? Она ведь далеко не всегда у Вас объективна, скорее очень очень субъективна и со многим из этой критики я не согласен, кроме указаний моих фактических ошибок (по типу ошибки понимания формата *.hpp как *.c).
А если он сколхозит свою службу так же, как нынче принято писать пользовательские приложения, то в ней с высокой вероятностью будет изрядный набор удобных целей для атак.
Видимо упоминания того, что службы работают в фоновом режиме было не достаточно. Ладно. Какой изрядный набор удобных целей для атак есть в описанном Вами случае? Интересно узнать.
Среднестатистическому программисту вообще нечего делать в области драйверов и служб
Почему? Есть какие-то ограничения? Программист (любой) может заинтересоваться этой областью и начать делать службы и писать драйвера. Возможно успешно, возможно не очень. Делать ему так определённо есть что, если ему это интересно.
Вы пытаетесь сформировать образ системного программирования как то, что доступно лишь "элите", "первоклассным стрелкам по ногам с помощью кольта C/C++", которые читают только жёсткую техническую литературу и знают точно-точно всё из своей области, потому что войти в неё сложно. Ну или чтобы в неё войти, надо прочитать кучу технической литературы.
Я ж не спорю. Системное программирование - действительно классная область, со своими проблемами, задачами и интересными особенностями. И да, чтобы в этой области хорошо разбираться нужно кучу технической литературы изучить и программировать низкоуровневые штуки. Но войти в эту область среднестатистический программист может, если захочет (и ничего Вы с этим не сделаете).
Боитесь конкуренции в системном программировании? Это лишнее, задач на всех хватит)
Это можно легко понять и по исходным файлам где определяются функции для службы - они используют расширение *.cpp, а не *.hpp, которые обычно используют для исходников на чистом Си.
Здесь не корректно указал расширение - *.c, а не *.hpp (корректировка комментария не возможна из-за ограничений по времени)
Вы уже второй раз откровенно палитесь с этим ".hpp"
Да, это действительно моя ошибка. Я почему-то про этот *.hpp формат принял ошибочно за *.c, действительно ошибся.
Заголовки для Си указываются конечно же в файле с расширением *.h, а исходники с расширением *.c. Для C++ исходники с расширением *.cpp, а заголовки можно как *.h или *.hpp оформлять. Тут Вы верно подметили.
Однако я не "палюсь", это лишь ошибка которую я в комментариях уже никак поправить не могу. Чтобы "палится" нужно сначала кем-то "казаться" или формировать образ о себе, всем о нём говорить и не подтверждать его своими действиями или словами. С тем же успехом можно утверждать, что Вы "палитесь" что не HTML-верстальщик, ведь HTML-верстальщики так не пишут :)
Увлекшись разжевыванием деталей, очевидных для любого мало-мальски опытного программиста, Вы даже ни словом не упомянули того, что служба по умолчанию запускается от имени системы (LOCAL_SYSTEM), а это еще серьезнее, чем права администратора.
Как это не упоминаю? Я это чётко обозначил в программном коде:
// Создание службы и получение её дескриптора
schService = CreateServiceA(
schSCManager, // Дескриптор SCM
SVCNAME, // Имя службы (отображается в диспетчере устройств)
SVCDISPLAY, // Краткое описание службы (отображается в диспетчере устройств и окне "Службы")
SERVICE_ALL_ACCESS, // Определение прав для службы (полный доступ)
SERVICE_WIN32_OWN_PROCESS, // Тип службы
SERVICE_DEMAND_START, // Тип запуска
SERVICE_ERROR_NORMAL, // Тип контроля ошибки
szPath, // Путь до исполняемого файла службы
NULL, // Группа
NULL, // Тег идентификатора
NULL, // Зависимости
NULL, // Стартовое имя (LocalSystem)
NULL); // Пароль
Если бы я расписывал все параметры функции CreateServiceA, то статья выросла бы ещё больше)
А какой смысл читатель Вашей статьи должен извлечь из этой фразы: "Функция StartServiceCtrlDispatcher соединяет основной поток процесса службы с SCM, в результате чего этот поток становится потоком SCM для вызывающего процесса"?
Что значит "соединяет поток"? Что такое "поток SCM для вызывающего процесса"?
Согласен, могут возникнуть трудности в понимании что тут я сформулировал. Думаю подкорректирую этот текст позже, чтобы не было недопониманий
Не могли бы Вы рассказать что такое WinAPI? Интересно узнать, чем Ваше понимание отличается от этого или вот этого понимания WinAPI.
Прежде чем на кого-то "указывать пальцем" убедитесь в том, что первый на кого Вы укажите должны быть не Вы.
Вы то точно понимаете как работает WinAPI, разницу между Си и C++, и можете "закрытыми глазами" определить пишет другой человек на C++ или на Си, верно? А если понимаете - поделитесь своими мыслями. А то никакой конкретики, если честно, я не услышал. Сплошная критика ради критики. Никаких замечаний по коду.
Если считаете что служба написана некорректно и где-то её можно поправить - дайте замечания программному коду и укажите где конкретно можно его поправить и как. Это будет гораздо ценнее, чем критика ради критики.
Скажите честно, какая часть написанного Вами сгенерирована ИИ?
Никакая, сам всё писал и в том числе комментарии. Не верите? Это нормально, сейчас очень много статей которые пишутся с помощью ИИ. По мне так такой труд не приносит пользы ни читателю, ни самому автору.
WinAPI - это ведь API, который является по сути набором высокоуровневых абстракций для программирования под Windows. Возможно есть способ написать службу и без использования WinAPI на чистом Си. Для этого нужно разработать какие-то свои похожие на WinAPI функции для работы с SCM. Грубо говоря повторить реализацию WinAPI, которая нужна для написания служб) Я об этом.
Написав эту статью, Вы повысили вероятность того, что однажды в Вашей системе появится очередная кривая служба, слепленная на коленке одним из таких новичков, который без Ваших подробных разъяснений этого не осилил бы
Вообще не понимаю причём тут данный туториал и "очередная кривая служба". Если она действительно кривая, то будьте добры объяснить в чём эта кривизна проявляется. Мне на данный момент это не понятно, как и какие могут здесь возникнуть проблемы с безопасностью.
Не все туториалы одинаково полезны. Например - "пошаговое руководство по сборке авиационной бомбы на кухне".
Согласен. Можно сделать его максимально полезным, если Вы поделитесь своим профессиональным опытом написания служб на C++ и расскажите какие минусы в представленной в статье реализации есть ("кривизна", "плохая безопасность").
В следующий раз, когда Вам встретится очередной кривой драйвер, инсталлятор, "оптимизатор реестра" или что-нибудь подобное - постарайтесь не забыть, что Вы лично внесли свою лепту в эту тенденцию.
Отнюдь, не вижу связи. В туториале рассматривается самое базовое приложение для управления службами ну и сама служба. Если программист пишет "кривой драйвер", то наверное ему его нужно исправить? А как написать "не кривой драйвер" если ты никогда не ошибался при его написании? Иными словами чтобы написать хороший драйвер нужно ошибаться, но необязательно. Ошибается ли среднестатистический программист при написании драйвера? Да, ошибается. Обязательно ли это? Нет, не обязательно. Вношу ли я прямо или косвенно вклад в то, что кто-то пишет кривой драйвер? Навряд ли, потому что в результате туториала создаётся базовая служба и приложения для управления ею, а не драйвер.
Чтобы программист стал профессионалом - ошибаться нормально, особенно когда программист готов эти ошибки исправлять и понимать почему это ошибка, собственно, возникает.
"Довольно устаревшие" - это Ваши тексты якобы на C++ (понятное дело - для кликбейта)
Никакой цели добавить в текст статьи "кликбейт" я не преследовал. То, что я использую именно C++, а не Си можно понять банально по расширению файлов исходного кода: там *.cpp используется, а не *.hpp.
Если я использую инструкции, которые можно на Си написать, это не значит что я использую везде Си.
Стыдно должно быть за такое
Почему стыдно? И почему должно так быть? Не понимаю. Материал я написал разобравшись в этой теме настолько, сколько необходимо для написания своей службы на C++ для решения прикладной задачи. Изученный мной материал я подробно расписал в виде туториала и выложил его на данную платформу. Писал я его для себя и для читателей, которым интересна данная тема. Хорошо бы если через пару лет вернувшись к этому материалу и я и читатель отлично понимал как разработать свою службу на Windows с использованием C++ и, может быть, щепоткой Си. Не знаю, за что мне должно быть стыдно.
И что же в Windows 10/11 появилось нового в отношении служб?
Ну за 20 лет точно что-то новое появилось) Будьте уверены) Что именно - я не знаю, но учитывая что кодовая база Windows растёт, то и службы (API для их работы и управления) эта кодовая база точно задевает)
Где-то оптимизацию поправили, где-то новое API добавили, где-то поток по другому работает или раздробили один на два. Ну, в общем точно что-то поменялось. На этот счёт можно другую статью написать о том, как изменилась работа служб в Windows) Я лишь исхожу из того, что развитие ОС Windows во времени предполагает изменения её API и подходов для разработки служб (как пример).
Считать, что ничего не изменилось - тоже не корректно. Известно же что в ИТ всё очень быстро развивается. А если это не так - нужны пруфы.
Спасибо за то, что уделили время поиску данных источников, думаю что они действительно могут расширить общее представление о том, как эти службы разрабатывать)
Однако представленные источники (кроме двух) не описывают полностью процесс разработки служб, а лишь рассказывают о некоторых их особенностях (где-то есть только установка и деинсталляция, а где-то и этого нет). Материал из данных источников довольно устаревший (есть ссылка где публикация была аж в 1996 году), и какие-то концепции могут быть подвержены критике (что-то может уже не использоваться).
Более близкий материал по содержанию есть по Вами приведённым ссылкам (там есть всё, о чём я писал и даже больше):
Это действительно бесценный материал, который стоит изучить. Конечно Windows NT (2005 года) это не Windows 10 (на которой я службу разрабатывал) и не Windows 11, но, думаю, есть какие-то общие детали, которые и там и тут используются. В книге по системному программированию так вообще всего предостаточно)
В любом случае нужно периодически актуализировать информацию со старых источников, не даром книги переиздаются и корректируются (особенно технические).
Лет тридцать назад подобная статья могла бы представлять какую-то ценность, но сейчас - увы.
Почему? И сейчас встречаются реальные задачи где нужно разработать службу для Windows или Linux. Я, например, сейчас такой задачей и занимаюсь. Если бы я где-то аналогичный материал нашёл, то для меня этот материал был бы ценен.
Ценность материала - штука очень субъективная. Для опытных профессионалов эта статья может нести нулевую ценность из-за того, что они всё это уже знают, а для новичков в этой теме она ценна.
Тип данной статьи - туториал, я не зря же его таким поставил. Туториал предполагает, что будет решена какая-то полезная задача пошагово. Ровно это я и делаю - решаю интересную мне задачу пошагово, с описанием всех своих действий чтобы интересующийся читатель мог эти действия воспроизвести и получить полезный результат в виде работающего приложения для управления службой на Windows.
В заголовке претенциозно заявлено "на C++", а за основу взяты древние тексты на чистом C, к которым сбоку прикручены отдельные элементы C++ вроде вызовов logger.
Вообще, я использую в данном проекте C++. Это можно легко понять и по исходным файлам где определяются функции для службы - они используют расширение *.cpp, а не *.hpp, которые обычно используют для исходников на чистом Си.
Общеизвестно что C++ старается сохранить обратную совместимость с Си, на базе которого этот язык и построен. Однако если я использую Си код в проекте на C++ это не значит, что я везде использую чистый Си. Я мог бы добавить классы в файле WinService.h и все функции сделать методами и тогда не получать замечания по поводу того, что я C++ использую, а не Си) Но я это сделал намерено для упрощения, потому что на C++ можно писать код в любом стиле, в том числе Си-стиле, что я и сделал.
И для объективности, если Вы сейчас зайдёте в репозиторий dev-win-sc, то увидите, что там C++ кода больше, чем кода на Си:
Как видите даже CMake инструкций в проекте больше, чем чистого кода на Си) А я сомневаюсь, что GitHub сильно ошибается в оценке кодовой базы, а если и ошибается - нужны пруфы, которых у меня нет (если у Вас есть - было бы интересно с ними ознакомится).
Везде трудолюбиво используются типы указателей с префиксом LP которые потеряли смысл сразу после перехода с 16-разрядной архитектуры на 32-разрядные.
Я использовал части кода из официальной документации Microsoft, которая обновлялась сравнительно недавно (13.06.2023, если верить содержимому их статей), поэтому сомневаюсь что префикс LP потерял свою актуальность. Если в официальной документации используются устаревшие и нерабочие элементы API, то согласитесь, такая документация была бы вредна и люди вообще бы не смогли сами такие службы разрабатывать, просто потому что актуальной инфы по этому поводу нет? Нельзя же наугад что-то делать, нужны хоть какие-то зацепки. Поэтому считаю что данное замечание не корректно.
Совершенно непонятно, для чего нужно столь подробное разжевывание
Честно говоря, я бы разжевал ещё более подробнее и глубже, но статья и так получилась большой, поэтому разжевал так, чтобы я или читатель вернувшись к этой статье через 1-2 или более лет смог совершенно спокойно понять о чём тут идёт речь и как разработать службу на C++.
Системные службы следует делать программистам, имеющим достаточную квалификацию, а для таких более чем достаточно уже имеющейся документации
Каких "таких"? Не понятно под кем Вы понимаете "таких". Может быть "такие" программисты тоже хотят стать квалифицированными специалистами в этой области и чтобы освоить эту тему такой материал им может быть полезен. Тем более я постарался дать теоретическую базу по службам в Windows, прежде чем приступить к их разработке чтобы было более понятно что они вообще есть такое и зачем нужны.
Статья может быть полезна разве что прикладникам на каких-нибудь JavaScript/Python, которые про C++ только слышали краем уха, но которым приспичило наваять службу, дабы значок их приложения всегда был в области уведомлений
Ну вот, уже хоть для кого-то данная статья имеет ценность) Служба - это не про "значок в области уведомлений", это про осуществление полезной работы в фоновом режиме. Да и программисты на JavaScript/Python/<любой другой язык кроме C/C++> может быть заинтересован в получении опыта работы на C++ для совершенно разных целей. Может быть интерес к самому языку, к работе на данном языке или повышение квалификации. Не думаю, что программист с минимальными знаниями C++ сможет хорошо понять то, что в статье происходит. Всё таки для её чтения нужно иметь хотя бы "средние" знания C++ и как на нём разрабатывать полноценные приложения.
Вероятность использования этого материала для создания сколько-нибудь адекватной и полезной службы, не создающей проблем с надежностью и безопасностью, стремится к нулю. :(
Не могли бы Вы рассказать о проблемах, которые связаны с надёжностью и безопасностью в изложенном мной материале? Было бы неплохо его улучшить, если Вы действительно знаете где в исходном коде есть потенциальные проблемы и как от них избавится, я бы мог внести правки в свой материал и те, кто будет его читать получат возможность побольше узнать об устройстве служб и как делать "не нужно".
На данный момент я все дескрипторы освобождаю и делаю все возможные проверки на разных этапах работы управляющих функций и на данный момент не вижу проблем с надёжностью и безопасностью, может быть Вы на них прольёте свет я буду этому только рад.
Думаю, что использование таких уже готовых шаблонов может быть уместно тогда, когда программист имеет полное понимание как эти службы вообще устроены, как они работают и как ими управлять из своей программы на более низком уровне.
В статье я не ставил цель "ускорить процесс разработки служб на Windows" потому что понятно, что для этого можно использовать уже готовые средства и инструменты заложенные в Delphi или C#. Так будет проще, быстрее и не нужно думать о том, как там всё внутри устроено. Однако такой вариант меня не устраивает, немного надоело, что везде всё уже сделано, и что "нужно использовать готовые решения".
Готовые решения это конечно хорошо, но сделать что-то самому с нуля, разобраться во множестве тонкостей и решить кучу проблем - это очень полезно.
Что ж, если Вы так считаете, то почему бы Вам лично статью на данной платформе не написать? Почему нет? Расскажите о решении какой-нибудь задачи из области системного или прикладного программирования, напишите хорошую статью так, как Вы её видите. Покажите своим примером как нужно статьи писать)
Ведь рассуждать так любой горазд мол "унылое болото", "платформа скатилась" и т.д. и т.п., но почему-то показать своим примером "как надо делать" не у каждого получается. Или Вы только потребитель? Посмотрел на Ваши статьи в профиле и там нет ни одной публикации после 2015 года, зато комментируете другие статьи до сих пор. А оценки то у статей неплохие, почему бы Вам не продолжить публиковать материалы? Чем больше технического контента на платформе, тем лучше.
Ладно бы если эти комментарии были не критикой ради критики, а несли в себе что-то действительно важное, что можно подчерпнуть и добавить в само содержимое статьи (от этого, повторюсь, выигрывают все), но конкретно Ваша критика мне видится очень субъективной и по сути просто критика ради критики, типа хобби, а вот конкретно к коду никаких замечаний у Вас нет (кроме холиварной темы "что есть Си, а что есть C++", которую продолжать я не хочу, поскольку у каждого своё мнение на этот счёт и я останусь при своём).
Станьте тем автором Хабра, который будет писать "достойные статьи", покажите как надо) Желательно каждую неделю) Буду лично читать Ваши статьи и набираться опыта того, как надо писать такие статьи на темы системного программирования) (не сарказм, уверен у Вас есть чему поучиться).
Вообще, любая вера, можно сказать, иллюзия. Но это уже плоскость философии, так что согласен. Кто на что горазд, так скажем)
Я собираю не обрывки, а описываю полноценный процесс создания служб, не более. А вот уж каким образом я углубляю знания - Вам навряд ли известно. Лично я разобрался в теме настолько, насколько требовалось и попытался до читателя донести усвоенный самим собой материал. Успешна эта попытка или нет - покажет время.
Спасибо за совет, но я сам лучше для себя решу что мне делать - публиковать материал или нет. Я не чувствую, что надо мной тут "смеются", скорее у читателей могут быть идеи по улучшению статьи, чему я всегда рад.
А если даже кто-то и смеётся, то это моя проблема или проблема тех, кто смеётся? :)))
Я свой уровень и свои возможности прекрасно знаю, есть ещё куда расти)
Даже если бы я был ИИ, то зачем мне это? Зачем мне писать эту статью с помощью ИИ или сгенерировать её полностью самим ИИ?
У меня ведь даже мотивации толком нет, чтобы генерировать статьи, польза от которых и для меня (человека), и для читателей (вот тут уже сложно - может быть и человек, а может быть и ИИ) может быть минимальна. Я наоборот стремлюсь к качеству материала и углублению как своих знаний, так и знаний читателя.
Не могли бы Вы подробнее описать данную проблему, которая может возникнуть? Хотелось бы её подробнее изучить. Если скинете ещё и ссылки на материал - будет вообще замечательно) Не совсем просто понимаю, когда функции SCM могут зависнуть и что имеется ввиду под "асинхронными вызовами" (понятно что это такое, но в контексте SCM'а - непонятно)
Ну, у меня отличные помощники в комментариях ;)
Читатель может узнать о том, куда глубже копнуть или что лучше изучить на основе критики, а это конечно отлично скажется на понимании материала или его дополнении, что безусловно только плюс)
Вы посмотрите сколько Вы уже всего написали в комментариях. Может быть это и критика ради критики, но, кого-то да направит на "путь истинный" :)
Да ошибся я, ну не могу поправить комментарий) Расширение hpp не используется для исходников на чистом Си)
Можете пожалуйста подробнее раскрыть суть предложения "причём весьма низкого качества"? Я бы хотел эту статью улучшить, если она действительно получилась не очень хорошего качества. Почему она низкого качества и чего в ней не хватает? Что бы Вы хотели видеть в данной статье, чего ещё нет? Любые предложения по её улучшению принимаются)
Простая статья может быть для конкретно Вас, но тех, кто в первый раз работает с такой задачей - это может быть сложно. Я не из-за размера её уровень поставил, а из-за содержимого, потому как посчитал его сложным. Но, это уже моё субъективное мнение) Оценка сложности - дело индивидуальное
Что могу сказать (потому что спорить немного надоело) - это полностью Ваше мнение. Правильно оно или нет - покажет время. Может быть через года опыта я приду к тому, что этот туториал содержит в себе некорректные подходы и с радостью его поправлю. Но пока никакой конкретики от Вас я не увидел
Интересная информация)
Про протокол DCE RPC (AFAIK) я не слышал, но знаю, что RPC обозначает удалённый вызов процедур. Где-то об этом уже читал (конкретно об использовании RPC в SCM), но действительно не углублялся в такие особенности.
С WinAPI я знаком на поверхностном уровне достаточном для решения прикладной задачи, не более. Я не утверждал, что я эксперт в WinAPI, я лишь понимаю на высоком уровне что это, в широком смысле, набор функций для работы с элементами Windows.
И я не ИИ. (и тут у кого-нибудь закралась мысль, что я всё это пишу с ИИ, потому что только ИИ будет отрицать что он ИИ :))
Ну, это Ваше мнение, как и всё прочее. Вы знаете как работает мозг на уровне "подкорки"? Расскажите об этом. Интересны Ваши знания в области нейрохирургии) Вдруг Вы бывший нейрохирург и отлично знаете как работает мозг программиста? Всё может быть)
Вообще, поделюсь своим опытом использования C++ (не смотря на Ваше субъективное мнение он у меня есть): с данным языком программирования я знаком ещё со школы. В школьные годы писал свою текстовую базу данных, простые приложения на WinAPI (преимущественно связанные с графикой), пробовал писать компилятор под Pascal и сделал дюжину консольных игр (для обычной консоли, терминала).
После школы учился в университете, где C++ использовал, к сожалению, крайне мало. В основном приложения на Qt, какие-то лабораторки, ну а затем и вовсе перешёл на Java/C#/JavaScript/Python, а о нём вспомнил только пару месяцев назад, когда потребовалось разобраться в вычислениях на CUDA. Ну и по работе появились задачи, которые с этим языком необходимо решать, а опыт его использования у меня есть.
Вообще этот язык мне очень импонирует и я с ним, можно сказать, мечтал "серьёзно" поработать. В общем-то сейчас я с ним и работаю "серьёзно"). Не зря же я читал кучу литературы об этом языке в своё время) А так я больше программировал на JavaScript/TypeScript последние пару лет.
Если программист успешно работает с каким-то одним языком программирования, то перейти на другой язык программирования (тем более с которым он работал ранее) будет не так трудно. Ведь программист уже не новичок и понимает как строятся программы. Я не новичок, в программировании уже довольно давно и это моё дело. Я его выбрал, я им занимаюсь, я в нём со временем расту.
По тексту комментариев или статьи очень сложно понять какой у программиста уровень, потому что словесное изложение мыслей это не тоже самое, что извергать код на интуитивно понятном уровне, который решает определённым образом задачу через какой-то алгоритм. Не знаю, как Вы этот уровень оцениваете.
Да, я квалифицированный специалист из области программной инженерии. Я не палюсь, а допускаю ошибки - это нормально. Даже если эти ошибки "откровенные ошибки". И я не стану писать "больно не бейте, если налажал" чтобы получить какого-то "снисхождения" (думаю Вы это имели ввиду) потому что если налажал - исправлю, если будут "бить" могу "стукнуть" в ответ. Всё довольно просто.
Моя статья ориентирована не на дилетантов, а на тех, кто более менее уже разбирается в программировании на C++ :) Посмотрите на уровень сложности статьи. Там стоит - "Сложный". Содержание соответствует уровню.
Я допускаю, что у меня есть пробелы в знаниях, но при выявлении этих пробелов я их успешно ликвидирую со временем. Я писал статью не только для того, чтобы предоставить материал по которому можно службы написать, но ещё и сам повторял уже изученные элементы и укреплял о них своё понимание. Так что я и обучающийся, и обучающий. Для кого как. Всё субъективно.
Я ну искренне не понимаю, причём тут данный туториал? Вы утверждали, что в коде есть проблемы с надёжностью и безопасностью в своём комментарии выше:
Я же правильно всё понял? Или Вы что-то другое имели ввиду?
Я попросил Вас - укажите на мои ошибки. Неоднократно это делал, однако так и не дождался конкретики, сплошная теория. И сейчас Вы пишите мол "ошибка будет тогда, когда какой-нибудь программист напишет то и то, вот тогда будет беда", а про конкретно текущий код у Вас нет претензий, я правильно понимаю? Я что-то уже запутался если честно) Какая-то критика ради критики)
Если у Вас есть конкретные предложения по улучшению статьи - предлагайте, с радостью это сделаю. Если их у Вас нет (с каждым комментарием я в этом только убеждаюсь), то ок - зачем тогда критика? Ради критики? Она ведь далеко не всегда у Вас объективна, скорее очень очень субъективна и со многим из этой критики я не согласен, кроме указаний моих фактических ошибок (по типу ошибки понимания формата *.hpp как *.c).
Видимо упоминания того, что службы работают в фоновом режиме было не достаточно. Ладно. Какой изрядный набор удобных целей для атак есть в описанном Вами случае? Интересно узнать.
Почему? Есть какие-то ограничения? Программист (любой) может заинтересоваться этой областью и начать делать службы и писать драйвера. Возможно успешно, возможно не очень. Делать ему так определённо есть что, если ему это интересно.
Вы пытаетесь сформировать образ системного программирования как то, что доступно лишь "элите", "первоклассным стрелкам по ногам с помощью кольта C/C++", которые читают только жёсткую техническую литературу и знают точно-точно всё из своей области, потому что войти в неё сложно. Ну или чтобы в неё войти, надо прочитать кучу технической литературы.
Я ж не спорю. Системное программирование - действительно классная область, со своими проблемами, задачами и интересными особенностями. И да, чтобы в этой области хорошо разбираться нужно кучу технической литературы изучить и программировать низкоуровневые штуки. Но войти в эту область среднестатистический программист может, если захочет (и ничего Вы с этим не сделаете).
Боитесь конкуренции в системном программировании? Это лишнее, задач на всех хватит)
Здесь не корректно указал расширение - *.c, а не *.hpp (корректировка комментария не возможна из-за ограничений по времени)
Да, это действительно моя ошибка. Я почему-то про этот *.hpp формат принял ошибочно за *.c, действительно ошибся.
Заголовки для Си указываются конечно же в файле с расширением *.h, а исходники с расширением *.c. Для C++ исходники с расширением *.cpp, а заголовки можно как *.h или *.hpp оформлять. Тут Вы верно подметили.
Однако я не "палюсь", это лишь ошибка которую я в комментариях уже никак поправить не могу. Чтобы "палится" нужно сначала кем-то "казаться" или формировать образ о себе, всем о нём говорить и не подтверждать его своими действиями или словами. С тем же успехом можно утверждать, что Вы "палитесь" что не HTML-верстальщик, ведь HTML-верстальщики так не пишут :)
Как это не упоминаю? Я это чётко обозначил в программном коде:
Если бы я расписывал все параметры функции CreateServiceA, то статья выросла бы ещё больше)
Согласен, могут возникнуть трудности в понимании что тут я сформулировал. Думаю подкорректирую этот текст позже, чтобы не было недопониманий
Не могли бы Вы рассказать что такое WinAPI? Интересно узнать, чем Ваше понимание отличается от этого или вот этого понимания WinAPI.
Прежде чем на кого-то "указывать пальцем" убедитесь в том, что первый на кого Вы укажите должны быть не Вы.
Вы то точно понимаете как работает WinAPI, разницу между Си и C++, и можете "закрытыми глазами" определить пишет другой человек на C++ или на Си, верно? А если понимаете - поделитесь своими мыслями. А то никакой конкретики, если честно, я не услышал. Сплошная критика ради критики. Никаких замечаний по коду.
Если считаете что служба написана некорректно и где-то её можно поправить - дайте замечания программному коду и укажите где конкретно можно его поправить и как. Это будет гораздо ценнее, чем критика ради критики.
Никакая, сам всё писал и в том числе комментарии. Не верите? Это нормально, сейчас очень много статей которые пишутся с помощью ИИ. По мне так такой труд не приносит пользы ни читателю, ни самому автору.
Не вижу проблем. А если служба не простая, а сложная? И ещё взаимодействует со множеством других служб?
Прямо о том, о чём я написал в комментарии.
WinAPI - это ведь API, который является по сути набором высокоуровневых абстракций для программирования под Windows. Возможно есть способ написать службу и без использования WinAPI на чистом Си. Для этого нужно разработать какие-то свои похожие на WinAPI функции для работы с SCM. Грубо говоря повторить реализацию WinAPI, которая нужна для написания служб) Я об этом.
Вообще не понимаю причём тут данный туториал и "очередная кривая служба". Если она действительно кривая, то будьте добры объяснить в чём эта кривизна проявляется. Мне на данный момент это не понятно, как и какие могут здесь возникнуть проблемы с безопасностью.
Согласен. Можно сделать его максимально полезным, если Вы поделитесь своим профессиональным опытом написания служб на C++ и расскажите какие минусы в представленной в статье реализации есть ("кривизна", "плохая безопасность").
Отнюдь, не вижу связи. В туториале рассматривается самое базовое приложение для управления службами ну и сама служба. Если программист пишет "кривой драйвер", то наверное ему его нужно исправить? А как написать "не кривой драйвер" если ты никогда не ошибался при его написании? Иными словами чтобы написать хороший драйвер нужно ошибаться, но необязательно. Ошибается ли среднестатистический программист при написании драйвера? Да, ошибается. Обязательно ли это? Нет, не обязательно. Вношу ли я прямо или косвенно вклад в то, что кто-то пишет кривой драйвер? Навряд ли, потому что в результате туториала создаётся базовая служба и приложения для управления ею, а не драйвер.
Чтобы программист стал профессионалом - ошибаться нормально, особенно когда программист готов эти ошибки исправлять и понимать почему это ошибка, собственно, возникает.
Никакой цели добавить в текст статьи "кликбейт" я не преследовал. То, что я использую именно C++, а не Си можно понять банально по расширению файлов исходного кода: там *.cpp используется, а не *.hpp.
Если я использую инструкции, которые можно на Си написать, это не значит что я использую везде Си.
Почему стыдно? И почему должно так быть? Не понимаю. Материал я написал разобравшись в этой теме настолько, сколько необходимо для написания своей службы на C++ для решения прикладной задачи. Изученный мной материал я подробно расписал в виде туториала и выложил его на данную платформу. Писал я его для себя и для читателей, которым интересна данная тема. Хорошо бы если через пару лет вернувшись к этому материалу и я и читатель отлично понимал как разработать свою службу на Windows с использованием C++ и, может быть, щепоткой Си. Не знаю, за что мне должно быть стыдно.
Ну за 20 лет точно что-то новое появилось) Будьте уверены) Что именно - я не знаю, но учитывая что кодовая база Windows растёт, то и службы (API для их работы и управления) эта кодовая база точно задевает)
Где-то оптимизацию поправили, где-то новое API добавили, где-то поток по другому работает или раздробили один на два. Ну, в общем точно что-то поменялось. На этот счёт можно другую статью написать о том, как изменилась работа служб в Windows) Я лишь исхожу из того, что развитие ОС Windows во времени предполагает изменения её API и подходов для разработки служб (как пример).
Считать, что ничего не изменилось - тоже не корректно. Известно же что в ИТ всё очень быстро развивается. А если это не так - нужны пруфы.
Спасибо за то, что уделили время поиску данных источников, думаю что они действительно могут расширить общее представление о том, как эти службы разрабатывать)
Однако представленные источники (кроме двух) не описывают полностью процесс разработки служб, а лишь рассказывают о некоторых их особенностях (где-то есть только установка и деинсталляция, а где-то и этого нет). Материал из данных источников довольно устаревший (есть ссылка где публикация была аж в 1996 году), и какие-то концепции могут быть подвержены критике (что-то может уже не использоваться).
Более близкий материал по содержанию есть по Вами приведённым ссылкам (там есть всё, о чём я писал и даже больше):
Александр Федотов. Управление системными службами Windows NT.
Джонсон М. Харт. Системное программирование в среде Windows.
Это действительно бесценный материал, который стоит изучить. Конечно Windows NT (2005 года) это не Windows 10 (на которой я службу разрабатывал) и не Windows 11, но, думаю, есть какие-то общие детали, которые и там и тут используются. В книге по системному программированию так вообще всего предостаточно)
В любом случае нужно периодически актуализировать информацию со старых источников, не даром книги переиздаются и корректируются (особенно технические).
Почему? И сейчас встречаются реальные задачи где нужно разработать службу для Windows или Linux. Я, например, сейчас такой задачей и занимаюсь. Если бы я где-то аналогичный материал нашёл, то для меня этот материал был бы ценен.
Ценность материала - штука очень субъективная. Для опытных профессионалов эта статья может нести нулевую ценность из-за того, что они всё это уже знают, а для новичков в этой теме она ценна.
Тип данной статьи - туториал, я не зря же его таким поставил. Туториал предполагает, что будет решена какая-то полезная задача пошагово. Ровно это я и делаю - решаю интересную мне задачу пошагово, с описанием всех своих действий чтобы интересующийся читатель мог эти действия воспроизвести и получить полезный результат в виде работающего приложения для управления службой на Windows.
Вообще, я использую в данном проекте C++. Это можно легко понять и по исходным файлам где определяются функции для службы - они используют расширение *.cpp, а не *.hpp, которые обычно используют для исходников на чистом Си.
Общеизвестно что C++ старается сохранить обратную совместимость с Си, на базе которого этот язык и построен. Однако если я использую Си код в проекте на C++ это не значит, что я везде использую чистый Си. Я мог бы добавить классы в файле WinService.h и все функции сделать методами и тогда не получать замечания по поводу того, что я C++ использую, а не Си) Но я это сделал намерено для упрощения, потому что на C++ можно писать код в любом стиле, в том числе Си-стиле, что я и сделал.
И для объективности, если Вы сейчас зайдёте в репозиторий dev-win-sc, то увидите, что там C++ кода больше, чем кода на Си:
Как видите даже CMake инструкций в проекте больше, чем чистого кода на Си) А я сомневаюсь, что GitHub сильно ошибается в оценке кодовой базы, а если и ошибается - нужны пруфы, которых у меня нет (если у Вас есть - было бы интересно с ними ознакомится).
Я использовал части кода из официальной документации Microsoft, которая обновлялась сравнительно недавно (13.06.2023, если верить содержимому их статей), поэтому сомневаюсь что префикс LP потерял свою актуальность. Если в официальной документации используются устаревшие и нерабочие элементы API, то согласитесь, такая документация была бы вредна и люди вообще бы не смогли сами такие службы разрабатывать, просто потому что актуальной инфы по этому поводу нет? Нельзя же наугад что-то делать, нужны хоть какие-то зацепки. Поэтому считаю что данное замечание не корректно.
Честно говоря, я бы разжевал ещё более подробнее и глубже, но статья и так получилась большой, поэтому разжевал так, чтобы я или читатель вернувшись к этой статье через 1-2 или более лет смог совершенно спокойно понять о чём тут идёт речь и как разработать службу на C++.
Каких "таких"? Не понятно под кем Вы понимаете "таких". Может быть "такие" программисты тоже хотят стать квалифицированными специалистами в этой области и чтобы освоить эту тему такой материал им может быть полезен. Тем более я постарался дать теоретическую базу по службам в Windows, прежде чем приступить к их разработке чтобы было более понятно что они вообще есть такое и зачем нужны.
Ну вот, уже хоть для кого-то данная статья имеет ценность) Служба - это не про "значок в области уведомлений", это про осуществление полезной работы в фоновом режиме. Да и программисты на JavaScript/Python/<любой другой язык кроме C/C++> может быть заинтересован в получении опыта работы на C++ для совершенно разных целей. Может быть интерес к самому языку, к работе на данном языке или повышение квалификации. Не думаю, что программист с минимальными знаниями C++ сможет хорошо понять то, что в статье происходит. Всё таки для её чтения нужно иметь хотя бы "средние" знания C++ и как на нём разрабатывать полноценные приложения.
Не могли бы Вы рассказать о проблемах, которые связаны с надёжностью и безопасностью в изложенном мной материале? Было бы неплохо его улучшить, если Вы действительно знаете где в исходном коде есть потенциальные проблемы и как от них избавится, я бы мог внести правки в свой материал и те, кто будет его читать получат возможность побольше узнать об устройстве служб и как делать "не нужно".
На данный момент я все дескрипторы освобождаю и делаю все возможные проверки на разных этапах работы управляющих функций и на данный момент не вижу проблем с надёжностью и безопасностью, может быть Вы на них прольёте свет я буду этому только рад.
Думаю, что использование таких уже готовых шаблонов может быть уместно тогда, когда программист имеет полное понимание как эти службы вообще устроены, как они работают и как ими управлять из своей программы на более низком уровне.
В статье я не ставил цель "ускорить процесс разработки служб на Windows" потому что понятно, что для этого можно использовать уже готовые средства и инструменты заложенные в Delphi или C#. Так будет проще, быстрее и не нужно думать о том, как там всё внутри устроено. Однако такой вариант меня не устраивает, немного надоело, что везде всё уже сделано, и что "нужно использовать готовые решения".
Готовые решения это конечно хорошо, но сделать что-то самому с нуля, разобраться во множестве тонкостей и решить кучу проблем - это очень полезно.