Перейти из форума на сайт.

НовостиФайловые архивы
ПоискАктивные темыТоп лист
ПравилаКто в on-line?
Вход Забыли пароль? Первый раз на этом сайте? Регистрация
Компьютерный форум Ru.Board » Компьютеры » Программы » FreeArc: бесплатный open-source архиватор

Модерирует : gyra, Maz

Widok (30-01-2009 12:03): лимит страниц. продолжаем здесь  Версия для печати • ПодписатьсяДобавить в закладки
Страницы: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100

   

Bulat_Ziganshin

Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
FreeArc
бесплатный open-source архиватор для Windows и Linux,
сочетающий высокую степень сжатия и большой набор возможностей

Официальный сайт
Документация он-лайн на консольную версию
Скриншоты / Документация на GUI версию
Страница загрузки
Проект на SourceForge.net / SVN-репозиторий

Последний релиз - FreeArc 0.40 от 1 января 2008 г. Новая версия включает мультимедиа-сжатие, улучшение обычного сжатия, сверх-быструю упаковку в режимах -m1/m2, поддержку произвольных внешних упаковщиков, настраиваемых в arc.ini, 1.5-кратное увеличение скорости работы на 2-ядерных процессорах, навороченное шифрование, полностью работающие плагины для FAR/TC, прямой доступ к архивам в интернете, восстановление архивов через интернет и множество других изменений (полный список)
 
Текущая альфа версия 0.50 от 23 июня 2008 г. Включает GUI с русификацией (описание), автоматическое определение типов файлов, создание SFX, ускорены режимы -m3/m4 и linux-версия, решены проблемы на машинах с 2+ гб ОЗУ, исправлены ошибки в -m1 и -mx (полный список изменений)

MiniFAQ...

Подробное описание используемых алгоритмов
Почему он сжимает лучше и быстрее, чем 7-zip/rar...
Результаты тестов, подтверждающие его крутизну...
Планы дальнейшего развития... (обновлены 15 июня)
Почему для использования 2+ гб памяти желательно установить 64-битную версию Windows
Что подразумевается под "интеграцией с Explorer"  
FreeArc wiki (включая описание формата архива)
External compressors Power Pack
Логотип - объявляется конкурс на иконки для FreeArc

Сторонние оконные программы для работы с FreeArc
wArc - простая и понятная программа управления архивами (требует .NET Framework 2.0)
PeaZip – менеджер архивов с поддержкой большого количества форматов, для Windows и Linux

предыдущая версия шапки

Всего записей: 3401 | Зарегистр. 13-08-2007 | Отправлено: 12:55 13-08-2007 | Исправлено: juvaforza, 20:57 28-01-2009
egor23



Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

Цитата:
лови - http://www.haskell.org/bz/memo.7z

обновлённая вроде принципиально ничем не отличается?
 
Вообщем предположения вроде бы подвердились про второй блок.
 
(WinXP 32bit)1Гб+2Гб(файл подкачки)+иероглифы
(WinXP 32bit)1Гб+2Гб(файл подкачки)
boot.ini /MAXMEM=1024
(WinXP 32bit)2Гб+2Гб(файл подкачки)+иероглифы
(WinXP 32bit)2Гб+2Гб(файл подкачки)
boot.ini /MAXMEM=2048
(WinXP 32bit)2.5Гб+2Гб(файл подкачки)+иероглифы
(WinXP 32bit)2.5Гб+2Гб(файл подкачки)
memo2g.exe x
 
(WinXP 32bit)1Гб+2Гб(файл подкачки)+иероглифы
(WinXP 32bit)1Гб+2Гб(файл подкачки)
boot.ini /MAXMEM=1024 /3GB /USERVA=3000  
(WinXP 32bit)2Гб+2Гб(файл подкачки)+иероглифы
(WinXP 32bit)2Гб+2Гб(файл подкачки)
boot.ini /MAXMEM=2048 /3GB /USERVA=3000
(WinXP 32bit)2.5Гб+2Гб(файл подкачки)+иероглифы
boot.ini /3GB /USERVA=3000
memo2g.exe x
memo4g.exe x
 
(WinXP 64bit)2.5Гб+2Гб(файл подкачки)
memo2g.exe x
memo4g.exe x
 
логи
Process Explorer..
 
memo log full +Process Explorer ..
 
Добавлено:
осталось во FreeArc это обкатать
только нужно учитывать если FreeArc-у будут отдаваться такие значия как выдаёт memo, то нужно не -1, а больше вычитать, вообщем обратите внимание что будет во FreeArc-е с размерами блоков.

Всего записей: 3832 | Зарегистр. 03-11-2003 | Отправлено: 20:21 12-01-2008
Bulat_Ziganshin

Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

Цитата:
обновлённая вроде принципиально ничем не отличается?

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

Всего записей: 3401 | Зарегистр. 13-08-2007 | Отправлено: 20:40 12-01-2008
egor23



Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

Цитата:
краткая справка:  
lzp - blocksize + blocksize + 4*2^hashsize  
rep - blocksize + 4*2^hashsize (по умолчанию размер хеша - четвертьт от ращмера словаря, округлённого до ближайшей степени двойки, для blocksize=1.5*2^n используется hashsize=0.25*2^n)  
lzma - dictsize (для хранения исходных данных) + 8*dictsize (для хранения хеш-цепочек, в fast режимах 4*dictsize) + ~2*dictsize (для хранения заголовков хеш-цепочек, размер достаточно произволен и выбирается внутри lzma-алгоритма; для fast-режимов здесь значение побольше, для max - поменьше)  
ppmd - вся память выделяется одним блоком

А при выборе в какой непрерывный блок памяти писать данные случаем не выбирается самый большой, даже для небольших данных?

Всего записей: 3832 | Зарегистр. 03-11-2003 | Отправлено: 21:09 12-01-2008 | Исправлено: egor23, 21:10 12-01-2008
Bulat_Ziganshin

Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
в общем, алгоритм вырисовывается такой:
1. берём объём своб. вирт. памяти - это необходимо чтобы не получать сообщения "Слишком мало виртуальной памяти"
2. танцуя от этого значения вниз, находим наибольший непрерывный блок памяти
3. используем min(объём физ. памяти, размер наиб. непр. блока) как базу для -lc. плюс добавляем ограничение -ld=1gb. поскольку по умолчанию -lc75%, то при упаковке используется максимум 3/4 от размера этого блока (или физ. ОЗУ)
 
эти ограничения используются при отсуствии lc/ld и обеспечивают  
1) невылет порграммы из-за нехватки памяти при упаковке
2) возможность распаковать данные на любом компе где стоит достаточно памяти
 
при использовании же -lc- -ld- эти ограничители отключаются и ответственность за работоспособность алгоритмов и возможность распаковки ложится целиком на пользователя
 
для обычных же юзеров в худшем случае ("Allocated 1326 mb") это означает сжатие с 64 мб словарём в lzma. конечно, это далеко не идеал (реально в этом случае можно использовать словарь в 128 мб), но для начала это терпимо. в идеале конечно надо
1) возвращать для алгоритма список размеров блоков памяти, которые ему потребуются
2) в каждом алгоритме выделять память в порядке уменьшения размеров блоков
3) для алгоритмов типа ppmd выделять память небольшими блоками, скажем по 1 мб
 
но это всё слишком сложно. пусть по умолчанию работает хотя бы надёжно, а при отключении проверок главное - чтобы была возможность использовать память как можно эффектвиней
 
соответственно, в режимах m8/m9 в настройках будет заказываться до 2-3гб озу, но реально эти заказы будут обрезаться если только не указано -lc- -ld-
 
 

Цитата:
то как быть при распаковке. представь себе, что ты посылаешь свой архив какому-нибудь японцу? да он же харакири себе сделает!  
 
Тоже самое будет и сейчас.  
Даже с тем же 7-zip-пом 64bit, тоже самое будет при использовании PPMD и большой размер модели 2Гб, не распакуется на 32bit системе, т.к. не сможет выделить столько памяти, с 1.5Гб будут проблему, и автор скорее всего это знает - выбора 2Гб нету.  
 

разница в том, что если данные упакованы со словарём в 1 гиг, то понятно что делать для их распаковки - поставить как минимум 1.5гб или найти кого-то с такой памятью. дальше же уже начинается шаманство - нужно деинсталировать иероглифы, сунуть /3g в boot.ini или поставить 64-битную систему. поэтому архивы, созданные обычным пользователм, без копания в настройках, должны распаковываться в 1гб памяти. с ручными же настройками это уже находится на совести того, кто упаковал
 
да, кстати, какой максимум словаря в lzma получается выставить (на vista с editbin) ? имхо, 255 мб должно работать? в rep/ppmd, как я понимаю, 2047 мег без проблем?
 
Добавлено:

Цитата:
А при выборе в какой непрерывный блок памяти писать данные случаем не выбирается самый большой, даже для небольших данных?

а фиг его знает. попробуй проверить сам - сопоставить макс. размер своб. блока и макс. размер словаря для каждого алгоритма
 
Добавлено:
сунул этот код внутрь fa, порверил с использованием wininet и без оного:
 
Test memory allocation using VirtualAlloc::MEM_RESERVE
Allocated 1447 mb
Allocated 329 mb
Allocated 72 mb
Allocated 72 mb
Allocated 34 mb
Allocated 13 mb
 
Test memory allocation using VirtualAlloc::MEM_RESERVE
Allocated 1779 mb
Allocated 72 mb
Allocated 72 mb
Allocated 45 mb
Allocated 13 mb
 
размер наиб. свободного блока в тончости соответствует макс. словарю, с которым может работать ppmd

Всего записей: 3401 | Зарегистр. 13-08-2007 | Отправлено: 21:32 12-01-2008
Bulat_Ziganshin

Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
1. память выделяется начиная с младших адресов. я обновил memo чтобы он показывал адреса выделенных блоков. если наибольшие блоки находятся внизу, то это означает, что это наиболее невыгодная стратегия. повлиять на неё кажется можно как-то через registry и/или через editbin. также есть флаг TOP_DOWN у VirtualALloc, но чтобы его включить мне придётся потрошить свой компилятор
 
2. lzma выделяет память так, что её фактичсеки нужен непрерывный блок в который всё сможет влезть. я попробую его переписать - ндеюсь, это сделает возможным работу со словарём до 384 мег
 
реальные требования памяти lzma - 9*dictsize+roundup(dictsize), гд roundup округляет вверх до степени двойки (это при dictsize>32мб)
 
я эту формулу подредактирую, чтобы округление шло не вверх, а до ближайшей степени двойки, тогда словарь в 95 мег будет требовать 919 мб и худо-бедно влезать в гиг ОЗУ (у себя и проверю ), словарь в 191 мег будет влезать в 2 гига и т.д.
 
Добавлено:
update: для lzma - плюс ещё 0.5*dictsize для ускорения сдвигов, хотя это значение можно и уменьшать при нужде. для fast режимов - всё в точности то же самое минус 4*dictsize

Всего записей: 3401 | Зарегистр. 13-08-2007 | Отправлено: 00:50 13-01-2008
egor23



Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

Цитата:
а фиг его знает. попробуй проверить сам - сопоставить макс. размер своб. блока и макс. размер словаря для каждого алгоритма

нечем сопоставлять

Цитата:
сунул этот код внутрь fa, порверил с использованием wininet и без оного:  
 
Test memory allocation using VirtualAlloc::MEM_RESERVE  
Allocated 1447 mb

можно глянуть на эту версию, а то очень интересно что будет с +wininet +иероглифы

Всего записей: 3832 | Зарегистр. 03-11-2003 | Отправлено: 02:32 13-01-2008 | Исправлено: egor23, 05:03 13-01-2008
egor23



Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

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

Всё зависит от кривости (или особенностей) уставновленного ПО.
пример:
A program that allocates a large block of contiguous memory may not start or may intermittently fail in Windows Server 2003
http://support.microsoft.com/kb/913409

Цитата:
CAUSE
This problem occurs because the Hnetcfg.dll library has an image base address of 5F270000. If the Hnetcfg.dll library is loaded at this address, you may experience memory fragmentation of the Windows user address space. You experience this fragmentation because the Hnetcfg.dll library is loaded at approximately 1.6 GB into the address space.

может ведь быть и хуже:
насколько понял от image base address зависит куды загрузится ПО, т.е. если это какая-нибудь dll-ка которая цепляется ко всем и всям и у ней image base address будет 2EE00000 (750Мб), то непрерывного блока в 1Гб может и не будет.
Но это всё размышления.
 
вот практика:
Outpost Firewall - wl_hook.dll Load Address: 0x10000000 (256Мб)
system32\LPK.DLL Load Address: 0x62F00000 (1583Мб)(Language Pack, Это наши иероглифы)
 
(WinXP 32bit)2.5Гб+2Гб(файл подкачки)+иероглифы + wl_hook.dll(Load Address: 0x10000000 (16Мб))
EDITBIN.EXE /REBASE:BASE=0x1000000 wl_hook.dll
Что Видим - был Allocated 1326 mb стал Allocated 1566, аккурат на 240Мб больше.
 
логи..
 
Про файл подкачки:
общие рекомендации Pagefile=1.5*RAM
RAM, Virtual Memory, Pagefile and all that stuff
http://support.microsoft.com/kb/555223/
Нужно тоже упомянуть, а то будет Выскакивать - Сообщение в Windows - Слишком мало виртуальной памяти.
 
 
Добавлено:
ну и wininet.dll дело не в ней самой, а в
system32\comctl32.dll - Load Address: 0x5D5B0000 (1494Мб)
которую использует(-ют) dll-ки, которые использует wininet.dl.
 
Вообщем вопрос считаю исчерпаным:
Откуда ноги у ограничений памяти растут найдены:
Зависит от размеров непрерывных блоков,
размеры непрерывных блоков зависят от ПО и их Load Address (image base address),
+ ограничения в Windows на размер Вирт.памяти. 2Гб\3Гб\4Гб.
 
PS: Если наплёл глупости в последних собщениях (на последних страниц 20) прошу меня попинать, можно даже ногами.
 
Добавлено:
Arc-gui.exe 8.01.08, тоже относится и к WinArc050.exe...
 
Load Address: 0x10000000 (256Мб)
iconv.dll
intl.dll
zlib1.dll
FileBXH.dll  - FileBox eXtender (Это кстати, про другой софт установленный у массового пользователя.)
 
system32\UxTheme.dll - Библиотека тем UxTheme (Microsoft) (Load Address: 0x5B260000 (1458Мб))
 
libgtk-win32-2.0-0.dll Load Address: 0x60480000 (1540Мб)
и т.д для других lib загружаемых - Load Addres выше.

Всего записей: 3832 | Зарегистр. 03-11-2003 | Отправлено: 07:53 13-01-2008 | Исправлено: egor23, 08:58 13-01-2008
egor23



Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Arc050.exe при не сетевой работает нормально.
 
Arc050.exe при извлечении по сети:
Arc050.exe x http://000.000.000.000/a.arc
использует dll-ки (приведены основные системные) Load Address:
system32\rsaenh.dll 0xFFD0000 (256Мб)
system32\umdmxfrm.dll 0x5B590000 (1462Мб)
system32\NETAPI32.dll 0x5BD50000
system32\serwvdrv.dll 0x5D270000
system32\comctl32.dll 0x5D5B0000
system32\hnetcfg.dll 0x698B0000
system32\mswsock.dll 0x71A30000
и т.д. с адресами выше...
 

Цитата:
Arc-gui.exe

Может GUI делать как просто GUI, который передаёт параметры CLI-версии.
CLI - использкет минимум dll-ок.

Всего записей: 3832 | Зарегистр. 03-11-2003 | Отправлено: 10:53 13-01-2008
egor23



Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

Цитата:
для обычных же юзеров в худшем случае ("Allocated 1326 mb")

меньше для GUI версии.
iconv.dll Load Address: 0x10000000 (256Мб)
system32\UxTheme.dll (Load Address: 0x5B260000 (1458Мб)
1458-256=1202Мб, а в реальности ещё меньше.

Всего записей: 3832 | Зарегистр. 03-11-2003 | Отправлено: 12:56 13-01-2008
slech



Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

Цитата:
Может GUI делать как просто GUI, который передаёт параметры CLI-версии

а он разве не так будет работать ?

Всего записей: 4893 | Зарегистр. 10-11-2004 | Отправлено: 13:16 13-01-2008
Bulat_Ziganshin

Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

Цитата:
можно глянуть на эту версию

http://www.haskell.org/bz/arc-255m.7z - используй -di+$
 
помимо прочего, я переделал lzma. сейчас он выделяет память трёмя кусками (8x, 1x и 1.5x) причём начинает с самого большого. потому эта версия и называется 255m  попробуй её на висте

Всего записей: 3401 | Зарегистр. 13-08-2007 | Отправлено: 13:45 13-01-2008
SCINER



Junior Member
Редактировать | Профиль | Сообщение | ICQ | Цитировать | Сообщить модератору

Цитата:
 В моем GUI именно так и сделано.

 
wArc:
Теперь имеет встроенный файлменеджер

Всего записей: 85 | Зарегистр. 17-12-2007 | Отправлено: 14:42 13-01-2008
Nikolai2004



Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
SCINER
"В моем GUI именно так и сделано"
это в ответ на "Может GUI делать как просто GUI, который передаёт параметры CLI-версии"?
 
конечно хорошо, что в wArc именно так и сделано. вот только все преимущества перекрывает необходимость .net framework. к сожалению...
 

Всего записей: 1523 | Зарегистр. 07-01-2004 | Отправлено: 14:51 13-01-2008
SCINER



Junior Member
Редактировать | Профиль | Сообщение | ICQ | Цитировать | Сообщить модератору
З.Ы. я не могу отредактировать шапку.

Всего записей: 85 | Зарегистр. 17-12-2007 | Отправлено: 15:22 13-01-2008
egor23



Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Bulat_Ziganshin

Цитата:
http://www.haskell.org/bz/arc-255m.7z - используй -di+$

Win64 - Гы работает в ручном режиме -lc- -ld-  
 
На автомате Win32, Win64 - почему-то выставляется лимит 1920m?
 
(WinXP 64bit)2.5Гб+2Гб(файл подкачки)
Arc050.exe a a.arc -lc- -ld- -mXXX -di -di+$ 2207.tar
 
пределы
 
lzma:255m
Virtual Memory
Peak Private Bytes 2762700кб=2698Мб=2.63Гб
Virtual Size 2822684кб=2756Мб=2.69Гб
 
lzma:511m:fast
Virtual Memory
Peak Private Bytes 3423444кб=3343Мб=3.26Гб
Virtual Size 3482140кб=3400Мб=3.32Гб
 
ppmd:2047m
Virtual Memory
Peak Private Bytes 2114344кб=2064Мб=2.02Гб
Virtual Size 2175696кб=2125Мб=2.07Гб
 
rep:2047m:h28
Virtual Memory
Peak Private Bytes 3165176кб=3091Мб=3.02Гб
Virtual Size 3224276кб=3149Мб=3.07Гб
 
lzp:1649m:h26
Virtual Memory
Peak Private Bytes 1705848кб=1666Мб=1.63Гб\3660392кб=3575Мб=3.49Гб
Virtual Size 1767120кб=1726Мб=1.69Гб\3717848кб=3631Мб=3.55Гб
 
full_log..

Цитата:
помимо прочего, я переделал lzma. сейчас он выделяет память трёмя кусками (8x, 1x и 1.5x)

В документации надо привести пример на практике, как правильно в ручную рассчитывать пределы, размер словаря\размер хэша и т.п.
 
Добавлено:

Цитата:
На автомате Win32, Win64 - почему-то выставляется лимит 1920m?

уточнее - автолимиты памяти
 
(WinXP 32bit)2.5Гб+2Гб(файл подкачки)
Arc050.exe a a.arc -mXXX:XXXXm -di -di+$ 2207.tar
 
Allocated 1562 mb, addr=10070000
Allocated  218 mb, addr=02570000
Allocated   86 mb, addr=71AC0000
Allocated   72 mb, addr=77FE0000
Allocated   45 mb, addr=7C9C0000
Allocated    7 mb, addr=7F7F0000
Allocated    4 mb, addr=77610000
Allocated    2 mb, addr=01970000
Allocated    1 mb, addr=77250000
 
ppmd:3000m
  Using ppmd:8:1920mb
  Memory for compression 1920mb, decompression 1920mb
ERROR: Can't allocate memory required for (de)compression in ppmd:8:1920mb
 
lzp:3000m
  Using lzp:2208mb:64:h18
  Memory for compression 321mb, decompression 321mb
ERROR: Can't allocate memory required for (de)compression in lzp:2208mb:64:h18
 
rep:3000m - 1280m (rep:1gb)
lzma:3000m - 1348m (lzma:128m)
 
 
ppmd:2047m
  Using ppmd:10:2050476kb
  Memory for compression 2002mb, decompression 2002mb
ERROR: Can't allocate memory required for (de)compression in ppmd:10:2050476kb
 
lzp:2047m
Compressing 1 file of 2.314.722.816 bytes: 0.02 secs
  Using lzp:982528kb:64:h18
  Memory for compression 1920mb, decompression  41.9%
ERROR: Can't allocate memory required for (de)compression in lzp:982528kb:64:h18
 
rep:2047m - 1280m (rep:1gb)
lzma:2047m - 1348m (lzma:128m)
 
 
rep
- предел 1305m (1306m-1536m не хватает памяти, начиная с 1537m авто срабатывает до rep:1gb)
  Using rep:1536mb
  Memory for compression 1792mb, decompression 1536mb
ERROR: Can't allocate memory required for (de)compression in rep:1536mb
 
rep - предел 1562m:h25
 
ppmd - предел 1562m
 
lzp - предел 780m:h25
 
lzma
- предел lzma:164m (lzma:165m-188m не хватает памяти, начиная с 189m авто срабатывает до lzma:128m)
  Using lzma:188mb:normal:bt4:32
  Memory for compression 1918mb, decompression 188mb
ERROR: Can't allocate memory required for (de)compression in lzma:188mb:normal:bt4:32

Всего записей: 3832 | Зарегистр. 03-11-2003 | Отправлено: 15:25 13-01-2008 | Исправлено: egor23, 15:42 13-01-2008
Bulat_Ziganshin

Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

Цитата:
На автомате Win32, Win64 - почему-то выставляется лимит 1920m?

я сделал две вещи:
человеческий алгоритм выделения памяти в lzma. теперь словарь ограничен 1/8 (1/4 в fast) от размера самого большого блока
печать статистики памяти
 
автоматику я ещё не переделывал, вот она и творит беспредел
 

Цитата:
В документации надо привести пример на практике, как правильно в ручную рассчитывать пределы, размер словаря\размер хэша и т.п.

для этого существуют форумы и факи. это для тебя интересно, а большинсту народа даром не упало
 
в целом пределами я доволен - теперь всё объяснимо, выставлю их в -m9
 

Цитата:
Может GUI делать как просто GUI, который передаёт параметры CLI-версии.  
CLI - использкет минимум dll-ок.

Цитата:
а он разве не так будет работать ?

в wArc/PeaZip - так (хотя им бы тоже не помешало вызывать GUI-индикатор прогресса или вообще дать пользователю возможность выбора); у меня же всё интегрировано в один exe-шник WinArc
 
лучше всего для толстых алгоритмов использовать внешние компрессоры. уже сейчас можно взять compressor.exe и использовать его подобным образом. в будущем же
 
1. compressor будет совместим по формату данных с внутренними алгоритмами так, что к примеру можно будет упаковать внешним lzma со словарём в 1 гиг, а распаковывать внутренним
2. понятно, будут 32 и 64-разрядные версии, причём компилироваться они будут ICC, что увеличит скорость на 10-20%
3. fa будет автоматом соображать хватит ли ему наличной памяти для выполнения операции или лучше отдать её на откуп внешней программе
4. fa научится работать с внешними упаковщиками через stdin/stdout, что позволит использовать их так же удобно, как и внутренние алгоритмы - никакой записи на диск пормежуточных данных, актуальный индикатор прогресса и т.д.
 
при этом compressor - чисто вычислительная программа, никакие dll ей не нужны. а arc/winarc в таком раскладе превращается в чисто оболочку, куда для удобства встроены самые быстрые и нетребовательные к памяти алгоритмы
 
 

Цитата:
понятно. просто большинство контента нынче выкладывается в peer2peer файлообменных сетях (напрмер torrent), а то что лежит на http/ftp защищено antileech-системами (например rapidshare). так что использовать сетевые возможности freearc можно только на небольших дистрибутивах (тапа самого freearc), но во времена толстых выделенок с безлимитными тарифами это становится малоактуально

 
если для torrent есть библиотеки, позволяющие извлекать данные с середины файла (может, curl?), то его поддержку точно так же можно включить в fa. далее, изложенное там - это в основном точка зрения Егора, который тоже не имеет современного доутспа к инету и выкачивает оттуда хабар к себе на винт
 
я же вижу развитие ситуации иначе - если интернет станвоится так же доступным, как локальная сеть, только на пару порядков медленней, то нам и нужны программы, работающие с URI напрямую, а не заставляющие выкачивать файлы на винт и затем стирать их (или копить весь этот хлам)

Всего записей: 3401 | Зарегистр. 13-08-2007 | Отправлено: 17:05 13-01-2008
slech



Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

Цитата:
понятно. просто большинство контента нынче выкладывается в peer2peer файлообменных сетях (напрмер torrent), а то что лежит на http/ftp защищено antileech-системами (например rapidshare). так что использовать сетевые возможности freearc можно только на небольших дистрибутивах (тапа самого freearc), но во времена толстых выделенок с безлимитными тарифами это становится малоактуально

вот скачали мы бэкапчик на 2 Гб по ftp а он битый. инфу для восстановления конечно же не включили. докачка файла не помогла. размеры одинаковые. но файл результат битый а источник нормальный. думаю что fa замечатеьно бы нам помог в той ситуации.
или я не прав ?
 
кстати как с авторизацией в таком случае для fa, если у нас доступ anonymous запрещён ?

Всего записей: 4893 | Зарегистр. 10-11-2004 | Отправлено: 17:32 13-01-2008 | Исправлено: slech, 17:34 13-01-2008
sav90



Newbie
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
прежде всего хочу поблагодарить за перспективный архиватор
но вот что хотелось изменить  
ИМХО лучше чтоб все дополнительные библиотеки
были в отдельной папке к примеру lib
а то когда открываеш папку сразу столько файлов как-то пугает
мелочь конечно, но все же

Всего записей: 18 | Зарегистр. 11-04-2007 | Отправлено: 18:47 13-01-2008
Benchmark



Gold Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
А вот еще вопрос появился.
 
Булат, а нет в планах реализовать функционал FA в виде отдельной DLL, как это сделано у 7zip ? Тогда поддержку FA можно было бы легко реализовать в любой программе, начиная от сторонних архиваторов и заканчивая различными файл-менеджерами.

Всего записей: 6852 | Зарегистр. 01-10-2002 | Отправлено: 19:25 13-01-2008
egor23



Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

Цитата:
CLI - использкет минимум dll-ок.

Имел ввиду что GUI в нынешнем виде, только свои dll (lib.. и т.п.), если бы использовались только они - обрезали бы непрерывный блок до 1540Мб-256Мб=1284Мб.

Всего записей: 3832 | Зарегистр. 03-11-2003 | Отправлено: 20:23 13-01-2008
   

Страницы: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100

Компьютерный форум Ru.Board » Компьютеры » Программы » FreeArc: бесплатный open-source архиватор
Widok (30-01-2009 12:03): лимит страниц. продолжаем здесь


Реклама на форуме Ru.Board.

Powered by Ikonboard "v2.1.7b" © 2000 Ikonboard.com
Modified by Ru.B0ard
© Ru.B0ard 2000-2024

BitCoin: 1NGG1chHtUvrtEqjeerQCKDMUi6S6CG4iC

Рейтинг.ru