Практически сразу, в PC-DOS, вместе с .COM файлами,
появились .EXE файлы (полн. "EXEcutable" или "исполняемые"). Сегодня речь пойдет именно об этом.
Поскольку история происходит снова в Microsoft, запутаться можно очень легко, в любом месте.
Как повернуть время вспять и выиграть Assembly с DOS-демкой в 2025-м году.
Разбираем олдскульные эффекты на примере демки "Demoded".
Секреты, хитрости и откровенное жульничество российского демомэйкинга.
История в картинках.
В игре CoreWars участники писали программы, которые сами клонировались в памяти и пытались затереть друг друга. Работало это в виртуальной машине с хитроумными инструкциями, которые позволяли создавать очень короткий код. Простейшая само-копирующаяся программа, "самобеглый MOV", выглядела вот так:
MOV 0, 1
Пояснение этой инструкции будет дано чуть ниже. Программа "бежит" по всему сегменту памяти, в котором происходит "битва" и затирает собою все ячейки последовательно. В языке RedCode используемом в игре эта инструкция занимает одну ячейку памяти.
Мне неизвестны реальные процессоры в которых были бы подобные "удобные" инструкции. И вот любопытно - насколько короткой можно сделать (а можно ли?) подобную "самобеглую" программу для какой-нибудь настоящей архитектуры. Ну хотя бы для 8086. Тем более что там сегменты обозримого размера - 64 килобайта.
Не страшно если вы не знаете или плохо помните команды ассемблера, их будет немного и мы снабдим их пояснениями.
Небольшое предупреждение! Я буду говорить не просто о том "Как запускаются комманды?", а покажу часть внутреннего мира операционных систем и покажу принципиальную разницу в их работе.
Это моя первая статья, вырванная из дневника, который я веду пока что закрыто, особо не выкладывая заметки в публичный доступ.
Доброго времени суток, господа и дамы! Иногда у некоторых людей возникает желание заняться откровенным непотребством в программировании — то, что не несет практической пользы напрямую, но помогает развлечься. В этой статье я хочу рассказать вам о лайфхаках, трюках (магических и не очень), алгоритмах на языке C!
Идея написать эту статью зародилась из моего поста. В нем я рассказал о том, что через последовательность Фибоначчи можно конвертировать мили в километры с небольшой погрешностью. Увидев, что многим понравилась, я задумался: почему бы не изучить еще какие-нибудь трюки, заодно практикуясь в программировании на C?
Всех, кто заинтересовался — прошу под кат.
Пока вы рождались, ходили в школу, заканчивали учебу и выходили на свою первую работу, на свете существовал совершенно особенный набор компиляторов, о котором крайне мало известно на просторах РФ.
Именно о нем пойдет сегодняшний рассказ.
Я заметил, что вокруг новых AI-инструментов для кодинга (типа Cursor AI, ChatGPT, Claude) идёт жаркая дискуссия. Классические программисты порой скептически смотрят на тех, кто активно пользуется генеративным ИИ вместо ручного кодирования. Некоторые считают таких «вайбкодеров» мешком софта без понимания: мол, они просто копипастят то, что выдаёт ИИ. Попробую разобраться в этом лично: ведь для многих из нас эти инструменты открывают новые возможности.
Как-то раз я послушал следующее интересное выступление (по-немецки): ссылка
В нём разобрано, как написать программу «hello world» для 64-разрядного дистрибутива Linux в шестнадцатеричном редакторе. Ассемблер здесь не используется, программа пишется непосредственно на машинном коде. Правда, в ней есть издержки на использование ELF.
Мне понравилась такая идея, и я решил повторить такой опыт, но немного в иной форме — а именно под 16-разрядной DOS в реальном режиме. У меня должен был получиться файл в формате COM, а не EXE, так как (на данном этапе) меня интересовал не столько формат файла, сколько кодировка инструкций. В вышеупомянутой лекции, если честно, не сообщается почти никаких подробностей о том, как именно перейти от ассемблерного кода к машинному — поскольку в случае разбора этих тем лекция, пожалуй, растянулась бы на несколько часов. Но здесь я всё разберу подробно, и при этом собираюсь пользоваться только документацией lntel, а также дизассемблировать код в целях верификации.
Также мы коротко поговорим о сегментации.
В качестве шестнадцатеричного редактора на этот раз воспользуемся hexedit.
Зачастую, в проектах ограничивается использование препроцессора по следующим причинам:
— Он не похож на весь остальной язык;
— Макросы могут возвращать неполные синтаксические конструкции, или вовсе различные, в зависимости от параметров.
Ввиду перечисленных особенностей, читать код с активным использованием препроцессора зачастую становится на порядок сложнее кода без него.
Со всеми его недостатками, инструмент есть в языке и достоин изучения.
Будущее разработки ПО, возможно, станет похожим на джаз. Каждый импровизирует, никто не смотрит на ноты.
На прошлой неделе я выпустил Protocollie. Сделал его за 4 дня, используя языки, которых не знаю, и даже не касаясь кода напрямую. Люди без конца спрашивают: «Как это удалось?» Но я даже не уверен, что получится повторить то же самое второй раз.
Мы все придумываем этот процесс на ходу.
Как удалось с помощью GitHub Copilot автоматизировать отслеживание изменений в базе знаний Ozon. Мой опыт создания собственного сервиса для мониторинга и сравнения обновлений без знаний программирования, с пошаговым описыванием создания архитектуры процесса.
Недавно работал в команде, занимавшейся разработкой встроенного ПО. Это ПО в значительной степени основывалось на конечных автоматах, которые десятками были разбросаны по множеству функций. И хотя такая архитектура весьма распространена в разработке встраиваемых систем, в особенности систем без ОС, я задался вопросом: неужели нет способа выразить поток управления более чисто?
Конечные автоматы в нашем коде работают прекрасно, но их понимание и обслуживание зачастую вызывало головную боль. В их работе отсутствовал линейный поток, плюс они требовали мысленного жонглирования флагами, состояниями и переходами, происходящими в функциях опроса.
Меня не покидала мысль: «А не будет ли проще написать логику в виде последовательной программы, ожидающей события и возобновляющей выполнение с места остановки?»
Естественно, в проекте не допускалось использование RTOS, посему традиционный подход применения потоков или систем блокирования для управления конкурентностью не рассматривался. Но я знал, что должна быть некая золотая середина.
Часто при передаче продукта заказчику, в виде готовой программы или некоторого аппаратного продукта, необходимо также защитить интеллектуальную собственность в виде исходных текстов программ и скриптов.
Компилируемые языки хоть как-то защищаются, соответственно, с помощью компиляции, хотя и это не панацея. А вот что делать со скриптами, которые могут быть написаны на bash или pyton?
Как вариант решения такой проблемы, может быть, шифрование скриптов с аппаратной привязкой дешифратора к платформе, на которой этот скрипт исполняется. Звучит красиво, но надёжно ли? Насколько будет эффективен и взломостойкий этот метод?
У меня в одном проекте была проба пере такого решения. Заодно проверил, и вскрыл это шифрование.
Продолжаю рассказывать широкой аудитории о «гусарских забавах» компьютерной элиты — третий по счету Binary Golf Grand Prix.
Немного рассуждений о языках программирования (ЯП) с уклоном на надежное и безопасное программирование.
Статья не публиковалась ранее, хотя была написана в 2019г, теперь можно смотреть как некую ретроспективу. Чем и воспользуюсь, вставляя замечания о былом по тексту (тег Upd).
Но тормозит развитие серии, ибо вышли уже 3 части и несколько переводов в тему:
Привет, меня зовут Марат Зимнуров, я тимлид в кросс-функциональной команде HR Admin Tech Авито. Тема функционального программирования не обделена вниманием — и все же тяжело найти действительно понятный и структурно изложенный разбор данного инструмента. Нет нормального гайда для старта — ни у нас, ни на Западе. Многие говорят про иммутабельность и монады, но путаются в основах. В статье разбираю, что такое функциональное программирование на самом деле и зачем оно нужно.
На третьем этапе олимпиады мы, как обычно, решали задачки на SQL, но в этом году надо было написать запрос не просто правильный, но и короткий. Чем короче — тем лучше результат. В детстве мы развлекались таким на микрокалькуляторах и на ассемблере, а сейчас я решил посмотреть, что получится, если попробовать то же на SQL. Получилось, на мой взгляд, интересно. Практического смысла в этом, конечно, никакого нет, но практики и на работе хватит, а тут мы развлекаемся.
Чтобы хорошо выступить, надо было — помимо прочего — выстроить правильную стратегию. Сразу писать максимально короткий запрос, без пробелов и с односимвольными именами не получится — легко самому запутаться. Поэтому сначала надо было решить задачу «по-человечески», а уже потом применить всякие микрооптимизации и получить заветные баллы. Но решить задачу, даже простую, всегда можно разными способами, и не всегда заранее понятно, какой из вариантов окажется короче после оптимизации. Поэтому нужно было не останавливаться, пробовать разные подходы, и при этом аккуратно хранить все версии, чтобы в любой момент можно было посмотреть на запрос еще раз и, чем Тьюринг не шутит, выиграть байтик-другой.
Мы традиционно разрешали пользоваться всеми благами интернета, включая ИИ. На эту тему многие сейчас переживают, но, честно говоря, я пока не вижу причин для беспокойства. Вот если бы все участники показали одинаково прекрасный результат, пришлось бы что-то придумывать. И то, конечно, не запрещать ИИ, а делать задачи более сложными. Но результаты у всех разные, и без собственной головы на плечах их не удалось бы получить (я попробовал), поэтому пока все хорошо. Если финалисты меня читают, было бы интересно услышать комментарии от первого лица: пользовались ли вы ИИ, насколько он вам помог или, может быть, наоборот, только отвлекал?
Я очень надеюсь, что не довёл ещё @bodyawmдо белого каления постоянными упоминаниями — но мимо этого я пройти, конечно, не мог. Как вы все помните, я сам что‑то пытался изобразить на тему «кастомизируемого телефона‑звонилки». Я давно обещал выложить свои наработки, но даже просто вспомнить, на чём я там сломался N лет назад — уже труд немалый, и если бы не активность единомышленника в этом направлении, которая меня стронула, сподвигла и стриггерила — стронуться, наверное, так бы и не смог. Особенно учитывая тот прискорбный факт, что я открываю свои собственные записки на эту тему и не понимаю там ни слова — положите на могилку Элджернона, что на заднем дворе, хотя бы пару цветочков...
...которая работает на первых Android-смартфонах в мире, компьютерах из 90-х и даже Mac'ах! Часть 2.
Иногда у меня лежит душа просто взять и написать какую-нибудь небольшую игрушку с нуля, без использования готовых движков. В процессе разработки я ставлю перед собой интересные задачки: игра должна весить как можно меньше, работать на как можно большем числе платформ и использовать нетипичный для меня архитектурный паттерн. Недавно я начал писать ремейк классических «танчиков» и в рамках серии статей готов рассказать о всех деталях разработки трёхмерной игры с нуля в 2025 году. Если вам интересно узнать, как работают небольшие 3D-демки «под капотом» от написания фреймворка до разработки геймплея и тестов на экзотических устройствах — жду вас под катом!
Однажды на собеседовании меня попросили привести примеры написанного мной кода: один — которым я наиболее горжусь, и другой — который я считаю наиболее неудачным. Недолго думая, я осознал, что на оба вопроса у меня готов ответ, и это один и тот же фрагмент кода. Горжусь я им потому, что, пожалуй, из всей моей практики именно этот код оказался наиболее весом, а стыжусь из-за него, так как, по мнению большинства из его читателей, этот код начался с костыля, который затем стали развивать:
