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

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

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

 Версия для печати • ПодписатьсяДобавить в закладки
Страницы: 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 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152

Открыть новую тему     Написать ответ в эту тему

Widok



Moderator-Следопыт
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Часть 1 | Часть 2 | Часть 3


Скачать последний релиз - FreeArc 0.666 от 20 мая 2010 г. Что нового: ускорение работы в 1.5-2 раза благодаря новой технологии многопоточного сжатия, распаковка архивов многих форматов используя технологии 7-zip, запуск файлов из архива, исправлены все проблемы интеграции с Explоrer (подробнее)
Текущая альфа версия: 0.67 - загрузка | список исправлений | блог


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


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


Родственные темы:
Inno Setup плюс внешние упаковщики - использование архивов FreeArc в инсталяторах
ISDone.dll - библиотека распаковки архивов в инсталяторах
REP & SREP
Пережатиe/Pекомпрессия/Oптимизация файлов для лучшего сжатия - "а как сжать ещё лучше?"
FreeArc и Unix - для альтернативно одарённых
• репозиторий FreeArc 'Next на github.com
• тема FreeArc 'Next на форуме encode.su
• раздел FreeArc на форуме krinkels.org

 
Другие архиваторы:
WinRAR
7-zip
PowerArchiver
HaoZip
BandiZip


Всего записей: 24190 | Зарегистр. 07-04-2002 | Отправлено: 11:36 23-11-2010 | Исправлено: Nikolai2004, 21:23 03-02-2021
Posetitel33



Newbie
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Здравствуйте! У меня такой вопрос: можно ли сделать опциональную распаковку arc-архивов в зависимости от выбранных пунктов? Я пробовал так:
 
Подробнее...
 
Но инсталятор просто выплёвывает все три архива, не распаковывая их. Если же не включать файлы в архив и писать #define ArcLocation "{src}\*.bin", то распаковываются сразу все архивы.
 
Можно ли решить мою проблему? Может быть тут такое уже обсуждалось, но я искал и не нашёл; так что извиняюсь за возможный повтор вопроса. Заранее спасибо.

Всего записей: 1 | Зарегистр. 04-08-2011 | Отправлено: 18:45 04-08-2011
kalpak

Junior Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Posetitel33
пропиши в скрипте не распаковывать по маске а передавать список файлов (можно через запятую)
и все будет тип топ
он же у тебя по маске ищет все файлы бин и распаковывает
а ты вместо маски сделай чтобы скрипт использовал список файлов
 
какое преимущество дает использование  future-lz
я  понял что требование к памяти при распаковке ниже
но ведь память и так при распаковке очень малая (16мб)

Всего записей: 155 | Зарегистр. 20-07-2007 | Отправлено: 08:19 05-08-2011 | Исправлено: kalpak, 17:08 06-08-2011
Profrager



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

Цитата:
какое преимущество дает использование  future-lz

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

----------
переехал сюда

Всего записей: 888 | Зарегистр. 22-05-2010 | Отправлено: 22:03 06-08-2011
kalpak

Junior Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
что значит щадящий режим ?
каким образом меньше операций i/o ?
он вроде побыстрее работает но вот насчет нагрузки на диск как то не заметил
 
 
странно, но среп стал неверно показывать память для упаковки
файл размером в 200мб
пишу srep -l256
(SuperREP 2.98 alpha)
он пишет  

Цитата:
D:\free_arc067\bin>srep -l256 "d:\games\portal 2\portal2\portal2.zip"
56 mb, -m3 -l256 -c128 -a4

однако в диспетчере задач пишет 270мб под конец
 
если писать l128  то память пишется и тратиться корректно
если не писать то также непонятно куда утекает
 
с файлом около 1.5 гб получается так
с l128 память корректно тратиться
с любыми другими к середине уже больше 600мб память
даже  с 1024 !!
 
для страховки везде прописал a1 все равно
(метод m3f везде, без f тоже проверял)
 
я разобрался
среп тот был скомпилирован мной вручную с помощью ms vs 2005
srep с ссылки автора работает корректно
кстати а чем srep32 отличается от srep ?
я peid проверил, там gcc компилятор, а в srep скорее всего ms vs 20xx
а разница между ними существенная ?i версия понятно побыстрее на intel-платформах
 
я все таки все их првоерил
такое же поведение у srep32/srep32i
у srep который в gcc построен все ок
 
кстати и теперь черtp arc\freearc не пашет, только вариант без -f пашет потому что я разделил srep

Цитата:
[External compressor:srep]
;options  = l%d (minimal match length, default=512)
packcmd   = srep {options} $$arcdatafile$$.tmp - <stdout>
unpackcmd = srep -d - - <stdin> <stdout>
 
[External compressor:srep_f]
;options  = l%d (minimal match length, default=512)
packcmd   = srep {options} -f - - <stdin> <stdout>
unpackcmd = srep -d - - <stdin> <stdout>

 
это у меня одного такие люки?

Всего записей: 155 | Зарегистр. 20-07-2007 | Отправлено: 22:45 06-08-2011 | Исправлено: kalpak, 20:52 07-08-2011
kalpak

Junior Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
у меня не распаковываются файлы запакованные srep 2.98 alpha
если файл больше 2 гб то не распаковывается
если меньше то без проблем
 
во время упаковки никаких ошибок не пишет
а при распаковке  

Цитата:
Ratio: 2,172,649,472 -> 2,137,387,555: 98.38%. Cpu 359.301 mb/sec, real 13.863 m
Ratio: 2,181,038,080 -> 2,145,776,191: 98.38%. Cpu 358.834 mb/sec, real 13.899 m
Ratio: 2,189,426,688 -> 2,154,164,827: 98.39%. Cpu 358.372 mb/sec, real 13.924 m
Ratio: 2,197,815,296 -> 2,162,553,463: 98.40%. Cpu 357.914 mb/sec, real 13.960 m
Ratio: 2,206,203,904 -> 2,170,942,099: 98.40%. Cpu 357.461 mb/sec, real 13.996 m
Ratio: 2,214,592,512 -> 2,179,330,735: 98.41%. Cpu 357.012 mb/sec, real 14.014 m
b/sec. Matches 5 4447 14188, I/Os 0, RAM 0/14, VM 0/0, R/W 0/0
  ERROR! Decompression problem: broken compressed data

параметры упаковки -l128 -f -a1, файл размером 2.29 ГБ
 
winxp sp2, 2gb ram, core 2 duo  4300
на работе также только проц и СП другие
core-i5 650  
win xp sp3
 
 
***
перепроверил, ошибка при распаковке бывает только при файле больше 2 гб если использовался -f, без -f все отлично распаковывается
 
все же. это нормально что при высоких lz min math память тратится даже больше чем при l32
я упаковываю файл 900 мб, у меня при параметрах -a4 под конец пишет уже  более гб выделено, когда как требование к памяти в 10 раз меньше (95мб)
версия 2.0 так не ведет себя
вообще как то странно диспетчер показывает данные, я когад сворачиваю окно срепа то пишет что память 100 мб, тогда как на графике потребления памяти никаких изменений и в графе доступно нечего не меняется, а если сворачивать/разворачивать окно то память скачет то вниз то вверх

Всего записей: 155 | Зарегистр. 20-07-2007 | Отправлено: 08:39 09-08-2011 | Исправлено: kalpak, 17:39 09-08-2011
Bulat_Ziganshin

Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Posetitel33
надо задавать вопрос разработчику скрипта. или ты используешь скрипт из поставки freearc???
 
Добавлено:

Цитата:
какое преимущество дает использование  future-lz  
я  понял что требование к памяти при распаковке ниже  
но ведь память и так при распаковке очень малая (16мб)

 
почитай, вроде полтемы у нас srep'у посвещено. но если коротко - то обычный алгоритм берёт данные не из этих 16 мег, а считывает из предыдущей части файла. т.е. если LZ-код говорит ему "следующие 10 мб данных точно совпадают с тем что было 100 мб назад", то он просто читает их из уже распакованной части файла. учитывая, что кодируются все повторы от 512 байт - это огромная нагрузка на дисковый кеш, а если в него всё не влезет - то и сам диск
 
future-lz устроен наоборот - уже после распаковки первый раз этих 10 мб он говорит "они нам ещё понадобятся через 100 мб, давай сохраним их копию в памяти", и таким образом всё что будет повторено хранится в памяти и нагрузки на винт нет. если же даже озу для этих данных не хватит, то они собираются в куски по 8 мб, которые записываются/читаются целиком. по сравнению с первым вариантом, где куски могут быть по 512 байт, нагрузка на диск на 4 порядка меньше так что он не становится узким звеном
 
Добавлено:

Цитата:
однако в диспетчере задач пишет 270мб под конец  

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

Цитата:
у меня не распаковываются файлы запакованные srep 2.98 alpha  
если файл больше 2 гб то не распаковывается

да, 32-битные версии srep имеют такую ошибку. спасибо!
 
раскладку я уже приводил:
 
srep - gcc
srep32/64 - msvc
srep32i/64i - icl
 
 
 
Добавлено:

Цитата:
однако в диспетчере задач пишет 270мб под конец  

а, сообразил - это скорей всего из-за mmap. попробуй -nommap; вероятно в gcc-версии mmap просто не срабатывает

Всего записей: 3401 | Зарегистр. 13-08-2007 | Отправлено: 11:16 10-08-2011
kalpak

Junior Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Bulat_Ziganshin
Цитата:
 
дело в том, что в винде несколько столбцов памяти. тебе нужен "выделенная память". а в рабочий набор может быть включаются закешированные самой виндой данные входного файла, кто её знает  

какая память ?
я смотрю столбик память, есть еще вирт. память, но указанная вам "выделенная память" отсутствует в списке возможных столбцов. (есть еще выгруж и не выгруж. пул, но там малое кол-во памяти пишет)
 

Цитата:
а, сообразил - это скорей всего из-за mmap. попробуй -nommap; вероятно в gcc-версии mmap просто не срабатывает

большое кол-во памяти потребляют (у меня уж точно, правда зависит от файла) все варианты srep/32/32i, флаг nommap всех их ограничивает в той, которая указана в mem req
 
я про lzf спросил потому что не сталкивался с теми случаями когда память тратится много, однако только что я запаковал архив (dbf-файлы) с lzf и при распаковке увидел что память он нехило тратит, теперь понятно к чему было написано  

Цитата:
- Таким образом, мы можем распаковать 22 ГБ файл с 2 ГБ ОЗУ, или даже с 200 МБ ОЗУ и 2 ГБ VM файле, и скорость остается очень высокой, около 100 МБ/с! Я считаю, что это выдающийся результат.  

получается зависит от кол-ва lz math

Всего записей: 155 | Зарегистр. 20-07-2007 | Отправлено: 12:52 10-08-2011 | Исправлено: kalpak, 12:53 10-08-2011
Bulat_Ziganshin

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

Цитата:
кстати и теперь через arc\freearc не пашет, только вариант без -f пашет потому что я разделил srep  

 
а вот этого я не понял
 
 
Добавлено:

Цитата:
я смотрю столбик память, есть еще вирт. память, но указанная вам "выделенная память" отсутствует

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

Цитата:
получается зависит от кол-ва lz math

зависит от общего объёма "отложенных на будущее" данных. я на английском форуме помнится даже график приводил для этого 22 гб файла

Всего записей: 3401 | Зарегистр. 13-08-2007 | Отправлено: 12:59 10-08-2011
kalpak

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

Цитата:
а вот этого я не понял  


Цитата:
 
[External compressor:srep]
;options  = l%d (minimal match length, default=512)
packcmd   = srep {options} $$arcdatafile$$.tmp - <stdout>
unpackcmd = srep -d - - <stdin> <stdout>
 
[External compressor:srep_f]
;options  = l%d (minimal match length, default=512)
packcmd   = srep {options} -f - - <stdin> <stdout>
unpackcmd = srep -d - - <stdin> <stdout>

кстати кажется в распаковку лучше добавить {options} чтобы ограничить память или еще какие нибудь параметрыы исп-лись при распаковке

Всего записей: 155 | Зарегистр. 20-07-2007 | Отправлено: 13:23 10-08-2011
egor23



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

Цитата:
кстати кажется в распаковку лучше добавить {options} чтобы ограничить память или еще какие нибудь параметрыы исп-лись при распаковке

последние рекомендации тут http://forum.ru-board.com/topic.cgi?forum=5&topic=35164&start=620#2
 
Добавлено:

Цитата:
я на английском форуме помнится даже график приводил для этого 22 гб файла

картинки тут http://forum.ru-board.com/topic.cgi?forum=5&topic=35164&start=240#11

Всего записей: 3831 | Зарегистр. 03-11-2003 | Отправлено: 13:34 10-08-2011
Bulat_Ziganshin

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

Цитата:
оказывается что по умолчанию в normal preset match finder - ht4 ?  

да. попробуй поищи в топике по "ht4", это апрель 2009-го afair
 

Цитата:
для tor в исходниках вроде написано что  он принимает параметры многие, например  p(parser ),

 
из help'a:
 
 -p#     -- parser (1-greedy,2-lazy), default 2
 
другие парсеры планировались, но так и не были реализованы. вообще tor интересен только для быстрого сжатия, иначе lzma круче
 
 

Цитата:
а нельзя сделать чтобы архиватор при распаковке архива с методом 4x4 (например lzma:128mb:fast:96:mc20) учитывал параметр t (кол-во потоков), для данного файла ставил t2  
а то получается смешная ситуация, запаковать смог, а распаковать нет ))  
(использовался архиватор 0.666 build)  
можно даже не указывать кол-во потоков, он все равно сможет запаковать, получается опция lc75p по-умолчанию работает, а опция ld75p - нет  
 
кстати unarc успешно его распаковывает  
(067 alpha 2011-03-18, 0.666 зависала [ошибки не было, просто нечего не делала])  

 
запутался я в твоих показаниях...

Всего записей: 3401 | Зарегистр. 13-08-2007 | Отправлено: 14:55 10-08-2011
kalpak

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

Цитата:
запутался я в твоих показаниях...

был файл 8гб, я его запаковал с 4x4:t2:lzma:128mb:128:mc10 (если т2 не указать, то памяти не хватит и ошибка выйдет)
но сохраняет он информацию что сделан архив 4x4:lzma:128mb:128:mc10  
и пишет что для распаковки надо больше 2гб памяти ( у меня лог. 4 потока)
т.е. получается что указать сколько потоков нужно для упаковки можно, а какое кол-во было указано не сохраняется в методе сжатия и он просто пытается задействовать все потоки
unarc успешно его распаковывает (067 версия), а FA жалуется что памяти не хватает
кстати а кол-во блоков в методе 4х4 чем то ограничено? у меня разница между xlzma и lzma около 50 мб (тот же файл 8гб), как я не пытался сделать блок большим

Всего записей: 155 | Зарегистр. 20-07-2007 | Отправлено: 15:40 10-08-2011
Bulat_Ziganshin

Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
kalpak
это всё без lc/ld? пиши чётко - команда (проще даже лог с экрана), конфиг компа, и что по твоему не так работает
 
пока я могу ответить только на один вопрос - t2 в архиве не запоминается именно потому, что архив может распаковываться на другой машине где озу будет меньше или больше. да и ни о чём это t2 не говорит, кроме скорости с какой у тебя прошла упаковка (в отличие от других опций, по которым можно понять степень сжатия)
 
Добавлено:
кстати, пришёл в голову трюк, который возможно способен на порядок ускорить распаковку обычного srep (без -f) когда идёт трешинг диска - считывать матчи параллельно в нескольких десятках потоков. тогда есть надёжда что сработает ncq и мы будем иметь qd=32 or so

Всего записей: 3401 | Зарегистр. 13-08-2007 | Отправлено: 17:20 10-08-2011 | Исправлено: Bulat_Ziganshin, 18:33 10-08-2011
kalpak

Junior Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Bulat_Ziganshin
вот я пакую файл
подробнее
 
в GUI пишет что для упаковк нужно ~2450mb для упаковки и ~2300 для распаковки
рисунок
я забыл написать t1 при упаковке, но вот только что сделал с т1 и результат такой же.
подробнее
 
только чтот-о я не могу распаковать их unarc, странную ошибку пишет
лог
система: win xp sp2 ram 2gb | core 2 duo e4400
на работе система: win xp sp3 ram 2gb | core i5 650

Цитата:
кстати, пришёл в голову трюк, который возможно способен на порядок ускорить распаковку обычного srep (без -f) когда идёт трешинг диска - считывать матчи параллельно в нескольких десятках потоков. тогда есть надёжда что сработает ncq и мы будем иметь qd=32 or so

а если жесткий диск не поддерживает ncq то что делать ?))
что такое qd=32 or so ?

Всего записей: 155 | Зарегистр. 20-07-2007 | Отправлено: 19:49 10-08-2011 | Исправлено: kalpak, 20:16 10-08-2011
Bulat_Ziganshin

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

Цитата:
а если жесткий диск не поддерживает ncq то что делать ?))  

тогда он будет работать с прежней скоростью
 

Цитата:
что такое qd=32 or so ?

or so="или типа того". qd - глубина очереди запросов, если долбить диск из 32 потоков, то qd будет 32 и диск с ncq получит шанс переупорядочить запросы, а диск без ncq просто выполнит их по очереди, как и сейчас
 

Цитата:
вот я пакую файл

теперь ясно. будем искать
 
Добавлено:

Цитата:
в GUI пишет что для упаковк нужно ~2450mb

кста на будущее есть команда lt:
 
подробнее
 

Всего записей: 3401 | Зарегистр. 13-08-2007 | Отправлено: 21:26 10-08-2011 | Исправлено: Bulat_Ziganshin, 21:34 10-08-2011
kalpak

Junior Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Bulat_Ziganshin
понятно, буду знать )
а вот насчет ошибка распаковки unarc странно, на работе  у меня получалось распаковывать

Всего записей: 155 | Зарегистр. 20-07-2007 | Отправлено: 22:05 10-08-2011
Bulat_Ziganshin

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

  • fixed bug: 32-bit version was unable to decompress large files (>2gb) compressed with -f

 
btw, i've tested srep on i7-2600k@4.6GHz - compression speed on my files was in 100-200 mb/s range so srep was ALWAYS limited by HDD speed
 
Добавлено:
 
 
and once again: -nommap testing proves that memory-mapped files slow down the SREP when you are short on RAM:
 

Код:
D:\>read lp2.pcf
Speed 84.369956 mbytes/sec
 
srep64i -m1           Cpu 148.074 mb/sec, real 83.986 mb/sec
 
srep64i -m2           Cpu 201.726 mb/sec, real 54.300 mb/sec
srep64i -m2 -nommap   Cpu 209.772 mb/sec, real 71.276 mb/sec
 
srep64i -m3           Cpu 155.684 mb/sec, real 40.795 mb/sec
srep64i -m3 -nommap   Cpu 157.294 mb/sec, real 57.553 mb/sec
 
Compression ratio: 22,069,494,174 -> 7,284,431,814: 33.01%

 
 
... while having tiny positive effect in situations when RAM is enough to cache all repeated portions of input file:
 

Код:
srep64i -m1           Cpu 119.653 mb/sec, real 114.771 mb/sec
 
srep64i -m2           Cpu 129.146 mb/sec, real 123.231 mb/sec
srep64i -m2 -nommap   Cpu 133.329 mb/sec, real 126.635 mb/sec
 
srep64i -m3           Cpu 108.918 mb/sec, real 105.573 mb/sec
srep64i -m3 -nommap   Cpu 111.773 mb/sec, real 94.049 mb/sec
 
Compression ratio: 5,586,729,972 -> 4,344,610,562

Всего записей: 3401 | Зарегистр. 13-08-2007 | Отправлено: 22:40 10-08-2011 | Исправлено: Bulat_Ziganshin, 23:45 10-08-2011
egor23



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

Цитата:
tested srep on i7-2600k@4.6GHz

главное не указали, кол-во RAM

Всего записей: 3831 | Зарегистр. 03-11-2003 | Отправлено: 00:31 11-08-2011
Engaged Clown



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

Всего записей: 8690 | Зарегистр. 08-06-2006 | Отправлено: 00:35 11-08-2011
Bulat_Ziganshin

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

Всего записей: 3401 | Зарегистр. 13-08-2007 | Отправлено: 02:11 11-08-2011
Открыть новую тему     Написать ответ в эту тему

Страницы: 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 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152

Компьютерный форум Ru.Board » Компьютеры » Программы » FreeArc (часть 4)


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

Powered by Ikonboard "v2.1.7b" © 2000 Ikonboard.com
Modified by Ru.Board
© Ru.Board 2000-2020

BitCoin: 1NGG1chHtUvrtEqjeerQCKDMUi6S6CG4iC

Рейтинг.ru