C++: Как мы докатились до Hello World в 2 МБ

http://www.phreedom.org/research/tinype/

А как там строка Cannot be run in dos mode поживает, проще её заменить на Hello World и сделать указатель на неё прямо из экзешника

HardWrMan 17 hours ago

Вот именно. Эта заглушка - часть стандартного РЕ. И если нам надо просто вывести строку, нам расширенный РЕ и не нужен, достаточно стандартного.

s-a-u-r-o-n 14 hours ago

Некоторые не только убирают эту заглушку, но и уменьшают размер исполняемого файла путём наложения заголовков DOS и PE друг на друга.

HardWrMan 11 hours ago

Ух, ловкачи!

TechExpert 16 hours ago

уважаемый, не много не по теме вопрос, тоже начинал программирование очень давно, еще на асме для z80, но потом не было такой необходимости низко программить. У вас очень хорошо получается объяснять. Могли бы вы посоветовать достойную литературу по реверс, интернет ресурсы, статьи, которые считаете полезными. Последнее время, читаю книги и понимаю, что они являются очень плохим переводом английских людьми далекими от программирования. в 90-х, 0-х литература как-то более дружелюбная и системная была.

antofik 15 hours ago

Practical Reverse Engineerying by Bruce Dang (ссылка)

AndreyDmitriev 11 hours ago

в дополнение к упомянутой книге можете полистать Даниэль Куссвюрм Профессиональное программирование на ассемблере x64, там довольно базово всё, но начинается с регистров и основ. А так — зависит от целей. Если просто поупражняться с ассемблером, то надо попробовать все ассемблеры, какие найдёте и выбрать "свой", FASM популярен, а мне больше ЕвроАссемблер нравится, там есть примеры всякие. Некоторые и MASM используют. По реверсу дизассемблер понадобится, можно IDA, можно Ghidra. Ну там Hex Editor, я 010 использую. Написать на Си несложное крякми приложение, самому же его дизассемблировать, пройти под отладчиком (windbg, x64dbg) и поломать. Криса Касперски можно почитать. Ну и самому пробовать так и сяк. ИИ не стесняться пользовать — он несложные примеры а асме легко генерит и отвечает на вопросы.

TechExpert 9 hours ago

Ассемблер боль мень мне знаком. Интересует имеено способы реверса, инструменты, подходы. Например, иногда некоторые вещи трудно найти. Искал недавно описание elf файла для qnx4 x86. Как происходит инициализация при запуске программ и распределение адресов для библиотечных функций. В ида есть отличный инструмент, она для знакомых компиляторов может найти известные сишные функции и дать им имена. Интересно каким образом создать подобную базу самому для другого компилятора. Подобные технологии мне и интересны. Желательно кросплатформенные и по железу. Сейчас реверсю qnx 6 под процессор sh4. Или вот часто нужно прям до байта разбирать команды ассемблера, чтобы точно понимать что за операнды и почему используются. Попадаются не всегда удобные таблицы или ссылки на сайт интел. Спасибо за информацию, буду изучать.

Gapon65 May 8 at 22:39

[ Я совершено не оспариваю неявное утверждение о том, что iostream в C++ это полнейшее "гуано". ]

Вопрос лишь - в чем, собственно, смысл делать сборку без динамических/разделяемых библиотек (флаг -static который при сборке передается в ld)? Если Вы строите бинарник для встроенных приложений (микроконтроллеров, систем реального времени) то C++ Standard Library вам точно не нужна поскольку эта библиотека (по умолчанию, если Вы не используете специальные аллокаторы) динамически аллокирует/освобождает память. Во всех осталных случаях удобнее использовать разделяемые библиотеки.

Если уберете этот флаг и скомпилируете:

g++ -O2 hello.cpp -o hello.exe

То результат будет совсем иной:

ls -al 
total 39
drwxr-xr-x 2 xxx yyy     4 May  8 15:23 .
drwxr-xr-x 8 xxx yyy     8 May  8 15:05 ..
-rw-r--r-- 1 xxx yyy    75 May  8 15:05 hello.cpp
-rwxr-xr-x 1 xxx yyy 18192 May  8 15:23 hello.exe

ldd hello.exe 
	linux-vdso.so.1 (0x00007ffed21c3000)
	libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007f4b17c00000)
	libm.so.6 => /lib64/libm.so.6 (0x00007f4b17b25000)
	libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f4b17eca000)
	libc.so.6 => /lib64/libc.so.6 (0x00007f4b17800000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f4b17ef0000)

nm hello.exe
0000000000403de0 d _DYNAMIC
0000000000404000 d _GLOBAL_OFFSET_TABLE_
0000000000401140 t _GLOBAL__sub_I_main
0000000000402000 R _IO_stdin_used
                 w _ITM_deregisterTMCloneTable
                 w _ITM_registerTMCloneTable
                 U _ZNKSt5ctypeIcE13_M_widen_initEv@GLIBCXX_3.4.11
0000000000401260 W _ZNKSt5ctypeIcE8do_widenEc
                 U _ZNSo3putEc@GLIBCXX_3.4
                 U _ZNSo5flushEv@GLIBCXX_3.4
                 U _ZNSt8ios_base4InitC1Ev@GLIBCXX_3.4
                 U _ZNSt8ios_base4InitD1Ev@GLIBCXX_3.4
                 U _ZSt16__throw_bad_castv@GLIBCXX_3.4
0000000000404080 B _ZSt4cout@GLIBCXX_3.4
0000000000404191 b _ZStL8__ioinit
                 U _ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_PKc@GLIBCXX_3.4
0000000000402118 r __FRAME_END__
000000000040201c r __GNU_EH_FRAME_HDR
0000000000404060 D __TMC_END__
000000000040037c r __abi_tag
000000000040405c B __bss_start
                 U __cxa_atexit@GLIBC_2.2.5
0000000000404058 D __data_start
0000000000401220 t __do_global_dtors_aux
0000000000403dd8 d __do_global_dtors_aux_fini_array_entry
0000000000402008 R __dso_handle
0000000000403dc8 d __frame_dummy_init_array_entry
                 w __gmon_start__
                 U __libc_start_main@GLIBC_2.34
00000000004011a0 T _dl_relocate_static_pie
000000000040405c D _edata
0000000000404198 B _end
0000000000401264 T _fini
0000000000401000 T _init
0000000000401170 T _start
0000000000404190 b completed.0
0000000000404058 W data_start
00000000004011b0 t deregister_tm_clones
0000000000401250 t frame_dummy
00000000004010b0 T main
00000000004011e0 t register_tm_clones

Vlad441 May 8 at 23:00

Как только вы начинаете полагаться на то что libstdc++ будет предустановлена в системе, есть риск, что на другом компьютере вы можете столкнуться c

Запуск программы невозможен, так как на компьютере отсутствует libstdc++.dll

Или какой-либо другой внешней библиотеки на которую вы полагаетесь. Это уменьшает переносимость и вынуждает качать внешние зависимости.

ldd hello.exe 
  linux-vdso.so.1 (0x00007ffed21c3000)
  libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007f4b17c00000)
  libm.so.6 => /lib64/libm.so.6 (0x00007f4b17b25000)
  libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f4b17eca000)
  libc.so.6 => /lib64/libc.so.6 (0x00007f4b17800000)
  /lib64/ld-linux-x86-64.so.2 (0x00007f4b17ef0000)

В вашем примере вы полагаетесь на то, что в системе будут и libstdc++ и libc и libm и еще от компилятора libgcc_s.

Если хоть чего-то из этого не будет, или же будет не той версии которой нужно (привет от GLIBC) - ваш файл превращается в тыкву. Он не запуститься в среде с musl или же где нет компилятора с его libgcc_s.so.

DustCn yesterday at 00:05

Ну так на другой системе будет компилятор. Вы перенесете на неё исходники, мейкфайл, и все. А если захочется "по серьезному" - делаете инсталлятор.
Если для портабильности все будут носить с собой полные библиотеки, то зачем тогда придумывали .so/dll?

saege5b 19 hours ago

А потом придумали Appimage и прочие :)

Компиляция на месте под конкретное железо это хорошо, но порой уж очень долго и заморочно :(

feelamee 16 hours ago

как иронично. Автор статьи, который ратует за размер бинарника, считает правильным паковать все зависимости вместе с приложением…

vadimr 16 hours ago

Ну так зависимости и являются частью приложения. Методически правильно делает.

feelamee 10 hours ago

зависимости это не часть приложения.

Зависимости это дополнительный функционал, который приложение использует. И они не обязательно производятся/поставляются вместе с приложением.

Зависимости являются частью приложения только если их нет)

Gutt 15 hours ago

А как только вы начинаете статически линковать свои бинарники, вы гвоздями прибиваете все уязвимости и баги, присутствовавшие в реализации стандартной библиотеке на момент линковки, к бинарнику. Фу так делать.

HardWrMan 15 hours ago

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

Так что это настраиваемый связанный параметр на одной оси: слева статика, справа динамика. Ну а истина где-то посередине.

valdemar-const 15 hours ago

Идея с динамическим связыванием с системными библиотеками не работает. В случае Windows, у которой хорошая поддержка обратной совместимости вплоть до версий ОС конца прошлого тысячелетия, это не проблема. DLL на Windows действительно работают хорошо. А вот с Linux — это боль. Потому что отдельный дистрибутив — это мир в себе, никакой совместимости там нет на концептуальном уровне. И если вы хотите распространять свою предкомпилированную программу, которая имеет максимальный охват, вам нужно полагаться на более старые версии системных библиотек и glibc, компилятор можно взять самый новый, но скомпилированный под всё то же древнее окружение. Упаковать ваш исполняемый файл и shared-библиотеки в AppImage и никогда не полагаться на то, что в системе или пакетном менеджере хост-дистрибутива будет в наличии какой бы то ни было пакет. Динамическая линковка с libstdc++ — это роскошь, которую могут себе позволить создатели пакетов отдельно взятой версии конкретного дистрибутива. Не вы выбираете, на какой версии стандарта C++ вам писать программу, а разработчик дистрибутива. Например, на современных Astra Linux или ALT системно установлен GCC 13. Если я хочу C++23 — всегда статическая линковка и сборка всех зависимостей из исходников со старой версией glibc. Благо, с Docker/CMake это очень просто реализовать.

А что до уязвимостей — да, полная перекомпиляция, программа разрабатывается, тестируется и распространяется как монолит, а не горстка связанных деталек.

ИМХО, разумеется. По работе намучался с этим вопросом. Есть ещё всякие Flatpak и аналоги, но это слишком сложно для простых пользователей, которым просто надо вашу программу запустить.

Sap_ru 14 hours ago

Ну да ну да, а потом вылезает VCRUNTIME140 и подобное. Поверх этого работает адски шаманская система манифестов и версионирования библиотек, которая, вроде как помогает, но если что-то пошло не так... Достаточно заглянуть в хранилище установленных бибилиотек, чтобы увидеть, что там может лежать по 50 версий системных библиотек.
В GCC и libstd, кстати, есть ещё более интересная штука, когда библиотека хранит в себе все предыдущие версии, а нужный API выбирается динамически при runtime подключении. Вот только очень мало кто это использует из программистов, а автоматически оно всегда к последней версии вяжется. Но в приниципе, можно на новом GCC можно скомпилировать программу, которая будет использовать более старый API и потому будет соместима с большинством линуксов со времён царя Гороха. libc++ это, к сожалению, не работает, так как библиотека завязана на версию C++, но и у MS с этим тоже всё сложно.

mshonich 5 hours ago

так именно поэтому нормальные библиотеки и собираются под несколько таргетов, включая экзотику типа musl)

зато для ОС загрузка бинарника с динамической линковкой максимально быстрая - все нужные либы уже в памяти почти 100%, только докинуть пару сегментов в карту памяти и приложение готово к работе. а эта ваша статическая линковка только занимает лишнюю физическую память да портит кеш

Gapon65 3 hours ago

Я согласен с Вами о том, что подобный сценарий имеет смысл, особенно для простых приложений. Но дело в том, что в современном мире большинство приложений раздаются с использование лишь двух основных способов (по крайней мере для Linux):

Docker containers (DockerHub, GitHub CR, etc.)
source code (GitHub)

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

В первом случае, все взаимо-согласованные внешние зависимости (LIBC, библиотеки исполнения компилятора, и прочее, что не является продуктом компиляции Вашего кода) включаются в базовый образ (image) run-time контейнерa. Run-time контейнер обеспечивает правильную среду для приложения. На основании такого контейнера вы уже строите следующий уровень - application container, который содержит лишь Ваше приложение скомпилированное для версий библиотек базового контейнера. Помимо собственно бинарников, Вы можете включить в свой контейнер все, что нужно для их работы - конфигурационные файлы, и прочее. Контейнеры это очень удобный механизм позволяющий максимально упростить application deployment либо через Docker run-time либо в Kubernetes.

Второй способ обычно требует CMake, который используется для сборки приложения там где оно и будет работать.

Sap_ru yesterday at 00:30

Во-первых и прежде всего, вы непонятно чего хотите добиться.
Во-вторых, есть ощущение, что вы это делаете неправильно.

Вы зачем-то смело прыгнули в "nostdlib", но при этом не используете оптимизацию линкера!
Никогда ни в коем случае не нужно на десктопе использовать "nostdlib" и писать свои CRT. Там всё намного-намного сложнее, чем кажется на первый взгляд. Вы совершенно точно что-то неуловимо поломаете и потом месяцами будете ошибки ловить.
Вы уверены, что ваш куцый CRT корректно отрабатывает работу с исколючениями и все имеющиеся в stdlib способы инициализации/деинициализации?
А математика вся во всех случаях будет работать? Точно-точно? А где тогда тонкая настройка компилятора?
У вас же в такой конфигурации масса всего работать не будет (или что хуже - будет работать некорректно) - от многопоточности, до особенностей работы с плавающей точкой и выделением памяти!
И, кстати, почему для начала не отключили исключения в настройках компилятора? Это сразу бы уменьшило размер файла, без вот этого всего. Всё равно вы практически наверняка поломали их, выкинув стандартный startup.

И ещё раз: почему вы даже не посмотрели в стону оптимизации линкером, которая во многом и была придумана, чтобы решить вашу "проблему": lto и тому подобное?

Я три раза портировал stdlib и crt на новые платформы, много раз писал на C++ под "голое железо" и поэтому повтрю: совершенно абсолютно никогда так не делайте на десктопе!!! Такие оптимизации требуют глубочайшего знания особенностей реализации crt и stdlib на конкретной платформе, компиляторе и линкере! На десктопе это применяется только для загрузчиков исполняемых файлов и ядра ОС, в который масса сил тратится на обеспечение совместимости с кокретными версиями компиляторов, линкеров и платформ!

И даже на микроконтроллерах я видел только две "любительские" (не поддержанные разработчиками контроллеров, компилятора или какого-то очень большого проекта) корректные реализации ctr. Подавляющее большинство реализаций содержат грубые ошибки, который авторы не видят только потому, что ещё не использовали в коде поломанные ими функции.

Vlad441 yesterday at 01:22

Я упоминал, что:

И, собственно всё. Иные флаги оптимизаций не влияют на размер при текущей кодовой базе.

То есть ни -flto/-flto=thin, ни -fno-exceptions ни даже специальный флаг GCC -fwhole-program не помогли выкинуть лишнее в случае включения iostream. Видимо линкер считает все его зависимости используемыми.

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

Оптимизации линкера очень хороши, но они бессильны если из конкретной сборки стандартной либы физически выкидывать нечего.

Что на счет отказа от CRT - я это использовал в качестве сравнительного примера именно для Hello World и только под Windows.

Однако для проектов посложнее, однозначно что этот путь будет крайне тернист и использование стандартного CRT будет куда выгоднее.

Я даже не стал приводить приводить примеров самопального CRT для Linux, т.к. там уже понадобились бы прямые ассемблерные вставки, что уже требует специализаций под конкретную архитектуру, а там уже есть чему ломаться. У части пользователей это могло бы просто не запуститься или что еще хуже выполнить это некорректно. Тут рациональнее использовать статическую линковку с musl заместо glibc.

hren_sobachiy 21 hours ago

Вроде как в UART посылать гораздо проще - делается виртуальный порт, туда программа без какой либо библиотеки льёт данные. На многих операционках исторически работа с портом не требует обвеса. ну а в shell всё это ловится. Вообщем как будто имеется виртуальная ардуина в которой есть этот cout<< и printf, запускаем putty и наслаждаемся printf с сотней байт.

AnSa8 21 hours ago

Добавьте флаг -fuse-ld=lld(если установлен lld) и сэкономите еще 1 килобайт.

Как мы докатились до того что язык, вотчина которого bare metal, превратился в ещё один клей для свистоперделок. А всё остальное это уже не принципиальное но неизбежное следствие.

HiItsYuri 19 hours ago

вотчина которого bare metal

А это кстати неправда. С++ предоставляет низкоуровневый доступ, но никогда не планировался как замена С в железках.

Dooez 18 hours ago

Спорное утверждение.

Развитием языка занимается комитет, в который входят люди из разных индустрий.

HiItsYuri 18 hours ago

Это только последние 10 лет стандарт взял курс на то, чтобы сделать язык более дружелюбным к железячникам.

hren_sobachiy 15 hours ago

Лучший cout<< тогда будет на VHDL/Verilog. Кстати был бы интересный printf с использованием многоядерного вывода, CUDA, нейросетевых-ядер и SIMD расширений процессора, для полноты ощущений консоли.

Можно, а зачем? (c)

Задача C++ (исторически, и как более удобный C) не дёргать printf, а максимально быстро и на любом чипе рассчитывать какие пиксели зажечь и с какой яркостью. А попытки сделать из него модный-молодёжный клей привели к jack of all trades, master of none: нишу железа по-прежнему занимает C, а как клей C++ со своим UB просто непригоден и опасен.

vanxant 14 hours ago

Ну если стоит задача реализовать printf для вывода на канвас или битмапу, то и SIMD и видеокарта могут быть вполне уместны.

Fedottt 5 hours ago

CUDA? Легко!

Код :)

#include <stdio.h>

__global__ void helloKernel( void )
{
  printf("Hello World!\n");
}

int main( void )
{
  helloKernel<<<1>>>();

  return 0;
}

Всего

Собираем в Developer PowerShell for VS и запускаем:

Вуаля. Итоговый исполняемый файл - всего 169 КБ.

rumtex 20 hours ago

Кроме -s есть ещё -Osize и ещё какой-то, не помню. Хелло ворлд скомпилированный fasm у меня весит 2025 байт.

AndreyDmitriev 19 hours ago

Если переложить данные из .data в .rdata, то при компиляции евро ассемблером вот этого:

EUROASM
hello2 PROGRAM Format=PE, Entry=Start, IconFile=

[.rdata]
Msg D "Hello, World!",10,13,0

INCLUDE winapi.htm

[.text]
Start: 	nop
    WinAPI GetStdHandle, 0FFFFFFF5h
    WinAPI WriteConsoleA, eax, Msg, 0Fh 
	WinAPI ExitProcess 0
ENDPROGRAM

станет секцией меньше, вот сравнение было/стало:

и получится 1564 байта. Я выигрываю, ваш ход. ;) Хотя вроде на хабре уже делали минимальный хелло мир на асме, да что-то найти не могу.

rumtex 15 hours ago

извиняюсь, я на дату просто посмотрел - там 164 байта. этож ассемблер. на эту тему больше конфузий вызывают компиляторы arm64 (zephirOS на 32битных инструкциях столько весит сколько ваш хелло ворлд)

stanukih 20 hours ago

Интересно, а в родной среде - Linux ситуация та же? А clang в Windows/Linux? А так же как в этом же контексте ведёт себя MSVC именно в Windows. Не так же разных версий по годам, а хотя бы текущие/последние. И плюс что по занимаемой оперативной памяти.

Для Линкус можно создать следующий вайб: хотеть минимальный ассемблер линукс убунту x86 вывод консоль ассемблер эльф.

Код:

section .data
    msg db "Hello, World!", 10      ; Строка с символом новой строки (10)
    msglen equ $ - msg              ; Вычисление длины строки

section .text
    global _start                   ; Точка входа для линковщика

_start:
    ; Системный вызов sys_write (вывод в консоль)
    mov rax, 1                      ; Номер вызова write для x86_64
    mov rdi, 1                      ; Дескриптор файла: 1 = stdout
    mov rsi, msg                    ; Указатель на строку
    mov rdx, msglen                 ; Длина строки
    syscall                         ; Вызов ядра

    ; Системный вызов sys_exit (завершение программы)
    mov rax, 60                     ; Номер вызова exit для x86_64
    xor rdi, rdi                    ; Код возврата 0 (успех)
    syscall                         ; Вызов ядра

Пререквистисы: sudo apt update && sudo apt install nasm binutils

Далее транслируем nasm -f elf64 hello.asm -o hello.o, линкуем ld hello.o -o hello

Размеры. Итого исполняемый 8.9 кБ а объектник 880 байт

Результат

Плюс ещё для DOS были упаковщики exe, сжимающие обычными zip-ом секции и потом разворачивающие в памяти

Также можно удалить различные артефакты командой strip --strip-all hello, после чего размер уменьшается 8872 -> 8488 байт

Можно оптимизировать далее, убрав выравнивание, символы ld -s -n -z max-page-size=4096 hello.o -o hello. Размер получился после этого 4560 байт.

Ну и хардкодить заголовок вручную вместо ассемблера

bits 64
org 0x00400000

; --- ELF Заголовок (EHDR) ---
ehdr:
    db 0x7F, "ELF", 2, 1, 1, 0      ; Магические байты, класс (64-бит), порядок байтов
    times 8 db 0                    ; Паддинг (не используется)
    dw 2                            ; e_type: исполняемый файл
    dw 62                           ; e_machine: x86-64
    dd 1                            ; e_version
    dq _start                       ; Точка входа (адрес начала кода)
    dq phdr - ehdr                  ; Смещение до программного заголовка
    dq 0                            ; Смещение до заголовка секций (отсутствует)
    dd 0                            ; Флаги
    dw 64                           ; Размер ELF заголовка
    dw 56                           ; Размер записи программного заголовка
    dw 1                            ; Количество программных заголовков
    dw 0, 0, 0                      ; Информация о секциях (не нужна для запуска)

; --- Программный заголовок (PHDR) ---
; Описывает, как загрузить файл в память
phdr:
    dd 1                            ; p_type: PT_LOAD (загружаемый сегмент)
    dd 5                            ; p_flags: R+X (чтение и исполнение)
    dq 0                            ; p_offset: смещение в файле
    dq 0x00400000                   ; p_vaddr: виртуальный адрес в памяти
    dq 0x00400000                   ; p_paddr: физический адрес
    dq filesize                     ; p_filesz: размер в файле
    dq filesize                     ; p_memsz: размер в памяти
    dq 0x1000                       ; p_align: выравнивание страниц

; --- Основной код ---
_start:
    ; Системный вызов sys_write (вывод строки)
    mov al, 1                       ; rax = 1 (write)
    mov edi, 1                      ; rdi = 1 (stdout - дескриптор консоли)
    lea rsi, [rel msg]              ; rsi = указатель на строку (относительный)
    mov dl, msg_len                 ; rdx = длина строки
    syscall

    ; Системный вызов sys_exit (завершение работы)
    mov al, 60                      ; rax = 60 (exit)
    xor edi, edi                    ; rdi = 0 (код возврата)
    syscall

msg db 'Hello, World!', 10          ; 10 — это символ переноса строки (\n)
msg_len equ $ - msg                 ; Вычисляем длину строки автоматически

filesize equ $ - ehdr               ; Полный размер файла

Далее транслируем это дело nasm -f bin tiny.asm -o tiny, затем делаем файл исполняемым chmod +x tiny

Рекорд! Для Линукс 158 байт

Аналогично думается под Windows можно вручную собрать заголовок, вместо текста Cannot be run in dos mode - свою любую строку

40kTons 16 hours ago

Хардкодить заголовок? Потужно. У меня на дурачка так не получилось

TimurZhoraev 6 hours ago

Попробуем завайбкодить. Кстати пример выше - это в чистом виде не вручную, а вот таким вот промптом сгенерированный пример. Эмбеддер-llm-хардварщик. Вообще говоря это супер, он знает весь мой 30-ти летний "компьютерный" опыт, а по факту всё наверное до 1957 года.

Первый промпт. Устанавливаем компилятор для Винды (всё-таки пришлось расчехлить мне комп с 10-кой). Ай командная строчка ой не могу дай бат-филе мне срочно BuildTools чтобы компилятор был сию секунду с проверкой оной winget запущу её из под админа проверь что это так а не просто юзер угрюмый, да так чтобы cl.exe был как надо! Туда же потом запусти vs vars для путей хороших.

Ставим MS C++

@echo off
setlocal

:: 1. Проверка прав администратора
net session >nul 2>&1
if %errorLevel% neq 0 (
    echo [!] Ошибка: Запустите скрипт от имени АДМИНИСТРАТОРА.
    pause
    exit /b
)

echo [+] Права подтверждены. Работаем...

:: 2. Установка Visual Studio Build Tools через winget
echo [+] Проверка и установка BuildTools...
winget install --id Microsoft.VisualStudio.2022.BuildTools --silent --override "--wait --add Microsoft.VisualStudio.Workload.VCTools;includeRecommended"

if %errorLevel% neq 0 (
    echo [!] Что-то пошло не так при установке через winget.
)

:: 3. Поиск vcvars64.bat для настройки путей (cl.exe)
echo [+] Настройка окружения cl.exe...

set "vcvars_path=C:\Program Files (x86)\Microsoft Visual Studio\2022\BuildTools\VC\Auxiliary\Build\vcvars64.bat"

if exist "%vcvars_path%" (
    call "%vcvars_path%"
    echo [+] Окружение настроено. Проверка:
    cl.exe
) else (
    echo [!] vcvars64.bat не найден по стандартному пути. 
    echo Попробуйте найти его вручную или проверьте установку.
)

pause

Промпт: Ты bare metal программер супер хард рок Металлика, такой же хардкод. Давай MZ ударные правь exe заголовок чётко в видe db asm под компилятор ml.exe только. Посчитай длину заголовок кастом PE Header фарш. А cannot be run in dos mode смело меняй на превед мир туда указатель строка хотеть мэссадж бокс А тоже. Хоти файл асм туда полный для запуска прога.эксэ, минимум байт стаб только вызов систем или винапи 32 бит винда десяточка, действуй!

Результат программы для ЭВМ на языке "Ассемблер"

Слушай сюда, кодер! Сейчас накидаем сырой байт-код, который ml.exe проглотит и не подавится. Мы собираем олдскульный MZ-заголовок (DOS-стаб), который прыгает прямо в PE-секцию. Никакого лишнего жира, только металл и регистры. Это — настоящий олдскульный фарш в духе Metallica, забудь про линкеры, мы пишем заголовок руками. Машинный код — наш закон! Твой EXE будет звучать как Master of Puppets — чётко по долям, байт к байту.

Лови фарш для ml.exe. Я выкинул всё лишнее, оставил только чистую ярость. Вместо стандартного нытья про DOS теперь там твой «Превед мир».

Custom MZ + PE Header (ASM Style)

assembly

.386
.model flat, stdcall

; --- ИМПОРТЫ И ЛИБЫ (The Backstage) ---
MessageBoxA PROTO :DWORD, :DWORD, :DWORD, :DWORD
ExitProcess PROTO :DWORD

includelib user32.lib
includelib kernel32.lib

; --- ДАННЫЕ (Объявлены заранее, чтобы не было A2006) ---
.data
    text    db "Превед мир! Это RAW ASM.", 0
    caption db "Hardcore Metal Edition", 0

.code

; --- MZ HEADER (The Kick Drum) ---
mz_start:
    db 4Dh, 5Ah             ; e_magic: 'MZ'
    dw 0090h                ; e_cblp
    dw 0003h                ; e_cp
    dw 0000h                ; e_crlc
    dw 0004h                ; e_cparhdr
    dw 0000h                ; e_minalloc
    dw 0FFFFh               ; e_maxalloc
    dw 0000h                ; e_ss
    dw 00B8h                ; e_sp
    dw 0000h                ; e_csum
    dw 0000h                ; e_ip
    dw 0000h                ; e_cs
    dw 0040h                ; e_lfarlc
    dw 0000h                ; e_ovno
    dw 4 dup(0)             ; e_res
    dw 0000h                ; e_oemid
    dw 0000h                ; e_oeminfo
    dw 10 dup(0)            ; e_res2
    dd 00000080h            ; e_lfanew -> Указатель на PE Header (128 байт)

; --- DOS STUB (The Solo) ---
; Твой кастомный стаб
msg_stub db 'Превед мир!', 24h ; '$' для DOS
stub_code:
    push cs
    pop ds
    mov dx, offset msg_stub - offset mz_start
    mov ah, 09h
    int 21h
    mov ax, 4C01h
    int 21h

; --- ВЫРАВНИВАНИЕ ---
; Добиваем до 0x80 (128 байт), где начинается PE
db (80h - (offset $ - offset mz_start)) dup(0)

PE_Header:
    db 'PE', 0, 0         ; Signature
    dw 014Ch              ; Machine: x86
    dw 0001h              ; NumberOfSections
    dd 663D5C00h          ; TimeDateStamp
    dd 0, 0               ; Symbols
    dw 00E0h              ; SizeOfOptionalHeader
    dw 0102h              ; Characteristics: EXECUTABLE | 32BIT

; --- ВЫХОД НА СЦЕНУ ---
start:
    ; Теперь 'text' и 'caption' определены заранее
    invoke MessageBoxA, 0, addr text, addr caption, 0
    invoke ExitProcess, 0

end start

ml.exe флаги дай

Для ml.exe (MASM), чтобы собрать этот хардкорный фарш под Win10, тебе нужны флаги, которые не задают лишних вопросов и делают чистый объектник.

Базовый набор для 32-bit (x86):

ml /c /coff main.asm

А теперь вторая стадия — Линковка (Лязг железа):

Чтобы твой кастомный заголовок и стаб взлетели на Десятке, link.exe нужно приструнить:

link /subsystem:windows /entry:start /nodefaultlib main.obj kernel32.lib user32.lib

Вообщем игры с кастомным заголовком не прошли под среду построения Microsoft. Выход только один - использовать ещё более железный FASM

Промпт. Йоу чел, bare metal! программер супер чёткий бит ага. такой же хардкод. Давай MZ раскачай правь exe заголовок коммон в видe db asm под компилятор FASM только. Посчитай длину заголовок кастом PE Header ага. А cannot be run in dos mode смело меняй на превед мир туда указатель строка хотеть мэссадж бокс А тоже. Хоти файл асм туда полный для запуска прога.эксэ, минимум байт стаб только вызов систем или винапи 32 бит винда десяточка, действуй йоу!

Используем FASM

Вот тебе самый чёткий и минималистичный хардкод на FASM. Настоящий bare metal стайл: MZ-заголовок, самописный PE-заголовок и минимум байтов для Win10.

Вместо скучного текста про DOS — твой «превед мир», который вылетит через MessageBoxA.

Код компиируется но винда ругается, ей нужны кратные 512

format binary as 'exe'

; ========================================================
; MZ HEADER (DOS STUB)
; ========================================================
db 'MZ'                      ; Signature
dw 0x0090, 0x0003, 0x0000, 0x0004, 0x0000, 0xffff, 0x0000
dw 0x00b8, 0x0000, 0x0000, 0x0000, 0x0040, 0x0000, 0x0000, 0x0000
times 8 dw 0
dd 0x00000080                ; Offset to PE Header

; --- DOS Code (Stub) ---
; Вместо "This program cannot be run..." фигачим месседж
stub_start:
    push    cs
    pop     ds
    mov     dx, msg_hello - stub_start
    mov     ah, 0x09
    int     0x21
    mov     ax, 0x4c01
    int     0x21

msg_hello db 'превед мир!', 0x0d, 0x0a, '$'
align 16

; ========================================================
; PE HEADER
; ========================================================
org 0x80
_pe_header:
db 'PE', 0, 0                ; Signature
dw 0x014c                    ; Machine (i386)
dw 1                         ; Number of Sections
dd 0                         ; TimeDateStamp
dd 0, 0                      ; PointerToSymbolTable, NumberOfSymbols
dw _op_size                  ; SizeOfOptionalHeader
dw 0x0102                    ; Characteristics (Executable, 32-bit)

_optional_header:
dw 0x010b                    ; Magic (PE32)
db 8, 0                      ; Major/MinorLinkerVersion
dd _code_size, 0, 0          ; SizeOfCode, SizeOfInitializedData, SizeOfUninitializedData
dd _start, _start            ; AddressOfEntryPoint, BaseOfCode
dd 0                         ; BaseOfData
dd 0x00400000                ; ImageBase
dd 0x1000                    ; SectionAlignment
dd 0x200                     ; FileAlignment
dw 4, 0                      ; Major/MinorOSVersion
dw 0, 0                      ; Major/MinorImageVersion
dw 4, 0                      ; Major/MinorSubsystemVersion
dd 0                         ; Win32VersionValue
dd _image_size               ; SizeOfImage
dd _header_size              ; SizeOfHeaders
dd 0                         ; CheckSum
dw 2                         ; Subsystem (Windows GUI)
dw 0                         ; DllCharacteristics
dd 0x100000, 0x1000          ; SizeOfStackReserve/Commit
dd 0x100000, 0x1000          ; SizeOfHeapReserve/Commit
dd 0                         ; LoaderFlags
dd 16                        ; NumberOfRvaAndSizes

; Data Directories
dd 0, 0                      ; Export
dd _import_table, 0          ; Import
times 14 dd 0, 0             ; Остальные нули

_op_size = $ - _optional_header
_header_size = $

; --- Section Table ---
db '.text', 0, 0, 0
dd _code_size                ; VirtualSize
dd 0x1000                    ; VirtualAddress
dd _code_size                ; SizeOfRawData
dd _start                    ; PointerToRawData
dd 0, 0                      ; Relocations, Linenumbers
dw 0, 0                      ; NumberOfRelocations, NumberOfLinenumbers
dd 0x60000020                ; Characteristics (Code, Execute, Read)

align 512
_start:
; ========================================================
; CODE SECTION (WIN32)
; ========================================================
    push 0                   ; uType (MB_OK)
    push _caption            ; lpCaption
    push _text               ; lpText
    push 0                   ; hWnd
    call [MessageBoxA]

    push 0
    call [ExitProcess]

_text    db 'Йоу, это Win10 Bare Metal!', 0
_caption db 'FASM Power', 0

align 16
; --- Import Table ---
_import_table:
dd _kernel32_import, 0, 0, _kernel32_name, _kernel32_thunks
dd _user32_import, 0, 0, _user32_name, _user32_thunks
dd 0, 0, 0, 0, 0

_kernel32_name db 'KERNEL32.DLL', 0
_user32_name   db 'USER32.DLL', 0

align 4
_kernel32_thunks:
ExitProcess dd _exit_proc_name
dd 0

_user32_thunks:
MessageBoxA dd _msgbox_name
dd 0

_kernel32_import = _kernel32_thunks
_user32_import   = _user32_thunks

_exit_proc_name dw 0
db 'ExitProcess', 0
_msgbox_name    dw 0
db 'MessageBoxA', 0

_code_size = $ - _start
_image_size = 0x2000

Что тут происходит, бро:

MZ Header: Вручную прописаны байты db 'MZ'. Смещение до PE указано как 0x80.
DOS Stub: Вместо стандартной ошибки — код на асме 16-бит, который выводит "превед мир!" и выходит.
PE Header: Полностью расписан через db/dw/dd. Считает длину опционального заголовка автоматически (_op_size).
Imports: Прямая привязка к USER32.DLL для MessageBoxA и KERNEL32.DLL для выхода.
Alignment: Всё выровнено под 512 байт (FileAlignment) и 4096 байт (SectionAlignment), чтобы Винда не ругалась.

Как собрать: Сохрани в hack.asm и жахни fasm hack.asm. На выходе будет чистейший экзешник.

Бро, я вижу на скрине, что файл hack.exe весит 674 байта. Это и есть главная проблема для Windows 10. Она видит, что файл не выровнен по границе 512 байт (FileAlignment), и считает его битым или вирусным.

Для «десятки» критично, чтобы SizeOfHeaders и физический размер файла были кратны 512. Давай сделаем финальный рывок — добавим жесткое выравнивание и поправим версию подсистемы на 5.1 (XP) или 6.0 (Vista), чтобы точно пролезло.

Вот код, который обязательно должен выдать файл размером ровно 1024 байта (или 1536).

Давай применим «тяжёлую артиллерию» FASM. Вместо ручного db/dw, будем использовать стандартные макросы, но с максимально жёстким контролем байтов. Это гарантирует, что заголовки будут правильными, а выравнивание — идеальным.

Вот код, который точно создаст валидный PE-файл. Сохрани его и скомпилируй:

fasm

include 'win32a.inc' ; Используем стандартные макросы для стабильности

format PE GUI 4.0     ; Указываем подсистему и версию (Win 95+)
entry start           ; Точка входа

; ========================================================
; MZ HEADER & DOS STUB (Твой кастомный стайл)
; ========================================================
; Примечание: FASM сам соберет PE, если использовать 'format PE', 
; но мы добавим твой текст через секцию или оставим стандарт.
; Чтобы сделать именно "превед мир" в DOS, нужно шаманить с бинарным форматом,
; но давай сначала заставим его просто работать в Win10.

section '.text' code readable executable

start:
    invoke MessageBox, 0, _message, _caption, MB_OK
    invoke ExitProcess, 0

_message db 'Йоу! Это Bare Metal на Win10!', 0
_caption db 'FASM Hack', 0

section '.idata' import data readable

library kernel32, 'KERNEL32.DLL', \
        user32,   'USER32.DLL'

import kernel32, \
       ExitProcess, 'ExitProcess'

import user32, \
       MessageBox, 'MessageBoxA'

; ========================================================
; ВЫРАВНИВАНИЕ (Секретный ингредиент)
; ========================================================
; Этот блок добьет файл до нужного размера, чтобы Винда не ругалась.
db 512 dup (0)

Use code with caution.

Почему этот вариант сработает:

format PE GUI 4.0: FASM сам правильно высчитает длину Optional Header, SizeOfImage и SizeOfHeaders. Тебе не нужно гадать с dd и dw.
invoke: Это чистый системный вызов через таблицу импорта, без лишнего мусора.
Alignment: Использование макросов section гарантирует, что данные будут лежать по правильным адресам, которые ожидает загрузчик Windows.

Как проверить:После компиляции размер файла должен быть кратно 512 (например, 1024, 1536 или 2048 байт).

Обратите внимание на расположение папок FASM для инклудов

2 килобайта. (2048)

Подменяем всё-таки заголовок

Как ни крути с заголовком, винда 10-ка и старше походу думает что это малварь

format binary as 'exe'

; --- Константы ---
IMAGE_BASE = 0x00400000
RVA_BASE   = 0x1000

FILE_START:
; ========================================================
; MZ HEADER (0x00 - 0x3F)
; ========================================================
db 'MZ'
dw 0x0090, 0x0003, 0x0000, 0x0004, 0x0000, 0xffff, 0x0000
dw 0x00b8, 0x0000, 0x0000, 0x0000, 0x0040, 0x0000, 0x0000, 0x0000
times 8 dw 0
dd 0x80                      ; PE заголовок на 128-м байте

; ========================================================
; DOS STUB (0x40 - 0x7F)
; ========================================================
db (0x40 - ($ - FILE_START)) dup 0 ; Жесткий переход на 0x40
    use16
    push    cs
    pop     ds
    mov     dx, msg_dos - FILE_START
    mov     ah, 9
    int     21h
    mov     ax, 4C01h
    int     21h
msg_dos db 'превед мир!$', 0

; ========================================================
; PE HEADER (0x80 - 0x1FF)
; ========================================================
db (0x80 - ($ - FILE_START)) dup 0 ; Жесткий переход на 0x80
_pe_header:
db 'PE', 0, 0
dw 0x014c, 1, 0, 0, 0
dw _op_size, 0x0102

_opt_header:
dw 0x010b
db 12, 0
dd 0x200, 0, 0
dd RVA_BASE, RVA_BASE
dd IMAGE_BASE
dd 0x1000, 0x200
dw 6, 0, 0, 0, 6, 0
dd 0, 0x2000, 0x200, 0, 2, 0
dd 0x100000, 0x1000, 0x100000, 0x1000, 0, 16

; Directories
dd 0, 0
dd (_import_table - CODE_START + RVA_BASE), _import_size
times 14 dd 0, 0
_op_size = $ - _opt_header

; Section Table
db '.text', 0, 0, 0
dd 0x1000, RVA_BASE, 0x200, 0x200, 0, 0, 0
dd 0x60000020

; Добиваем ПЕРВЫЙ блок до 512 байт (0x200)
db (0x200 - ($ - FILE_START)) dup 0

; ========================================================
; CODE & DATA (Блок 2, старт с 0x200 в файле)
; ========================================================
CODE_START:
    use32
    push    0
    push    dword (_caption - CODE_START + RVA_BASE + IMAGE_BASE)
    push    dword (_text - CODE_START + RVA_BASE + IMAGE_BASE)
    push    0
    call    dword [(_iat_msg - CODE_START + RVA_BASE + IMAGE_BASE)]

    push    0
    call    dword [(_iat_exit - CODE_START + RVA_BASE + IMAGE_BASE)]

_text    db 'Йоу, дамп теперь чистый!', 0
_caption db 'Bare Metal', 0

align 4
_import_table:
dd (_k_names - CODE_START + RVA_BASE), 0, 0, (_k_dll - CODE_START + RVA_BASE), (_k_thunks - CODE_START + RVA_BASE)
dd (_u_names - CODE_START + RVA_BASE), 0, 0, (_u_dll - CODE_START + RVA_BASE), (_u_thunks - CODE_START + RVA_BASE)
dd 0, 0, 0, 0, 0
_import_size = $ - _import_table

_k_dll db 'KERNEL32.DLL', 0
_u_dll db 'USER32.DLL', 0

_k_names: dd (_aExit - CODE_START + RVA_BASE), 0
_u_names: dd (_aMsg - CODE_START + RVA_BASE), 0

_k_thunks: _iat_exit dd (_aExit - CODE_START + RVA_BASE), 0
_u_thunks: _iat_msg  dd (_aMsg - CODE_START + RVA_BASE), 0

_aExit dw 0
       db 'ExitProcess', 0
_aMsg  dw 0
       db 'MessageBoxA', 0

; --- ХВОСТ ---
; Добиваем до ровного КБ (1024 байта / 0x400)
db (0x400 - ($ - FILE_START)) dup 0

Вообщем винда походу детектирует битый заголовок и не даёт запускаться.

Теперь жмём секции

Бро, Десятка — та ещё вредина. Если файл весит 1.5 КБ, но «молчит», значит, ей не нравится, что импорты лежат в одной куче с кодом в режиме PE 6.0. Она считает такую структуру небезопасной и тихо гасит процесс.

Давай сделаем каноничный вариант. Мы разделим код и импорт на две секции.

Держи код, который 100% выкинет бокс:

include 'win32a.inc'

; Ставим 6.0 для совместимости с Win10 x64
format PE GUI 6.0
entry start

; --- СЕКЦИЯ КОДА ---
section '.text' code readable executable
start:
    invoke MessageBox, 0, _message, _caption, MB_OK
    invoke ExitProcess, 0

_message db 'Йоу! На 2КБ всё летает!', 0
_caption db 'FASM Win10', 0

; --- СЕКЦИЯ ИМПОРТА ---
; Разделение секций — ключ к успеху на свежих билдах Винды
section '.idata' import data readable

library kernel32, 'KERNEL32.DLL', \
        user32,   'USER32.DLL'

import kernel32, \
       ExitProcess, 'ExitProcess'

import user32, \
       MessageBox, 'MessageBoxA'

Use code with caution.

Почему этот вариант — «золотой»:

Чистые права: Секция кода — только для чтения и выполнения. Секция данных — только для чтения. Win10 это любит.
Разделение: Загрузчик Windows чётко видит, где искать таблицу функций (IAT), и не путается в твоих байтах.
Стабильность: Этот шаблон — база. Если он не запустится, значит, твой антивирус или защитник (Windows Defender) считает самописные EXE без цифровой подписи угрозой.
Красава, бро! 1536 байт — это «золотое сечение» для FASM на Десятке. Значит, загрузчик всё-таки проглотил комбинированную секцию, и мы вписались ровно в три блока по 512 байт.
Это чистая победа: файл максимально поджат, импорты живые, Win10 не ругается. Настоящий Bare Metal стайл, как ты и хотел.
Что мы имеем в итоге:
- Заголовок: Стандартный PE (1024 байта), который не триггерит защиту системы.
- Секция: Одна общая .all (512 байт), где и код, и данные, и таблица импорта.
- Вес: Ровно 1.5 КБ.
Теперь ты можешь в этот же .asm накидывать любой функционал. Пока ты не выйдешь за пределы оставшихся свободных байтов в этой секции, размер файла так и останется 1536.

Итак, диалог с 1,5 кБ кто меньше? Объявляется конкурс на не битый заголовок содержащий что то вроде

Для ранних версий винды вполне возможно что ок, речь идёт о 10ке и старше. Итак, рекордсмен ровно 1536 байт. Идём к 1024 или 512.

AnSa8 16 hours ago

Размеры. Итого исполняемый 8.9 кБ ...

Чего так много?


__attribute__ (( section( ".text" ) ))
static char str[] = "Hello!\n";

extern "C" void _start() {
	asm volatile ( "syscall" :: "a"( 1/*SYS_write*/), "D"(1/*STDOUT_FILENO*/), "S"(str), "d"(sizeof( str )) );
	asm volatile ( "syscall" :: "a"(60/*SYS_exit */), "D"(0) );
}

wsl -e g++ -O2 -fno-exceptions -fno-rtti -fno-asynchronous-unwind-tables -nostartfiles -s -static -fuse-ld=gold -Wl,--gc-sections main.cpp -o main.elf

main.elf - 824 байта.

А если ещё сделать:

wsl -e objcopy -j .text main.elf

То остаётся всего 528 байтов.

s-a-u-r-o-n 14 hours ago

Под Windows не получится сделать аналогично, поскольку в нём плавают номера syscall-ов от версии к версии.

Они и в Линуксе плавают.

netch80 8 hours ago

Нет, однажды добавленное уже остаётся навеки. Вы, наверно, с разными платформами путаете, вот тут номера между даже x86-32 и x86-64 несовместимы.

ivanrt 17 hours ago

Нет, ответил ниже. 15kb и та и другая прога.

d3d14 19 hours ago

Не нужно вручную инициализировать CRT.
В MSVS собирается с опцией NODEFAULTLIB вообще без CRT - размер 2.5 кБ.

CoolCmd 19 hours ago

у visual c++ 2022 размер 64-битного exe равен 220 КБ. из зависимостей - только kernel32.dll. видимо, качество библиотеки g++ для винды (???) не слишком хорошее.

Nemoumbra 16 hours ago

А при чём тут g++, если MSVC? g++ и под Винду есть.

CoolCmd 11 hours ago

А при чём тут g++, если MSVC?

я сравниваю библиотеки msvc и g++.

я в курсе, что g++под винду есть, просто автор в статье не указал прямым текстом, под какую платформу собирал прогу.

Vlad441 1 hour ago

Таргет вроде бы явный - hello.exe а не просто hello. Да системные вызовы чисто виндовые.

titbit 18 hours ago

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

RedEyedAnonymous 18 hours ago

это как раз-таки очень правильно, так как уже пришла пора отказываться от файловых библиотек в пользу объектных. Когда линкуется только то что необходимо а не то что нагрузили. Вплоть до того что в библиотеках прописываются условные пути по идентификаторам как их обходить. Вообще говоря эта кухня, структура эльфов, exe-шников, dll-so уже не менялась лет так 40, там капитальный ремонт нужен с учётом современных требований IDE и LLM, плюс довозка в компиляторы, линкёры нормального рефакторинга и работой вот с такими синтаксическими деревьями и кодогенерацией на нормальном уровне а не скрытой от пользователя

Блин, как же в лохматом году борманы в своём дельфе умели выкидывать лишнее при линковке, а авторы современного, моднючего ц++ разучились?

SilverTrouse 17 hours ago

Лишнее выкидывается. Вопрос в том, что они считают лишним.

LittleAlien 12 hours ago

У “борманов” те же проблемы, если в стандартных библиотеках прописана какая-то инициализация (а она прописана в VCL, в Classes и т.д.), никакой смарт линкер не поможет и прицепится всё.

Ewoke 18 hours ago

Самая дикость, что этих printf-ов готовых, полно в сишных рантайм-библиотеках msvcrt, ТЫСЯЧИ ИХ. Причем они есть уже в винде изкаробки, но обязательно все равно нужно с собой dll-hell возить в каждом дистрибутиве каждого приложения, добавляя очередной Visual C Runtime 2026.

ilgbs 18 hours ago

import <iostream>;

int main()
{
	std::cout << "Hello World";
}

Только что в Windows скомпилировал данный код в последней версии Visual Studio 2026 с флагом -O2, у меня получился исполняемый файл размером 11 Кб.

osmanpasha 17 hours ago

Дак оно и в gcc столько же весит, если динамически слинковать с рантаймом, как MS VC делает по умолчанию (выше в коментах есть).

titbit 18 hours ago

В итоге для всех упомянутых версий 15.2.0, 13.1.0, 10.3.0, 4.9.2 получаем стабильные 3,50 КБ (3 584 байт)

Если достаточно поиграться опциями и отключить исключения например, то у меня тот же файл выдает уже 2560 байт именно на g++. Чтобы сделать меньше надо сливать секции уже, что в случае gnu ld не так тривиально как для msvc link: надо аккуратно править скрипты линкера.

Вы можете спросить, ну а зачем компилятор сует обработку исключений в код, если из кода очевидно, что никаких исключений не предвидется? Ответ прост: специально никто ничего не сует, просто вариант runtime библиотеки один - и он на все, даже самые тяжелые, случаи. Потому что иначе пришлось бы иметь два варианта библиотек - для исключений и без них. И два варианта кажутся ерундой, но потом кто-то скажет, а мне не нужно utf8, а кому-то rtti, а кому-то потоки не нужны, а кому-то еще не нужна поддержка новых фич процессоров ну и т.д. и число вариантов билиотек устремляется к тысячам, а это банально никто не сможет поддерживать. Так что придется смириться с тем, что runtime библиотека обычно есть в паре-тройке вариантов покрывающих 97% всех программ и да, размер этой библиотеки обычно приличный, ну а для оставшихся экзотических вариантов придется выкручиваться самостоятельно.

osmanpasha 16 hours ago

Хех, с компилятором для микроконтроллеров ARM (arm-gcc-none-eabi), такая ситуация как раз. Там на каждый вариант архитектуры свой рантайм (типа "arm v8-m c вещественными числами двойной точности"). В итоге с каждой новой версией компилятор толстеет на сотню-другую мегабайт, gcc 5 весил 100Мб, gcc 7 - 450Мб, gcc 10 - 730Мб, gcc 15 - 1.1 Гб.

Vlad441 12 hours ago

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

Чтобы все эти паре-тройке вариантов можно было выкинуть ели они явно не нужны.

isumix 17 hours ago

Ну вот, оказывается не npm единый - является черной дырой зависимостей, а даже православные плюсы этим грешат.

import std?

Akon32 17 hours ago

Тем временем, hello world на Python занимает 23 байта. Естественно, если вы не хотите тянуть рантайм, то приходится тянуть реализации "std::cout <<" в каждый бинарник. Особенно показателен Rust - без специальных (и известных всем, проблема не новая) оптимизаций по размеру бинарник легко оказывается больше 100МБ. С оптимизациями - вполне приличные ~500КБ.

Кстати да, для интерпретируемых языков можно попробовать наассемблерить что-то вроде кода для JVM:

.class public HelloWorld
.super java/lang/Object

; Стандартный конструктор (необходим для любого класса)
.method public <init>()V
   aload_0
   invokenonvirtual java/lang/Object/<init>()V
   return
.end method

; Точка входа в программу (main)
.method public static main([Ljava/lang/String;)V
   .limit stack 2   ; Указываем максимальную глубину стека
   
   ; Получаем статический объект System.out
   getstatic java/lang/System/out Ljava/io/PrintStream;
   
   ; Кладем строку на вершину стека
   ldc "Hello JVM Bytecode!"
   
   ; Вызываем метод println
   invokevirtual java/io/PrintStream/println(Ljava/lang/String;)V
   
   return
.end method

Создаём ^^ этот файл HelloWorld.j, скачиваем jasmin.jar отсюда компилируем

java -jar jasmin.jar HelloWorld.j

должно получиться: Generated: HelloWorld.class

запускаем

размер байткода для ява: 384 байт

Akon32 16 hours ago

Да, сначала хотел привести в пример Java, но формат .class - это минимум сотни байт.

Запускаем эмулятор DOS. Берём TASM (Turbo assembler) компилируем следующее для работы с консолью через прерывание 21h

.model tiny        ; Указываем модель tiny для создания .com файла
.code
org 100h           ; Точка входа для .com файлов всегда начинается с адреса 100h

start:
    mov ah, 09h    ; Функция DOS 09h: Вывод строки на экран
    mov dx, offset msg ; Помещаем адрес сообщения в регистр DX
    int 21h        ; Вызываем прерывание DOS

    mov ax, 4C00h  ; Функция DOS 4Ch: Завершение программы (код возврата 0)
    int 21h        ; Вызываем прерывание DOS

msg db 'Hello World!$' ; Строки для функции с символом '$'

end start

Транслируем tasm hello.asm и потом tlink /t hello.obj
Получаем файл .com размером 25 байт

Можно также без DOS сразу используя BIOS прерывание 10h для вывода на экран (записать по 0 дорожка 0 цилиндр 0 сектор только аккуратно)

.model tiny
.code
org 100h

start:
    mov ah, 0Eh    ; Функция BIOS 0Eh: Вывод символа в режиме телетайпа
    mov si, offset msg ; Указатель на начало строки в регистр SI

print_loop:
    lodsb          ; Загружаем следующий байт из DS:SI в регистр AL и двигаем SI
    cmp al, 0      ; Проверяем, не дошли ли мы до конца строки (нуля)
    je done        ; Если встретили 0, выходим из цикла
    int 10h        ; Вызываем прерывание BIOS для печати одного символа в AL
    jmp print_loop ; Переход к следующему символу

done:
    ret            ; В .com файлах простая команда ret завершает программу

msg db 'Hello World!', 0 ; Строка заканчивается нулем (null-terminated)

end start

размер не сильно отличается, до 50 байт в любом исполнении

HardWrMan 17 hours ago

О Зубкове я написал выше. :)

PS Из COMы можно выходить по RET, потому что перед запуском система кладёт туда адрес возврата на вызов сервиса 0x4C@INT21. Кстати, можно ещё тупо INT 20h вызвать без параметра.

Можно даже ещё круче - вылететь с ошибкой (без ret) но сделать вывод на экран, плюс ещё без терминатора $

Функционально железобетонный вариант под dos, который громит всё вокруг но выводит, плюс с элементами машинных кодов 0xCD, 0x21 - это int21h в ASCII формате это =!

[org 0x100]

start:
    mov dx, msg        ; Адрес строки
    mov ah, 0x09       ; Функция печати DOS

    ; Провал в код. Процессор начнет исполнять строку.
msg:  
    db "═!Hello World"

HardWrMan 16 hours ago

Это уже на грани фола.

0xCD, 0x21 - это int21h в ASCII формате это =!

Желательно уточнить, что тут не знак "равно" (=) а двойная горизонтальная рамка псевдографики. Потому что "равно" это 0x3D.

Viacheslav01 15 hours ago

да, так и есть. Если уж DOS = и ═ (тут он так отображается)это чуть разные вещи, то про Unicode уже и говорить не приходиться. А так в принципе там просто можно вполне дописать db 0xCD, 0x21. Если нет транслятора ассемблера, то можно уж прям сразу в hex, в машинных кодах. Не помню кто умел печатать из хекса в символы - вроде как Dos Navigator, Notron не умел, только смотреть в виде hex.

B4 09 BA 0B 01 CD 21 B8 00 4C CD 21 Hello World!$

Вспоминаются странички с таким содержимым из разряда Радио-86 РК.

На Спектруме можно было шить ассемблер в машинных командами PEEK/POKE прямо в ОЗУ. Из интерпретатора Бэйсика )). Да и в DOS что-то такое можно было делать с таблицей векторов. Это уже потом HIMEM и прочие config,sys подвезли почти что с виртуалкой

Помню подобную фигню "B4 09 BA 0B 01 CD 21 B8 00 4C CD 21" писал для z80 на салфетках лежа в больнице. И читал и понимал, сейчас не предстаавляю как мозг с этим справлялся, сернуть бы его )

HardWrMan 15 hours ago

Я до сих пор в состоянии понять бинарные опкоды от MCS80, хотя прошло уже 30 лет с момента когда я реально этим пользовался. Помогает при починке всяких Корветов и прочих ПК/ЛК на ВМ80.

Viacheslav01 9 hours ago

Ооо корветы, я как раз пытаюсь найти себе 8020 за вменяемые деньги в нормальном состоянии, закрыть недоделанное в школе дело )))

HardWrMan 9 hours ago

Тогда, вам точно сюда.

Viacheslav01 6 hours ago

Спаисбо

Akon32 8 hours ago

C9 это ret. Больше не помню.

Viacheslav01 6 hours ago

00 nop

d3d14 8 hours ago

Я, помнится, для диплома, писал для Z80 прошивку переводя асм в hex коды на листочке, по таблице опкодов :)

HardWrMan 15 hours ago

Не помню кто умел печатать из хекса в символы - вроде как Dos Navigator, Notron не умел, только смотреть в виде hex.

Здрасьте. Иметь такие познания и забыть про hiew?

Да и в DOS что-то такое можно было делать с таблицей векторов.

Turbo Pascal имел легальные функции установки вектора любого прерывания, чем я часто пользовался.

TimurZhoraev 10 hours ago

нуу это знаменитый, он потом уже только появился когда с друзьями обменивались 3.5'' вместо 5.25'', не всё сразу, на пятёрке как раз умещались norton utilites. Помню windows 3.11 занимал что то в районе с десяток мелких дискет. Там уже и borland c подоспел и masm/tasm, а дос навигатора вполне хватало смотреть hex по F3, потом FAR конечно же (сейчас Midnight в принципе хватает), дизассемблер тоже был вроде как из этих пакетов, hiew это конечно классика, помню как можно было весело менять команды выравниванием до неузнаваемости или попытка им посмотреть сжатые exe-файлы, были ещё такие exe-шники которые ловили int 03 дебаггер и вываливались ругаясь ая яй нельзя меня ломать.

Самое интересное - это попытка написать com резидентный (TSR) вирус )) который сканил по 21h и заражал другой com, встраиваясь в код. Exe вирусы это уже другое дело, особенно шифрующиеся, понравился тогда Civil Defence, который матом на принтер ругался. Потом как-то попался этот текстовик (он не оригинальный, что-то не ищется, наверное уже в забвении). Тогда был drWeb, полифаг Лозинского и ещё какой-то. Плюс ещё эксперименты с прямым чтением цилиндр-сектор-голова по int 13.

vanxant 14 hours ago

поясните нафига тут этот мусор в строке? что мешало сделать честное int 21h и только потом msg: db "Hello world" ? Т.е. в двоичном виде изменится только адрес msg

TimurZhoraev 10 hours ago

Это из того времени, когда tasm/masm нужно было школьнику где-то разыскать на дискете. Тогда "кнопка download" была разве что в институтах или FIDO (и то это для тех у кого был модем). Поэтому приходилось использовать подручные средства, это так, дань истории, когда можно было переводить ASCII в машиный код и обратно, глядя в те самые 80 строк и 25 столбцов на 13'' ЭЛТ мониторе. Первый 386й, 4 МБ, SVGA до 800 на 600, 1994й год, 9-ти игольный Эпсон. Первые проги были .com, умещающиеся в сегмент 64 кБ. Их действительно можно было делать прямо в машкодах, взяв книжку по опкодам 8086 (тогда тоже надо было ещё раздобыть), вычислять смещение для jmp/jc вручную. Всегда забавляли вот эти вот карты - смайлики и это была как "таблица умножения" и тот самый 0x9 пищащий в спикер, int21 как раз умел это делать.

для кириллицы как сейчас помню: mode con cp select=866 или prepare как то так

czz 12 hours ago

Запускаем эмулятор DOS

Ну не совсем спортивно, вы фактически, пишете код для виртуальной машины и тянете рантайм в виде эмулятора :)

ivanrt 17 hours ago

Проблемы портирования posix на винду? На Linux всё нормально, потестировал на Gentoo:

Linux -Os: c + stdio: 15kb, c++ + iostream: 15kb

Какой нафиг посикс...

KseandI 3 hours ago

Скорее всего про CRT имелось ввиду.

KseandI 3 hours ago

Вот бы в статье была бы указана команда и с какими флагами (а точнее, с каким флагом) компилировал автор, что у него такая большая разница…

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

brat_viktor 17 hours ago

Собрал под Ubuntu в Qt Creator и Qt6.4.2 проект С++, без использования Qt и размер исполняемого файла 16 кб. Переносил чисто файл в голую папку /tmp, чтобы быть уверенным что не тянутся либы из относительных путей - запускается нормально.

Самое сложное в метрологии - не намерять фигни!

100h 16 hours ago

Сделал то же самое (и внизу запостил коммент ) - подтверждаю!

HardWrMan 16 hours ago

чтобы быть уверенным что не тянутся либы из относительных путей

А что с абсолютными?

fshp 16 hours ago

Если не статически линковали и не шаманили с настройками линкера, то проверьте через ldd

bogolt 6 hours ago

Чтобы понять что он тянет нужно выполнить `ldd <бинарник>`

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

0xdead926e 17 hours ago

попробовала все то же самое на clang'e (с вижловой стл и вижловым линкером)- 212 килобайт в случае iostream и 124 килобайта в случае std::print. видать, g++ там всю свою библиотеку насильно тащит.

Что касается C++ то можно навайбить следующее (вместе со стандартной библиотекой)

#include <iostream>

int main() {
    // Отключаем синхронизацию с stdio для небольшого ускорения
    std::ios_base::sync_with_stdio(false);
    
    std::cout << "Hello, World!" << std::endl;
    return 0;
}

Далее небольшой бэш для компиляции

g++ -Os -s -fno-ident -fno-asynchronous-unwind-tables -DNDEBUG main.cpp -o hello_cpp
# 1. Удаляем все лишние секции (комментарии, заметки)
strip --strip-all -R .comment -R .note.ABI-tag -R .note.gnu.build-id hello_cpp

В итоге файл 14192 байт

Можно использовать упаковщик исполняемых upx, который sudo apt install upx-ucl

g++ -Os main.cpp -o hello_cpp

/usr/bin/upx -9 hello_cpp

После чего размер становится 6332 байт

Ну или трюк, компиляция C++ файла со C-вставкой

Делаем "С++" файл со следующим содержимым без main

extern "C" {
    void _start() {
        // static гарантирует, что строка в секции .rodata, а не на стеке
        static const char msg[] = "Hello from C++!\n";
        
        asm volatile (
            "mov $1, %%rax;"     // sys_write
            "mov $1, %%rdi;"     // stdout
            "mov %0, %%rsi;"     // адрес строки
            "mov $16, %%rdx;"    // длина
            "syscall"
            :
            : "r" (msg)
            : "rax", "rdi", "rsi", "rdx", "memory"
        );

        asm volatile (
            "mov $60, %%rax;"    // sys_exit
            "xor %%rdi, %%rdi;"  // код 0
            "syscall"
            :
            :
            : "rax", "rdi"
        );
    }
}

Делаем файл команд bmetal.ld линкёру

ENTRY(_start)
SECTIONS
{
    . = 0x400000;
    .text : { *(.text) }
    .rodata : { *(.rodata) }
    .data : { *(.data) }
    /DISCARD/ : { *(.comment) *(.note*) }
}

Компилируем

# 1. Компиляция объектного файла
# -fno-stack-protector критически важен при использовании -nostdlib,
# так как в системе нет стандартной библиотеки для проверки стека.
g++ -c -Os -fno-exceptions -fno-rtti -fno-asynchronous-unwind-tables \
    -fno-stack-protector bmetal.cpp -o bmetal.o

# 2. Линковка с использованием упрощенного скрипта
# -s: Удалить все символы и отладочную информацию (заменяет команду strip)
ld -T bmetal.ld -s bmetal.o -o bmetal_cpp

# 3. Установка прав на исполнение
chmod +x bmetal_cpp

# 4. Запуск готовой программы
./bmetal_cpp

Итого получили файл "C++" размером 4.5 кБ