Практически сразу, в PC-DOS, вместе с .COM файлами, (или файлами команд),
появились .EXE файлы (полн. "EXEcutable" или "исполняемые"). Сегодня речь пойдет именно об этом.
Поскольку история происходит снова в Microsoft, запутаться можно очень легко, в любом месте.
Небольшое предупреждение! Я буду говорить не просто о том "Как запускаются комманды?", а покажу часть внутреннего мира операционных систем и покажу принципиальную разницу в их работе.
Это моя первая статья, вырванная из дневника, который я веду пока что закрыто, особо не выкладывая заметки в публичный доступ.
Всем здрасте, и сегодня у нас продолжение низкоуровневого программирования. В этой части мы все разобьем на модули, а так же напишем ввод, благодаря чем мы сможем сделать маленькую командную оболочку!
Всем здрасте, и сегодня мы начнем наше прохождение через низкоуровневый кодинг - написание ОС. Сегодня мы напишем загрузчик (точнее конфиг к GRUB) и простенькое ядро, которое будет выводить "Hello OSDev!"
Что нам понадобится:
Вы когда‑нибудь смотрели на.EXE‑файл своей любимой DOS‑игры и думали: «Что там внутри? Можно ли это понять без докторской по ассемблеру?» Эта не просто очередной обзор регистров. Это второй шаг в глубокое погружение туда, где байты начинают «говорить». Мы начинаем с тех, кто дал нам язык: с Рэя Доббса, чьи книги «Programming in the MS‑DOS Environment» и «Advanced MS‑DOS Programming» были библией поколения, с Рэндэлла Хайды, чья «The Art of Assembly Language» научила мыслить на языке машины, и с Ральфа Броуна, чей «Interrupt List» стал первым справочником, в котором каждое int 21h перестаёт быть чёрным ящиком и приобретает конкретный смысл. Вы узнаете, что AX, CX, DS:DX и EFLAGS — это не раздельные элементы. Вы поймёте, как они связаны, как передаются данные, как принимаются решения, как программа взаимодействует с системой. Как прерывания становятся точками соприкосновения с системой и как по ним можно восстановить логику программы. Мы начинаем движение от байтов к смыслообразующему коду. Готовы сделать следующий шаг?
Планировщик — мозг операционной системы. Его задача: решать, какая задача выполняется сейчас, и по каким правилам выдавать процессор другим задачам. Для embedded систем это особенно критично: ресурсы ограничены, реальное время важно, а поведение должно быть предсказуемым.
Это вторая из цикла статей про создание микроядерной операционной системы. В прошлой статье рассматривался таймер и HAL. Для вновь пришедших необходимо сначала ознакомиться с ней: ссылка.
Последние несколько вечеров я занимаюсь написанием простенькой операционной системы с микроядерной архитектурой. Зная, что такое занятие имеет не только исследовательский смысл, но и может стать кому то темой для курсовой или дипломной работы, я решил поделиться матчастью и показать, как всё устроено. OSdev был и остаётся высшим пилотажем в мире программирования, и я готов помочь.
Устаревшие технологии не исчезают. Они просто уходят в подполье: в архивы, на дискеты, в память тех, кто помнит, как это было. DOS-игры не просто программы. Это произведения инженерного искусства, созданные в эпоху, когда каждый байт имел значение, а каждый такт процессора, вес. Они работали на железе, которое сегодня кажется примитивным, но при этом умели то, что многим современным системам не под силу: дышать.
Моя первая игра была на дискете. Она называлась Syndicate (1993, Bullfrog Productions), и я не понимал, как она работает. Я видел, как агенты стреляют, как взрываются здания, как звучит саундтрек, но не имел ни малейшего представления, что за этим стоит.
Я знал C. Я знал, что такое переменные, циклы, указатели. Но я не мог объяснить, как в игре реализован путь юнита, как обрабатывается урон, как генерируется уровень. Тогда я не понимал кода, но код уже управлял мной.
Спустя годы я вернулся к этим играм не как игрок, а как исследователь. И понял: они — лучшая школа программирования, которую только можно себе представить.
Современные игры скрывают свою архитектуру за слоями абстракций: виртуальные машины, движки, фреймворки. Чтобы понять, как они работают, нужно разобраться в десятках технологий.
DOS-игры - другое дело: нет виртуальных машин; нет сборщиков мусора; нет драйверов. Есть только процессор, память и код, написанный на C/C++ или ассемблере. Это делает их идеальной школой для изучения реального программирования.
Дизассемблирование таких игр — это не про взлом. Это археология программирования: вы не ломаете систему, а восстанавливаете её логику по обломкам машинного кода, как археолог, собирающий мозаику из черепков.
Как-то раз я послушал следующее интересное выступление (по-немецки): ссылка
В нём разобрано, как написать программу «hello world» для 64-разрядного дистрибутива Linux в шестнадцатеричном редакторе. Ассемблер здесь не используется, программа пишется непосредственно на машинном коде. Правда, в ней есть издержки на использование ELF.
Мне понравилась такая идея, и я решил повторить такой опыт, но немного в иной форме — а именно под 16-разрядной DOS в реальном режиме. У меня должен был получиться файл в формате COM, а не EXE, так как (на данном этапе) меня интересовал не столько формат файла, сколько кодировка инструкций. В вышеупомянутой лекции, если честно, не сообщается почти никаких подробностей о том, как именно перейти от ассемблерного кода к машинному — поскольку в случае разбора этих тем лекция, пожалуй, растянулась бы на несколько часов. Но здесь я всё разберу подробно, и при этом собираюсь пользоваться только документацией lntel, а также дизассемблировать код в целях верификации.
Также мы коротко поговорим о сегментации.
В качестве шестнадцатеричного редактора на этот раз воспользуемся hexedit.
Данная статья направлена на повышение уровня понимания принципов работы барьеров памяти, которые лежат в основе атомарных операций. Она не описывает историю и первопричины появления данного механизма, а служит объяснением основных подходов.
Идеей было донести простыми словами и примерами механизмов работы барьеров памяти, поэтому в данной статье нет углубления в синтаксис ассемблер команд или архитектур процессоров.
Давным-давно, когда F11 и F12 еще не придумали, F1-F10 располагались слева, Ctrl жил на месте CapsLock, а IBM продавала компьютеры с гарантией на 90 дней, владельцы компьютеров работали в MS-DOS. Процессор еще не знал, что такое защищенный режим, память не делилась на области пользователя и ядра, виртуальной памяти не было, как не было и многозадачности. MS-DOS программа на счет "раз" нарушала работу ядра и компьютер приходилось перезагружать. Программы скромно умещались в 64 Кб, а, если превышали это ограничение, жизнь их становилась труднее.
Дизассемблируем 16-битную программу: InDuLgEo V3-B горит пламенем на экране, печатает текст и трезвонит, как старый телефон.
Большинство компиляторов — это монолитные черные ящики, унаследованные из прошлого. Мы отвергли этот путь. Мы разбираем архитектуру x86_64 до "первых принципов", чтобы понять, как на самом деле работает кремний. В этой статье мы вскрываем капот нашего компилятора ZGEN и его "фабрики машинного кода" — hwm. Никакой магии. Только чистая, детерминированная инженерия, которая превращает ассемблер в исполняемые биты.
Дарова! Сегодня я поделюсь с вами опытом, как я пытался написать собственную ОС и, что из этого вышло. Запасайтесь чайком с печеньками и присаживайтесь поудобнее! Пора окунуться в 16ти битный мир...
Мы не просто пишем код. Мы строим компиляторы, которые строят код. AsmX G3 — это не обновление, это переосмысление с первых принципов. Приготовьтесь к глубокому техническому погружению в архитектуру нашего нового компилятора ZGEN, где мы вскроем каждый компонент, от ядра до сборщика ELF, и покажем инженерные решения, которые определяют будущее системного программирования.
Это моя пятая попытка диалога с сообществом. Четыре предыдущие закончились баном. Но это не жалоба. Это деконструкция системы, которая наказывает за отклонение от нормы. Мы разберем, почему «низкий технический уровень» стал оружием конформизма и как продолжать строить, когда твой проект — системная аномалия.
Прежде чем технология изменит мир, она проходит через тысячи часов испытаний в лаборатории. Мы открываем двери нашего R&D отдела и показываем, над чем инженеры AsmX Foundation работают прямо сейчас. Улучшенная диагностика ошибок, новый синтаксис и первые шаги к полноценным вызовам библиотечных функций. Загляните в будущее компилятора.
Привет, читатель! Ты видишь это лицо и надпись "I ALWAYS COME BACK"? Это не просто мем для хайпа — это моё обещание. И я его сдержал.
Я вернулся, чтобы анонсировать AsmX G3 — новое поколение моего проекта, которое вот-вот перевернёт твоё представление о низкоуровневом программировании. Это событие, частью которого я хочу тебя видеть.
Как оптимизировать модель Mamba для выполнения на CPU? Ускоряем код в 20 раз по сравнению с PyTorch, нарушая в процессе все правила оптимизации.
🚨 Что такое Hard Fault простыми словами
Hard Fault — это критическая ошибка процессора.
Проще говоря, это ситуация, когда микроконтроллер встречает что-то настолько «невозможное» для себя, что не может продолжить выполнение программы.
Типичный пример — попытка обратиться к памяти, которой не существует, или выполнение запрещённой инструкции.
Когда это происходит, процессор сразу передаёт управление специальному обработчику — Hard Fault Handler.
Недавно залез в ROM оригинального Power Macintosh G3 и случайно обнаружил там пасхалку, о которой до этого ещё нигде не писали.
Началось с того, что одним воскресным утром я решил заглянуть в файл-шаблон ROM для Mac с помощью программы HEX Fiend Эрика Хармана. Меня интересовало, какие ресурсы хранятся в постоянной памяти Power Mac G3. Эта ROM использовалась в моделях Beige, Mini Tower и всех G3, выпускавшихся с 1997 по 1999 годы.
Пишу я эту статью в середине 2025, и мне не верится, что сегодня Power Mac G3 уже больше 27 лет. Невероятно!
