UPX 3.xx, the Ultimate Packer for eXecutables |
Добро пожаловать, гость ( Вход | Регистрация )
UPX 3.xx, the Ultimate Packer for eXecutables |
-=CHE@TER=- |
May 27 2007, 17:58
Сообщение
#1
|
Walter Sullivan Группа: Root Admin Сообщений: 1,360 Регистрация: 4-February 08 Пользователь №: 3 Спасибо сказали: 313 раз(а) |
UPX
Вышел UPX 3.00. Всем советую его качать и использовать. Из особенно понравившихся нововведений: 1) Почему-то некоторые .EXE файлы стали лучше жаться (по сравнению с 1.24w (*улыбается*)). Что не может не радовать. 2) Появилась опция "--exact" пакует файл так, что после распаковки ("-d") он в точности байт-в-байт совпадает с тем, что было перед запаковкой (если этот ключ не указать, то файлы оригинальный и распакованный будут во многих байтах различаться). Для интереса сжимал разные программы с и без этого ключа - на сжатии никак не отражается (в сжатом виде одинаково занимают), так что буду его использовать. 3) Появился ещё один мега ключ "--lzma", который для особо толстых .EXE файлов использует алгоритм сжатия LZMA (от 7zip надо полагать). И правда пакует куда лучше, но пригодится только для толстых, от 500 Кб и больше (может и меньше - зависит от файла), программ т.к. на мелких файлах готовый .EXE получится больше, чем если эту опцию не использовать (т.к. в код запакованного .EXE добавляется алгоритм распаковки LZMA, который нехило весит). Ну и, конечно, памяти LZMA для работы потребует больше... В общем, все кто ещё не разжился 3-ей версией - вперёд! а) Для обычных файлов делаем так: upx -9 --exact filename.exe б) А для особо толстых файлов так: upx -9 --lzma --exact filename.exe Насчёт LZMA: .EXE файл от простой программы на Delphi 7 CODE Begin End. Занимает 12800 байт (со стрипнутыми Reloc'ами). Обычное сжатие сделает из него 8704 байта. LZMA сделает 10752 байта. Выводы делайте сами - чистых 2 Кб довеска при LZMA. Так что тренируйтесь лучше на толстых файлах. (*улыбается*) |
-=CHE@TER=- |
May 31 2007, 15:22
Сообщение
#2
|
Walter Sullivan Группа: Root Admin Сообщений: 1,360 Регистрация: 4-February 08 Пользователь №: 3 Спасибо сказали: 313 раз(а) |
С UPX 3.00 вышла такая шткуа:
Пакую им .EXE файл от Scorcher DEMO с опцией "--exact", но после распаковки начиная с 00092A10 до 00098113 включительно, в 800-ах байтах есть различия. Так что "--exact" тут получается не полный. Создал у них отчёт об ошибке. Интересно, что скажут. |
jTommy |
May 31 2007, 16:05
Сообщение
#3
|
Наблюдающий Группа: CTPAX-X Сообщений: 197 Регистрация: 4-February 08 Из: деревня Москва Пользователь №: 6 Спасибо сказали: 19 раз(а) |
|
-=CHE@TER=- |
Jun 2 2007, 13:20
Сообщение
#4
|
Walter Sullivan Группа: Root Admin Сообщений: 1,360 Регистрация: 4-February 08 Пользователь №: 3 Спасибо сказали: 313 раз(а) |
Да ладно тебе - это не офтопик.
На самом деле не сжатие с потерями, а сжатие с игнорированием какой-то информации. Т.е., видимо, в UPX записан алгоритм, по которому восстанавливаются какие-то структуры. Другое дело, что Scorcher - старая игра и Windows-версия написана на WATCOM C++, который очень кривой для написания на нём под Windows ("чистый" .EXE без упаковки UPX'ом - только под Windows 9x запускается, иначе говорит, что это вообще не Windows-приложение). Обрати внимание, что расхождение байтов именно в хвосте файла. Похоже на то, что какие-то ресурсы "перепаковываются". На работоспособности, вроде, никак не отражается, но досадно, что изменяет файл, хотя ключ "--exact" и указан. |
Xplorer |
Jun 4 2007, 16:57
Сообщение
#5
|
Advanced Member Группа: CTPAX-X Сообщений: 52 Регистрация: 4-February 08 Пользователь №: 8 Спасибо сказали: 30 раз(а) |
В новой версии также появились ключи --brute и --ultra-brute. При их использовании UPX переберёт все возможные комбинации алгоритмов сжатия и фильтров и выберет ту, для которой размер файла после сжатия будет минимальным.
|
-=CHE@TER=- |
Jun 4 2007, 21:16
Сообщение
#6
|
Walter Sullivan Группа: Root Admin Сообщений: 1,360 Регистрация: 4-February 08 Пользователь №: 3 Спасибо сказали: 313 раз(а) |
В новой версии также появились ключи --brute и --ultra-brute. При их использовании UPX переберёт все возможные комбинации алгоритмов сжатия и фильтров и выберет ту, для которой размер файла после сжатия будет минимальным. Спасибо! Правда --ultra-brute дико долго перебирает - проще так попробовать -9 с lzma или обычным сжатием. (*улыбается*)Кстати, в баг-трекере сам Laszlo Molnar ответил: QUOTE Actually this is a bug in the documentation. The "--exact" option is not implemented yet for the formats for which it was invented. Laszlo |
-=CHE@TER=- |
Jun 19 2007, 17:32
Сообщение
#7
|
Walter Sullivan Группа: Root Admin Сообщений: 1,360 Регистрация: 4-February 08 Пользователь №: 3 Спасибо сказали: 313 раз(а) |
Хех, Markus F.X.J. Oberhumer отписался в виде "Что пристал? не видишь - работаем":
QUOTE --exact is work in progress. The docs have been updated for 3.01. и отчёт об ошибке был успешно закрыт. (*улыбается*) Надеюсь, доведут эту штуку до ума. Полезная. |
-=CHE@TER=- |
Aug 11 2007, 14:10
Сообщение
#8
|
Walter Sullivan Группа: Root Admin Сообщений: 1,360 Регистрация: 4-February 08 Пользователь №: 3 Спасибо сказали: 313 раз(а) |
Вышла версия 3.01 (ссылка в первом посте).
Берём файл "upx.doc" и читаем (в квадратных скобках то, что добавили): QUOTE --exact: when compressing, require to be able to get a byte-identical file after decompression with option -d. [NOTE: this is work in progress and is not supported for all formats yet. If you do care, as a workaround you can compress and then decompress your program a first time - any further compress-decompress steps should then yield byte-identical results as compared to the first decompressed version.] Я торчу. (*улыбается*)И ещё, а жесть!!!, я получаю при попытке упаковать "Scor95.exe" (upx.exe -9 --exact Scor95.exe) вот такое сообщение: QUOTE upx: Scor95.exe: CantPackException: option '--exact' does not work with this file По истине универсальное решение: нет поддержки - нет проблем! (*улыбается*)Что-то мне подсказывает, что его поддержку они если и введут, то очень не скоро (если вообще введут)... Так что пока остановлюсь на 3.00. |
Grom PE |
Oct 11 2007, 00:32
Сообщение
#9
|
Advanced Member Группа: CTPAX-X Сообщений: 84 Регистрация: 7-February 08 Из: i@grompe.org.ru Пользователь №: 3,120 Спасибо сказали: 95 раз(а) |
Нашел в upx.exe недокументированный параметр --small — использовать распаковщик на 44 байта меньшего размера =)
|
angeld29 |
Aug 29 2008, 08:06
Сообщение
#10
|
Newbie Группа: CTPAX-X Сообщений: 3 Регистрация: 28-August 08 Пользователь №: 11,486 Спасибо сказали: 5 раз(а) |
зачем вообще паковать исполнимые файлы?
винты сейчас достаточны большие, основной объем это все равно ресурсы, а не испольнимый файл, а для передачи по интернету лучше паковать в обычный архив экономя место на диске увеличиваем расход оперативной памяти при запуске в случае DLL файлов расход памяти в разы увеличивается, для каждого приложения использующего dll создается своя копия DLL в памяти |
-=CHE@TER=- |
Aug 29 2008, 09:22
Сообщение
#11
|
Walter Sullivan Группа: Root Admin Сообщений: 1,360 Регистрация: 4-February 08 Пользователь №: 3 Спасибо сказали: 313 раз(а) |
зачем вообще паковать исполнимые файлы? Возможно, в случае Си-программ основной размер это ресурсы, а в случае Delphi - шлакокод, обрабатывающий всякие эксепшины и прочий хлам. Grom PE, кстати, сделал замену системных модулей, чтобы конечные файлы практически ничего не занимали (7 Кб против стандартных 40 Кб у консольной программы - ощутите разницу, хотел сделать на FASM'е ещё меньше, но передумал - работы много (*улыбается*)). Кстати, большинство программ на сайте сейчас ничем не упаковано т.к. как раз используется замена системных модулей.винты сейчас достаточны большие, основной объем это все равно ресурсы, а не испольнимый файл, а для передачи по интернету лучше паковать в обычный архив экономя место на диске увеличиваем расход оперативной памяти при запуске Про размер оперативной памяти - согласен. Однако, если программа отработала и выгрузилась (т.е. не торчит в оперативной памяти 24/7) - то, по мне, лучше уж пусть она упакованная лежит, ибо большие жёсткие диски, увы, не у всех есть. в случае DLL файлов расход памяти в разы увеличивается, для каждого приложения использующего dll создается своя копия DLL в памяти Полностью согласен. Поэтому .DLL никогда не пакую. Тут, кстати, есть ещё одно проблема - пакованные .DLL плохо себя чувствуют под wine - народ жаловался, что работать с ними нельзя. |
angeld29 |
Aug 29 2008, 14:50
Сообщение
#12
|
Newbie Группа: CTPAX-X Сообщений: 3 Регистрация: 28-August 08 Пользователь №: 11,486 Спасибо сказали: 5 раз(а) |
QUOTE Возможно, в случае Си-программ основной размер это ресурсы, а в случае Delphi - шлакокод, обрабатывающий всякие эксепшины и прочий хлам. Grom PE, кстати, сделал замену системных модулей, чтобы конечные файлы практически ничего не занимали (7 Кб против стандартных 40 Кб у консольной программы - ощутите разницу, хотел сделать на FASM'е ещё меньше, но передумал - работы много (*улыбается*)). Кстати, большинство программ на сайте сейчас ничем не упаковано т.к. как раз используется замена системных модулей. Про размер оперативной памяти - согласен. Однако, если программа отработала и выгрузилась (т.е. не торчит в оперативной памяти 24/7) - то, по мне, лучше уж пусть она упакованная лежит, ибо большие жёсткие диски, увы, не у всех есть. я имел ввиду не ресурсы exe а другие фалы которые идут с программой если игра занимает dvd, то экономить 30кб на exe просто смешно и если в дельфи все так плохо со стандартным кодом, то тем более его паковать не надо чтобы при запуске он весь в память не грузился в винде есть такая штука как FileMapping, в оперативной памяти только то что использовалось а в случае упакованного exe он весь загружается PS. сейчас купить диск для которого будет критичен размер exe нереально |
Упрощённая версия | Сейчас: 30th September 2024 - 10:08 |