Если автор отличает Си от 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#. Так будет проще, быстрее и не нужно думать о том, как там всё внутри устроено. Однако такой вариант меня не устраивает, немного надоело, что везде всё уже сделано, и что "нужно использовать готовые решения".
Готовые решения это конечно хорошо, но сделать что-то самому с нуля, разобраться во множестве тонкостей и решить кучу проблем - это очень полезно.
Думаю да, это было бы легче, учитывая что слои абстракции в C# вырастают с каждой новой версией этого языка так, что можно разработать службу значительно быстрее.
Однако использовать два языка программирования (C++ и C#) - не всегда уместно, поскольку программы на разных языках программирования имеют свои особенности, которые могут зависеть от платформы (в следствие чего поддержка таких программ требует больших усилий), да и скрытие "рутинных задач" за большим слоем абстракции лишает программиста важного - получения опыта. Ведь разобраться как устроено управление службами на C++, на мой взгляд, ценнее, чем использовать высокоуровневые абстракции и просто решить задачу так, как проще или так, как "модно".
Конечно, и в статье используется высокоуровневые абстракции из WinAPI. Может быть есть способ написать службу на более низком уровне с использованием чистого Си и без WinAPI, однако такого способа я, на данный момент, не знаю. Если бы знал такой способ - сделал бы на чистом Си) Уменьшая слои абстракции и используя более низкоуровневые инструменты программист получает больше опыта за счёт необходимости разбираться в большем числе деталей.
Я уже считать устал, сколько раз оно так в одном месте собиралось за прошедшие десятки лет...
Не могли бы Вы поделится ссылкой (или ссылками), где аналогичный материал собран в одном конкретном месте и где так же (или даже лучше) рассматривается подобная тема? Не исключаю, что я, возможно, плохо искал и поэтому столкнулся с проблемой разрозненности информации по разным источникам.
Думаю не только мне будет полезно ознакомится с другими работами, где данная тема широко освящена.
Тема разработки веб-приложений с помощью библиотеки Three.js для создания трёхмерной графики довольно интересна. Сейчас и игры делают с её помощью, коммерческие приложения или просто визуализации (например, для кластерного трёхмерного анализа это может быть применимо).
Однако по ходу чтения статьи я обнаружил, что после её прочтения - мало что из неё понял и уяснил, хотя с трёхмерной графикой опыт работы уже имел. Хотел бы выразить ряд замечаний связанных с материалом самой статьи и её оформлением, с целью мотивировать авторов данной статьи её улучшить.
Начнём с замечаний по материалу. В статье не ясно какой будет конечный результат, как мы к этому результату пришли, что для этого нужно сделать (нумерованный список с действиями это не объясняет, а только добавляет вопросов). Понятно, что в начале было (косвенно) о разработке механизма, с помощью которого можно будет преобразовать картинку в 3D модель (если я правильно понял):
Возможность конвертировать картинки разных форматов в 3d визуал.
Но, что-то, ни картинки, ни 3D модели в конечном итоге я не увидел в статье.
Когда пишут статьи где подразумевается работа с графикой (2D, 3D, 4D), то в статье, как бы, хорошим тоном считается добавлять картинки начального, промежуточного и конечного результата. Особенно радует когда понятно с помощью каких алгоритмов, программного кода или подхода мы пришли от A к B и от B к C.
Начнем с того, что такое файл JSON.
Мы так и не узнали что такое файл JSON :) Возможно Вы имели ввиду файл package.json, т.к. после этого предложения идёт описание и предназначение файла package.json. В любом случае, наблюдается непоследовательность изложения. Файл package.json просто так появиться не может, он создаётся с помощью специальной утилиты npm (для командной строки это утилита, а вообще это пакетный менеджер). И после описания файла package.json идёт следующий текст:
Для начала установите Node.js, если у вас его еще нет, а так же установим webpack (чуть позже он нам пригодится)
Если вы хотите объяснить что такое package.json, то это следует делать только после того, как вы опишите что такое Node.js и NPM, потому что складывается ощущение что этот файл нужно создать самому, а Node.js это так - что-то стороннее. Файл package.json описывает в целом конфигурацию JS/TS модуля, с зависимостями и прочими вещами.
Команда для macOS
Мы живём в мире, где царствует кроссплатформенная и кроссбраузерная разработка. Не у всех читателей на Хабре компьютер с MacOS, поэтому если вы решаетесь написать команду для установки Node.js на свою ОС, то следует дать ссылку или написать где-нибудь рядом команды для установки под другие ОС (например, Ubuntu или Windows).
Если же ваша работа целиком и полностью охватывает только MacOS, то об этом следует написать сразу в начале, чтобы пользователи понимали в какой среде будет происходить работа и, соответственно, сможет ли пользователь все эти эксперименты повторить.
После этого мы запускаем команду npm init -y, которая создает нам файл json с базывыми настройками
Данный текст требуется доработать. Есть ошибка в слове "базовыми" и не ясно что за файл создаёт нам утилита npm, при вызове команды npm init -y (а он создаёт как раз package.json).
Я постараюсь кратко описать всю структуру и математику проекта, поэтому опишу основной алгоритм выполнения
Формулировка данного текста довольна не точная, потому что структуру проекта Вы не описываете. Вы описываете основной алгоритм, который заложили в программный код на JavaScript, но не структуру проекта. Обычно под структурой проекта понимается набор файлов, папок (или каталогов), которые определённым образом упорядочены и это упорядочение имеет какую-то смысловую нагрузку. Например, в каталоге app у нас входная точка в программу, а в каталоге hooks специальные хуки. Или в каталоге models у нас модели, а в shader у нас шейдеры.
Необходимо скачать библиотеку three так же через brew
Здесь нужна также команда и также на более распространённые ОС чем MacOS (так вы увеличите число заинтересованных читателей).
с собитием нажатия
Стоит обнаружить и поправить побольше таких слов, потому что читается это забавно :)
которая будет используется
Это сюда же :)
Очистка группы
Что за группа? В представленном статье коде непонятно что под группой (переменной или константой group) подразумевается? Почему её нужно очистить? Зачем? Что она из себя представляет? Думаю здесь нужно подумать над тем, чтобы добавить описание этой ... ячейки (ячейкам) оперативной памяти, которую занял и выделил под ваш скрипт браузер и который контролирует доступ к этой ячейки памяти из вашего скрипта (через, например, движок V8 или любой другой, который есть в популярных MacOS браузерах). Переменная это или константа - непонятно, поэтому написал абстрактно :)
Цикл для создания 3D-объектов
Здесь в программном коде ошибка. Нужна закрывающая фигурная скобка в конце цикла. В общем-то дальше такие ошибки также встречаются (нужно вычитывать статью, перед публикацией, чтобы таких "мелких" недочётов не было, иначе из-за этого можно "нахватать минусов").
В принципе, это все. Нам осталось загрузить результат в объект img и отрисовать это все с помощью функции, которая вызывает саму себя и обновляет данные сцены и камеры
И дальше идёт код анимации, по видимому, а не отрисовки объекта img. Как я понял, в функции animation идёт рендеринг сцены и камеры, а не объекта img.
Значения нормализуются, деля на 255
Деля что на что, и зачем нужна нормализация в данном случае? Тема не раскрыта.
В общем и целом, предлагаю авторам статьи ещё раз перечитать материал и его улучшить, ему это действительно необходимо, чтобы он лучше читался и было понятно о чём идёт речь. Тема векторизации также не раскрыта.
По оформлению статьи есть также замечания, которые мне, как читателю, показались нуждающимися во внимании.
Первое замечание касается не целевого использования цитаты для оформления списков:
Список это цитата, список или список цитат?
Списки всегда лучше оформлять списком. У хабра замечательный редактор (правда с обратной совместимостью прошлых статей проблемы есть, но в целом норм), его возможности можно использовать на максимум чтобы добиться хорошего оформления статьи. Есть даже специальные публикации о том, как нужно оформлять статьи. Советую их почитать, будет полезно.
На хабре также есть редактор исходного текста программ. Если добавить программный код на страницу то рядом есть выпадающий список с возможными языками программирования. Стоит его активно использовать и читать исходный код будет легче:
И JSON, и команды можно оформить как и код - будет выглядеть лучше
Программный код должен оформляться как программный код, а не как часть текста. То же относится и к командам:
Код с текстом мешать не стоит, выглядит это очень не очень
Нумерованные заголовки также не стоит выделять цитатами, для этого есть заголовки разного уровня в самом редакторе (как правило их хватает).
Также не хватает библиографического списка (какими статьями вы руководствовались, когда писали данный материал?) и ссылку на исходный код (потому краткие его выжимки не дают понимания полной картины).
Хорошая статья, если она что-то обозревает (например, результаты исследования), содержит минимум кода, но при этом максимум словесного описания, проектирования и визуализации. После прочтения такой статьи нет недопонимания ключевых вещей, а для ознакомлением с деталями можно всегда обратиться к исходному коду.
Спасибо за статью, очень рекомендую её улучшить (моменты основные расписал), у этой темы определённо есть будущее.
Рекомендую также ознакомиться с книгой про работу с графическими процессорами в браузере (WebGPU), может быть эта тема будет вам интересна)
Желаю успехов в дальнейшем развитии во frontend-разработке и в освоении трёхмерной графики!
Во втором аргументе используется не указатель на временный объект, а ссылка на переменную из локальной области видимости функции, которая по стеку вызовов находится выше, т.к. даже под хранение в памяти указателей выделяется память, а для ссылок, насколько я помню, память не выделяется. Поэтому аргументы в функции, которые являются указателями, не так сильно оптимизирует общую используемую память приложения (многие уверены в обратном), большей оптимизации можно достичь с помощью ссылок, дабы избежать не нужных конструкторов копирования тяжеловесных объектов, а маршрутизировать конкретные ссылки на эти объекты и с ними уже работать.
Думаю, чтобы не было проблем, имеет смысл переписать конструктор таким образом:
explicit Logger(const std::string& name, const std::ostream& out = std::cout);
будет осуществляться без ошибок и не будет для аргумента name вызываться не нужный конструктор копирования.
Вдобавок, было бы неплохо добавить ещё множество конструкторов по умолчанию. Например, конструктор копирования, без параметров, присваивания и т.п.. Перегрузка операторов ещё может быть полезным механизмом, чтобы, например, постоянно не вызывать методы логгера. Условно можно в файл записать лог и через такую конструкцию:
log += "Новая строка";
log += BuildLogMessage(date, type, "Ещё одна новая строка");
Определённо интересный проект для изучения и исследования некоторого множества тонкостей языка программирования C++. Это хороший опыт)
Однако у меня есть кое-какие рекомендации к форматированию самой статьи, т.к. её немного "сложно" читать (если так можно выразиться).
Поскольку авторы на Хабре часто описывают результаты своей практической или теоретической деятельности есть определённые правила по "красивому оформлению статьи". Очень рекомендую с ней ознакомится, т.к. они в общем и целом позволят улучшить форматирование Вашей статьи.
Написал я логгер на C++ для C++ https://github.com/Fallet666/logger
А еще важная информация, я ищу работу C++ разработчика, пожалуйста напишите мне https://t.me/born_in_void, если можете помочь, я студент в Москве)
Такое введение в статье выглядит немного странно. Всё таки Хабр не является ресурсом, прямой целью которого является помощь в трудоустройстве (хотя косвенно она присутствует) - для этого есть соседний сайт Хабр.Карьера, рекомендую заглянуть, может быть так Вы быстрее найдете работу. Вдобавок в конце статьи Ваши контакты уже видны (в т.ч. ссылка на Telegram), зачем повторяться?
В целом ссылки по типу "https://github.com/Fallet666/logger" или "https://t.me/born_in_void" лучше оформлять как пример_1 и пример_2. Т.е. текстом, а не ссылкой. Потому что интерес читателя перейти по ссылке будет больше, если для перехода по ней достаточно одного нажатия. Сейчас же ссылки нужно выводить с помощью мышки, чтоб по ней перейти.
Форматирование для кода на Хабре поддерживается и достаточно успешно. Код будет выглядеть красивее, если при вставки кода выбрать конкретный язык программирования (делается это сверху в выпадающем меню "Язык"). Достаточно сравнить:
Тут у заголовков "плывёт" размер. Казалось бы "Упрощенные функции для каждого уровня" стоит сделать больше, чем нумерованные наименования глобальных функций логгера, т.к. он описывает свой подраздел. Здесь же кажется, что как раз наименование подраздела это обычный выделенные текст, а сам подраздел - элемент нумерованного списка, который не должен быть вообще заголовком H3 (сейчас он такой). Для задания "жирного" оттенка тексту лучше использовать свойство для стилизации текста при его выделении, если это требуется. Но не стоит этим перенасыщать статью. Например, текст "Пример использования" можно вообще не выделять жирным, а методы в нумерованных списках выделять без выделения номера (но это уже мелочи).
У раздела, подраздела и далее по уменьшению, как правило, размер текста уменьшается. Так просто принято, так удобно, легко читаемо и интуитивно понятно где логические границы.
Успехов в поиске работы и дальнейшем написании статей!
P.S. Сам я тоже студент и во время обучения меня нехило так "прокачали" преподаватели по оформлению своих работ (ГОСТы всякие). Они не просто так придуманы, с их помощью реально читать работы проще и легче. Курсовые, статьи в журналах, ВКР, диссертации - для всего этого есть свои ГОСТы, которые делают работу лучше. Статью, которую легко читать, чаще плюсуют ;)
Да ошибся я, ну не могу поправить комментарий) Расширение 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#. Так будет проще, быстрее и не нужно думать о том, как там всё внутри устроено. Однако такой вариант меня не устраивает, немного надоело, что везде всё уже сделано, и что "нужно использовать готовые решения".
Готовые решения это конечно хорошо, но сделать что-то самому с нуля, разобраться во множестве тонкостей и решить кучу проблем - это очень полезно.
Думаю да, это было бы легче, учитывая что слои абстракции в C# вырастают с каждой новой версией этого языка так, что можно разработать службу значительно быстрее.
Однако использовать два языка программирования (C++ и C#) - не всегда уместно, поскольку программы на разных языках программирования имеют свои особенности, которые могут зависеть от платформы (в следствие чего поддержка таких программ требует больших усилий), да и скрытие "рутинных задач" за большим слоем абстракции лишает программиста важного - получения опыта. Ведь разобраться как устроено управление службами на C++, на мой взгляд, ценнее, чем использовать высокоуровневые абстракции и просто решить задачу так, как проще или так, как "модно".
Конечно, и в статье используется высокоуровневые абстракции из WinAPI. Может быть есть способ написать службу на более низком уровне с использованием чистого Си и без WinAPI, однако такого способа я, на данный момент, не знаю. Если бы знал такой способ - сделал бы на чистом Си) Уменьшая слои абстракции и используя более низкоуровневые инструменты программист получает больше опыта за счёт необходимости разбираться в большем числе деталей.
Не могли бы Вы поделится ссылкой (или ссылками), где аналогичный материал собран в одном конкретном месте и где так же (или даже лучше) рассматривается подобная тема? Не исключаю, что я, возможно, плохо искал и поэтому столкнулся с проблемой разрозненности информации по разным источникам.
Думаю не только мне будет полезно ознакомится с другими работами, где данная тема широко освящена.
Тема разработки веб-приложений с помощью библиотеки Three.js для создания трёхмерной графики довольно интересна. Сейчас и игры делают с её помощью, коммерческие приложения или просто визуализации (например, для кластерного трёхмерного анализа это может быть применимо).
Однако по ходу чтения статьи я обнаружил, что после её прочтения - мало что из неё понял и уяснил, хотя с трёхмерной графикой опыт работы уже имел. Хотел бы выразить ряд замечаний связанных с материалом самой статьи и её оформлением, с целью мотивировать авторов данной статьи её улучшить.
Начнём с замечаний по материалу. В статье не ясно какой будет конечный результат, как мы к этому результату пришли, что для этого нужно сделать (нумерованный список с действиями это не объясняет, а только добавляет вопросов). Понятно, что в начале было (косвенно) о разработке механизма, с помощью которого можно будет преобразовать картинку в 3D модель (если я правильно понял):
Но, что-то, ни картинки, ни 3D модели в конечном итоге я не увидел в статье.
Когда пишут статьи где подразумевается работа с графикой (2D, 3D, 4D), то в статье, как бы, хорошим тоном считается добавлять картинки начального, промежуточного и конечного результата. Особенно радует когда понятно с помощью каких алгоритмов, программного кода или подхода мы пришли от A к B и от B к C.
Мы так и не узнали что такое файл JSON :) Возможно Вы имели ввиду файл package.json, т.к. после этого предложения идёт описание и предназначение файла package.json. В любом случае, наблюдается непоследовательность изложения. Файл package.json просто так появиться не может, он создаётся с помощью специальной утилиты npm (для командной строки это утилита, а вообще это пакетный менеджер). И после описания файла package.json идёт следующий текст:
Если вы хотите объяснить что такое package.json, то это следует делать только после того, как вы опишите что такое Node.js и NPM, потому что складывается ощущение что этот файл нужно создать самому, а Node.js это так - что-то стороннее. Файл package.json описывает в целом конфигурацию JS/TS модуля, с зависимостями и прочими вещами.
Мы живём в мире, где царствует кроссплатформенная и кроссбраузерная разработка. Не у всех читателей на Хабре компьютер с MacOS, поэтому если вы решаетесь написать команду для установки Node.js на свою ОС, то следует дать ссылку или написать где-нибудь рядом команды для установки под другие ОС (например, Ubuntu или Windows).
Если же ваша работа целиком и полностью охватывает только MacOS, то об этом следует написать сразу в начале, чтобы пользователи понимали в какой среде будет происходить работа и, соответственно, сможет ли пользователь все эти эксперименты повторить.
Данный текст требуется доработать. Есть ошибка в слове "базовыми" и не ясно что за файл создаёт нам утилита npm, при вызове команды npm init -y (а он создаёт как раз package.json).
Формулировка данного текста довольна не точная, потому что структуру проекта Вы не описываете. Вы описываете основной алгоритм, который заложили в программный код на JavaScript, но не структуру проекта. Обычно под структурой проекта понимается набор файлов, папок (или каталогов), которые определённым образом упорядочены и это упорядочение имеет какую-то смысловую нагрузку. Например, в каталоге app у нас входная точка в программу, а в каталоге hooks специальные хуки. Или в каталоге models у нас модели, а в shader у нас шейдеры.
Здесь нужна также команда и также на более распространённые ОС чем MacOS (так вы увеличите число заинтересованных читателей).
Стоит обнаружить и поправить побольше таких слов, потому что читается это забавно :)
Это сюда же :)
Что за группа? В представленном статье коде непонятно что под группой (переменной или константой group) подразумевается? Почему её нужно очистить? Зачем? Что она из себя представляет? Думаю здесь нужно подумать над тем, чтобы добавить описание этой ... ячейки (ячейкам) оперативной памяти, которую занял и выделил под ваш скрипт браузер и который контролирует доступ к этой ячейки памяти из вашего скрипта (через, например, движок V8 или любой другой, который есть в популярных MacOS браузерах). Переменная это или константа - непонятно, поэтому написал абстрактно :)
Здесь в программном коде ошибка. Нужна закрывающая фигурная скобка в конце цикла. В общем-то дальше такие ошибки также встречаются (нужно вычитывать статью, перед публикацией, чтобы таких "мелких" недочётов не было, иначе из-за этого можно "нахватать минусов").
И дальше идёт код анимации, по видимому, а не отрисовки объекта img. Как я понял, в функции animation идёт рендеринг сцены и камеры, а не объекта img.
Деля что на что, и зачем нужна нормализация в данном случае? Тема не раскрыта.
В общем и целом, предлагаю авторам статьи ещё раз перечитать материал и его улучшить, ему это действительно необходимо, чтобы он лучше читался и было понятно о чём идёт речь. Тема векторизации также не раскрыта.
По оформлению статьи есть также замечания, которые мне, как читателю, показались нуждающимися во внимании.
Первое замечание касается не целевого использования цитаты для оформления списков:
Списки всегда лучше оформлять списком. У хабра замечательный редактор (правда с обратной совместимостью прошлых статей проблемы есть, но в целом норм), его возможности можно использовать на максимум чтобы добиться хорошего оформления статьи. Есть даже специальные публикации о том, как нужно оформлять статьи. Советую их почитать, будет полезно.
На хабре также есть редактор исходного текста программ. Если добавить программный код на страницу то рядом есть выпадающий список с возможными языками программирования. Стоит его активно использовать и читать исходный код будет легче:
Программный код должен оформляться как программный код, а не как часть текста. То же относится и к командам:
Нумерованные заголовки также не стоит выделять цитатами, для этого есть заголовки разного уровня в самом редакторе (как правило их хватает).
Также не хватает библиографического списка (какими статьями вы руководствовались, когда писали данный материал?) и ссылку на исходный код (потому краткие его выжимки не дают понимания полной картины).
Хорошая статья, если она что-то обозревает (например, результаты исследования), содержит минимум кода, но при этом максимум словесного описания, проектирования и визуализации. После прочтения такой статьи нет недопонимания ключевых вещей, а для ознакомлением с деталями можно всегда обратиться к исходному коду.
Спасибо за статью, очень рекомендую её улучшить (моменты основные расписал), у этой темы определённо есть будущее.
Рекомендую также ознакомиться с книгой про работу с графическими процессорами в браузере (WebGPU), может быть эта тема будет вам интересна)
Желаю успехов в дальнейшем развитии во frontend-разработке и в освоении трёхмерной графики!
Действительно, проблема есть. Думаю, что автор имел ввиду что-то такое:
Сейчас конструктор определён так:
Во втором аргументе используется не указатель на временный объект, а ссылка на переменную из локальной области видимости функции, которая по стеку вызовов находится выше, т.к. даже под хранение в памяти указателей выделяется память, а для ссылок, насколько я помню, память не выделяется. Поэтому аргументы в функции, которые являются указателями, не так сильно оптимизирует общую используемую память приложения (многие уверены в обратном), большей оптимизации можно достичь с помощью ссылок, дабы избежать не нужных конструкторов копирования тяжеловесных объектов, а маршрутизировать конкретные ссылки на эти объекты и с ними уже работать.
Думаю, чтобы не было проблем, имеет смысл переписать конструктор таким образом:
Тогда вызов
будет осуществляться без ошибок и не будет для аргумента name вызываться не нужный конструктор копирования.
Вдобавок, было бы неплохо добавить ещё множество конструкторов по умолчанию. Например, конструктор копирования, без параметров, присваивания и т.п.. Перегрузка операторов ещё может быть полезным механизмом, чтобы, например, постоянно не вызывать методы логгера. Условно можно в файл записать лог и через такую конструкцию:
Определённо интересный проект для изучения и исследования некоторого множества тонкостей языка программирования C++. Это хороший опыт)
Однако у меня есть кое-какие рекомендации к форматированию самой статьи, т.к. её немного "сложно" читать (если так можно выразиться).
Поскольку авторы на Хабре часто описывают результаты своей практической или теоретической деятельности есть определённые правила по "красивому оформлению статьи". Очень рекомендую с ней ознакомится, т.к. они в общем и целом позволят улучшить форматирование Вашей статьи.
Такое введение в статье выглядит немного странно. Всё таки Хабр не является ресурсом, прямой целью которого является помощь в трудоустройстве (хотя косвенно она присутствует) - для этого есть соседний сайт Хабр.Карьера, рекомендую заглянуть, может быть так Вы быстрее найдете работу. Вдобавок в конце статьи Ваши контакты уже видны (в т.ч. ссылка на Telegram), зачем повторяться?
В целом ссылки по типу "https://github.com/Fallet666/logger" или "https://t.me/born_in_void" лучше оформлять как пример_1 и пример_2. Т.е. текстом, а не ссылкой. Потому что интерес читателя перейти по ссылке будет больше, если для перехода по ней достаточно одного нажатия. Сейчас же ссылки нужно выводить с помощью мышки, чтоб по ней перейти.
Форматирование для кода на Хабре поддерживается и достаточно успешно. Код будет выглядеть красивее, если при вставки кода выбрать конкретный язык программирования (делается это сверху в выпадающем меню "Язык"). Достаточно сравнить:
До:
После:
По поводу заголовков:
Тут у заголовков "плывёт" размер. Казалось бы "Упрощенные функции для каждого уровня" стоит сделать больше, чем нумерованные наименования глобальных функций логгера, т.к. он описывает свой подраздел. Здесь же кажется, что как раз наименование подраздела это обычный выделенные текст, а сам подраздел - элемент нумерованного списка, который не должен быть вообще заголовком H3 (сейчас он такой). Для задания "жирного" оттенка тексту лучше использовать свойство для стилизации текста при его выделении, если это требуется. Но не стоит этим перенасыщать статью. Например, текст "Пример использования" можно вообще не выделять жирным, а методы в нумерованных списках выделять без выделения номера (но это уже мелочи).
У раздела, подраздела и далее по уменьшению, как правило, размер текста уменьшается. Так просто принято, так удобно, легко читаемо и интуитивно понятно где логические границы.
Успехов в поиске работы и дальнейшем написании статей!
P.S. Сам я тоже студент и во время обучения меня нехило так "прокачали" преподаватели по оформлению своих работ (ГОСТы всякие). Они не просто так придуманы, с их помощью реально читать работы проще и легче. Курсовые, статьи в журналах, ВКР, диссертации - для всего этого есть свои ГОСТы, которые делают работу лучше. Статью, которую легко читать, чаще плюсуют ;)