Win32, assember (MASM32). Я перепробовал много вариантов, даже подставлял свою собственную stub-заглушку вместо станартной (той, что выводит "This program cannot be run in DOS mode"). Но все равно, меньше 1.5 КБ файлы не получаются. Неужели это ограничение нельзя никак обойти? (Вот, кстати, что получилось: http://dklab.ru/chicken/nablas/27.html).

Второй вопрос связан с первым. Дело в том, что ассемблер - не единственное средство написания сверхмалых программ. Как-то давно я заставил Turbo C 1.0 делать COM-файлы размером от 100 байт, и при этом можно было реально писать на Си (конечно, без прибамбасов, но язык был полностью нормальным). Тогда это делалось при помощи замены c0.obj на свой собственный (пустой). Вопрос: нельзя ли что-то подобное проделать с MSVC? Или с каким-нибудь другим Си-компилятором?

set MASM=C:\masm32
set DIR=Obj
set INCLUDE=%INCLUDE%;%MASM%
set LIB=%LIB%;%MASM%\lib

del %PROG%.exe 2>nul
mkdir %DIR% 2>nul

%MASM%\BIN\ML.EXE /nologo /c /coff /Zd /Fo%DIR%\%PROG%.obj
main.asm
%MASM%\BIN\LINK.EXE /nologo /PDB:NONE /SUBSYSTEM:%SUBSYS%
%DEBUG% /Out:%DIR%\%PROG%.exe %DIR%\%PROG%.obj

copy %DIR%\%PROG%.exe %PROG%.exe >nul 2>nul
pause


(взято из http://dklab.ru/chicken/nablas/27.html)
То есть это именно этот командный файл.
Как я понял.
Единственное, что я постоянно практикую это /FIXED ключик, который убирает лишний reloc раздел, если он конечно есть.

Иногда это помогает.

Момент 1.
Это не ограничение, а следствие формата ПЕ...

Момент второй -- выравнивание.
К сожалению у различных Виндовс к нему различные требования.
:(((
Под 98 значения ниже 16 (кажется так) не прошли.
А под 2000 даже очень хорошо работает.

Момент 3:

Это вызов Win32 функций через шлюзы, а не через заглушки.
Но думаю это не намного уменьшит код.

Второй вопрос
Я так понимаю дело сводится к выключению c runtime library.

#pragma comment(linker,"/ENTRY:main /FILEALIGN:0x200 /MERGE:.data=.text /MERGE:.rdata=.text /SECTION:.text,EWR /IGNORE:4078")

Не помню уже откуда.

Написание экстра-маленьких Win32 приложений на С++

У y0da был пример. Есть пара статей Питрека на эту тему.

Dmitry_Koteroff

Вопрос: нельзя ли что-то подобное проделать с MSVC? Или с каким-нибудь другим Си-компилятором?


Это оччень больная тема :(

Дело в том, что линкёр в пакете VC Особенный... (не могу сказать другое :))

Он генерирует минимальные asm файлы например на 1 или 2 kb больше.
Никак не могу с этим справится.

Как только использую ликёр из MASM 32
Получаю обычный размер.
Может наконец кто-то решит этот ворпос!!!

Ну не дизасмить же этот чёртов link.exe!!!

А насчёт VC? если докапаетесь как избавится от RunTimeLib то... всё OK.

Four-F
Перекрёстный вопрос:
/IGNORE:4078
Подробнее.. (может в этом причина?)

Елки-палки, так это же просто супер! Спасибо огромное — то, что надо!

Программа:

#include <windows.h>
#pragma comment(linker,"/MERGE:.rdata=.text")
#pragma comment(linker,"/FILEALIGN:512 /SECTION:.text,EWRX /IGNORE:4078")
#pragma comment(linker,"/ENTRY:New_WinMain")
#pragma comment(linker,"/NODEFAULTLIB")

void New_WinMain(void) {
MSG msg; // ииии...... поехали крутиться......
while(GetMessage(&msg,NULL,0,0)) {
TranslateMessage(&msg);
DispatchMessage(&msg);
}
ExitProcess(0);
}

Далее создаем новый пустой проект (Win32 application), именно пустой! Добавляем туда этот файл. Переключаемся в режим Release. Идем в Options и включаем там Debug information - Program database. Ставим Optimize for size. Ставим Debug info в опциях линкера (если нужно; это увеличивает размер EXE-шника, но зато позволяет трассировать программу). Все! Размер EXE-шника - ровно 1 КБ.

Черт, как тут код вставлять по-нормальному...

Да, я тут еще чуть-чуть этот вопрос поисследовал. Оказывается, не надо Release превращать в Debug. Достаточно просто взять настройки Debug-а и убрать вручную там /GZ (как это сделать через меню, я не нашел - похоже, вообще никак нельзя сделать; редактируйте текст командной строки в окошке настроек, там он есть и подхватывается). После этого программа начинает линковаться и в Debug-е; правда, размер ее - более 50 КБ. Для уменьшения размера Debug-а можно поставить не Program database for edit & continue, а просто Program Database (размер уменьшается до 11 КБ, а на отладке это в разумных случаях не сказывается). Естественно, в Release размер EXE-шника по-прежнему 1 КБ.

Еще можно включить Optimize for Size, fastcall вместо stdcall (насколько я понимаю, через регистры сподручнее будет, чем через стек), ну и процессор сменить с pentium на 486 (или даже на 386) - для лучшей совместимости.

Все, пишу еще одну статью (-;

Написал:
http://dklab.ru/chicken/nablas/28.html

Спасибо. Тему можно в архив (если тут такой есть).

[ Edmond: /IGNORE:4078
Подробнее.. (может в этом причина?) ]

Если сливаешь секции PE с разными атрибутами, этот флаг нужен для подавления предупреждения линкера LNK4078.
Насчет причины не понял. Если ты имеешь ввиду влияние на размер, то нет - на размер это никоим образом не влияет.

И вот ещеTechniques for reducing Executable size

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

Тоже отличная статья.

Почему fastcall — изврат? Насколько я понимаю, он заставляет передавать параметры через регистры. Это довольно удобно должно быть, и, главное, красиво (если потом дизасемблировать). Правда, может, ему зехочется запушить регистры в стек для сохранения, что увеличит размер...

Честно говоря я подробно не знаю что эта опция делает (да и ты похоже тоже ;-) ) и разбираться с этим лень, но так думаю что переводит юзерные функции из stdcall в fastcall. Хотя хз, запросто может быть и не так.
В любом случае из всех call'ов в программах подавляющее их большинство приходится на API. А это в любом случае stdcall.
Потом нет никакой гарантии, что размер при fastcall уменьшится, это же не smallcall ;-) Может как раз все наоборот произойти.

Потом на машине даже с маленьким винтом, например 5Гб, при fat32 размер кластера 4Кб. Так что хоть твоя прога один кб, хоть два - ничего не меняет. А про более емкие винты я вообще молчу.

Да и впамяти она меньше страницы тоже не займет, те же 4кБ.

Да и вообще нет никакого смысла до посинения оптимизировать размер, т.к. объем физической памяти выделяемой Windows при создании процесса похоронит любую оптимизацию. Какая разница сколько твой процесс отожрет - 500кБ или 501кБ? Вобщем мораль - оптимизируй да знай меру ;-)

Да, она «переводит юзерные функции из stdcall в fastcall». Рассуждения про API совершенно верные, я над этим не задумывался. Значит, действительно, выигрыш (возможный) минимален.

Что касается того, «зачем оптимизировать» — это уже дзэн, я писал об этом в статье.

Вроде как у FASM минимальный размер экзешника - 1Kb...

Dmitry_Koteroff
Значит, действительно, выигрыш (возможный) минимален.
======================================================
Этот выйгрышь полностью зависит от оптимизатора.
Во всяком случае рекомендация такая:
fastcall хорошо для небольших функций с малым числом параметров.
(лучше 2)