» Вопрос об архивировании

нужен архиватор минимального размера под винду, ((меньше чем рар, который 133кб)
с командной строкой.

чтобы включить его в софтину

подскажите плз

если включить в свою софтину то лучше реализовать какой-нибудь алгоритм сжатия собственными силами.

а маленький есть arj, но это мне кажется устарело по качеству сжатия

других вариантов не посоветуете?

Ну, своим силами нормально не сделаешь, либо убьешь хрен знает сколько времени... Можно подключить библиотеку какую-нибудь... Если С++, то могу порекомендовать zlib. Сам не юзал, не надо было, но говорят, хорошая штука. http://www.gzip.org/zlib/

Добавлено
хотя, щас посмотрел, ее можно подрубить и к Delphi, и к VB...

zlib пробовали уже.. почему то он не подошел, еще предлоджите плз

ZokbI4

Цитата:

3. Where can I get a Visual Basic interface to zlib?

See
* http://www.winimage.com/zLibDll/
* http://www.dogma.net/markn/articles/zlibtool/zlibtool.htm
* contrib/visual-basic.txt in the zlib distribution

Цитата:

10. I need a Delphi interface to zlib.

See the contrib/delphi directory in the zlib distribution.

http://www.gzip.org/zlib/FAQ.txt

а вот важно совсем забыл, чтобы он могу директори архивировать, а не только отдельные файлы.
в pkzip мы так и не поняли как это делать

ZokbI4
Вот этого не знаю, pkzip под рукой нет...

Добавлено
Разобрался...
pkzip.exe -arp имя_архива путь_к_папке\*.*

Пример:
pkzip.exe -arp windows.zip c:\windows\*.*

Цитата:

Ну, своим силами нормально не сделаешь, либо убьешь хрен знает сколько времени...

нормально сделать можно всё, если руки из правильного места растут - времени может понадобиться, это правда.

но зато минимум размера (потому как будет только необходимая функциональность), максимум поддержки. этот вариант более подходит если разработка коммерческая

odl455

Цитата:

этот вариант более подходит если разработка коммерческая

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

Yolffff

но ведь речь не о создании полноценного продукта - архиватор. я про то что если в продукте нужна такая функциональность - то использовать сторониий продукт командной строки это немного криво, я уж не гооврю про производительность. может им
там нужно перебирать какой-то каталог и все подкаталоги архивировать и назначать специальное уникальное имя. то есть короче я к тому что можно подобрать конечно уже сделанный архиватор, вызывать его как-то, чего-то передавая на вход, если это подходит то ради бога! но раз люди озаботились размером - то почему они не думают ещё на 1, 2, 3 шага вперёд - о производительности, о надёжности, об обработке ошибок и всяких разных нештатных ситуаций и тп

odl455
Ну дык это-то понятно... Потому я и посоветовал Zlib. Который работает не из командной строки, бесплатен, доступен в исходниках. Что еще надо?
Если прога на С++, подрубай исходники. Если Delphi/VB - есть откомпиленная dll и интерфейсы...

спасибо большое!

ZokbI4
Так чего в итоге используете? pkzip или zlib?

pkzip отлично работает!

Добавлено
тут возникла новая проблема!
pkzip не берет блинные имена ибо ДОС,

нужна альтернатива

ZokbI4

Цитата:

pkzip не берет блинные имена ибо ДОС,

pkzip25 понимает длинные имена, мы им пользуемся.

и весит 300кб? больше чем рар в 2 раза?!

ZokbI4
Как вариант, создаешь файл, в который заносишь соотнесенные коротккие и длиннные имена, при архивации получаются короткие имена, а при разархивации берешь и считываешь эти короткие имена, из файла берешь соответсвующие длинные и ренеймишь. Второй вариант, есть такие штуки как упаковщики файлов, только не надо кричать, что это неправилько, если человеку важен объем, то н-р UPX 300 кб файл упакует примерно в 100-150 кб. Есть еще cabinet.dll которая позволяет создавать cab архивы, можно ее поюзать.

odl455

Цитата:

а маленький есть arj, но это мне кажется устарело по качеству сжатия

Ну во-первых о КАЧЕСТВЕ сжатия тут говорить не приходится, архиваторы всегда пользуются алгоритмами сжатия без потерь, поэтому говорим о СТЕПЕНИ сжатия.
Во-втлорых, по степени сжатия к arj нет никаких претензий. Ибо вся математика, которая используется при сжатии разработана достаточно давно, и ничего нового пока не придумали. Разные архиваторы используют разные методы сжатия, этим обусловлены разные показатели их работы.
Вывод: вся реклама новых архиваторов, которая говорит, что степень сжатия в десятки и десятки раз больше чем у предшественников - ложь и провокация.

Yolffff

Цитата:

Ну, своим силами нормально не сделаешь, либо убьешь хрен знает сколько времени...

За три дня вполне реально написать свой архиватор, тем более, что все алгоритмы давным-давно разработаны и найти их можно где угодно.
Вывод: написать можно, было бы желание.

Ну и чего я могу посоветовать. Элементарный поиск в яндексе тут же выводит на алгоритмы сжатия RunLenghtEncoding и LZW. Последний испытан временем и хорошо отработан. Рекомендую написать свою длльку с требуемым набором функций.
Успехов.

CamTracer
Да, алгоритмы разработаны и известны. Разница - в качестве кодирования этих алгоритмов, то есть в эффективности. Отточеную реализацию архиватора за три дня не сделать. Она будет наверняка медленнее того же zlib. Если хочется поизобретать велосипед - можно писать самому. Если нужно, чтоб работало, причем работало нормально - лучше взять готовую, отточенную реализацию и пользоваться ей. Если напрягает, что в библиотеке присутствует излишняя функциональность - тоже не проблема.Тот же zlib в исходниках, выдираешь оттуда только то, что надо - и вперед. И займет это куда меньше трех дней, и работать будет эффективнее архиватора, написанного за три дня.

Все, конечно, ИМХО.

Yolffff
Ну тут спорить конечно сложно, ибо все зависит от кривизны рук программиста.
Ближайшее рассмотрение скачанного архива показывает, что в zlib реализована модификация алгоритма LZ77 (смотри файл algorithm.txt). А в самом коде каких-то особых изысков я не нашел.
Переделка кода, как показывает опыт, не быстрее, чем написание программы с нуля. Это все-таки не hello, world.
Ну и самый главный аргумент:

Цитата:

zlib пробовали уже.. почему то он не подошел, еще предлоджите плз

Вывод: лениво писать самому (ну или радиус кривизны рук очень маленький), переделай кого-нибудь (согласен, zlib - хорошая и полезная весчь..., не зря все-таки почти 10 лет разрабатывается. Можно её достаточно быстро переиначить - будет жать и папки и длинные имена).
Успехов.

А где найти хедэры для Cabinet.dll,т.е. описание экспорта с именами функций и параметрами(и конечно же,с описаниями каждой процедуры)?Желательно для синтаксиса Visual Basic(можно и на Delphi/C,но могут возникнуть проблемы конверсии типов,хотя Delphi я не раз неплохо переводил на Visual Basic).А то я пишу некое подобие Setup'ки,надо сжатие(т.к. файлы Setup'ки хранятся в ресурсах,то аппликуха с огромным файлом грузится оооооооооооочень долго(раз я создал Setup'ку с файлами ок. 74 Мб,так она у меня на AMD Sempron 1800MHz 512 RAM грузилась ок 30с,а у чувака с Celeron 750MHz 128 RAM раз в 50 дольше!).Хоть упаковщики exe-шников(коими я пользуюсь нередко,а точнее всегда-ОПТИМИЗАЦИЯ!!!) и сжимают это дело(правда,все Setup'ки от рождения сжаты) кое-как,но распаковка таких монстров-дело долгое(нахрена Microsoft® Windows™ грузит ВСЕ ресурсы сразу,а не подгружает их динамически???).Конечно,можно создать лаунчер под именем Setup.exe и,выводя сообщение типа "Загрузка,please wait",стартить истинный инсталлер,хранящийся,допустим,под именем Setup.dat с помощью CreateProcess,но это всё равно будет криво.Может,поможете???

TP09H
Ну во первых все функции нашли достойное описание в MSDN
поищи функции которые начинаются на FCI
Раздел Win32 anc COM cabinet SDK API
И вот тебе сам SDK c microsoft download http://download.microsoft.com/download/platformsdk/cab/2.0/w98nt42kmexp/en-us/Cabsdk.exe

...А во-вторых, у тебя весьма поверхностное представление об оптимизации. Ты в курсе, например, что запакованная программка, когда её запускаешь, откушивает виртуальной памяти куда больше, чем незапакованная? Это ты на диске место сэкономишь, а в оперативной памяти потеряешь гораздо больше. Поэтому и такая разница во времени загрузки, наверное. И ИМХО не "Microsoft ® Windows™ грузит ВСЕ ресурсы сразу", а распаковщик. Конечно, могу и ошибаться, маловато данных ты дал, но то, что ты тут рассказываешь, очень похоже на описанные мною причины.

TP09H

Цитата:

но распаковка таких монстров-дело долгое(нахрена Microsoft® Windows™ грузит ВСЕ ресурсы сразу,а не подгружает их динамически???

А как MS может что-либо подгрузить динамически(даже если и понадобится), если ты все запаковал? Система понятия не имеет что находится внутри. Вот ей и приходится все разархивировать сначала и все помещать в память по несколько раз.

TP09H
По поводку инсталяции зачем почемуне хранить отдельно файлы для инсталации отдельно допустим в setup.dat. Тогда запуск программы инстала будет очень быстрый, памяти кушать будет мало, и онаже будет из отдельного файла ресурсов распаковывать твои файлы и их инсталить.

I have no russian lang on this comp because of the lame administrators in OGTU,so I'll speak English(sorry if my Eng is lame).Thanx to all who answers TP09H
-----------
RedPromo:thanx for recommendation,but I have INet 2 rarely and have less ability to move SDK from OGTU to my home.Download speed 2 small.I means that setup.dat will be EXE,and launcher will says smth. like "loading,plz wait" and run Setup.dat using CreateProcess(because separate Setup.dat will not be so economic,it's better to have all files in 1)
-----------
Qraizer:ok,I'm in course of the "memory eating" problem,but RAMemory isn't so important(for me),the most important problem is disk space.And what is IMHO?
-----------
dneprcomp:and if the Application wasn't packed,loading time isn't decreased

Цитата:

Qraizer:ok,I'm in course of the "memory eating" problem,but RAMemory isn't so important(for me),the most important problem is disk space.

Than don't complain to the "AMD Sempron 1800MHz 512 RAM" vs "Celeron 750MHz 128 RAM" difference of load time. But also, once to download and many times to load into memory are two big differences.
Цитата:

And what is IMHO?

IMHO is "In My Humble Opinion" abbreviation - too widespread.
Цитата:

(sorry if my Eng is lame)

Analogously

dneprcomp
А распаковщик имеет понятие,но всё равно распаковывает ВСЁ!!!А может,в файле куча картинок по 1234Кб каждая,а показываются они не сразу после запуска,а,допустим,в About'е???ЗАЧЕМ!?!?!? грузить сразу все ресурсы
Qraizer
Thanx за объяснение ИМХи

TP09H

Цитата:

А распаковщик имеет понятие,но всё равно распаковывает ВСЁ

Распаковщику до лампады все твои ресурсы. Он вообще такого слова не знает. Его дело распаковывать, а не умно определять что там понадобиться через пять минут, а что через час. И как ты себе представляешь выборочную распаковку только скрина "About" когда он понадобиться?
Цитата:

and if the Application wasn't packed,loading time isn't decreased

Прости, но не верится. Чем замерял? На глаз? Время долно уйти хотя бы на распаковку. Другое дело, что разница может быть неопределяема человеком.