Комментарии 77
__cdecl
Все что вы пишете в этом абзаце как то ориентировано на 32-битные процессы, которые уже мало кому нужны, виндовс 11 так вообще 32 битной нет даже. В x64 все работает иначе, и регистры по другому называются даже. Да и смысла указывать calling convention особого нет, он там один фактически кроме разве что всяких редких случаев с vectorcall.
std::cout
...а ведь и прпвда c++ код. ;)
PS: статья понравилась, все нужное собрано в одном месте.
а ведь и прпвда c++ код
В том смысле, что компилятор C его не примет - безусловно. :)
все нужное собрано в одном месте
Я уже считать устал, сколько раз оно так в одном месте собиралось за прошедшие десятки лет...
Я уже считать устал, сколько раз оно так в одном месте собиралось за прошедшие десятки лет...
Не могли бы Вы поделится ссылкой (или ссылками), где аналогичный материал собран в одном конкретном месте и где так же (или даже лучше) рассматривается подобная тема? Не исключаю, что я, возможно, плохо искал и поэтому столкнулся с проблемой разрозненности информации по разным источникам.
Думаю не только мне будет полезно ознакомится с другими работами, где данная тема широко освящена.
Основное "конкретное место", как тут уже отметили - MSDN. Там есть абсолютно все, что может потребоваться для создания службы. А чрезмерно подробное разжевывание в стиле "для начинающих" - классическая медвежья услуга. Не должны начинающие заниматься такими вещами, никогда.
О программировании служб Win32 очень много написано в конце 90-х и начале 2000-х, сейчас ссылки на ту литературу навскидку не найти - они завалены тоннами хлама, сгенерированного ИИ. Вот что попалось среди хлама:
Джонсон М. Харт. Системное программирование в среде Windows.
Дж. Рихтер, Дж. Кларк. «Программирование серверных приложений для Microsoft Windows 2000
Александр Федотов. Управление системными службами Windows NT.
Сергей Холодилов. Программирование служб: подробности
Всеволод Стахов. Программирование сервисов в Windows 2000
Александр Фролов, Григорий Фролов. Программирование для Windows NT. Создание сервисного процесса
А уж сколько понаписано про создание служб на C# - в глазах рябит.
Спасибо за то, что уделили время поиску данных источников, думаю что они действительно могут расширить общее представление о том, как эти службы разрабатывать)
Однако представленные источники (кроме двух) не описывают полностью процесс разработки служб, а лишь рассказывают о некоторых их особенностях (где-то есть только установка и деинсталляция, а где-то и этого нет). Материал из данных источников довольно устаревший (есть ссылка где публикация была аж в 1996 году), и какие-то концепции могут быть подвержены критике (что-то может уже не использоваться).
Более близкий материал по содержанию есть по Вами приведённым ссылкам (там есть всё, о чём я писал и даже больше):
Александр Федотов. Управление системными службами Windows NT.
Джонсон М. Харт. Системное программирование в среде Windows.
Это действительно бесценный материал, который стоит изучить. Конечно Windows NT (2005 года) это не Windows 10 (на которой я службу разрабатывал) и не Windows 11, но, думаю, есть какие-то общие детали, которые и там и тут используются. В книге по системному программированию так вообще всего предостаточно)
В любом случае нужно периодически актуализировать информацию со старых источников, не даром книги переиздаются и корректируются (особенно технические).
Материал из данных источников довольно устаревший
"Довольно устаревшие" - это Ваши тексты якобы на C++ (понятное дело - для кликбейта), а на самом деле - очень топорно переделанные с каких-то старых текстов на C. :) Стыдно должно быть за такое.
Конечно Windows NT (2005 года) это не Windows 10 (на которой я службу разрабатывал) и не Windows 11
И что же в Windows 10/11 появилось нового в отношении служб? Последнее сколько-нибудь значимое нововведение было в Vista (тэги и запуск системных служб в нескольких процессах), но для разработки собственной службы это не актуально.
"Довольно устаревшие" - это Ваши тексты якобы на C++ (понятное дело - для кликбейта)
Никакой цели добавить в текст статьи "кликбейт" я не преследовал. То, что я использую именно C++, а не Си можно понять банально по расширению файлов исходного кода: там *.cpp используется, а не *.hpp.
Если я использую инструкции, которые можно на Си написать, это не значит что я использую везде Си.
Стыдно должно быть за такое
Почему стыдно? И почему должно так быть? Не понимаю. Материал я написал разобравшись в этой теме настолько, сколько необходимо для написания своей службы на C++ для решения прикладной задачи. Изученный мной материал я подробно расписал в виде туториала и выложил его на данную платформу. Писал я его для себя и для читателей, которым интересна данная тема. Хорошо бы если через пару лет вернувшись к этому материалу и я и читатель отлично понимал как разработать свою службу на Windows с использованием C++ и, может быть, щепоткой Си. Не знаю, за что мне должно быть стыдно.
И что же в Windows 10/11 появилось нового в отношении служб?
Ну за 20 лет точно что-то новое появилось) Будьте уверены) Что именно - я не знаю, но учитывая что кодовая база Windows растёт, то и службы (API для их работы и управления) эта кодовая база точно задевает)
Где-то оптимизацию поправили, где-то новое API добавили, где-то поток по другому работает или раздробили один на два. Ну, в общем точно что-то поменялось. На этот счёт можно другую статью написать о том, как изменилась работа служб в Windows) Я лишь исхожу из того, что развитие ОС Windows во времени предполагает изменения её API и подходов для разработки служб (как пример).
Считать, что ничего не изменилось - тоже не корректно. Известно же что в ИТ всё очень быстро развивается. А если это не так - нужны пруфы.
То, что я использую именно C++, а не Си можно понять банально по расширению файлов исходного кода
То есть, если я помещу программу на чистом C в файл с расширением .cpp, она автоматически станет "программой на C++"?
там *.cpp используется, а не *.hpp
Вы уже второй раз откровенно палитесь с этим ".hpp". Для справки: .hpp - это типовое расширение заголовка на C++, содержащего не только объявления/определения, но и реализацию (или бОльшую ее часть). Утверждению "на C++, а не на Си" соответствовало бы ".cpp, а не .c".
Если я использую инструкции, которые можно на Си написать
Вы их используете преимущественно. А еще создается впечатление, что Вы толком не знаете ни C, ни C++.
Материал я написал разобравшись в этой теме настолько, сколько необходимо для написания своей службы на C++
Да, Вы написали его в стиле "как значки и строчки объединить в группы, чтобы получилась работающая служба". Статьи в таком стиле неплохо смотрятся под названиями "использование GDI для рисования фигур", "ваша первая многопоточная программа" и т.п. Но в сфере системного программирования это выглядит довольно убого.
Увлекшись разжевыванием деталей, очевидных для любого мало-мальски опытного программиста, Вы даже ни словом не упомянули того, что служба по умолчанию запускается от имени системы (LOCAL_SYSTEM), а это еще серьезнее, чем права администратора.
и я и читатель отлично понимал как разработать свою службу на Windows с использованием C++ и, может быть, щепоткой Си
Для начала неплохо бы понимать, из каких соображений выбран C++, для чего там может потребоваться (или не потребоваться) "щепотка Си", и чем эти языки отличаются. У Вас, судя по всему, это понимание весьма поверхностное.
Ну за 20 лет точно что-то новое появилось)
А конкретно?
Будьте уверены)
Отличный аргумент, непробиваемый.
Где-то оптимизацию поправили, где-то новое API добавили, где-то поток по другому работает или раздробили один на два. Ну, в общем точно что-то поменялось
Если Вы о том, как организованы стандартные системные службы, то там как раз много чего регулярно меняется. Но Ваша статья не об этом.
исхожу из того, что развитие ОС Windows во времени предполагает изменения её API и подходов для разработки служб (как пример)
Так в чем же конкретно поменялись API и/или подходы к разработке?
К чему у Вас, например, вот это: "Выделение буфера для зависимых служб происходит с помощью функции HeapAlloc"
Почему HeapAlloc, а не new, malloc, LocalAlloc, GlobalAlloc?
А это: " нужно учитывать, что выделенная память не может быть куда-либо перемещена"?
Кем перемещена, когда, зачем?
А какой смысл читатель Вашей статьи должен извлечь из этой фразы: "Функция StartServiceCtrlDispatcher соединяет основной поток процесса службы с SCM, в результате чего этот поток становится потоком SCM для вызывающего процесса"?
Что значит "соединяет поток"? Что такое "поток SCM для вызывающего процесса"?
Вы уже второй раз откровенно палитесь с этим ".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 для вызывающего процесса"?
Согласен, могут возникнуть трудности в понимании что тут я сформулировал. Думаю подкорректирую этот текст позже, чтобы не было недопониманий
Я почему-то про этот *.hpp формат принял ошибочно за *.c, действительно ошибся
Фишка в том, что мало-мальски опытный программист таких ляпов не допустит, это где-то на уровне подкорки.
Заголовки для Си указываются конечно же в файле с расширением *.h, а исходники с расширением *.c. Для C++ исходники с расширением *.cpp, а заголовки можно как *.h или *.hpp оформлять.
И таких пространных объяснений мало-мальски опытный программист тоже давать не будет. Это порождает сомнения в том, что Вы сколько-нибудь хорошо знаете что C, что C++, и что у Вас есть мало-мальски приличный опыт их использования.
Чтобы "палится" нужно сначала кем-то "казаться"
Опубликовав статью на тему системного программирования, без предисловия в стиле "я вообще-то токарь, но вот почитал того-сего, и решил свести воедино, больно не бейте, если налажал", Вы заявили о себе, как о квалифицированном специалисте. Допуская в комментариях откровенные ляпы, Вы и палитесь.
Как это не упоминаю? Я это чётко обозначил в программном коде
Вы действительно полагаете, что типичный дилетант в системном программировании, на которого ориентирована Ваша статья, даже не то, чтобы поймет, а вообще заметит эту ремарку?
Блин, я ведь сперва как-то проглядел, что у Вас там написано до "(LocalSystem)". "Стартовое имя" - это что вообще? Вы точно уверены, что понимаете смысл этого параметра?
Согласен, могут возникнуть трудности в понимании что тут я сформулировал
Беда в том, что Вы этого не понимаете (как и ряда других вещей), однако берете на себя функцию обучающего, а не обучаемого.
Фишка в том, что мало-мальски опытный программист таких ляпов не допустит, это где-то на уровне подкорки.
Ну, это Ваше мнение, как и всё прочее. Вы знаете как работает мозг на уровне "подкорки"? Расскажите об этом. Интересны Ваши знания в области нейрохирургии) Вдруг Вы бывший нейрохирург и отлично знаете как работает мозг программиста? Всё может быть)
И таких пространных объяснений мало-мальски опытный программист тоже давать не будет. Это порождает сомнения в том, что Вы сколько-нибудь хорошо знаете что C, что C++, и что у Вас есть мало-мальски приличный опыт их использования.
Вообще, поделюсь своим опытом использования C++ (не смотря на Ваше субъективное мнение он у меня есть): с данным языком программирования я знаком ещё со школы. В школьные годы писал свою текстовую базу данных, простые приложения на WinAPI (преимущественно связанные с графикой), пробовал писать компилятор под Pascal и сделал дюжину консольных игр (для обычной консоли, терминала).
После школы учился в университете, где C++ использовал, к сожалению, крайне мало. В основном приложения на Qt, какие-то лабораторки, ну а затем и вовсе перешёл на Java/C#/JavaScript/Python, а о нём вспомнил только пару месяцев назад, когда потребовалось разобраться в вычислениях на CUDA. Ну и по работе появились задачи, которые с этим языком необходимо решать, а опыт его использования у меня есть.
Вообще этот язык мне очень импонирует и я с ним, можно сказать, мечтал "серьёзно" поработать. В общем-то сейчас я с ним и работаю "серьёзно"). Не зря же я читал кучу литературы об этом языке в своё время) А так я больше программировал на JavaScript/TypeScript последние пару лет.
Если программист успешно работает с каким-то одним языком программирования, то перейти на другой язык программирования (тем более с которым он работал ранее) будет не так трудно. Ведь программист уже не новичок и понимает как строятся программы. Я не новичок, в программировании уже довольно давно и это моё дело. Я его выбрал, я им занимаюсь, я в нём со временем расту.
По тексту комментариев или статьи очень сложно понять какой у программиста уровень, потому что словесное изложение мыслей это не тоже самое, что извергать код на интуитивно понятном уровне, который решает определённым образом задачу через какой-то алгоритм. Не знаю, как Вы этот уровень оцениваете.
Опубликовав статью на тему системного программирования, без предисловия в стиле "я вообще-то токарь, но вот почитал того-сего, и решил свести воедино, больно не бейте, если налажал", Вы заявили о себе, как о квалифицированном специалисте. Допуская в комментариях откровенные ляпы, Вы и палитесь.
Да, я квалифицированный специалист из области программной инженерии. Я не палюсь, а допускаю ошибки - это нормально. Даже если эти ошибки "откровенные ошибки". И я не стану писать "больно не бейте, если налажал" чтобы получить какого-то "снисхождения" (думаю Вы это имели ввиду) потому что если налажал - исправлю, если будут "бить" могу "стукнуть" в ответ. Всё довольно просто.
Вы действительно полагаете, что типичный дилетант в системном программировании, на которого ориентирована Ваша статья, даже не то, чтобы поймет, а вообще заметит эту ремарку?
Моя статья ориентирована не на дилетантов, а на тех, кто более менее уже разбирается в программировании на C++ :) Посмотрите на уровень сложности статьи. Там стоит - "Сложный". Содержание соответствует уровню.
Беда в том, что Вы этого не понимаете (как и ряда других вещей), однако берете на себя функцию обучающего, а не обучаемого.
Я допускаю, что у меня есть пробелы в знаниях, но при выявлении этих пробелов я их успешно ликвидирую со временем. Я писал статью не только для того, чтобы предоставить материал по которому можно службы написать, но ещё и сам повторял уже изученные элементы и укреплял о них своё понимание. Так что я и обучающийся, и обучающий. Для кого как. Всё субъективно.
А какой смысл читатель Вашей статьи должен извлечь из этой фразы: "Функция StartServiceCtrlDispatcher соединяет основной поток процесса службы с SCM, в результате чего этот поток становится потоком SCM для вызывающего процесса"?
Ну, примерно тот же, что и из фразы в документации (из русского перевода, но перевод тут вполне адекватен оригиналу):
Подключает поток main процесса службы к диспетчеру управления службами, что приводит к тому, что поток будет потоком диспетчера управления службой для вызывающего процесса.
По-моему, и то, и то одинаково непонятно. Так что это - косяк автора документации из MS, а не автора статьи.
А в комментарии в том же разделе документации таки разъяснено, что это значит на самом деле: что поток, в котором был вызван StartServiceCtrlDispatcher, в случае успеха оставется ожидать внутри в SCM (точнее (полагаю) - в коде прокси в библиотеке поддержки RPC, которая уже обращается к самому процессу SCM) момента, когда SCM нужно будет обратиться к сервису через функцию обратного вызова: эта функция вызывается либо в этом потоке, либо в другом, но созданном в контексте этого потока.
А вот почему MS не написала сразу это в основном описании - тайна сия велика есть. Но автор статьи в этом точно не виноват.
По-моему, и то, и то одинаково непонятно. Так что это - косяк автора документации из MS, а не автора статьи.
По-Вашему, автор претендует только на дословный перевод исходной документации? По его собственным словам, он претендует на гораздо большее.
почему MS не написала сразу это в основном описании - тайна сия велика есть. Но автор статьи в этом точно не виноват.
Он не был бы виноват, выступай он в роли переводчика. Но он подал себя, как "разобравшегося", и возомнил, что в этом состоянии уже готов кого-то обучать. А по сути, он толком не разобрался, а лишь коряво слепил вместе разнородные сведения, обмазав их обтекаемыми рассуждениями.
По его собственным словам, он претендует на гораздо большее.
Я уже не раз отмечал, что публикация была сформирована на базе моего текущего опыта разработки служб, не более.
Он не был бы виноват, выступай он в роли переводчика.
Скажите, если я взял отрывок из документации, или любого другого ресурса, где интересный для меня материал есть и перевёл его на русский язык (может быть даже неудачно), то можно ли считать всю статью переводом? Ну это ведь не правильно? То, что я заимствую из других источников - совершенно нормально. Большую часть того, что Вы прочитаете я написал самостоятельно, своими руками. Лишь изредка прибегал к переводу отрывков из официальной документации чтобы не было с ней расхождений, и с этим пояснением - точно такая же история.
А по сути, он толком не разобрался, а лишь коряво слепил вместе разнородные сведения, обмазав их обтекаемыми рассуждениями.
По сути Вы не читаете ответы на мои комментарии или имеете очень короткую "конфликтную память", раз продолжаете из комментария в комментарий нести одну и туже идею: "автор не разобрался", "да как он посмел не правильно на критику отреагировать", "да я предоставил все факты как на блюдичке что его статья плохая, а он ещё спорит".
Вы "бревно" в своём глазу вообще не видите? Я неоднократно Вам пытался доказать, что Ваша точка зрения не совсем конструктивна. Она имеет ряд проблем, которых Вы не видите, но продолжаете нести одну и ту же идею в комментариях)
Вы бы не просто "дизлайкали" мои ответы к Вашим комментариям, а читали бы их хотя бы (неоднократно подмечаю уже, что через секунду они "кому-то не понравились", хотя за секунду такое не прочитать, можете скинуть на "стороннее мнение умных и образованных людей").
Складывается ощущение, что Вы вообще не видите что я пишу, видимо потому что думаете, что я использую ИИ даже для комментариев (такой чести комментарии Ваши не заслуживают чтоб ради них ещё напрягать целый выделенный ЦОД), а зачем читать то, что ИИ на генерировал, верно? То и дело я задаюсь вопросом - зачем читать то, что на генерировало Ваше ограниченное субъективное мнение, которое не поменяется если ему намекнуть, что в нём есть проблемы? Вы же как пишите одно и тоже, так и продолжаете писать)
По поводу выполнения функции StartServiceCtrlDispatcher: добавил в статье пояснение, раскрывающая подробнее её работу и связь с DispatchTable (SERVICE_TABLE_ENTRY).
Спасибо всем, кто обратил внимание на недостаточную информативность.
Никакой цели добавить в текст статьи "кликбейт" я не преследовал. То, что я использую именно C++, а не Си можно понять банально по расширению файлов исходного кода: там *.cpp используется, а не *.hpp.
Ну почестному С++ там как раз не много, как минимум напрашивается класс Service, так же для хенделов какой-нибудь класс Handle с использованием RAII.
Плюс не рассмотрены кейсы когда требуются ретраии и случаи когда функции SCM зависают и нужно делать асинхронные вызовы.
Плюс не рассмотрены кейсы когда требуются ретраии и случаи когда функции SCM зависают и нужно делать асинхронные вызовы.
Не могли бы Вы подробнее описать данную проблему, которая может возникнуть? Хотелось бы её подробнее изучить. Если скинете ещё и ссылки на материал - будет вообще замечательно) Не совсем просто понимаю, когда функции SCM могут зависнуть и что имеется ввиду под "асинхронными вызовами" (понятно что это такое, но в контексте SCM'а - непонятно)
Если посмотреть на список параметров OpenSCManager то там есть lpMachineName, это возможность удаленной работы с сервисами. В одной из наших фичей в бизнес логике была функциональность загрузки бинарных файлов на шару, удаленная регистрация сервиса, запуск сервиса, какая то работа, остановка сервиса, удаление. И с тысячами различных конфигураций кастомеров, разных протоколов NTLM, Kerberos разных с файрволов и пр, иногда в случае работы удаленно по сети, практически любая функция из SCM могла зависнуть или отвалиться с ошибкой на ровном месте.
Для того что бы ваша программа не зависла вместе с SCM нужно как-то асинхронно делать вызов, самый простой вариант все это выносить в отдельн6ый поток, но тут тоже множество подводных камней с правильной обработкой и передачей ошибок/исключений из одного потока в другой, что делать с зависшим потоком, терминировать или складывать в “отстойник” и т.д.
В вашей статье нет совершенно никакого намека на С++, просто вызов WinApi функций на Си с глобальными переменными и пр.
Для работы на С++ нужно все-таки делать какие-то абстракции, интерфейсы, самым первым, собственно, напрашивается
class SCManager, следом класс Service , со стороны реализации непосредственно сервиса так же напрашивается универсальный шаблон типа class TService, где в качестве параметров шаблона задаётся основная бизнес функция сервиса.
Очень важно подсветить безопасность всей этой истории, у вас сервис по умолчанию будет запушен под Local System, что дает очень много прав и если у вас в этом сервисе крутить какой ни будь RPC сервер, то это очень “тонкое” место с возможностью повышения привилегий.
Можно так же рассмотреть использование Managed Service Account и Group Managed Service Accounts.
В целом ваша статья не плохая, но и не особа информативная, относительно MSDN.
Смотрел я тут на то, как вы автора насекомите, и подумал, что, наверное, стоит вмешаться, чтобы противостоять разгулу реакции ;-) , так сказать. Потому как я, хоть и из поколения динозавров, но идею, что все должно оставаться как было в моей молодости, не поддерживаю.
Не должны начинающие заниматься такими вещами, никогда.
Аспекта тут два и оба разные :-)
Во-первых, в программировании те области, которые некогда были вотчиной избранных адептов, по мере развития становятся доступными профанам. Мой любимый пример - разработка GUI приложений под Windows. В 1990-м году Windows внезапно выстрелила на рынке и резко появился спрос на тех, кто мог писать соответствующие приложения. А вот писать их было реально сложно: и концептуально - потому что событийно-управляемое программирование, и технически - ибо приходилось следловать многочисленным ритуалам, начиная с обработчиков многоообразия сообщений в функции окна - и все это на голом C, "по Петцольду"(была такая книга)
Но, во-вторых, для упрощения работы с новыми областями обычно появляются новые инструменты. Для Windows сначала это были Borland OWL и MFC от Microsoft, убравшие под капот много рути, потом появились Visual Basic и PowerBuilder, позволившие легко и просто (методом "визуального программирования") делать простые приложения силами не сильно квалифицированных разработчиков-"формошлепов", затем появился Delphi, который позволил и формошлепов использовать, и более сложнные задачи решать силами более квалифицированных программистов. Заодно и сама среда WIndows совершенствовалась - к примеру, пропала нужда выполнения всех этих ритуалов с GlobalAlloc/GlobalLock, без которых в реальном режиме Windows 3.0 жизни не было.
Так что с течением времени начинающие вполне могут заняться тем, что раньше требовало избранных. Но лучше это делать с использованием более подходящих инструментов, убирающих под капот как можно больше сложностей реализации. И IMHO концептуальная ошибка автора статьи - всего лишь в том в том, что он написал статью для начинающих о том, как решать конкретную задачу инструментами, для начинающих не предназначенными.
PS Но вот то, что автор, не разобравшись, стал объявлять устаревшими книги в области, в которой мало что поменялось - это меня таки позабавило.
как вы автора насекомите
Это я сдерживаюсь изо всех сил, ибо автор так старательно напрашивается на грубости, что сдерживаться нелегко. :)
те области, которые некогда были вотчиной избранных адептов, по мере развития становятся доступными профанам
Да и ради бога, пока профаны резвятся где-нибудь в песочнице, лично для себя и непосредственного окружения. Если же отстаивать их право работать на продакшн и заниматься обучением других, можно внезапно обнаружить, что самолет, в котором Вы летите, ведет один профан, а ПО для автоматики делали другие.
Мой любимый пример - разработка GUI приложений под Windows
Это совершенно негодный пример для этой темы. Приложение, что GUI, что текстовое/консольное - это конечный элемент структуры, лист на дереве зависимостей. От того, что оно написано профаном, могут пострадать только конечные пользователи приложения, которые это приложение запускают осознанно. А когда профан не только начинает писать системные компоненты, которые запускаются автоматически, имеют повышенные права, работа которых не видна непосредствоенно и т.п., но и пытается учить этому других - это уже "туши свет, сливай воду". :)
с течением времени начинающие вполне могут заняться тем, что раньше требовало избранных
Когда это затрагивает только их самих - сколько угодно. :)
Я вот раньше никогда не занимался высокотемпературной пайкой, и с газокислородным горелками дела не имел, но приспичило медные трубы запаять, пришлось заняться. :) Пока я это делаю у себя дома - еще полбеды, а вот если я, при имеющемся уровне знаний/опыта, наберусь наглости предлагать свои услуги и/или писать "обучающие" тексты, то более образованные и опытные люди с полным правом будут тыкать меня мордой в лужу. :)
то, что автор, не разобравшись, стал объявлять устаревшими книги в области, в которой мало что поменялось - это меня таки позабавило.
Вы, похоже, не обратили внимания на то, что автор имеет крайне поверхностное представление о сфере, в которую он влез. Почитайте внимательно и статью, и его ответы на комментарии - там ведь вообще нигде не видно никаких четких, сколько-нибудь глубоких познаний. Он хорошо умеет плести словесные кружева - в области какой-нибудь философии или современной "психологии" ему б цены не было, там это очень любят. Он ведь почти ни на один конкретный вопрос не дает четкого ответа - только ходит вокруг да около, замазывает общими рассуждениями и развесистыми словесами свое незнание и непонимание. А те, кто недостаточно внимателен и дотошен (как раз его целевая аудитория), ошибочно принимают это за образованность и опыт. Вот это и раздражает больше всего. Как и то, что тут вообще синдром Даннинга-Крюгера в полный рост.
Это я сдерживаюсь изо всех сил, ибо автор так старательно напрашивается на грубости, что сдерживаться нелегко. :)
Да ну что Вы, грубите на здоровье, не сдерживайтесь, я ведь Вам с удовольствием отвечу :) Может это Вам необходимо жизненно - писать гневные комментарии к статьям, которые задевают сферу (или область), которая Вам симпатизирует или задевают Ваше эго (которое, вообще-то, судя по комментариям сильно раздуто).
Что я, спрашивается, задаю Вам вопрос на Ваши придирки к статье по поводу программного кода? Может Вы вообще просто тролль, и на самом деле не разбираетесь в программировании служб вообще, а где-то "нахватались" в интернете и начинаете содержимое её поносить, без каких-либо конкретных предложений по её улучшению и конкретных проблем с программным кодом (то что Вы указали на проблему перевода MSDN не считается, тут с кодом проблем нет).
Почитайте внимательно и статью, и его ответы на комментарии - там ведь вообще нигде не видно никаких четких, сколько-нибудь глубоких познаний
Ровно как и у Вас) Почитайте свои комментарии, где там хоть сколько-нибудь глубокие познания в области системного программирования? Правильно - их нет. Зато утверждать, что "автор нахватался" - хлебом не корми, как и оставить мои комментарии без какого-либо внимания и потом утверждать что "автор то, автор сё". Я уже давно объяснил в чём именно Вы не правы в своих суждениях, но Вы это предпочли пропустить мимо. Эго не позволяет, видимо.
Если Вы так относитесь к моим ответам, то может и мне на Ваши внимания не обращать? А зачем, если Вы всё равно несёте одну и ту же идею? Но, это уже риторический вопрос.
Вот это и раздражает больше всего. Как и то, что тут вообще синдром Даннинга-Крюгера в полный рост.
Эффект Даннинга - Крюгера - Эффект Даннинга — Крюгера — Википедия (не благодарите).
Насколько я понял, то чтобы этому "синдрому" соответствовать надо себя сначала "мнить" экспертом, чего я не делал ни в публикации своей, ни в комментариях (если это не так - докажите). Это исключительно Ваше мнение, что я себя преподношу или "мню" как "эксперт системного программирования", хотя по факту это не так. Я даже в комментарии (одном из) указал на свой реальный опыт разработки и там не числится "системный программист". Я совсем недавно начал этой темой плотно заниматься (последние 2 месяца, если точнее) и разбираюсь я с этой темой за счёт раннего опыта программирования на C++ (благодаря которому и могу вообще понимать, что там происходит в "системном программировании") и причем не на уровне "hello, world", а на более углублённом. STL, алгоритмы и структуры данных, модель памяти C++, CMake, ООП, многопоточность - не просто знакомые для меня слова, а то, с чем я работал и изучал ранее и сейчас работаю с этим ещё больше. WinAPI я не включил в этот список поскольку дальше оконных приложений и служб пока не ушёл. И я не эксперт и таковым себя не считаю, напротив, мне многое ещё предстоит "осилить".
Приходится всё повторять, что уже ранее выложил в отдельном комментарии (который Вы не читали, видимо).
На это "замечание" я ответил отдельно, поскольку Ваша "критика" не выдерживает никакой критики :) Вы если что-то утверждаете - гугл в помощь, потому что пытаетесь залезть в мою сферу ("психология / философия", пометка: сарказм) без предварительной подготовки. Так нельзя, Вы же сами в своих комментариях эту идею преследуете. Значит ли это, что сами Вы этому не следуете? Вероятно так, поскольку это проблема многих людей (меня в том числе). Это часть нашей природы, неотъемлемая.
классная статья, а так мало плюсов. Автору - респект! Сейчас на очередную новомодную библиотеку на питоне (которая через пару лет станет старомодной) больше откликов, чем на базу из мира C++. Неправильно это.
Намного легче написать службу на c# где поддержка этого намного удобнее и из него уже запускать c++ код
Думаю да, это было бы легче, учитывая что слои абстракции в C# вырастают с каждой новой версией этого языка так, что можно разработать службу значительно быстрее.
Однако использовать два языка программирования (C++ и C#) - не всегда уместно, поскольку программы на разных языках программирования имеют свои особенности, которые могут зависеть от платформы (в следствие чего поддержка таких программ требует больших усилий), да и скрытие "рутинных задач" за большим слоем абстракции лишает программиста важного - получения опыта. Ведь разобраться как устроено управление службами на C++, на мой взгляд, ценнее, чем использовать высокоуровневые абстракции и просто решить задачу так, как проще или так, как "модно".
Конечно, и в статье используется высокоуровневые абстракции из WinAPI. Может быть есть способ написать службу на более низком уровне с использованием чистого Си и без WinAPI, однако такого способа я, на данный момент, не знаю. Если бы знал такой способ - сделал бы на чистом Си) Уменьшая слои абстракции и используя более низкоуровневые инструменты программист получает больше опыта за счёт необходимости разбираться в большем числе деталей.
высокоуровневые абстракции из WinAPI. Может быть есть способ написать службу на более низком уровне с использованием чистого Си и без WinAPI
Вы о чем вообще?
Прямо о том, о чём я написал в комментарии.
WinAPI - это ведь API, который является по сути набором высокоуровневых абстракций для программирования под Windows. Возможно есть способ написать службу и без использования WinAPI на чистом Си. Для этого нужно разработать какие-то свои похожие на WinAPI функции для работы с SCM. Грубо говоря повторить реализацию WinAPI, которая нужна для написания служб) Я об этом.
А я о том, что Вы даже толком не понимаете, что такое WinAPI, и что там за "высокоуровневые абстракции". А выражение "без использования WinAPI на чистом Си" - это вообще шедевр. Скажите честно, какая часть написанного Вами сгенерирована ИИ?
Вы даже толком не понимаете, что такое WinAPI
Не могли бы Вы рассказать что такое WinAPI? Интересно узнать, чем Ваше понимание отличается от этого или вот этого понимания WinAPI.
Прежде чем на кого-то "указывать пальцем" убедитесь в том, что первый на кого Вы укажите должны быть не Вы.
Вы то точно понимаете как работает WinAPI, разницу между Си и C++, и можете "закрытыми глазами" определить пишет другой человек на C++ или на Си, верно? А если понимаете - поделитесь своими мыслями. А то никакой конкретики, если честно, я не услышал. Сплошная критика ради критики. Никаких замечаний по коду.
Если считаете что служба написана некорректно и где-то её можно поправить - дайте замечания программному коду и укажите где конкретно можно его поправить и как. Это будет гораздо ценнее, чем критика ради критики.
Скажите честно, какая часть написанного Вами сгенерирована ИИ?
Никакая, сам всё писал и в том числе комментарии. Не верите? Это нормально, сейчас очень много статей которые пишутся с помощью ИИ. По мне так такой труд не приносит пользы ни читателю, ни самому автору.
Не могли бы Вы рассказать что такое WinAPI?
Зачем мне это рассказывать, когда это стандартный и ходовой термин, суть которого описана, в том числе, и по приведенным Вами ссылкам?
А вот фраза "написать службу на более низком уровне с использованием чистого Си и без WinAPI" не является ни стандартным, ни ходовым выражением, это Ваше собственное высказывание. Поэтому я и пытаюсь узнать, какой смысл Вы в него вложили, ибо для любого, понимающего, что такое WinAPI, и как он используется в C, эта фраза очевидно абсурдна, бессмысленна.
Никаких замечаний по коду
По коду я Вам уже высказал конкретные замечания. То, что он компилируется и как-то работает - не основание для того, чтобы публиковать его под видом руководства.
Если считаете что служба написана некорректно и где-то её можно поправить
Я считаю, что вся статья написана некорректно. На таком уровне уместно писать статьи о прикладном программировании, но никак не о системном. Когда неверный подход лежит в самой основе, править что-то в коде - как переставлять кровати в том борделе из анекдота.
и что там за "высокоуровневые абстракции".
Таки позанудствую, не возражаете?
Ну, строго говоря, в данном конкретном случае API SCM - это таки более высокоуровневые абстракции для механизмов более низкого уровня: работы с реестром для установки/удаления/изменения конфигурации служб и обращения к точкам вызова процесса SCM (services.exe) по протоколу DCE RPC (AFAIK). То есть, теоретически, можно не пользоваться этим самым "высокоуровневым" API SCM, а использовать в программе чисто API реестра и API RPC вместе с описаниями интерфейсов точек вызова на IDL - их правда, ещё найти надо, или, скорее сделать (AFAIK они не дркументированы), и поменяться они, как все недокументированное могут от версии к версии Windows. Но принципиальная возможность работы с сервисами на более низком уровне таки есть.
Но что-то, правда, заставляет меня сомневаться, что автор статьи писал слово "высокоуровневый", понимая все это, а не просто с намерением простыми, универсальными, но малозначащими словами отделаться от критики (ну, или его ИИ набрался таких словечек во всяких интернетах).
API SCM - это таки более высокоуровневые абстракции для механизмов более низкого уровня: работы с реестром для установки/удаления/изменения конфигурации служб
Строго говоря, это разные вещи. Реестр - это просто база данных, в которой хранятся сведения о службах, а SCM отвечает за управление этой базой. По-хорошему, непосредственная работа с базой в обход SCM вообще не должна была допускаться, но так уж вышло, что в MS сами использовали обходные пути, поэтому вынуждены и дальше тянуть совместимость.
А абстракции в API SCM ничуть не больше, чем в реестровых записях.
обращения к точкам вызова процесса SCM (services.exe) по протоколу DCE RPC (AFAIK)
Здесь абстракция действительно имеет место. Осталось понять, каким боком чистый C мог бы способствовать ее обходу - при том, что примеры фактически на нем и написаны. :)
Но что-то, правда, заставляет меня сомневаться, что автор статьи писал слово "высокоуровневый", понимая все это, а не просто с намерением простыми, универсальными, но малозначащими словами отделаться от критики (ну, или его ИИ набрался таких словечек во всяких интернетах).
О том и речь, что автор взял на себя задачу, адекватно вывезти которую он не в состоянии. Ему еще учиться и учиться до того, как учить кого-то другого.
О том и речь, что автор взял на себя задачу, адекватно вывезти которую он не в состоянии. Ему еще учиться и учиться до того, как учить кого-то другого.
Ну, у меня отличные помощники в комментариях ;)
Читатель может узнать о том, куда глубже копнуть или что лучше изучить на основе критики, а это конечно отлично скажется на понимании материала или его дополнении, что безусловно только плюс)
Вы посмотрите сколько Вы уже всего написали в комментариях. Может быть это и критика ради критики, но, кого-то да направит на "путь истинный" :)
Интересная информация)
Но что-то, правда, заставляет меня сомневаться, что автор статьи писал слово "высокоуровневый", понимая все это, а не просто с намерением простыми, универсальными, но малозначащими словами отделаться от критики (ну, или его ИИ набрался таких словечек во всяких интернетах).
Про протокол DCE RPC (AFAIK) я не слышал, но знаю, что RPC обозначает удалённый вызов процедур. Где-то об этом уже читал (конкретно об использовании RPC в SCM), но действительно не углублялся в такие особенности.
С WinAPI я знаком на поверхностном уровне достаточном для решения прикладной задачи, не более. Я не утверждал, что я эксперт в WinAPI, я лишь понимаю на высоком уровне что это, в широком смысле, набор функций для работы с элементами Windows.
И я не ИИ. (и тут у кого-нибудь закралась мысль, что я всё это пишу с ИИ, потому что только ИИ будет отрицать что он ИИ :))
которые могут зависеть от платформы
В чем проблему написать простейшую службу, запускающую ехе, и скомпилить ее под x86?
Работа проделана, не спорю, но часть из нее IMHO - лишняя. А поскольку статья явно рассчитана на начинающих, эту часть можно было бы и не публиковать и, тем самым, сократить статью - и это IMHO пошло бы ей на пользу: сейчас великовата она получилась.
В Windows для работы со службами уже есть встроенная в систему обвязка: комнда sc.exe либо группа команд *-Service в Powershell. Если их использовать, то не нужно писать всю обвязку для установки и удаления службы - все делается через sc либо *-Service, а для работы самой службы всё это излишне: достаточно было бы оставить только регистрацию процесса службы в SCM (StartServiceCtrlDispatcher) с блоком точек входа в сервисы (в данном случае сервис - один) в main ( а не в _tmain, которая, кстати, только запутывает тех, кто знает C/C++), эту самую функцию входа в сервис (которая вызывает RegisterServiceCtrlHandlerEx, регистрирующий функцию обратного вызова, через которую SCM передает команды) и упомянутую функцию обратного вызова.
И мучиться с Get-WMIObject (который, кстати, обычно сокращают до gwmi) для работы со службами тоже не нужно - упомянутые команды куда удобнее. Ну, а запуск и остановку службы, совмещенную с процессом ожидания завершения этой операциии вообще удобнее делать командами net start и net stop.
PS Ну и, побрюзжу, мне это вполне по возрасту.
В результате поиска справочных материалов, примеров реализации служб и литературы для полноценного понимания их разработки я столкнулся с проблемой разрозненности информации в разных источниках. Узнать как полноценно разработать службу на Windows используя только один источник - сложная задача. Даже в официальной документации Майкрософт все примеры разрознены и разбросаны по разным страницам и чтобы снабдить своё приложение основными функциями приходится искать и соединять разные блоки кода из разных примеров.
Странно мне это. Когда давным-давно в далекой-далекой галактике я делал свой первый сервис, мне почему-то вполне хватило доступной документации из MSDN Library: общего описания жизненного цикла сервисов и документации по конкретным API. Может быть, это потому, что примеров я и не ждал: сервис я писал на первой 32-разрядной Delphi (так было надо), под которую примеров не завезли да и не ожидалось их. И классов, работу с сервисом облегчающих, в той Delphi не было тоже. Так что, пришлось разбираться чисто по описанию, как оно должно работать, и делать все самому. Впрочем, тогда такое положение было нормальным и даже хорошим: куда хуже делать что-либо вообще без документации - а порой приходилось. Правда, с другой стороны, тогда из службы можно было невозбранно вывести MessageBox на рабочий стол, а сейчас с этим проблемы.
Но тем, кто привык разрабатывать с помощью копипасты кусков примеров - им таки эта статья, наверное, будет полезной. Посему я воздержусь от ее оценки.
А сейчас в Delphi из коробки есть шаблон сервиса со всеми обвязками. Буквально сразу можно писать только код полезной нагрузки.
Думаю, что использование таких уже готовых шаблонов может быть уместно тогда, когда программист имеет полное понимание как эти службы вообще устроены, как они работают и как ими управлять из своей программы на более низком уровне.
В статье я не ставил цель "ускорить процесс разработки служб на Windows" потому что понятно, что для этого можно использовать уже готовые средства и инструменты заложенные в Delphi или C#. Так будет проще, быстрее и не нужно думать о том, как там всё внутри устроено. Однако такой вариант меня не устраивает, немного надоело, что везде всё уже сделано, и что "нужно использовать готовые решения".
Готовые решения это конечно хорошо, но сделать что-то самому с нуля, разобраться во множестве тонкостей и решить кучу проблем - это очень полезно.
Имхо, самый важный вопрос от комментатора выше (и вопрос, который возник у меня) это зачем нужно самому реализовывать install/start/stop/uninstall? Ведь есть уже встроенные утилиты, которые это делают. Для понимая устройства сервисов новичком этот код ничего не даёт, а только отвлекает от собственно тела сервиса.
Статья на этот вопрос не отвечает, запутывая читателей. Для новичков слишком много информации сразу. Для не новичков -- непонятно, зачем.
В крайнем случае, эти примеры можно было бы вынести в приложение в конце.
Для понимая устройства сервисов новичком этот код ничего не даёт, а только отвлекает от собственно тела сервиса.
Я так не считаю, поэтому акцентировал особое внимание на реализации этих функций. Если можно эти функции контролировать, то почему бы этого не сделать? Может быть в этих функциях какие-то дополнительные действия необходимы (например, логирование). Да и после реализации этих функций будет понимание того, как уже готовые утилиты (примерно) запускают службы.
Статья на этот вопрос не отвечает, запутывая читателей.
Не понимаю где тут может быть путаница. Сначала я описал что такое службы и как они работают, а затем описал реализацию приложения, которая управляет службой и, собственно, саму точку входа в службу. Всё, вроде бы, последовательно.
Для не новичков -- непонятно, зачем
Статья не для совсем новичков, а уже тех, кто более менее понимает как программировать приложения и столкнулся с задачей написания службы для Windows.
Я б сказал, что в статье лишнее примерно всё.
Хоть службы и лишены пользовательского интерфейса, но они могут пригодится при работе с этим самым пользовательским интерфейсом
А как же Allow windows service to interact with desktop?
https://learn.microsoft.com/en-us/windows/win32/services/interactive-services
Да и MessageBox можно бахнуть в SYSTEM desktop ради лулзов в любой момент
Лет тридцать назад подобная статья могла бы представлять какую-то ценность, но сейчас - увы.
В заголовке претенциозно заявлено"на C++", а за основу взяты древние тексты на чистом C, к которым сбоку прикручены отдельные элементы C++ вроде вызовов logger. Везде трудолюбиво используются типы указателей с префиксом LP которые потеряли смысл сразу после перехода с 16-разрядной архитектуры на 32-разрядные.
Совершенно непонятно, для чего нужно столь подробное разжевывание. Системные службы следует делать программистам, имеющим достаточную квалификацию, а для таких более чем достаточно уже имеющейся документации.
Статья может быть полезна разве что прикладникам на каких-нибудь JavaScript/Python, которые про C++ только слышали краем уха, но которым приспичило наваять службу, дабы значок их приложения всегда был в области уведомлений. Вероятность использования этого материала для создания сколько-нибудь адекватной и полезной службы, не создающей проблем с надежностью и безопасностью, стремится к нулю. :(
Лет тридцать назад подобная статья могла бы представлять какую-то ценность, но сейчас - увы.
Почему? И сейчас встречаются реальные задачи где нужно разработать службу для 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++ и как на нём разрабатывать полноценные приложения.
Вероятность использования этого материала для создания сколько-нибудь адекватной и полезной службы, не создающей проблем с надежностью и безопасностью, стремится к нулю. :(
Не могли бы Вы рассказать о проблемах, которые связаны с надёжностью и безопасностью в изложенном мной материале? Было бы неплохо его улучшить, если Вы действительно знаете где в исходном коде есть потенциальные проблемы и как от них избавится, я бы мог внести правки в свой материал и те, кто будет его читать получат возможность побольше узнать об устройстве служб и как делать "не нужно".
На данный момент я все дескрипторы освобождаю и делаю все возможные проверки на разных этапах работы управляющих функций и на данный момент не вижу проблем с надёжностью и безопасностью, может быть Вы на них прольёте свет я буду этому только рад.
Для опытных профессионалов эта статья может нести нулевую ценность из-за того, что они всё это уже знают, а для новичков в этой теме она ценна
Службы, драйверы ядра и подобное - темы не для новичков, это аксиома. Странно, что Вы этого не понимаете. Написав эту статью, Вы повысили вероятность того, что однажды в Вашей системе появится очередная кривая служба, слепленная на коленке одним из таких новичков, который без Ваших подробных разъяснений этого не осилил бы.
Тип данной статьи - туториал, я не зря же его таким поставил. Туториал предполагает, что будет решена какая-то полезная задача пошагово
Не все туториалы одинаково полезны. Например - "пошаговое руководство по сборке авиационной бомбы на кухне".
Вообще, я использую в данном проекте C++. Это можно легко понять и по исходным файлам где определяются функции для службы - они используют расширение *.cpp
Да, это примерно как делать и запускать под Windows исключительно DOS-программы, но при этом утверждать "я работаю и программирую под Windows". :)
Я мог бы добавить классы в файле WinService.h и все функции сделать методами и тогда не получать замечания по поводу того, что я C++ использую, а не Си)
Не нужно искусственно добавлять классы там, где они не нужны. Замечания в основном в отношении того, что в своем "коде на C++" Вы используете то, ради ухода от чего и создавался C++ - объявление переменных задолго до инициализации, заворачивание понятного const_cast в невнятный макрос, NULL вместо nullptr, никому не нужный void в качестве формального параметра и прочее. Уж на сколько я сам ретроград в отношении C++, но Ваши тексты откровенно режут глаза.
Я использовал части кода из официальной документации Microsoft, которая обновлялась сравнительно недавно
То, что они регулярно обновляют даты, не означает, что обновляется содержимое. Там многое не обновлялось уже лет тридцать.
сомневаюсь что префикс LP потерял свою актуальность
Актуальность он потерял еще тогда, когда от short/long pointer перешли к flat pointer (то есть, от Win16 к Win32). Хоть под Win16 служб никогда и не было, но MS в своих заголовках для NT традиционно дублировали типы указателей P* типами LP*. Они настолько же "актуальны", как и (void) в определении/объявлении функции - синтаксически корректны, но ни малейшего смысла не имеют.
Может быть "такие" программисты тоже хотят стать квалифицированными специалистами в этой области и чтобы освоить эту тему такой материал им может быть полезен
Чтобы стать достаточно квалифицированным для разработки системных программ, программисту необходимо читать серьезную профильную литературу, а не "пошаговые туториалы". В следующий раз, когда Вам встретится очередной кривой драйвер, инсталлятор, "оптимизатор реестра" или что-нибудь подобное - постарайтесь не забыть, что Вы лично внесли свою лепту в эту тенденцию.
Написав эту статью, Вы повысили вероятность того, что однажды в Вашей системе появится очередная кривая служба, слепленная на коленке одним из таких новичков, который без Ваших подробных разъяснений этого не осилил бы
Вообще не понимаю причём тут данный туториал и "очередная кривая служба". Если она действительно кривая, то будьте добры объяснить в чём эта кривизна проявляется. Мне на данный момент это не понятно, как и какие могут здесь возникнуть проблемы с безопасностью.
Не все туториалы одинаково полезны. Например - "пошаговое руководство по сборке авиационной бомбы на кухне".
Согласен. Можно сделать его максимально полезным, если Вы поделитесь своим профессиональным опытом написания служб на C++ и расскажите какие минусы в представленной в статье реализации есть ("кривизна", "плохая безопасность").
В следующий раз, когда Вам встретится очередной кривой драйвер, инсталлятор, "оптимизатор реестра" или что-нибудь подобное - постарайтесь не забыть, что Вы лично внесли свою лепту в эту тенденцию.
Отнюдь, не вижу связи. В туториале рассматривается самое базовое приложение для управления службами ну и сама служба. Если программист пишет "кривой драйвер", то наверное ему его нужно исправить? А как написать "не кривой драйвер" если ты никогда не ошибался при его написании? Иными словами чтобы написать хороший драйвер нужно ошибаться, но необязательно. Ошибается ли среднестатистический программист при написании драйвера? Да, ошибается. Обязательно ли это? Нет, не обязательно. Вношу ли я прямо или косвенно вклад в то, что кто-то пишет кривой драйвер? Навряд ли, потому что в результате туториала создаётся базовая служба и приложения для управления ею, а не драйвер.
Чтобы программист стал профессионалом - ошибаться нормально, особенно когда программист готов эти ошибки исправлять и понимать почему это ошибка, собственно, возникает.
не понимаю причём тут данный туториал и "очередная кривая служба"
Связь самая непосредственная. Любые (без исключения) туториалы предназначены для тех, кто или вообще не понимает сути описываемой деятельности, или понимает ее чисто интуитивно, и сам не в состоянии понимать адекватные технические описания. Туториалы типа "как отключить обновления через редактор реестра" исключительно уместны, так как предназначены для обычных пользователей, для которых не предусмотрено более адекватных средств управления, и которым нужно отключить обновления в своей системе, а не написать программу, отключающую их в произвольной.
Ваш туториал по созданию службы практически бесполезен для профессионального системного программиста - вместо него он будет использовать техническую документацию. Но им охотно воспользуется любой, кто с помощью подобных же туториалов научился составлять относительно работоспособные программы, не особо понимая, что и как они делают, а лишь записывая в нужном порядке символы и слова. Когда такие ребята сваяют очередное кривое и глючное поделие, чтоб занять свою нишу на рынке - и черт бы с ними. Но с помощью таких, как Вы, они успешно лезут туда, где им не место.
как и какие могут здесь возникнуть проблемы с безопасностью
Элементарно: служба, которую по Вашему туториалу напишет дилетант, скорее всего, будет работать с файлами и/или реестром. Если он, замыслив удалить со всем содержимым какой-нибудь временный каталог или созданную им ветку реестра, перепутает пути, и сделает это с системными путями, то в обычном непривилегированном приложении он получит отлуп, а в службе этот код исправно отработает.
А если он сколхозит свою службу так же, как нынче принято писать пользовательские приложения, то в ней с высокой вероятностью будет изрядный набор удобных целей для атак.
если Вы поделитесь своим профессиональным опытом написания служб на C++
Каким конкретно опытом я мог бы поделиться в данном контексте? Я в этой сфере не придумал ничего нового - все давным давно описано вдоль и поперек.
Кстати, Вы хоть в курсе, что у типичного "современного программиста на C++" тексты Ваших примеров вызовут когнитивный диссонанс? :) Его очень удивит использование legacy-функций вместо string, отсутствие других привычных обращений к STL, первое присваивание переменным, определенным где-то выше, и т.п. Эти тексты адекватно поймет только тот, кто одновременно знает и C, и C++, причем C++ он изучал по материалам минимум двадцатилетней давности.
Если программист пишет "кривой драйвер", то наверное ему его нужно исправить?
Для начала неплохо бы ответить на вопросы "почему драйвер получился кривым?" и "действительно ли человек, написавший драйвер, является программистом?".
как написать "не кривой драйвер" если ты никогда не ошибался при его написании?
Уж точно - не писать драйвер по "туториалу". Для начала следует изучить все, что необходимо знать в этой сфере, и понимать, как устроен драйвер, в какой среде он работает, как с ним взаимодействует система, каковы типичные риски, и т.п. Все это неплохо описано и в документации MS, и в профильной литературе. Но мне попадались и "туториалы" вроде Вашего, в стиле "ваша программа не имеет доступа к портам? напишите драйвер, который это делает!". Соответственно, попадались и поделия, реализующие через глубокую кривую задницу то, что положено делать совсем иначе.
Ошибается ли среднестатистический программист при написании драйвера?
Среднестатистическому программисту вообще нечего делать в области драйверов и служб. А квалифицированные программисты, работающие в этих областях, и ошибаются соответственно - например, в том, что забыли инициализировать или освободить память, а не в том, что используют в программе конструкции, смысла которых не понимают.
Элементарно: служба, которую по Вашему туториалу напишет дилетант, скорее всего, будет работать с файлами и/или реестром. Если он, замыслив удалить со всем содержимым какой-нибудь временный каталог или созданную им ветку реестра, перепутает пути, и сделает это с системными путями, то в обычном непривилегированном приложении он получит отлуп, а в службе этот код исправно отработает.
Я ну искренне не понимаю, причём тут данный туториал? Вы утверждали, что в коде есть проблемы с надёжностью и безопасностью в своём комментарии выше:
Вероятность использования этого материала для создания сколько-нибудь адекватной и полезной службы, не создающей проблем с надежностью и безопасностью, стремится к нулю.
Я же правильно всё понял? Или Вы что-то другое имели ввиду?
Я попросил Вас - укажите на мои ошибки. Неоднократно это делал, однако так и не дождался конкретики, сплошная теория. И сейчас Вы пишите мол "ошибка будет тогда, когда какой-нибудь программист напишет то и то, вот тогда будет беда", а про конкретно текущий код у Вас нет претензий, я правильно понимаю? Я что-то уже запутался если честно) Какая-то критика ради критики)
Если у Вас есть конкретные предложения по улучшению статьи - предлагайте, с радостью это сделаю. Если их у Вас нет (с каждым комментарием я в этом только убеждаюсь), то ок - зачем тогда критика? Ради критики? Она ведь далеко не всегда у Вас объективна, скорее очень очень субъективна и со многим из этой критики я не согласен, кроме указаний моих фактических ошибок (по типу ошибки понимания формата *.hpp как *.c).
А если он сколхозит свою службу так же, как нынче принято писать пользовательские приложения, то в ней с высокой вероятностью будет изрядный набор удобных целей для атак.
Видимо упоминания того, что службы работают в фоновом режиме было не достаточно. Ладно. Какой изрядный набор удобных целей для атак есть в описанном Вами случае? Интересно узнать.
Среднестатистическому программисту вообще нечего делать в области драйверов и служб
Почему? Есть какие-то ограничения? Программист (любой) может заинтересоваться этой областью и начать делать службы и писать драйвера. Возможно успешно, возможно не очень. Делать ему так определённо есть что, если ему это интересно.
Вы пытаетесь сформировать образ системного программирования как то, что доступно лишь "элите", "первоклассным стрелкам по ногам с помощью кольта C/C++", которые читают только жёсткую техническую литературу и знают точно-точно всё из своей области, потому что войти в неё сложно. Ну или чтобы в неё войти, надо прочитать кучу технической литературы.
Я ж не спорю. Системное программирование - действительно классная область, со своими проблемами, задачами и интересными особенностями. И да, чтобы в этой области хорошо разбираться нужно кучу технической литературы изучить и программировать низкоуровневые штуки. Но войти в эту область среднестатистический программист может, если захочет (и ничего Вы с этим не сделаете).
Боитесь конкуренции в системном программировании? Это лишнее, задач на всех хватит)
Даже если Вы не ИИ, то Вам отлично удается его имитировать.
Даже если бы я был ИИ, то зачем мне это? Зачем мне писать эту статью с помощью ИИ или сгенерировать её полностью самим ИИ?
У меня ведь даже мотивации толком нет, чтобы генерировать статьи, польза от которых и для меня (человека), и для читателей (вот тут уже сложно - может быть и человек, а может быть и ИИ) может быть минимальна. Я наоборот стремлюсь к качеству материала и углублению как своих знаний, так и знаний читателя.
Я наоборот стремлюсь к качеству материала и углублению как своих знаний, так и знаний читателя
Даже если Вы искренне в это верите, то это, к сожалению, лишь иллюзия. То, что Вы способны писать пространные тексты и собирать в кучу обрывки разнородных материалов, не имеет отношения ни к качеству, ни к углублению знаний.
Если не хотите, чтобы над Вами смеялись - или углубляйте знания перед тем, как излагать их на публике, или излагайте только то, в чем уже достаточно глубоко разобрались и имеете опыт. Возможно, статьи по программированию на JS/TS у Вас получились бы значительно лучше - по крайней мере, сейчас.
Даже если Вы искренне в это верите, то это, к сожалению, лишь иллюзия. То, что Вы способны писать пространные тексты и собирать в кучу обрывки разнородных материалов, не имеет отношения ни к качеству, ни к углублению знаний.
Вообще, любая вера, можно сказать, иллюзия. Но это уже плоскость философии, так что согласен. Кто на что горазд, так скажем)
Я собираю не обрывки, а описываю полноценный процесс создания служб, не более. А вот уж каким образом я углубляю знания - Вам навряд ли известно. Лично я разобрался в теме настолько, насколько требовалось и попытался до читателя донести усвоенный самим собой материал. Успешна эта попытка или нет - покажет время.
Если не хотите, чтобы над Вами смеялись - или углубляйте знания перед тем, как излагать их на публике, или излагайте только то, в чем уже достаточно глубоко разобрались и имеете опыт.
Спасибо за совет, но я сам лучше для себя решу что мне делать - публиковать материал или нет. Я не чувствую, что надо мной тут "смеются", скорее у читателей могут быть идеи по улучшению статьи, чему я всегда рад.
А если даже кто-то и смеётся, то это моя проблема или проблема тех, кто смеётся? :)))
Я свой уровень и свои возможности прекрасно знаю, есть ещё куда расти)
Это можно легко понять и по исходным файлам где определяются функции для службы - они используют расширение *.cpp, а не *.hpp, которые обычно используют для исходников на чистом Си.
Здесь не корректно указал расширение - *.c, а не *.hpp (корректировка комментария не возможна из-за ограничений по времени)
Замечу все же, что GitHub крайне хреново определяет язык в файлах репозитория. Например, файлы inc, он безоговорочно считает как код на C++, однако, они много где используется. Например, в Delphi принято такое расширение для файлов, которые подключаются директивой {$include 'file.inc'}
Есть даже целые репозитории, которые GitHub определяет как проект на C++, в то время, как он полностью на Pascal (Delphi).
Странно, ни разу не видел файлов .inc с кодом на C++. Это расширение всегда типично использовалось для вставок на ассемблере, в makefile, в том же Pascal и т.п.
https://github.com/ev1313/Pascal-SDL-2-Headers
Тут только файлы pas и inc в которых исключительно код на Delphi/Pascal
Результат:
А где там php вообще не понятно
Да не, довольно неплохо если такая статья будет находится поиском, например. Можно и по MSDN все сделать, но тот понемногу мутирует, непонятно что с ним в итоге будет. Более того MSDN это reference, а это как пример службы с хорошим описанием типовых вещей организации сервиса.
Совершенно непонятно, для чего нужно столь подробное разжевывание.
Вот такие комментарии вроде "автор ты больше такое не пиши" по моему абсолютно не корректные. Обычно автор сам в силах разобраться что ему писать или не писать. WinAPI программирование хоть и ушло из мейнстрима все еще актуально, есть кому опыт других интересен.
Вот из-за таких авторов Хабр и скатился от некогда вполне серьезного и уважаемого ресурса к унылому болоту, в котором что-то достойное бывает не каждую неделю. :)
в котором что-то достойное бывает не каждую неделю
Что ж, если Вы так считаете, то почему бы Вам лично статью на данной платформе не написать? Почему нет? Расскажите о решении какой-нибудь задачи из области системного или прикладного программирования, напишите хорошую статью так, как Вы её видите. Покажите своим примером как нужно статьи писать)
Ведь рассуждать так любой горазд мол "унылое болото", "платформа скатилась" и т.д. и т.п., но почему-то показать своим примером "как надо делать" не у каждого получается. Или Вы только потребитель? Посмотрел на Ваши статьи в профиле и там нет ни одной публикации после 2015 года, зато комментируете другие статьи до сих пор. А оценки то у статей неплохие, почему бы Вам не продолжить публиковать материалы? Чем больше технического контента на платформе, тем лучше.
Ладно бы если эти комментарии были не критикой ради критики, а несли в себе что-то действительно важное, что можно подчерпнуть и добавить в само содержимое статьи (от этого, повторюсь, выигрывают все), но конкретно Ваша критика мне видится очень субъективной и по сути просто критика ради критики, типа хобби, а вот конкретно к коду никаких замечаний у Вас нет (кроме холиварной темы "что есть Си, а что есть C++", которую продолжать я не хочу, поскольку у каждого своё мнение на этот счёт и я останусь при своём).
Станьте тем автором Хабра, который будет писать "достойные статьи", покажите как надо) Желательно каждую неделю) Буду лично читать Ваши статьи и набираться опыта того, как надо писать такие статьи на темы системного программирования) (не сарказм, уверен у Вас есть чему поучиться).
Автор неплохо постарался, однако рейтинг сложный перебор.
они используют расширение *.cpp, а не *.hpp, которые обычно используют для исходников на чистом Си.
Если автор отличает Си от C++ по расширению, да ещё утверждает, что hpp якобы используется для исходников на чистом Си, у меня возникают очень серьёзные вопросы к его компетенции в этом вопросе. Настолько серьёзные, что на низкопробный легаси код, приведённый в статье, уже даже не смотришь.
Работа и вправду проделана большая, но выставленный автором высокий уровень сложности совершенно не соответствует действительности. Это, несмотря на размер, достаточно простая статья, причём весьма низкого качества. Я бы категорически не рекомендовал её использовать будущим читателям как учебное пособие или что-то в этом роде.
Тем не менее, я хочу пожелать автору успехов, при должном упорстве он, конечно, многого может добиться, особенно если прислушается к критике со стороны более опытных людей, уже высказавших свои основные замечания в комментариях.
Я лишь отмечу, что любой Си-код является валидным C++-кодом, а суть C++ состоит не только в другом расширении и не только в использовании операторов ввода-вывода) Рекомендую почитать на досуге исходные коды известных Си и C++ библиотек, да и в принципе более подробно ознакомиться с основами обоих языков, сходствами и различиями между ними. Расширение у Вас, может быть, и .cpp, но C++ разработчики так не пишут и Вам на это напрямую указал @emusic
C++ разработчики так не пишут
А с этим другая засада. :) C++ разработчики, выросшие на современной литературе, чаще всего не мыслят C++ без STL, многоуровневых шаблонов, исключений, лямбд и прочего, даже если что-то из этого явно избыточно. Еще неизвестно, сможет ли типичный C++ - прикладник, осваивающий системное программирование, написать код лучше того, что мы видим здесь. :)
Если автор отличает Си от C++ по расширению, да ещё утверждает, что hpp якобы используется для исходников на чистом Си
Да ошибся я, ну не могу поправить комментарий) Расширение hpp не используется для исходников на чистом Си)
Работа и вправду проделана большая, но выставленный автором высокий уровень сложности совершенно не соответствует действительности. Это, несмотря на размер, достаточно простая статья, причём весьма низкого качества. Я бы категорически не рекомендовал её использовать будущим читателям как учебное пособие или что-то в этом роде.
Можете пожалуйста подробнее раскрыть суть предложения "причём весьма низкого качества"? Я бы хотел эту статью улучшить, если она действительно получилась не очень хорошего качества. Почему она низкого качества и чего в ней не хватает? Что бы Вы хотели видеть в данной статье, чего ещё нет? Любые предложения по её улучшению принимаются)
Простая статья может быть для конкретно Вас, но тех, кто в первый раз работает с такой задачей - это может быть сложно. Я не из-за размера её уровень поставил, а из-за содержимого, потому как посчитал его сложным. Но, это уже моё субъективное мнение) Оценка сложности - дело индивидуальное
Взгляните на этот образец: https://blog.csdn.net/xiaoyafang123/article/details/52235295
Он, спору нет, тоже не идеален, но в целом заслуживает внимания.
Взгляните на этот образец: https://blog.csdn.net/xiaoyafang123/article/details/52235295
Действительно интересный пример реализации службы представлен в данной статье, спасибо что поделились им)
Однако я так и не понял, почему моя статья "весьма низкого качества" (по вашей характеристике), видимо никаких деталей узнать не суждено.
Если Вы имели ввиду то, что код написан не очень качественно - вопросов нет. Тут у каждого своё понимание как он должен быть написан. Возможно я перепишу в будущем программный код этой статьи и выпущу отдельную публикацию по этому поводу, чтобы не было сомнений что я использую C++, но причём тут конкретно вся статья - не совсем ясно.
Может быть оформлено не очень или что-то не до сказано. В публикации из Вашего комментария вообще практически только код и есть, с небольшими пояснениями на китайском) Так я, конечно, писать не буду, если это Ваше понимание "весьма качественной статьи", так как имею противоположное мнение. Но программный код хорошо написан, возьму на вооружение.
Есть такое понятие - "нахватавшийся". Вы своей статьей произвели на более-менее образованных и опытных в теме людей именно такое впечатление.
Если бы в ответ на первую критику Вы стали отвечать что-нибудь вроде "да, согласен, полез не в свою сферу, думал проскочить за счет общей эрудиции, но не вытянул, больше так не буду", Вы могли бы рассчитывать на более сдержанную реакцию. Но Вы даже сейчас продолжаете упрямо талдычить: "ничего не понимаю, я старался, вроде все написал хорошо, разве что по мелочи где-то напутал, чего пристали?".
Умный и амбициозный человек в ответ на такую критику будет землю носом рыть, чтоб соответствовать. Вы же предпочитаете оправдываться в стиле "ну и что, все ошибаются, ничего страшного". Но одни ошибаются в порядке исключения, а другие - просто потому, что иначе не умеют. Выбрав такой подход, Вы будете лажаться систематически, и каждый раз просить отнестись к Вам снисходительно. То есть, отвечать за последствия Ваших косяков придется кому-то другому.
Разумеется, многим из тех, кто не считает себя профессионалом в этих областях, Ваша статья представляется образцом глубокой и последовательной работы, чуть ли не шедевром - они тут уже отметились респектами. Кто-то из них, возможно, владеет предметом даже лучше Вас, но у них попросту не хватило нахальства заниматься менторством, а у Вас - хватило.
Интересный у Вас взгляд на происходящее, конечно :)
Есть такое понятие - "нахватавшийся". Вы своей статьей произвели на более-менее образованных и опытных в теме людей именно такое впечатление.
А Вы у всех "более-менее образованных и опытных людей" мнение спросили? Или всех под одну гребёнку за счёт Ваших личных убеждений подстраиваете? Нельзя же быть 100% уверенным что всё так, как Вы думаете. Это называется субъективизм. Думаю что и для таких людей (по Вашей характеристике) в этом материале есть что-то полезное и интересное, ну, или они заинтересуются этой темой и разберутся в ней более глубоко, чем разобрался я. Всё равно есть плюсы.
да, согласен, полез не в свою сферу, думал проскочить за счет общей эрудиции, но не вытянул, больше так не буду
Ещё раз - я с Вами во многом не согласен и у меня достаточно опыта, по моему мнению, чтобы с Вами дискутировать, будь у Вас опыта хоть в 10 раз больше меня - общие принципы разработки ПО (драйвера, игры, веб-приложения и многие другие) не особо меняются. Есть детали, есть глубина, которую нужно учитывать (без неё никак), но в широком смысле я могу разобраться как устроена разработка служб исходя из своего опыта (что я и сделал перед публикацией данного материала).
То что я "полез не в свою сферу" - я так не считаю. Я программист и в рамках данной статьи ничем кроме программирования (служб) не занимался. Это моя сфера ровно настолько, насколько она и Ваша. Здесь просто задачи другие и область (направление) системного программирования имеет кучу своих тонкостей, в которых необходимо разобраться. Я это учитываю.
Умный и амбициозный человек в ответ на такую критику будет землю носом рыть, чтоб соответствовать.
А это манипулятивный приём уже пошёл. Если я на такую Вашу критику не отреагировал "как положено", то что? Я теперь не умный и не амбициозный? Да как я посмел на Вашу критику ещё о чём то с Вами спорить, ужас (сарказм, нет).
Вы же предпочитаете оправдываться в стиле "ну и что, все ошибаются, ничего страшного".
Не правда, я спрашивал у Вас не однократно - где проблемы в программном коде. К статье если ещё можно придраться (ошибки в словах, не очень информативные предложения в тексте), то к коду Вы не придираетесь (если это не холиварная тема "Си это или C++"). Я за улучшение материала данной статьи, я это и буду делать по мере поступления ошибок. От Вас только критика ради критики (ну и критика персональная) идёт, не более.
Выбрав такой подход, Вы будете лажаться систематически, и каждый раз просить отнестись к Вам снисходительно. То есть, отвечать за последствия Ваших косяков придется кому-то другому.
Я такой подход не выбирал, я за развитие. Через ошибки программист развивается равно как и любой специалист в своей области. Систематически я не лажаю, насколько я себя знаю. Относится "снисходительно" ко мне я никого не прошу. Я уже отвечал на эту Вашу критику выше. За свои ошибки и косяки отвечаю я сам.
Разумеется, многим из тех, кто не считает себя профессионалом в этих областях, Ваша статья представляется образцом глубокой и последовательной работы, чуть ли не шедевром - они тут уже отметились респектами.
Думаю кому-то она действительно понравилась и из "профессионалов" по Вашему мнению. Шедевры оценивают куда большим числом "лайков")
Кто-то из них, возможно, владеет предметом даже лучше Вас, но у них попросту не хватило нахальства заниматься менторством, а у Вас - хватило.
Не сомневаюсь, Вы, например, возможно владеете этим предметом лучше меня. Это же не плохо? Что плохого в том, что кто-то лучше разбирается в предмете? Это ещё один хороший повод по общаться и поделится опытом, так сказать расширить кругозор. Но, Ваша критика тут придерживается другой цели - скорее "задеть" как-то, только вообще не получается. Из комментария в комментарий такая тенденция наблюдается.
Слово "ментор" в нынешней её трактовке мне крайне не симпатизирует. Я просто поделился своим текущим опытом и опубликовал его. Предлагаю и Вам сделать тоже самое и показать мне и читателям "как надо писать достойные статьи".
Да не слушай никого - спасибо за статью. Собрал все вместе. Разобрался. Молодец. Да хоть на чистом C - какая разнница? Какие-то странные придирки и претензии.
Тут или человека опередили со статьей или еще какие-то причины негодования и нападок, явно не связанные с темой.
Проблема не столько в подаче (Ваша подача, хоть и не в моём вкусе, возможно, будет весьма полезна для новичков: немало вещей достаточно подробно описаны), сколько именно в качестве кода. Именно поэтому я и привёл пример более удачной (по моему мнению) реализации. Не предлагаю Вам писать на китайском, но прошу обратить внимание на структуру кода, использующиеся синтаксические конструкции и пр.
Добавил ссылку на эту статью и другие в список рекомендованных источников, спасибо за хороший образец программного кода)
перед тем, как городить свои огороды я бы посоветовал посмотреть проекты типа NSSM - the Non-Sucking Service Manager
Разработка служб для Windows на C++