» FreeArc (часть 4)

да, с заданием пароля через каллбэк действительно все нормально распаковывает. Значит пасс надо будет не через параметр в FreeArcExtract передавать, а только в каллбэке прописывать передачу.

у меня все время ошибка когда я запускаю UnarcDllExample.exe x archive.arc

а почему арк спрашивает ввод пароля (при открытии) когда исп-ся -dm<crypt_method> (при упаковке)?
кстати если скомбинировать -dm и -ae то будет ошибка


Цитата:

C:\unarc>arc a -dmaes-256 -p? -ae=aes-256 arc_ *
FreeArc 0.67 (September 10 2011) creating archive: arc_.arc

Enter encryption password:
Reenter encryption password:
Compressed 5 files, 555,392 => 345,688 bytes. Ratio 62.2%
Compression time: cpu 0.27 secs, real 0.27 secs. Speed 2,091 kB/s
All OK

C:\unarc>arc lt arc_.arc
FreeArc 0.67 (September 10 2011) listing archive: arc_.arc

Enter decryption password:
arc: aes-256/ctr:n1000:r0 doesn't include salt

C:\unarc>

или это не верное так делать ?

Цитата:

у меня все время ошибка когда я запускаю UnarcDllExample.exe x archive.arc

я похож на телепата? пиши какая конкретно ошибка, с логом


Цитата:

а почему арк спрашивает ввод пароля (

читай доку. если не читаешь - используй gui для создания архивов

Bulat_Ziganshin
у меня выходит отчет об ошибке (dwwin.exe), ну это не важно

а насчет пароля, в том то и дело что я его через GUI и создаю
но так как пароли нельзя вводить пустые то его никак не откроешь и смысла нет так создавать архивы, только если в паре с старой unarc.dll
т.е. я даже не хочу с паролем шифровать каталоги архива а просто , а он его запрашивает при попытке открытия
(упаковка аналогичная через GUI делается также)

[more=листинг]C:\unarc>arc a -mlzma -dmaes archive
FreeArc 0.67 (September 10 2011) creating archive: archive.arc
Compressed 6 files, 567,959 => 367,315 bytes. Ratio 64.6%
Compression time: cpu 0.30 secs, real 0.28 secs. Speed 2,019 kB/s
All OK

C:\unarc>unarcc x -dpdir-old-version-unarc archive.arc
filename 0 0 UnarcDllExample.cpp
read 0 0
write 0 0
filename 0 0 unarcc.exe
write 0 0
filename 0 0 UnarcDllExample.exe
write 0 0
filename 0 0 unarc.dll
write 0 0
filename 0 0 pwd-11111-unarc.arc
write 0 0
filename 0 0 unarc.arc
write 0 0
read 0 0
write 0 0
quit 0 0
FreeArcExtract() was successful

C:\unarc>arc x -dpdir archive.arc
FreeArc 0.67 (September 10 2011) extracting archive: archive.arc

Enter decryption password:

ERROR: bad password for archive archive.arc

C:\unarc>unarcc x -dpdir-new-version-unarc archive.arc

C:\unarc>[/more]
....
только что еще раз перепроверил все в GUI
если упаковать допустим так lzma+aes-256, потом открыть файл и перепаковать любым другим методом то также выйдет запрос пароля
вот листинг в консольной версии (а если --recompress не использовать с u/f то не перепаковывается с переданным методом)
[more=листинг]
C:\unarc>arc a -mlzma+aes unarc.arc
FreeArc 0.67 (September 10 2011) updating archive: unarc.arc
Compressed 6 files, 820,471 => 622,927 bytes. Ratio 75.9%
Compression time: cpu 0.42 secs, real 0.33 secs. Speed 2,500 kB/s
All OK

C:\unarc>arc u --recompress -mppmd unarc.arc
FreeArc 0.67 (September 10 2011) updating archive: unarc.arc
Compressing 6 files, 820,471 bytes. Processed 0%
Enter decryption password:
1%arc: write: invalid argument (Bad file descriptor)


C:\unarc>arc u -mppmd unarc.arc
FreeArc 0.67 (September 10 2011) updating archive: unarc.arc
Compressed 6 files, 820,471 => 622,927 bytes. Ratio 75.9%
Compression time: real 0.06 secs. Speed 0 kB/s
All OK

C:\unarc>arc lt unarc.arc
FreeArc 0.67 (September 10 2011) listing archive: unarc.arc

Archive type: FreeArc
Total bytes: 820,471
Compressed bytes: 622,927
Ratio: 75.9%

Directory blocks: 1
Directory, bytes: 222
Directory, compressed: 187
Solid blocks: 1
Avg. blocksize: 801 kb

Compression memory: 2869 kb
Decompression memory: 1066 kb
Dictionary: 810 kb

Archive locked: -
Archive comment: -
Recovery info: -
SFX size: -
Headers encrypted: -

Encryption algorithms: aes-256/ctr

Pos Size Compressed Files Method
-----------------------------------------------------------------------------
* 31 820,471 622,927 6 lzma:810kb:normal:32+a
es-256/ctr:n1000:r0
-----------------------------------------------------------------------------
6 files, 820,471 bytes, 622,927 compressed
All OK

C:\unarc>arc a -mppmd unarc.arc
FreeArc 0.67 (September 10 2011) updating archive: unarc.arc
Compressed 6 files, 820,471 => 647,921 bytes. Ratio 78.9%
Compression time: cpu 0.66 secs, real 0.72 secs. Speed 1,142 kB/s
All OK

C:\unarc>arc lt unarc.arc
FreeArc 0.67 (September 10 2011) listing archive: unarc.arc

Archive type: FreeArc
Total bytes: 820,471
Compressed bytes: 647,921
Ratio: 78.9%

Directory blocks: 1
Directory, bytes: 193
Directory, compressed: 160
Solid blocks: 1
Avg. blocksize: 801 kb

Compression memory: 48 mb
Decompression memory: 48 mb
Dictionary: -

Archive locked: -
Archive comment: -
Recovery info: -
SFX size: -
Headers encrypted: -
Encryption algorithms: -

Pos Size Compressed Files Method
-----------------------------------------------------------------------------
31 820,471 647,921 6 ppmd:10:48mb
-----------------------------------------------------------------------------
6 files, 820,471 bytes, 647,921 compressed
All OK
C:\unarc>
[/more]

Цитата:

а насчет пароля, в том то и дело что я его через GUI и создаю

ну-ка, ну-ка, покажи мне как ты через gui без использования ручного ввода опций задаёшь эту команду "arc a -mlzma -dmaes archive". ещё раз - если ты неспособен прочесть доку и просто наугад тыкаешь в кнопочки, то при создании архива просто отметь галочку "шифрование". всё остальное программа сделает сама

а же привел листинг
можно опустить -mlzma это я сделал чтобы сжать данные
а вот -dmlzma можно вводить в поле метода сжатия

может это конечно не совсем правильно использовать программу, но это пока возможно
(сжатие совместно с алгоритмом шифрования наверное тоже не совсем правильно)

да, защиты от дурака в программе нет. я думаю, это не самая важная функция

Bulat_Ziganshin
Где про метод сжатия xtor почитать ? что это такое ?

ndch
xtor - это 4x4:tor
xtor/xlzma/xppmd значит это 4x4:method

Есть ли в природе DLL, обладающая функциональностью arc.exe или близко к тому? Если нет, то будет?

vishyakov
для упаковки?
если для упаковки то нет
для распаковки unarc.dll

kalpak
Жаль. Ну ладно, пусть будет хотя бы декомпрессия.

unarc.dll - это которая из пакета InnoSetup support? Она может распаковать любые архивы FA? А как её использвать-то? Документация на неё и API есть?

vishyakov
да, она самая
а зачем документация? )) там всего 1 функция (ну еще одна, которую вряд ли кто то будет использовать)
и она та в скрипте примера распаковки объявлена

vishyakov
дело в том, что dll создавалась как часть проекта InnoSetup support и потому никто её специально не документировал. давай сделаем это прямо сейчас - мне для этого нужен как раз такой свежий человек как ты, который бы мог заметить пропуски в описании

итак: unarc.dll позволяет распаковывать архивы FreeArc. для этого она предоставляет функцию FreeArcExtract, пример использования которой вы можете найти в http://freearc.org/download/testing/unarc2011-09-18.7z

Синтаксис вызова:

errcode = FreeArcExtract(callback, command[1], command[2], command[3], ...);

где errcode - код ошибки (FREEARC_OK=0 при успехе, остальные коды можно найти в Common.h)
command[1]... - команда, которую должен выполнить unarc, список должен завершаться NULL или "". синтаксис поддерживаемых команд можно увидеть, вызвав unarc.exe без параметров
callback - ваша функция, которая будет вызываться из FreeArcExtract, может быть NULL

Пример вызова:

int errcode = FreeArcExtract(callback, "x", "-o+", "--", "a.arc", "*.obj", "*.lib", NULL);

С какими параметрами при этом вызывается callback, можно увидеть, откомпилировав и запустив UnarcDllExample.cpp

Спасибо, займусь. Даже мануал напишу :)

А пока у меня еще предложение. Предлагаю встроить препроцессор ZRLE, удаляющий последовательности нулей. Конкретно:

Алгоритм имеет параметр N.
Пусть встретилась последовательности нулей длинной k штук. Если k<N, то оставляем её как есть. Иначе заменяем её на k нулей плюс один байт равный k-N.

Думаете, RLE бесполезен? А вот и нет.
Например, моя папка C:\windows сжимается таким образом на 4%, в абсолютном исчислении это составило ~1 Гб.
На этих же данных я провёл испытания, взяв N=5, и скармливая выход freearc'у с опциями от -m1 до -m9.
Результат: сжатие улучшилось на 0.6-1.0 процентов.
Мало? Это больше, чем разница между -m8 и -m9. И при этом, как вы понимаете, бесплатно в плане потребляемых ресурсов.

А как изменяется время сжатия данных после их предобработки ZRLE? Трудно оценить, что будет в реальных условиях, но в идеальных, когда данные находятся целиком в системном кэше, время уменьшается на те самые 4%.

Причем в моём случае ZRLE находился в заведомо невыгодном положении - вероятно он сбивал с толку анализатор и exe-процессор.

Что скажете?

Цитата:

Пусть встретилась последовательности нулей длинной k штук. Если k<N, то оставляем её как есть. Иначе заменяем её на k нулей плюс один байт равный k-N.

во-первых ты не так описал алгоритм, а во-вторых имхо ты накосячил в своей реализации его) Т.к. lzma (+ rep, входящий в алгоритмы фриарка) гораздо эффективней справятся с любыми последовательностями одинаковых байт, а zrle только добавит лишнюю избыточность. Ты делал анпакер своего ZRLE?

Цитата:

lzma (+ rep, входящий в алгоритмы фриарка) гораздо эффективней справятся с любыми последовательностями одинаковых байт

Полностью поддерживаю, а когда Булат встроит SREP - мне кажется степень сжатия улучшится в разы.
vishyakov
Опиши детальнее, если есть наработки - выложи. Пока не могу судить и делать выводы, ибо не вижу + по сравнению в имеющимися алко во FA

snkreg
я не думаю что в разы
в различных ММ-файлах или еще где-то может даст хороший выигрыш
иногда помогает, а иногда даже ухудшает ситуацию (хотя больше чем на 10% не должен вырасти размер)
вот вчера я сжимал например папку с 50-60 файлами PDF размером общим в 700МБ (все сформированы из одного отчета разные данные только отображены)

precomp+srep+rep+lzma оказался почти такой же как
precomp+rep+lzma

единственное не запомнил сколько время ушло

kalpak
Слушай, а как думаешь, можно ли сделать тест всех вариантов? Ну прям к примеру сжимаешь 20Гб, ставишь на ночь - он у тебя проходится всеми возможными комбинациями, после каждой проходки архив удаляется, чтобы не засорять хард - потом выдается отчет - время, размер на выходе и выигрыш.
Bulat_Ziganshin
Булат, как ты на это смотришь?

snkreg
ты хочешь смерти моего винта? ))конечно можно
берешь арк пишешь arc a -mvariant1 archive files ; -mvariant2 archive files ;... >>output.txt
и потом мучайся разобрать его и придать вид таблицы
(была у меня такая таблица, но я забыл ее сохранить нормально, правда там были только встроенные алгоритмы, потому как precomp/srep на том файле нечего не давали)
но тут вопрос а что это за данные
Автор арка я думаю много разных тестов делает (ему же надо было определять алгоритмы для -m1..m9)

kalpak
Я же говорю, чтобы винт не умер - каждый архив сохранять в ТЕМР и удалять после сжатия. а на выходе нормальная отформатированная табличка. просмотрел, сделал выводы, ккой метод для тебя лучше - и уже заюзал его.

Цитата:

Ну прям к примеру сжимаешь 20Гб, ставишь на ночь - он у тебя проходится всеми возможными комбинациями, после каждой проходки архив удаляется

ночи явно не хватит) допуская шаг где то 5% каждого параметра от его максимального значения думаю пару недель пройдет пока все это завершится

Цитата:

имхо ты накосячил в своей реализации его...ты делал анпакер своего ZRLE?

За него я спокоен, он очень хорошо протестирован и отработал в бою всё лето.


Цитата:

ты не так описал алгоритм

А как надо?

Цитата:

rep, входящий в алгоритмы фриарка

REP детектит только достаточно длинные последовательности (если не ошибаюсь, от 32 байт; такие zero runs действительно попадаются не часто), причём на каждую ссылку тратит 12 байт.


Цитата:

lzma... гораздо эффективней справятся с любыми последовательностями одинаковых байт

Вас послушать, так lzma вообще лучше использовать в одиночку. Ведь применение, например, dict перед lzma не ставится под сомнение. А zrle делает то же, что dict или rep: уменьшает объем данных сохраняя уровень избыточности, что уменьшает объем работы и увеличивает эффективный размер словаря lzma.


Цитата:

ибо не вижу + по сравнению в имеющимися алко во FA

Сжатие улучшается на величину до 1% без потерь в скорости. Это разве не плюс?


Цитата:

Опиши детальнее, если есть наработки - выложи.

Здесь бинарники, исходник на всякий случай, и немного статистики: ZRLE.rar

Цитата:

Пусть встретилась последовательности нулей длинной k штук. Если k<N, то оставляем её как есть. Иначе заменяем её на k нулей плюс один байт равный k-N.

да, с рабочими вариантами программы стало понятней где ошибка в описании. Надо так:
Цитата:

Иначе заменяем её на N нулей плюс один байт равный k-N.

Цитата:

REP детектит только достаточно длинные последовательности (если не ошибаюсь, от 32 байт; такие zero runs действительно попадаются не часто), причём на каждую ссылку тратит 12 байт.

реп, в отличие от rle, кодирует все найденные одинаковые последовательности на протяжении своего словаря в эти 12 байт, будь то нули, или любые другие произвольные значения каждого байта. Тут эти алгоритмы вообще сравнивать не стоит - они разного назначения, хоть и схожие по проихождению.

Цитата:

Вас послушать, так lzma вообще лучше использовать в одиночку. Ведь применение, например, dict перед lzma не ставится под сомнение. А zrle делает то же, что dict или rep: уменьшает объем данных сохраняя уровень избыточности, что уменьшает объем работы и увеличивает эффективный размер словаря lzma.

вот с последним предложением согласен. Да и почему именно нули? Можно же таким образом с любыми последовательностями байт сделать.

И в приведенной тобой таблице не понятно как-то. Данные для каждого режима разные что-ли?
Ну и в общем то плюс в этом не хитром алгоритме вижу только в отсутствии потребляемой памяти. С остальным rep и srep на низких значениях параметра -l ИМХО должны справиться лучше.

Добавлено:
P.S. все же всё это стоит проверить на различного рода данных и в достаточном объеме для подтверждения того или иного утверждения.

vishyakov И отвязать программу от фрейм ворка.

Цитата:

Иначе заменяем её на N нулей плюс один байт равный k-N.

Да, разумеется.


Цитата:

И в приведенной тобой таблице не понятно как-то. Данные для каждого режима разные что-ли?

Нет, одни и те же. Я приукрасил таблицу, чтоб понятней было. Ссылка та же: ZRLE.rar


Цитата:

Можно же таким образом с любыми последовательностями байт сделать.

Можно конечно, хотя таких на порядок меньше.


Цитата:

И отвязать программу от фрейм ворка.

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

Цитата:

Нет, одни и те же. Я приукрасил таблицу, чтоб понятней было

в прошлом варианте у тебя графы время и размер были перепутаны, что сбило меня с толку (ну или lister в тотал коммандере криво xls показывает)


Цитата:

Можно конечно, хотя таких на порядок меньше

но конечный эффект алгоритма же все равно повысится.


Цитата:

Вот бы можно было оформлять DLL-плугины..

у меня такие мечтания тоже были... пока Булат не сказал про cls фильтры) Так что это возможно) Примеры и реализацию смотри в исходниках FreeArc'а

Profrager
http://freearc.org/download/testing/unarc2011-09-26.7z - теперь в загружаемых cls dll выполняются вызовы CLS_INIT и CLS_DONE, и выгружаются сами dll. проверь плиз. вместо op==-1 надо перехватывать op==CLS_DONE

там есть тестовая cls-test.dll (исходник simple_codec.cpp), которая это демонстрирует:


Код: C:\>UnarcDllExample.exe t a.arc

simple_codec.cpp: 1

event("filename", 0, 0, "Arc.exe")
event("read", 0, 0, "")
event("read", 0, 0, "")
event("read", 0, 0, "")
event("read", 0, 0, "")
event("read", 0, 0, "")
event("read", 0, 0, "")
event("read", 0, 0, "")
event("write", 3, 0, "")
event("write", 3, 0, "")
event("quit", 0, 0, "")
FreeArcExtract() was successful

simple_codec.cpp: 2

Bulat_Ziganshin

Цитата:

http://freearc.org/download/testing/unarc2011-09-26.7z - теперь в загружаемых cls dll выполняются вызовы CLS_INIT и CLS_DONE, и выгружаются сами dll. проверь плиз. вместо op==-1 надо перехватывать op==CLS_DONE

спасибо, все работает (ток я unarc.dll компилил с SVN'а - очень удобно смотреть что поменялось в коде).

Цитата:

кстати, FA поддерживает и использование stdin/stdout

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

Цитата:

я попробовал zrle5 на 3 своих тестовых файлах - везде получилось хуже. можешь сам посмотреть

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

Добавлено:

Цитата:

http://freearc.org/download/testing/dll100.7z
http://freearc.org/download/testing/dll700.7z
http://freearc.org/download/testing/MsOfficeBCJ.7z

последние 2 архива не доступны для скачивания.

Добавлено:
З.Ы. я пока тож плюс в rle не смог получить.

Цитата:

последние 2 архива не доступны для скачивания.

http://freearc.org/download/testdata/dll100.7z
http://freearc.org/download/testdata/dll700.7z
http://freearc.org/download/testdata/MsOfficeBCJ.7z


Цитата:

SVN'а - очень удобно смотреть что поменялось в коде)

для того его и держим я сделал иначе чем ты предлагал, но надеюсь что будет работать не хуже. а порядку так больше


Цитата:

stdin/stdout
только этот метод какой-то не очень стабильный.

а в чём нестабильность выражается?