>Хреново он работает: распаковывает бинарник в /tmp, потом запускает. >Гораздо правильней было бы распаковывать прямо в память, а потом >передовать туда управление.
ты, наверное, только под дос программировал... на крайняк -- под винду :))
под линухом так -- нельзя ( в доках к упксу, кстати, про это написано). к тому же, учитывая наличие всяких дисковых кэшей, сильно подозреваю, что все по-любому останется в памяти...
>Посему - в топку, ибо bzip2/gzip/rar/7z рулят куда больше.
> Тогда начни с подбора старых версий хксов и всего остального. Которые были рассчитаны на такую среду.
иксы то меня как раз слабо волнуют, я их обрезал достаточно неплохо, а вот с Qt4 не знаю что делать, занимают много, а делать свой конфиг для урезанной сборки Qt... я ж пока и сам не знаю, что из него использовать будут...
Вообще тогда можно пойти двумя путями - пытаться отхачить Makefile'ы при сборке qt на тему повставлять приведенные анонимусом
`strip --strip-unneeded -R .comment -R .note *` или же если программа использующая qt будет одна - собрать программу статично с либами qt (только qt сам должен быть статично собран).Потом опять strip на получившийся здоровенный бинарь ну и пожать еще все upx'ом.
В любой POSIX системе можно подгрузить презагружаемую библиотеку которая заменит open() и т. д. на их декомпрессующие при необходимости аналоги, в том числе у загрузчика. Когда у меня был диск 80Mb -- использовал такое под Linux. Называлось libz или около того.
>>Хреново он работает: распаковывает бинарник в /tmp, потом запускает. >Гораздо правильней было бы распаковывать прямо в память, а потом >передовать туда управление.
>ты, наверное, только под дос программировал... на крайняк -- под винду >:)) под линухом так -- нельзя
Как сказали выше - это не "unix-way". Если вдаваться дальше в теорию ОС - есть переключатель исполняемых файлов в загрузчике, смотрит на magic number и определяет - как запускать исполняемый файл (например - a.out, ELF, shell script или для организации эмулятора исполняемых файлов другой архитекутры). Так скажите мне - на кой чёрт городить эти распаковщики бинарных файлов, библиотеки - если в самом ядре десятилетия назад было заложено решение такой проблемы ? Добавляем маленкий участок кода в ядро (там, где ему и пололжено быть) - и избавляемся от всех этих костылей.
>В ядре FreeBSD очень давно существует pseudo-device gzip (если правильно помню): просто сжимаешь командой gzip бинарник - вуаля: и сжат, и работает :-)
ну это намного лучше чем данный компрессор, имхо, и код распаковщика в памяти не храниться и проще.
>В случае gzip скорость распаковки обычных бинарников на Pentium 4 2400 MHz около 40 МБ/с, а степень сжатия - в два раза, скорость чтения при использовании DMA в середине харда - те же 40 МБ/с. Т. е. бинарник размером в 20 МБ сжимается до 10 МБ, он считывается за 0,25 с и распаковывается еще за 0,5 с, итого 0,75 с, когда мог бы просто считаться 0,5 с. А тут еще все это время используются ресурсы процессора, которые могли бы быть использованы на более полезные нужды.
Интересно, конкретные цифры! А можно поподробнее про методику тестирования?
а мне нравится :) написал прогу, сжал - и люди будут думать, что ты пишешь компактные полнофункциональные проги, и вместо покупки толстых программ, будут покупать твою
кстати, помнится, lnx-бинарники упакованные этой хернёй под obds умеют только в корку падать, что впрочем верно и для самой тулзы, которая кроме того нативно даже не компилилась. т.ч. в печку
1 она требует байтового mtd-устройства, на обычных блочных устройствах только через жопу в ядре 2.6 можно использовать
2 она глючит как срань господня, при интенсивном использовании появляются ошибки, больше и больше, до тех пор пока ФС не посыпется вообще (а jffs2chk в природе не существует)
это я по опыту использования этой шняги на заурусах