Comments 47
Не выгоднее ли (проще, больше выигрыш в объёме файла) просто запаковать бинарники UPX?
У упаковщиков таких как UPX есть минусы из-за которых ими пользоваться не всегда удобно:
Выигрыш от использования UPX только при запуске программ с DVD или сетевого диска — т.е. там где медленная скорость доступа, более маленький exe файл скорее попадет в оперативную память.
В случае же который описан в статье распаковка ресурсов происходит непосредственно в момент создания нужной формы, и после создания ее буфер с распакованными данными освобождается.
- Файл может дольше запускаться за счет увеличенного времени сканирования антивирусом (ему нужно распаковать сначала файл)
- В занимаемой памяти выигрыша нет, она разворачивается полностью
- Опять же при запуске начинается распаковка ВСЕГО приложения что занимает время
Выигрыш от использования UPX только при запуске программ с DVD или сетевого диска — т.е. там где медленная скорость доступа, более маленький exe файл скорее попадет в оперативную память.
В случае же который описан в статье распаковка ресурсов происходит непосредственно в момент создания нужной формы, и после создания ее буфер с распакованными данными освобождается.
… а если мы создаем одну форму n раз, у нас будет n раз распаковка происходить?
Файл может дольше запускаться за счет увеличенного времени сканирования антивирусом (ему нужно распаковать сначала файл)
Вообще-то, антивирусу нужно проверять все, что упаковано. Так что, если ваше приложение станет достаточно популярным, антивирусы начнут распаковывать и его для проверки. В ресурсах формы вполне можно прятать бинарник :)
А как на это антивирусы будут реагировать? Проверяли?
АВАСТ, он вообще подозрительно относится к любой незнакомой программе — скомпилировал и все, через песочницу запуск… поэтому у разработчиков папка с проектами находится в исключениях антивируса, а для простого смертного такая утилита попросту бесполезна. Я думаю, такая программа у параноидального антивируса будет помещена сразу в карантин, без вопросов… в остальных случаях — либо будет каждый раз спрашивать с подозрением на вирус перед патчем файла либо блокировать доступ к файлу.
Конечно, с уже пропатченным файлом проблем нет — он же не выполняет никаких подозрительных действий — точно так же обращается к ресурсам и т.д. по поведению ничем не отличается от оригинального.
Конечно, с уже пропатченным файлом проблем нет — он же не выполняет никаких подозрительных действий — точно так же обращается к ресурсам и т.д. по поведению ничем не отличается от оригинального.
Не всем антивирусам нравится UPX — потому что им часто упаковывают вирусы. Так что программу, предназначенную для широкого распространения, лучше в UPX не заворачивать. Тем более, что сетап все равно все сожмет по-максимуму.
Эта тулза стала бы реально полезной, если бы сама «учила» любую VCL программу распаковывать свои ресурсы, т.е. подменяла бы InternalReadComponentRes. Но это, конечно, непростая задача.
У BilleniumSoft был готовый продукт — Citadel для сжатия и шифрования DFM-ок в Delphi программах. Последняя поддерживаемая версия судя по информации на сайте — Delphi 2009.
п.с. fyi
п.с. fyi
Все таки использование DFM компрессора спорная вещь.
Так же было бы неплохо какую то статистику показать этого метода.
Ну например разницу между сжатым и не сжатым и 3 варианта:
1) Пустая форма
2) Штук 10-20 разных контроллов
3) Пару картинок на форме.
И еще вопрос — необходимость подключение модуля Zlib не приведет ли к нивелированию размере?
Так же было бы неплохо какую то статистику показать этого метода.
Ну например разницу между сжатым и не сжатым и 3 варианта:
1) Пустая форма
2) Штук 10-20 разных контроллов
3) Пару картинок на форме.
И еще вопрос — необходимость подключение модуля Zlib не приведет ли к нивелированию размере?
На формах с ресурсами в виде картинок на кнопках и других компонентах выигрыш будет огромным. В остальном же… делфи сама умеет DFM-ки хранить в двоичном виде!
>>У упаковщиков таких как UPX есть минусы из-за которых ими пользоваться не всегда удобно:
>> Файл может дольше запускаться за счет увеличенного времени сканирования антивирусом (ему нужно распаковать сначала файл)
>> В занимаемой памяти выигрыша нет, она разворачивается полностью
>> Опять же при запуске начинается распаковка ВСЕГО приложения что занимает время
Если программа запускается на 486DX или Pentium 100, то да, можно заметить замедление при запуске, на процессорах в 1GHz на проверку антивирем и распаковку уходят доли секунды, конечно при условии что Ваш EXE'шник имеет не сильно большой размер, до 50 Mb.
Сколько программа занимает в памяти опять же не важно при текущем уровне развитя техники, 1 гиг памяти сейчас есть даже на самых простеньких ПК, а то что программа сожрет 5 или 15 Mb ОЗУ это мелочи. Если уж озадачиваться расходом памяти, то тогда нужно писать на Delphi 7, для сравнения EXE'шник с голой формой на D7 занимает 370 Kb на диске и 1,3 Mb ОЗУ, на последнем XE7 — 2,2 Mb на диске и 1,6 Mb ОЗУ — цифры говорят сами за сябя.
>> Файл может дольше запускаться за счет увеличенного времени сканирования антивирусом (ему нужно распаковать сначала файл)
>> В занимаемой памяти выигрыша нет, она разворачивается полностью
>> Опять же при запуске начинается распаковка ВСЕГО приложения что занимает время
Если программа запускается на 486DX или Pentium 100, то да, можно заметить замедление при запуске, на процессорах в 1GHz на проверку антивирем и распаковку уходят доли секунды, конечно при условии что Ваш EXE'шник имеет не сильно большой размер, до 50 Mb.
Сколько программа занимает в памяти опять же не важно при текущем уровне развитя техники, 1 гиг памяти сейчас есть даже на самых простеньких ПК, а то что программа сожрет 5 или 15 Mb ОЗУ это мелочи. Если уж озадачиваться расходом памяти, то тогда нужно писать на Delphi 7, для сравнения EXE'шник с голой формой на D7 занимает 370 Kb на диске и 1,3 Mb ОЗУ, на последнем XE7 — 2,2 Mb на диске и 1,6 Mb ОЗУ — цифры говорят сами за сябя.
Стандартная библиотека раздута?
Помню, где-то была статья о helloworld в несколько килобайт.
Помню, где-то была статья о helloworld в несколько килобайт.
Для Delphi была (да и сейчас есть), довольно забавная штука — KOL Ее главная идея была, в том, что большая часть стандартных библиотек была переписана на ASM-е. В результате можно было писать программы на Delphi (ну с некоторыми нюансами конечно) в несколько килобайт. Я даже для нее когда то писал примеры, с Socket-ом например…
Беда KOL-а в скудной функциональности и непонятных ошибках на ровном месте. Когда-то пытался тоже использовать… слишком много шаманства нужно чтобы писать приложения с помощью этих библиотек.
Согласен. функциональность уступает VCL со всеми ее расширениями. Что то сложное на нем писать было конечно трудно, но всякую приятную мелочь — где от малого размера приложения получалось дополнительное эстетическое наслаждение — очень даже! ))
Вроде бы, они там использовали чуть ли не свой exception-driven псевдокод.
(Имеется ввиду, ошибочный опкод x86, за которым следовало несколько байт псевдокода, который был короче, чем аналогичный по функциональности x86). Обработчик исключения ловил эту ошибку, считывал псевдокод и выполнял его.
Особенно экономилось место на вызовах функций, т.к. аргументы для Push и Call сильно оптимизировались за счёт применения локальных таблиц этих самых переменных.
(Имеется ввиду, ошибочный опкод x86, за которым следовало несколько байт псевдокода, который был короче, чем аналогичный по функциональности x86). Обработчик исключения ловил эту ошибку, считывал псевдокод и выполнял его.
Особенно экономилось место на вызовах функций, т.к. аргументы для Push и Call сильно оптимизировались за счёт применения локальных таблиц этих самых переменных.
Скорей всего, раздута не библиотека а архитектура такая что компилятор не может однозначно решить использует ли приложение какой-то код из библиотеки или нет, особенно из системных функций. Где-то произошел просчет в основах реализации ООП…
Раздута именно библиотека (и это не просчет в основах реализации ООП — это RTTI, без которого ООП не получится).
Не подключаете Forms — и будет экзешник в десятки килобайт, не подключаете SysUtils — еще меньше. Но придется самому реализовывать message loop и рисовать окошки через WinApi.
Не подключаете Forms — и будет экзешник в десятки килобайт, не подключаете SysUtils — еще меньше. Но придется самому реализовывать message loop и рисовать окошки через WinApi.
Не подключаете Forms — и будет экзешник в десятки килобайт, не подключаете SysUtils — еще меньше
Но отказаться от system уже не так просто. Хотя и можно.
Использовал StripReloc (http://www.jrsoftware.org/striprlc.php), потом поверх него UPX. StripReloc удалял неиспользованные ресурсы. По причине малой экономии размера программы при обрезании StripReloc, по сравнению с UPX -> теперь только UPX использую.
К слову, на P-166 (моем первом, медленном компьютере) программы, сжатые ASPack/UPX/и.т.д. запускались по времени одинаково с незапакованными. Из этого сделал вывод, что такой параметр, как время на распаковку, можно не учитывать.
Бесплатность UPX хорошо сказалась на его использовании.
Интересно как в комментариях люди реагируют на статью. Я считаю, что пример интересный.
К слову, на P-166 (моем первом, медленном компьютере) программы, сжатые ASPack/UPX/и.т.д. запускались по времени одинаково с незапакованными. Из этого сделал вывод, что такой параметр, как время на распаковку, можно не учитывать.
Бесплатность UPX хорошо сказалась на его использовании.
Интересно как в комментариях люди реагируют на статью. Я считаю, что пример интересный.
Не знаю как в 2010, но вроде была возможность сохранять dfm как бинарник, а ни как текст. Это уже и сжатие данных.
Хотя пример работы с перехватом стандартной функции действительно интересный.
Хотя пример работы с перехватом стандартной функции действительно интересный.
Как выше уже писали, если изначально все DFM-ки держать в бинарниках то они выпадают из системы контроля версий, т.е. все изменения на формах(а это например SQL-запросы в визуальных компонентах размещенных на формах) не будут отражены в проекте.
Почему выпадают? Ну, допустим, diff внятный сделать не получится, но разницу-то учесть в с.к. версий можно.
Учесть… а смысл если не сможешь прочитать что там изменилось?
Комментарий к коммиту?
Смысл? Откатить, очевидно, при необходимости.
Смысл? Откатить, очевидно, при необходимости.
откатить можно и из резервной копии(по сути так оно и будет т.к. файл будет включен в СКВ полностью как двоичный), важнее понять какие изменения произошли из-за чего нужно делать откат.
Тогда и исходники можно откатывать из резервной копии. Зачем, если есть скв?
diff тоже не всегда поможет — опустим, одну иконку в hex заменили на другую. Как понять, что где?
Сложно представить, где может не хватит комментария к коммиту, который описывает изменения.
важнее понять какие изменения произошли из-за чего нужно делать откат.
diff тоже не всегда поможет — опустим, одну иконку в hex заменили на другую. Как понять, что где?
Сложно представить, где может не хватит комментария к коммиту, который описывает изменения.
Будет хотябы понятно что изменили иконку и кто это сделал, а не просто «что-то изменилось».
Revision xyz: dev: changed icon X to Z. Date: xxyyzz Author: xyz.
Комментарии должны объяснять «почему это сделано» а не «что сделано».
С чего бы это? Кому должны?
Если я коммичу десяток файлов, измененных для какой-то фичи, я напишу, что сделано (добавлена фича xyz), а не почему. Мало ли почему добавлена… захотелось.
Если я коммичу десяток файлов, измененных для какой-то фичи, я напишу, что сделано (добавлена фича xyz), а не почему. Мало ли почему добавлена… захотелось.
Здесь уже уклон в организацию работы есть и поэтому будет сложнее объяснить. Например, есть проекты, где коммит должен быть привязан к задаче/багу из какого-нибудь redmine-a и за «захотелось» можно получить по рукам. Плюс если коммит затрагивает много файлов, удобнее же написать «Реализовано пимпу «Зделать зашибись»», а то что в dfm-ке для этого поменяны свойства пары дополнительных контролов — это уже детали. Какие могут понадобиться через полгода, а могут и не понадобиться.
Повторюсь — организация работы в проектах разная. Многим удобнее, когда все что может быть текстом (ресурсы, dfm-ы, скрипты для создания и изменения базы данных и прочее) представлено текстом. Особенно в системе контроля версий.
Повторюсь — организация работы в проектах разная. Многим удобнее, когда все что может быть текстом (ресурсы, dfm-ы, скрипты для создания и изменения базы данных и прочее) представлено текстом. Особенно в системе контроля версий.
И на каждый чих делать коммит?
В случает текстового dfm-a diff поможет не всегда. В случае бинарного — никогда.
Да и массово заменить tbutton на tmybutton тоже будет сложнее.
Да и массово заменить tbutton на tmybutton тоже будет сложнее.
Ага, вот это уже реалистичный сценарий, спасибо.
Пожалуйста :)
Мне когда-то очень легко дался в одном проекте переход из одного набора компонент на другой (конкретно — из IBX на FIBPlus) как раз потому, что можно было массово заменить TIBQuery на TpFIBQuery (ну и остальные компоненты так же). Сердечно поблагодарив старшего программиста за предусмотрительность после того случая всегда храню dfm-ки в текстах.
Мне когда-то очень легко дался в одном проекте переход из одного набора компонент на другой (конкретно — из IBX на FIBPlus) как раз потому, что можно было массово заменить TIBQuery на TpFIBQuery (ну и остальные компоненты так же). Сердечно поблагодарив старшего программиста за предусмотрительность после того случая всегда храню dfm-ки в текстах.
Внутри exe dfm всегда в двоичном виде.
А хранить исходный dfm в двоичном виде есть смысл разве что если стоит цель причинить себе страдания.
А хранить исходный dfm в двоичном виде есть смысл разве что если стоит цель причинить себе страдания.
Sign up to leave a comment.
Сжатие DFM ресурсов в Delphi программах