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

НовостиФайловые архивы
ПоискАктивные темыТоп лист
ПравилаКто в 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
andhunt

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

Bulat_Ziganshin, мог бы дать ответ или может кто-то из мемборов сможет мне помочь, если необходимо готов заплатить.
 
 
можно сделать следующее в FreeArc.
 
в архиваторе есть модуль freearc-installer.sfx, который запускает setup.exe , но если в архиве были еще файлы то он их не распаковывает в текущую папку.
нужно чтобы работало следующим образом, у меня есть к примеру три файла:  
1. setup.exe  
2. primer.exe
3. primer.txt
 
я их архивирую через модуль freearc-installer.sfx , а когда уже распаковываю эти файлы setup.exe должен запуститься сам автоматически и удалиться, а оставшиеся файлы primer.exe и primer.txt должны распаковаться в текущую папку как обычно?(т.е. setup.exe после запуска удаляется , а primer.exe и primer.txt должны просто распаковаться)
как такое реализовать, если такого нет могли бы за отдельную плату подредактировать этот модуль?

Всего записей: 9 | Зарегистр. 24-02-2011 | Отправлено: 01:21 27-02-2011
egor23



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

Цитата:
Разархивировал .arc, попробовал напрямую srep -d, то же самое - ошибка, прекращение распаковки.


Цитата:
Вопрос с установкой решился. Вроде бы помогло увеличение объема файла подкачки (Win7x86, родные 4Гб, своп поставил "рекомендовано системой").


Цитата:
Ещё возможная проблема (подсмотрел на сайте где брал) - кеширование антивирусом распаковываемого файла

может проблема всё таки в памяти? проверьте её, а то очень сомнительно, что антивирус косячит, кэширует то он скорее всего на HDD.

Всего записей: 3831 | Зарегистр. 03-11-2003 | Отправлено: 02:46 27-02-2011
Bulat_Ziganshin

Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Benchmark measuring effect of -nommap option on system with 8Gb RAM:
 
First test, 5.5 gb file compressed down to 4.4 gb:
Cpu 57.299 mb/sec, real 56.471 mb/sec -m1
Cpu 57.263 mb/sec, real 56.599 mb/sec -m1 -nommap
Cpu 58.545 mb/sec, real 57.968 mb/sec -m2
Cpu 57.594 mb/sec, real 56.189 mb/sec -m2 -nommap
Cpu 48.428 mb/sec, real 48.010 mb/sec -m3
Cpu 46.168 mb/sec, real 39.404 mb/sec -m3 -nommap
 
As you see, memory-mapped files (i.e. lack of -nommap option) has no effect on -m1 (in fact, MMF not used at all in -m1), there is a small improvement of 3-4% in -m2, and 20% in -m3
 
MMF files are used to retrieve matches to compare, that explains the result: -m1 doesn't do it at all (it verifies matches by SHA1 hash). -m2 retrives only small amount of real matches (500 thousands here), and -m3 retrives huge amount of match candidates (13 millions for this file) that is much faster with direct memory access instead of read call
 
 
Second test, 22gb file compressed down to 7gb:
Cpu 76.367 mb/sec, real 73.785 mb/sec -m1
Cpu 91.401 mb/sec, real 52.799 mb/sec -m2
Cpu 91.136 mb/sec, real 56.497 mb/sec -m2 -nommap
Cpu 72.282 mb/sec, real 36.478 mb/sec -m3
Cpu 68.879 mb/sec, real 35.693 mb/sec -m3 -nommap
 
Here we see about 10% speed improved in -m2 without MMF. srep is memory-hungry here, and may be it is the effect of larger OS memreqs to support MMF operation. but actually i don't know the reason, only had to say that i've tested several times and results were the same
 
 
Third test, the same 22gb file placed to Intel SSD 120 gb disk, that is 2x faster on linear reads, and has 100x smaller access time:
Cpu 77.116 mb/sec, real 75.453 mb/sec -m1
Cpu 92.865 mb/sec, real 56.718 mb/sec -m2
Cpu 90.861 mb/sec, real 73.738 mb/sec -m2 -nommap
Cpu 73.316 mb/sec, real 45.534 mb/sec -m3
Cpu 68.548 mb/sec, real 45.869 mb/sec -m3 -nommap
 
Here, memory-mapped files degrade -m2 performance even more

Всего записей: 3401 | Зарегистр. 13-08-2007 | Отправлено: 17:06 27-02-2011
egor23



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

Цитата:
Here, memory-mapped files degrade -m2 performance even more

а обратили внимание на счётчик, например в Диспетчере задач, Mem Use, что со временем памяти показывается вся доступная.
На что это оказывает влияние это уже другой вопрос, на который я не могу ответить.
 
Добавлено:
Aroyl

Цитата:
Вот ссылка на репак: Dragon Age Origins - Diamond Edition  
Нужен только первый образ - DAODE_RusEng_RePack_DVD1.iso  
Файл с которым я мучался называется Daodata1.arc, лежит в каталоге Data.  
Внутри него daomain.dat - обработаный srep'ом архив, содержащий 2 файла - daotemp1.arc (19Гб) и daotemp2.arc(5Гб), каждый из которых содержит внутри множество файлов. Я распаковывал последовательно и проблема была практически на ка

У меня проблем с распаковкой Daodata1.arc и daomain.dat не возникло.

Цитата:
Внутри него daomain.dat - обработаный srep'ом архив, содержащий 2 файла - daotemp1.arc (19Гб) и daotemp2.arc(5Гб)

про это не понял после daomain.dat получаю daomain.arc 18.5ГБ (без сжатия) внутри которого два архива arc без сжатия, точно уже непомню примерно 5ГБ и 13.5ГБ.
зачем было так делать мне непонятно.
 
Немного тестов на распаковку с -mXXX
 
srep294.exe -m1f daomain.arc daomain.arc.srep294_m1f
 
srep294.exe -d daomain.arc.srep294_m1f nul
Compression ratio: 19913271662 -> 12259186550: 61.56%. Cpu 129.241 mb/sec, real 48.617 mb/sec. Matches 0 371681 4110533, I/Os 0, MiBs 0 1415 6140
 
srep294.exe -d -nomd5 -m128k daomain.arc.srep294_m1f nul
Compression ratio: 19913271662 -> 12259186550: 61.56%. Cpu 357.891 mb/sec, real 50.095 mb/sec. Matches 0 371681 4110533, I/Os 3998, MiBs 0 436 2967
 
srep294.exe -d -nomd5 -m512k daomain.arc.srep294_m1f nul
Compression ratio: 19913271662 -> 12259186550: 61.56%. Cpu 311.145 mb/sec, real 46.650 mb/sec. Matches 0 371681 4110533, I/Os 1436, MiBs 0 475 3627
 
srep294.exe -d -nomd5 -m2m daomain.arc.srep294_m1f nul
Compression ratio: 19913271662 -> 12259186550: 61.56%. Cpu 302.217 mb/sec, real 46.532 mb/sec. Matches 0 371681 4110533, I/Os 414, MiBs 0 781 4659

Всего записей: 3831 | Зарегистр. 03-11-2003 | Отправлено: 21:00 27-02-2011
Bulat_Ziganshin

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

Цитата:
У меня проблем с распаковкой Daodata1.arc и daomain.dat не возникло.  

так дело именно в том, что проблемы возникают у одного из 10.000. если б проблемы были у большинства - всё было б ясно, а так они оказываются в дураках
 
вот из моего расследования:
U:\>fc /b lp2.pcf.srep-r G:\lp2.pcf.srep-r              
Сравнение файлов lp2.pcf.srep-r и G:\LP2.PCF.SREP-R      
91DDA103: 2B 6B                                          
BD1C6103: 9C DC                                          
 
потом объясню. но по похожим адресам и номеру бита похоже на конкретную микросхему памяти

Всего записей: 3401 | Зарегистр. 13-08-2007 | Отправлено: 21:59 27-02-2011
egor23



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

Цитата:
1. улучшения в -m3 пока не удалось реализовать. по большому счёту, если тебе не хватает памяти для кеширования всех необходимых частей файла, то остаётся только стиснуть зубы и ждать либо использовать -m1.

для меня выходом будет stdin/stdout но там сейчас не доделки, и хотелось бы чтобы у  FreeArc\Arc\unarc был полноценный stdin/stdout.

Цитата:
 compression made about 20% faster


Цитата:
3. потетстируй с -m1/2/3, с и без -nommap. особенно меня интересует окончательная разница в сжатии (после lzma) результатов -m1 vs -m3

1. Подопытный Nero-9.2.6.0_trial.tar 1883МБ, srep294_x64.exe \ srep293_x64.exe
 
Результаты..

Всего записей: 3831 | Зарегистр. 03-11-2003 | Отправлено: 22:54 27-02-2011
Bulat_Ziganshin

Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
SREP 2.95 alpha:
 
    * -mem option limits amount of RAM used for future-LZ decompression
    * -vmfile and -vmblock options fine-tunes VM file used in -mem mode
 
Tests with the same 22gb->7gb file:

Код:
       : Cpu 211.560 mb/sec, real 165.110 mb/sec. Matches 0 174390 1449482, I/Os 0, RAM 0/1919, VM    0/0, R/W 0/0
-mem1g : Cpu 203.116 mb/sec, real 151.955 mb/sec. Matches 0 174390 1482625, I/Os 0, RAM  0/983, VM 0/1000, R/W 1560/1560
-mem500: Cpu 193.556 mb/sec, real 136.138 mb/sec. Matches 0 165382 1621776, I/Os 0, RAM  0/460, VM 0/1656, R/W 3768/3768
-mem200: Cpu 146.510 mb/sec, real  99.487 mb/sec. Matches 0  70888 2376056, I/Os 0, RAM  0/160, VM 0/2136, R/W 12120/12120
-mem100: Cpu  76.815 mb/sec, real  54.448 mb/sec. Matches 0  29368 4950862, I/Os 0, RAM   0/60, VM 0/2360, R/W 36760/36760
 

 
So, we are able to decompress 22gb file with 2gb of RAM, or even with 200 mb RAM and 2gb VM file, and speed remains very high, at 100 mb/s! I think, it's outstanding result
 
Info about interpreting new decompression stats. Let's consider the following line:
 
RAM 346/1024, VM 664/984, R/W 824/1488
 
It means that there are 1024 MiB of RAM allocated, of those 346 MiB is currently used (memory is never returned to OS)
VM file is 984 MiB long, of those 664 MiB is in use now
1488 MiB were written to VM file, of those 824 MiB was already read back
VM.current = VM.W - VM.R equation is always true, here it's 664=1488-824
 
At the end of decompression, we have a sort of that:
RAM 0/983, VM 0/1000, R/W 1560/1560
i.e. two zeros and R=W, while the rest of nu,bers shows how much memory/disk was used and how much data were written to VM file
 
Also, sum of RAM and VM size required for given file decompression should be constant. Actually, it slightly grows as -mem decreased, due to inefficiencies in the memory management
 
Please also note that -mem limits total amount of RAM used, that includes 40 mb for I/O buffers, while RAM value in stats shows only memory used for match data

Всего записей: 3401 | Зарегистр. 13-08-2007 | Отправлено: 23:37 27-02-2011
egor23



Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
srep295.exe -d -mem128m -vmfile=vmfile_temp Nero-9.2.6.0_trial.tar.srep294_m3f_a4 - | 7z.exe x -si -ttar
 
Ratio: 1974371328 -> 506371254: 25.65%. Cpu 94.158 mb/sec, real 28.186 mb/sec. Matches 0 15102 286644, I/Os 0, RAM 0/88, VM 0/320, R/W 1160/1160
 
Everything is Ok
 
Folders: 57
Files: 1052
Size:       1973508786
Compressed: 568320
 
работает

Всего записей: 3831 | Зарегистр. 03-11-2003 | Отправлено: 00:14 28-02-2011
egor23



Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Bulat_Ziganshin
ну вот приехали
srep295.exe -d s-so123_512.srep s-so123.tar
Ratio: 16735272960 -> 9873103080: 59.00%. Cpu 187.707 mb/sec, real 20.837 mb/sec
  ERROR! Checksum of decompressed data is not the same as checksum of original data
 
s-so123_512.srep делался 01.12.2009 скорее всего версией 0.8
 
Добавлено:

Цитата:
ну вот приехали  
srep295.exe -d s-so123_512.srep s-so123.tar  
Ratio: 16735272960 -> 9873103080: 59.00%. Cpu 187.707 mb/sec, real 20.837 mb/sec  
  ERROR! Checksum of decompressed data is not the same as checksum of original data  
 
s-so123_512.srep делался 01.12.2009 скорее всего версией 0.8

s-so123_512.srep распакован версией 0.8
при повторной попытке c srep295.exe распаковка прошла удачно

Всего записей: 3831 | Зарегистр. 03-11-2003 | Отправлено: 02:46 28-02-2011
egor23



Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Bulat_Ziganshin
Подопытный s-so123.tar 22427МБ, srep295_x64.exe
 
Упаковка
Compression ratio: 23516088832 -> 13137073412: 55.86%. Cpu 21.334 mb/sec, real 16.087 mb/sec -m1f -a1
Compression ratio: 23516088832 -> 13137263784: 55.87%. Cpu 38.879 mb/sec, real 24.641 mb/sec -m1f -a4  
 
Лог..
 
Распаковка
srep295_x64.exe -d -mem1800m -vmfile=vmfile_temp -s s-so123.tar.srep295_m1f_a1_l512 nul
Ratio: 23516088832 -> 13137548864: 55.87%. Cpu 154.378 mb/sec, real 39.751 mb/sec. Matches 0 12626 120042, I/Os 0, RAM 0/1759, VM 0/1568, R/W 2752/2752
 
srep295_x64.exe -d -mem1800m -vmfile=vmfile_temp -s s-so123.tar.srep295_m1f_a4_l512 nul
Ratio: 23516088832 -> 13137759232: 55.87%. Cpu 155.478 mb/sec, real 44.838 mb/sec. Matches 0 9531 124168, I/Os 0, RAM 0/1759, VM 0/1504, R/W 2600/2600
 
Добавлено:
Bulat_Ziganshin
для -m1 многопоточность сделать возможно?

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



Gold Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Позволил себе наглость поправить шапку.
Что сделал:
 
1) Добавил тему по Rep и Srep. Шапка там включена, можно развить тему.
2) Добавил в архиваторы PowerArchiver и HaoZip.
 
Backup под
 
[/#]

Всего записей: 8692 | Зарегистр. 08-06-2006 | Отправлено: 15:41 28-02-2011 | Исправлено: Engaged Clown, 15:45 28-02-2011
egor23



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

Цитата:
-mem100: Cpu  76.815 mb/sec, real  54.448 mb/sec. Matches 0  29368 4950862, I/Os 0, RAM   0/60, VM 0/2360, R/W 36760/36760

хи, получается ~100ГБ total R/W HDD

Всего записей: 3831 | Зарегистр. 03-11-2003 | Отправлено: 17:49 28-02-2011
andhunt

Newbie
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Кто сможет помочь за отдельную плату осуществить такое в архиваторе?
 
можно сделать следующее в FreeArc.
 
в архиваторе есть модуль freearc-installer.sfx, который запускает setup.exe , но если в архиве были еще файлы то он их не распаковывает в текущую папку.
нужно чтобы работало следующим образом, у меня есть к примеру три файла:  
1. setup.exe  
2. primer.exe
3. primer.txt
 
я их архивирую через модуль freearc-installer.sfx , а когда уже распаковываю эти файлы setup.exe должен запуститься сам автоматически и удалиться, а оставшиеся файлы primer.exe и primer.txt должны распаковаться в текущую папку как обычно?(т.е. setup.exe после запуска удаляется , а primer.exe и primer.txt должны просто распаковаться)
как такое реализовать, если такого нет могли бы за отдельную плату подредактировать этот модуль?

Всего записей: 9 | Зарегистр. 24-02-2011 | Отправлено: 23:57 28-02-2011
V2driver



Full Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
andhunt сколько $?

Всего записей: 462 | Зарегистр. 01-02-2010 | Отправлено: 04:11 01-03-2011
Bulat_Ziganshin

Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
V2driver
и ты туда же? нельзя молча игнорировать тролля?

Всего записей: 3401 | Зарегистр. 13-08-2007 | Отправлено: 09:35 01-03-2011
slech



Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Bulat_Ziganshin
а почему троля ?
ты сам говорил о поддержке проекта.

Всего записей: 4890 | Зарегистр. 10-11-2004 | Отправлено: 10:13 01-03-2011
CDK

Junior Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Попробовал freearc-installer.sfx. Он при запуске начинает тупо распаковывать в temp без каких либо запросов. Попробовал с -s0 (по аналогии с -s2) - тогда уже не запускает в конце setup.exe. Я так понимаю что вариант с запросом куда распаковать не предусмотрен или дело не в лыжах?
ЗЫ: чего-то я rtfm никакого по freearc-installer.sfx не нашел

Всего записей: 46 | Зарегистр. 01-09-2006 | Отправлено: 10:36 01-03-2011 | Исправлено: CDK, 10:37 01-03-2011
Bulat_Ziganshin

Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
CDK
1. а зачем там спрашивать? идея именно в том, чтоб предоставить распакованные файлы для setup.exe, а он уж дальше как нужно разбросает. и вообще лучше использовать IS
2. rtfm нет поскольку в нём нечего описываать

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



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

Цитата:
так дело именно в том, что проблемы возникают у одного из 10.000. если б проблемы были у большинства - всё было б ясно, а так они оказываются в дураках


Цитата:
srep295.exe -d s-so123_512.srep s-so123.tar  
Ratio: 16735272960 -> 9873103080: 59.00%. Cpu 187.707 mb/sec, real 20.837 mb/sec  
  ERROR! Checksum of decompressed data is not the same as checksum of original data

Мысля:
Проблема в том что данные получаются битые? или в том что подсчёт md5 сбоит?
можно для тестирования сделать билд, который не прерывает распаковку?

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

Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
slech
тролль - потому что повторяет своё сообщение, разве не очевидно? соответственно, помогая таким людям, вы может и улучшите своё материальное положение, но способствуете засиранию темы и превращению её в такой же отстойник как и темы по is, рекомпрессии и пр.
 
Engaged Clown
имхо лучшая тема по srep - та, в которой никак не упоминается его название. иначе и в неё набегут пионеры
 

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

-nomd5
 
Добавлено:

Цитата:
7. может иконку кнопки Add заменить на основную FA ? по аналогии с WinRar.
тогда не мешало бы и кнопку извлечь переделать, а то какой то плейер получается  

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

Цитата:
Цитата:
разобрался. ты напоролся на известную багу в arc - если в архиве arc можно найти несжатый архив другого формата, то он откроет именно внутренний архив:
 
а что значит несжатый ?т.е. если  я упакую cab - то потом данные свои распоковать не смогу ?  

 
если он не упакуется, то извлечь можно будет с помощью 0.60 или убрав 7z.dll из каталога программы
 

Цитата:
хм, а как же создание архива ARC без пробелов в имени и успешном листинге ?  

случайное совпадение. от версии архиватора зависит, ибо 0.666 сжимает несколько иначе, сохраняя as-is несжавшиеся блоки

Всего записей: 3401 | Зарегистр. 13-08-2007 | Отправлено: 13:53 01-03-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

Рейтинг.ru