Уменьшение размера исполняемого файла

[скалогрыз]

...возможно речь об оптимизаторе, а не о линкере. Линкер это программа made

а не "ld"-ли линкер? make лишь запускает его.

[Лекс Айрин]

скалогрыз, что ж, буду знать. Спасибо за уточнение.

[vitaly_l]

Вот так ещё можно было бы решить задачку:

Порядок "компиляции" такой:
1) препроцессинг,
2) ассемблирование,
3) компилирование,
4) линкер.

Адреса (согласно описанию) - задаются на этапе 4) линковки. Однако, после этапа 2) ассемблирования.... по идее, можно запускать: 3) компилятор и 4) линковщик - от любого языка программирования и они всё сделают. Соответственно, можно запустить, этапы: 3) компилятор и 4) линковщик от "турбо паскаля 7" и всё получится. А "турбо паскаль 7" умеет удалять имена, как говорили выше.

Но я не умею, в FPC запускать, отдельно этапы 1-2 и => потом: 3) компилятор и 4) линковщик от других IDE


.

[Лекс Айрин]

Увы, но Ваши способы не дают существенного уменьшения размера файлов.

2) Удаление названий из исполняемого файла (оставить только адреса после линковки).

Да, в процессе разных сегодняшний проверок я нашел как это сделать в Лазаре. Пусть и не полностью, но по возможности близко к этому. Это галочка в свойствах проекта "вырезать символы из исполняемого файла." она дает очень небольшое похудение.

1) Умная обфускация

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

И всего-то нужно надстройку и линковщик написать / оптимизировать.

А как вы будете вмешиваться в процесс компиляции программ? Ведь Ваша надстройка должна будет запуститься после того как будут скомпилированы все модули, но перед компоновкой. Или Вы собираетелсь редактировать exe файл?

Добавлено спустя 17 минут 21 секунду:

Порядок "компиляции" такой:
1) препроцессинг,
2) ассемблирование,
3) компилирование,
4) линкер.

не так.
Лексический анализ,
препроцессинг,
Синтактический анализ,
оптимизация,
компиляция модулей,
оптимизация2 (не всегда),
сборка (линковка)

[vitaly_l]

Лексический анализ,
препроцессинг,
Синтактический анализ,
оптимизация,
компиляция модулей,
оптимизация2 (не всегда),
сборка (линковка)

А где ассемблирование?

Добавлено спустя 1 минуту 57 секунд:

обфускация это сокрытие кода

Я всегда говорю про "умную обфускацию", например как в JS/


.

[Лекс Айрин]

А где ассемблирование?

Компиляция модулей. Сам процесс именно ассемблирования (преобразование в *.asm файл) обычно пропускают, так как это лишь напрасная трата времени. Но, при желании, параллельно иногда можно создать asm-листинг. Уж в FPC точно можно.

Я всегда говорю про "умную обфускацию", например как в JS/

Какая разница? В HEX-редакторе тоже можно рисовать, но это же не значит, что это аналог фотошопа. Есть, кстати, подобный же прикол с архиватором и программой сжатия. Не каждый архиватор сжимает файлы. Несмотря на противоположное мнение. Например, этого не делает tar

[vitaly_l]

параллельно иногда можно создать asm-листинг

Ага... вот от этого: "иногда", кстати - можно попробовать оттолкнуться... и нарисовать картину Репина "Приплыли" прямо в HEX-редакторе...
И можно ли, откомпилировать этот asm-листинг, каким нить сторонним компилятором? Компилятором типа от Турбо Паскаля №7. Можно?
Или любым другим, который умеет, удалять "лишние" названия из исполняемого файла. Можно asm-листинг откомпилировать?


.

[Лекс Айрин]

vitaly_l, при желании, можно и от молнии прикурить. Что бы скомпилировать этот листинг нужно выполнить столько условий, что практически нерентабельно. Нужно:
Привести формат листинга к необходимому ассемблеру (если, конечно, сам компилятор этого не сделал)))
Добавить в файл необходимые ресурсы, которые не присутствуют в асм-тексте (и не факт, что их удастся подключить)
скомпилировать и собрать файл.

ЯВУ ассемблерный текст могут воспринимать максимум как отдельно собранный объектный модуль. Ну или как встроенный asm-оператор.

[pupsik]

Присоединяюсь к Лексу:

Sergei I. Gorelkinугу... что же тогда проги такие тяжелые?

Уж очень интересно почитать..

по поводу LLCL

Провел некоторые тесты. Весьма интересно. Размерчик в 10 раз меньше. Памяти использует в 2, 1,5 раза меньше. Запуск приложения быстрее. Огромный, как для меня, плюс - не надо "париться" как с KOL.
Наблюдаются глюки с формами. Ограниченный (с моей точки зрения хватает) набор компонентов. В принципе можно добавить. Не проверял возможность "импорта" в лин.
Вполне можно использовать для простых вин. утилит.

vitaly_l я, кажись, поспешил с выводом....
обфускация: https://ru.wikipedia.org/wiki/%D0%9E%D0%B1%D1%84%D1%83%D1%81%D0%BA%D0%B0%D1%86%D0%B8%D1%8F
При чем тут размеры и жабка?
По поводу KOL:
1. Он изначально предполагался быть подменой. Т.е. альтернативное мнение.
2. Уж дочитайте книжку. А не вскользь просмотрел быстренько.
3. Альтернативные функции имеют свою особенность. Или вы думаете все гладко было в дельфине?

п.с.
KOL "встраивается" (т.е. лпк файл есть. Возможно вы не из того свн качали, их 2) в лазарь вполне нормально. Со свежей версией лазаря необходима маленькая обработка напильником. Стандарт набор компонентов имеется. Бинарники жирные создаются (в сравнении с дельфином ).
О размерах. Полноценный дбф вьювер с генератором отчетов в 5-ом дельфине в 20 кб это нормально? Учитывая что все визуально с маленьким "рукоблудством". Хотя... 8 метров - куда круче. Дань моде.

[vitaly_l]

возможность "импорта" в лин.

LLCL - только для винды, кто-то выше писал.

обфускация: https://ru.wikipedia.org/wiki/%D0%9E%D0 ... 0%B8%D1%8F
При чем тут размеры и жабка?

Прочитайте, в вике же ясно написано и по Русски: "см. Цели обфускации: Оптимизация программы с целью уменьшения размера работающего кода."

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

Только с целью повышения уровня моих скудных знаний, т.к. автор KOL - безусловно много более сильный программист нежели я, но использование KOL скорее всего уже устарело, т.к. последняя модификация аж 2006 года. А вот: LLCL - каждый день обновляется (вчера видел) и подключать просто, тоже видел. Думаю, для винды, он самое лучшее (наверное), я не пробовал и не тестировал, только посмотрел принцип работы. На днях подключу в проект и посмотрю результат. Потом поделюсь. Жаль что LLCL Линукс не поддерживает.

Присоединяюсь к Лексу:
Sergei I. Gorelkinугу... что же тогда проги такие тяжелые?

Уж очень интересно почитать..

Лазарус КРОСПЛАТФОРМЕННЫЙ... и вставляет СВОИ библиотеки в ЛЮБУЮ программу. А например LLCL, уменьшает тем что, подключает вместо них системные от винды, поэтому с ними проект получается маленьким, и для линуксов это не работает, т.к. там ДРУГИЕ системные библиотеки. Сложно с Вами программистами... всему Вас приходится художникам обучать. В смысле: Хорошего настроения!


.

[pupsik]

только для винды, кто-то выше писал

и..и. Это слова разраба, я их озвучил. Вы думаете мне что то помешает, при необходимости, сделать и для лина?

Оптимизация программы с целью уменьшения размера работающего кода

Мдя..я. Как это касается размера бинарника? Конечно: 5 строк и 10000 повлияют на размер (байт туда, байт сюда ). Но..о в итоге: а воз и ныне там. Да же больше может стать.

Эх..х,. В общем:
1. Кол в свн - вчера обновилось. по идее, сейчас не 2006. Обновилась дельфийская версия.
2. LLCL - не давно выложен. Если не ошибаюсь. И это клон. Уже 6-ой день не обновлялось
По поводу вашей "идеи о размере". В принципе доля истины есть. Но..о, чутка не то.

п.с.
Зачем "скрываться" в художниках?

[vitaly_l]

Кол в свн - вчера обновилось

Я смотрел на его сайте, возможно даты на сайте устарели. Тогда беру свои слова обратно. KOL - поддерживается. Нужно смотреть.

LLCL - не давно выложен. Если не ошибаюсь. И это клон. Уже 6-ой день не обновлялось

Вчера смотрел на гитхабе кажется, там всё новенькое было, только только обновлённое.

Зачем "скрываться" в художниках?

я не скрываюсь, я действительно по образованию художник. А программирование для меня на 77% - средство выживания.

Добавлено спустя 11 минут 11 секунд:

Вы думаете мне что то помешает, при необходимости, сделать и для лина?

Вам возможно это и легко, а для меня это не реально, т.к. я принцип понимаю, но не более того (моих знаний не хватит).


.

[pupsik]

Мдя..я: ошибся. Последний ап - 25.08.15 Но..о это дельфийская версия.
http://sourceforge.net/p/kolmck/code/HEAD/tree/

Вам возможно это и легко

я не писал легко или нет. Я писал: при необходимости. Это малость иное "направление"...

[SSerge]

А например LLCL, уменьшает тем что, подключает вместо них системные от винды

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

4) линковщик от "турбо паскаля 7" и всё получится. А "турбо паскаль 7" умеет удалять имена, как говорили выше.

Опс! А ничего, что модели линковки в DOS и Windows совершенно разные? А ничего, что в TP в принципе нет ни классов, ни соответствующих им полей "published" (тех самых, имена которых в истинной форме в обязательном порядке присутствуют в исполняемом коде)? И вообще, имена и код TP умеет удалять только свои. А вот где начинается "стандартный объектный код" (в windows файлы с расширением .OBJ), здесь действует следующее правило: имена переменных здесь еще есть (классов, кстати, уже нет - модель и формат объектного файла на них вообще не рассчитанаы, и каждый класс рассыпается на набор функций и полей, закодированных чуднЫм образом), а таблиц взаимозависимостей - уже нет. И последняя стадия сборки каждый объектный файл в готовый проект вставляет только целиком и никак иначе. Так что по сути дело не в сборщике, а в той стадии, которая выбирает функции и классы из библиотек языка внутреннего формата (aka .TPU, .FPU и прочих подобных; в Visual C++ для этого делается грандиозный файл кросс-линков, который в несколько раз больше самого проекта и по которому именно делается оптимизация, фоновая перекомпиляция и прочее). И только тут возможно выбросить лишний код. Кстати, именно по озвученной причине в Си принято аж с самого рождения языка исходник каждой функции записывать в отдельный файл. Иначе, получается ситуация, когда в файле например 100 независимых функций, из них используется только одна, а поскольку правило: исходный файл -> объектный файл - к финальному проекту, использующему эту одну функцию, будет прилинкован весь мертвый код остальных 99-ти.

С точки зрения сокращения размера загрузочного файла... Ну-с, в том же Linuks g++ (gcc), загрузочный файлы в целом обычно меньше, чем у fpc. Однако, если посмотреть, у них по умолчанию динамическая линковка с кучей системных библиотек. У C# и JAVA размер загрузочных файлов аналогичного с лазарусовским функционала в десятки раз меньше того, что генерирует Lazarus, но: не забываем о cистемных библиотеках исполняющей среды и саму исполняющую среду, сопровождающую такие программы.

imho, если сбудется "мечта" о динамической линковке рунтайма лазаруса, это похоронит его нынешнее достоинство - "везу весь свой код на себе, в одной программе - и буду независим", и создаст кучу проблем.

[sign]

Ошибка