C *

Массивы окружают нас всегда и везде: многоквартирные дома, вагоны в составе поезда, книги на полке, строевая ходьба в армии, кнопки на клавиатуре.Вот и получается, что и архитектуру кода тоже интуитивно так и хочется везде, где можно организовывать в массив.

В этом тексте я написал о некоторых подходах к организации кода для микроконтроллеров.

Основная идея - массив наша основная скрепа.

Главные достоинства представленной архитектуры - это простота поддержки, сопровождения и масштабирования кодовой базы.

Всем привет! Эта статья - про очень простой алгоритм маскирования данных при пересылке по протоколу WebSocket. Но рассказать я хочу не про сам алгоритм, а про путь оптимизации, который я прошел, чтобы сделать его эффективным. Я до сих пор уверен, что можно еще лучше и если так, то надеюсь уважаемые читатели мне подскажут! Приступим...

В программировании микроконтроллеров на Си часто приходится писать драйверы для умных и навороченных ASIC чипов с управлением по I2C/SPI/MDIO интерфейсам.

Обычно перед запуском эти чипы надо правильным образом сконфигурировать.

Такие чипы всегда оперируют с реальными физическими величинами. Одновременно с этим ячейки памяти этих ASIC чипов - дискретные, двоичные. Поэтому все производители микросхем кодируют эти переменные бинарными кодами разной разрядности.

В этом тексте я показал как можно делать интерпретаторы этих величин.

В данной статье я рассмотрю подключение утилиты dfu‑util, написанную на языке С, к С++ проекту на CMake в виде сабмодуля.

Одна из главных целей статьи — это подключение старого и типового кода на С к своему проекту. Здесь приведены проблемы генерируемых файлов, борьба с кодом незнакомого разработчика (особенно если это разработчик на Си), особенности портирования окружения на Windows и т. д.

Формат статьи представляет собой некое подобие дневника разработчика (как, собственно, следует из названия публикации), поэтому материал может быть использован и как технический гайд, и как вечернее чтиво.

* Превью сгенерировано с помощью Adobe Firefly

Привет, Хабр.

Скорее всего то, о чем я сейчас расскажу, уже было реализовано и не единожды.

Но пусть это все равно лежит здесь, возможно эта статья будет кому-то полезна в качестве методического материала или HOWTO. Все, сказанное ниже является продуктом моего текущего опыта разработки и не претендует на идеальное решение.

Мы продолжаем тему о проектировании и разработке вредоносного ПО для macOS. Первую часть публикации вы можете прочитать здесь. 

В этой статье мы:

- Изучим методики инъецирования кода и то, как он применяется в вредоносном ПО;

- Затронем способы обеспечения постоянства хранения;

- В конце мы покажем простой процесс инъецирования шелл-кода и его постоянного хранения. 

В этой статье мы погрузимся в мир проектирования и разработки вредоносного ПО для macOS, которая по сути является операционной системой на основе Unix. При исследовании внутренностей системы Apple мы воспользуемся классическим подходом с опорой на базовые знания эксплойтов, программирования на C и Python, а также знакомство с низкоуровневым языком ассемблера. Хотя представленные в статье темы могут быть сложными, я постараюсь изложить их понятным языком.

ReactOS — это проект, где победу над регрессией, появление новой фичи или её рабочего прототипа празднуют так громко, что FOSS‑сообществу приходится отвлекаться от переписывания всего на Rust и полемик о systemd. В последний раз мы проверяли ReactOS в 2013 году, почти одиннадцать лет назад. Проверка была неточной ввиду неполного понимания структуры папок, из‑за чего в поле видимости PVS‑Studio оставались компоненты Wine. Пришло время освежить память и провести новую проверку, учитывая опыт предыдущей недоработки.

Так или иначе сталкиваться с регулярными выражениями приходилось большинству разработчиков. Мое первое знакомство произошло с реализацией regex в STL std::regexp. Чаще всего регулярки используются в проверке входных данных, что-то вроде проверки корректности введенного пользователем URL, адреса IPv4, адреса IPv6, телефонного номера и при этом скорость выполнения операции regex не сильно влияет на время отклика от приложения. Но, что если вам приходится проверять сотни, тысячи или даже десятки тысяч правил и все это на постоянно меняющихся наборах входных данных в реальном времени? В этой ситуации вам не просто нужен быстрый алгоритм, вам понадобится лучший из них, вам понадобиться чемпион!

IBM i (AS/400) является "объектной" системой, построенной на концепции "все есть объект". У каждого объекта есть имя (может меняться в течении его жизненного цикла), тип (устанавливается единожды при создании и далее не меняется) и, в некоторых случаях, атрибуты ("подтип", аналогично типу, устанавливаются при создании и не могут быть изменены). Также объект может иметь текстовое описание (необязательное) - строка до 50-ти символов, которое может быть задано как при создании, так и после.

Действия, разрешенные над данным конкретным объектом, определяются его типом. Простейший пример - тут нельзя открыть программу в hex редакторе и поправить пару байтиков - такая операция просто не предусмотрена для объекта типа *PGM.

Существует очень большое количество типов системных объектов, предоставляющих большие возможности для разработчика.

Цитата из предисловия к книге Френка Солтиса "Основы AS/400":

Приветствуем!

Так получилось, что нам достались два аттенюатора Agilent 8494H и 8496H. Они долго лежали без дела, поскольку отсутствовал контроллер управления. Конечно, четыре простых переключателя справились бы с этой задачей, но хотелось реализации с дисплеем показывающий текущее значение затухания и программное управление. Проект сделан в EasyEDA и Atmel Studio.

Более 6-ти лет занимаюсь разработкой под IBM i (бывшая AS/400). В основном, конечно, это работа с БД и разная бизнес-логика, но иногда приходится и что-то низкоуровневое писать.

Не так давно занимался разработкой удобного и простого в использовании API для работы с User Queue (есть на АС-ке такой системный объект - очередь *USRQ). И в заголовке извлекаемого из очереди сообщения есть такой параметр - message enqueue time (время размещения сообщения в очереди). Который описан как _MI_Time. Которое, в свою очередь, определено как

История зарождения PHP

История PHP начинается не с полноценного языка программирования, а с набора CGI-скриптов на C, известного как PHP/FI 1. В этой статье мы возвращаемся к истокам PHP, рассматривая его первую версию, её компиляцию и функциональность.

Кто я такой, чтобы делиться своими суждениями и утверждениями? Мне почти 47, в сфере IT профессионально работаю около 25 лет, начав самообучение со школы, с папиного i386 с сопроцессором и модемного dial-up на зюхелях (ну... все же помнят.. да? ну да же? :-) Естественно, среди моего опыта и высшее образование, и технические сертификаты, и работа во множестве компаний самого разного масштаба и разных стран. Сейчас я обладаю как негативным, так и позитивным опытом в различных аспектах IT технологий, попробовав себя как в софте, так и в железе.

Этот опыт заставляет меня поделиться информацией из той самой негативной составляющей с целью предотвращения его повторения читателями. И да, тут будет много злобы и яда к тому дерьму тем технологиям, с которыми приходится работать каждый день DevOps и даже системным администраторам. Однако статья наполнена реализмом, а вовсе не пессимизмом! :-D В ней будет раскрыта вся голая правда про лично Ваше будущее как DevOps инженера!

Привет! Меня зовут Александр Каленюк, и я крепко подсел на C++. Пишу на C++ 18 лет кряду, и все эти годы отчаянно пытаюсь избавиться от этой разрушительной зависимости.

Всё началось в конце 2005 года, когда мне довелось писать движок для симуляции 3D-пространства. В этом движке было буквально всё, чем язык C++ мог похвастаться в 2005 году. Трёхзвёздочные указатели, восьмиуровневые зависимости, C-подобные макросы повсюду. Кое-где – вкрапления ассемблера. Итераторы в стиле Степанова и мета-код в стиле Александреску. В общем, всё. Кроме ответа на самый важный вопрос: зачем?

Книга рассказала об идеях, что лежат в основе операционных систем, на примере xv6. Одна часть кода xv6 выражает основные идеи и каждая строка кода важна - переключение потоков, пространства пользователя и ядра, блокировки и т.д. Другая часть кода воплощает алгоритмы и структуры данных, которые легко заменить на другие - политика планирования процессов, структуры файлов на диске, устройство журнала файловой системы и т.д. Книга полагается на интерфейс системных вызовов Unix, который оказался успешным настолько, что идеи легли в основу и других современных ОС.

Книга об xv6 на русском языке в формате PDF, HTML и EPUB.

Глава 1

Глава 2

Я пишу игру на игровую консоль Playdate на чистом C. Игра в жанре "выживальщик" наподобие Vampire Survivors. Так как в чистом C отсутствуют многие современные объектно-ориентированные удобства мне приходится по-всякому изворачиваться чтобы адаптировать свои идеи в код. В этих заметках ты узнаешь из первых уст как создаётся игруля с нуля от идеи до публикации.

В прошлой главе я описал как инициализирую сцену, как очищаю ресурсы, показал как заполняю сцену реквизитом и даже поэкспериментировал с генерацией этого самого реквизита. В этой главе я расскажу как работает самая важная функция GameUpdate, в частности, обработка ввода и процессинг данных.

GameUpdate это функция-колбэк, которая вызывается каждый тик. А значит её задача это реализовать святую троицу любой игры: