» FreeArc (часть 4)

а если всё же сначала попробовать поискать среди бесплатных?
http://habrahabr.ru/blogs/iconoskaz/114508/

а, это меня фраза про "стандартные иконки" с толку сбила
"фирменную" иконку FreeArc, конечно, ни в каком готовом наборе найти не получится..

using 4x4:tor:3:2mb:h256kb
Compressed 361 files, 430,097,775 => 299,114,442 bytes. Ratio 69.5%
Compression time: cpu 18.50 secs, real 5.01 secs. Speed 85,877 kB/s

rep:16mb+4x4:tor:3:1mb
Compressed 361 files, 430,097,775 => 281,437,322 bytes. Ratio 65.4%
Compression time: cpu 17.64 secs, real 5.19 secs. Speed 82,866 kB/s


Добавлено:
using 4x4:tor:3:2mb:h256kb
Compressed 2,905 files, 236,542,287 => 186,087,534 bytes. Ratio 78.6%
Compression time: cpu 10.14 secs, real 3.23 secs. Speed 73,138 kB/s

rep:16mb+4x4:tor:3:1mb
Compressed 2,905 files, 236,542,287 => 179,805,028 bytes. Ratio 76.0%
Compression time: cpu 10.62 secs, real 3.52 secs. Speed 67,215 kB/s

Может я чего не учитываю, но разница по времени мала, а сжатие заметно.

Добавлено:
В своих тестах я эффекта от rep:32 не заметил

rep:16mb+4x4:tor:3:1mb
Compressed 2,905 files, 236,542,287 => 179,805,028 bytes. Ratio 76.0%
Compression time: cpu 10.62 secs, real 3.52 secs. Speed 67,215 kB/s

rep:16mb:32+4x4:tor:3:1mb
Compressed 2,905 files, 236,542,287 => 179,205,644 bytes. Ratio 75.7%
Compression time: cpu 12.50 secs, real 5.83 secs. Speed 40,571 kB/s


Добавлено:
Разве что только на rep:256

rep:16mb+4x4:tor:3:1mb
Compressed 2,905 files, 236,542,287 => 179,805,028 bytes. Ratio 76.0%
Compression time: cpu 10.62 secs, real 3.52 secs. Speed 67,215 kB/s

rep:16mb:256+4x4:tor:3:1mb
Compressed 2,905 files, 236,542,287 => 179,616,048 bytes. Ratio 75.9%
Compression time: cpu 11.19 secs, real 3.80 secs. Speed 62,244 kB/s

А меньше rep:256 скорее вред, чем польза.

Bulat_Ziganshin

Цитата:

-nomd5

так откуда я узнаю что сбой произошёл, если сбой связан с расчётом md5?
или всё таки установленно, что данные получаются на выходе битые?

нужно что-то наподобие http://www.7-zip.org/logos.html

http://freearc.org/download/testing/fazip01.zip

FAZip is a standalone compression utility like gzip and bzip2.
It doesn't support any cmdline options but features the same great
compression power as FreeArc itself.


I don't recommend to use it for doing real compression due to it's
lack of CRC checking, file identification and other features common
for Unix compression tools. Consider it as technology demonstration
which may sometimes grow into really useful tool. Compression methods
supported and their parameters are exactly the same as in FreeArc
(so see FreeArc.htm for details). In paricular, it supports CLS external
compressors placed in cls-*.dll and accelerated compression functions
from facompress*.dll


Usage examples:

Fast binary data compression and decompression:
Код: fazip 4x4:tor:3 example.tar example.fazip
fazip d example.fazip example.tar

slech
так есть же отдельная тема про логотип для FreeArc - вон её даже в шапку добавили
там и лежат все "нагенерированные пользователями" идеи

или о чём ты?

Bulat_Ziganshin
В чём отличае fazip.exe от arc.exe, для чего он нужен ?

sabio
не совсем о логотипе, но может в той теме и продолжить.
речь о иконках интерфейса.

ndch


Цитата:

1. freearc is an archiver while fazip is a compressor. for example, fazip can compress to nul or to stdout
2. fazip prints more stats using just one line - it's what i need for benchmarking

Первый пункт для меня более предпочтителен, ну и главное чтоб еще распаковывал в stdout.

Цитата:

Here, memory-mapped files degrade -m2 performance even more

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

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



Цитата:

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

да, я сейчас как рза над этим раюботаю. в самом srep stdin+stdout тоже что-то разладился с 18 февраля, надо разобраться


Цитата:

srep295_x64.exe -d -mem1800m -vmfile=vmfile_temp

-vmfile можно не указывать, там по дефолту future-lz.tmp


Цитата:

для -m1 многопоточность сделать возможно?

при упаковке? уже естью у меня 4-ядерник до 40% нагружается

Bulat_Ziganshin
Как дела с финальной версией ФА (0.70)? На оф. сайте висело сообщение что выйдет в декабре. В чем задержка?

Bulat_Ziganshin

Цитата:

имхо лучшая тема по srep - та, в которой никак не упоминается его название. иначе и в неё набегут пионеры

Попытка создать разжёваную тему, не получится - всегда можно удалить из закладок, пусть пионЭры между собой общаются.
Всяко разгрузит тему по пережатию.

vasulpr

Цитата:

В чем задержка

Во времени.

у мене така проблема

FA 0.666
win7 and winXP
уровень сжатия ультра с упорядочиванием файлов по расширению
3,25 Гб ОП
С свободно 4,82 Гб
D свободно 296Гб на этот проводится архивация

Цитата:

чтение входных файлов при архивации и запись выходных при распаковке идёт через кеш.

Ну кэши заполняются/сбрасываются в одном потоке (последовательно) или в разных (параллельно)?

VasulNoz
чисти диск С: Не буду объяснять почему.

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

без кеширования первый сжимающий поток сам бы читал данные из файлов

VasulNoz
в настройках программы установи tempdir на d:

Bulat_Ziganshin
FreeArc не использует больше ~2гб ram? Сжимаю с параметром -mx.

Цитата:

так откуда я узнаю что сбой произошёл, если сбой связан с расчётом md5?

fc /b с оригиналом

Цитата:

или всё таки установленно, что данные получаются на выходе битые?

да. в общем, рассказываю, что у меня было: невозможно было вообще проверить, правильно ли работает srep, из-за того что при распаковке сыпались ошибки. думал, что это из-за большого числа I/O операций при обычной распаковке, но потом оказалось, что и распаковка future-lz без ограничений памяти сбоит

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

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

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

для прикола - лог моих тестов (диск g - сбойный, напоминаю что srep создаёт врем. файл в тек. каталоге): [more=лог]F:\Temp>G:\f.cmd G:\lp2.pcf.srep-r

F:\Temp>"C:\!\FreeArchiver\Compression\SREP\srep64i.exe" -d G:\lp2.pcf.srep-r nul
Ratio: 2600468480 -> 1427841725: 54.91%. Cpu 315.115 mb/sec, real 148.644 mb/sec. Matches 16903 17275 101865, I/Os 0, RAM 470/632, VM 0/0, R/W 0/0
ERROR! Checksum of decompressed data is not the same as checksum of original data

F:\Temp>"C:\!\FreeArchiver\Compression\SREP\srep64i.exe" -d -mem1g G:\lp2.pcf.srep-r nul
Ratio: 2600468480 -> 1427841725: 54.91%. Cpu 301.439 mb/sec, real 268.311 mb/sec. Matches 16903 17275 101865, I/Os 0, RAM 470/632, VM 0/0, R/W 0/0
ERROR! Checksum of decompressed data is not the same as checksum of original data

F:\Temp>"C:\!\FreeArchiver\Compression\SREP\srep64i.exe" -d -mem500 G:\lp2.pcf.srep-r nul
Ratio: 2600468480 -> 1427841725: 54.91%. Cpu 296.611 mb/sec, real 259.126 mb/sec. Matches 13148 13520 101865, I/Os 0, RAM 291/459, VM 192/192, R/W 0/192
ERROR! Checksum of decompressed data is not the same as checksum of original data

F:\Temp>"C:\!\FreeArchiver\Compression\SREP\srep64i.exe" -d -mem200 G:\lp2.pcf.srep-r nul
Ratio: 2600468480 -> 1427841725: 54.91%. Cpu 276.444 mb/sec, real 226.211 mb/sec. Matches 11208 11580 105105, I/Os 0, RAM 158/159, VM 368/576, R/W 384/752
ERROR! Checksum of decompressed data is not the same as checksum of original data

F:\Temp>"C:\!\FreeArchiver\Compression\SREP\srep64i.exe" -d -mem100 G:\lp2.pcf.srep-r nul
Ratio: 335544320 -> 216895290: 64.64%. Cpu 294.645 mb/sec, real 224.164 mb/sec. Matches 2399 3548 6909, I/Os 0, RAM 32/59, VM 64/64, R/W 0/64^CЗавершить выполнение паке
тного файла [Y(да)/N(нет)]? y



G:\>G:\f.cmd F:\Temp\lp2.pcf.srep-r

G:\>"C:\!\FreeArchiver\Compression\SREP\srep64i.exe" -d F:\Temp\lp2.pcf.srep-r nul
Ratio: 22069494174 -> 7008860732: 31.76%. Cpu 287.307 mb/sec, real 185.588 mb/sec. Matches 0 174390 1449482, I/Os 0, RAM 0/1919, VM 0/0, R/W 0/0

G:\>"C:\!\FreeArchiver\Compression\SREP\srep64i.exe" -d -mem1g F:\Temp\lp2.pcf.srep-r nul
Ratio: 22069494174 -> 7008860732: 31.76%. Cpu 274.860 mb/sec, real 163.288 mb/sec. Matches 0 174390 1482625, I/Os 0, RAM 0/983, VM 0/1000, R/W 1560/1560

G:\>"C:\!\FreeArchiver\Compression\SREP\srep64i.exe" -d -mem500 F:\Temp\lp2.pcf.srep-r nul
Ratio: 7365197824 -> 4428665852: 60.13%. Cpu 292.157 mb/sec, real 104.050 mb/sec. Matches 4254 18705 190765, I/Os 0, RAM 156/459, VM 1440/1656, R/W 216/1656
ERROR! Checksum of decompressed data is not the same as checksum of original data

G:\>"C:\!\FreeArchiver\Compression\SREP\srep64i.exe" -d -mem200 F:\Temp\lp2.pcf.srep-r nul
Ratio: 7365197824 -> 4428665852: 60.13%. Cpu 259.695 mb/sec, real 165.344 mb/sec. Matches 4893 12391 211440, I/Os 0, RAM 152/159, VM 1464/2136, R/W 1736/3200
ERROR! Checksum of decompressed data is not the same as checksum of original data

G:\>"C:\!\FreeArchiver\Compression\SREP\srep64i.exe" -d -mem100 F:\Temp\lp2.pcf.srep-r nul
Ratio: 7365197824 -> 4428665852: 60.13%. Cpu 215.878 mb/sec, real 120.354 mb/sec. Matches 1026 8544 264278, I/Os 0, RAM 52/59, VM 1624/2360, R/W 4096/5720
ERROR! Checksum of decompressed data is not the same as checksum of original data



F:\Temp>G:\f.cmd F:\Temp\lp2.pcf.srep-r

F:\Temp>"C:\!\FreeArchiver\Compression\SREP\srep64i.exe" -d F:\Temp\lp2.pcf.srep-r nul
Ratio: 7365197824 -> 4428665852: 60.13%. Cpu 305.780 mb/sec, real 229.560 mb/sec. Matches 29409 31697 188028, I/Os 0, RAM 1382/1872, VM 0/0, R/W 0/0
ERROR! Checksum of decompressed data is not the same as checksum of original data

F:\Temp>"C:\!\FreeArchiver\Compression\SREP\srep64i.exe" -d -mem1g F:\Temp\lp2.pcf.srep-r nul
Ratio: 7365197824 -> 4428665852: 60.13%. Cpu 295.632 mb/sec, real 248.457 mb/sec. Matches 7637 27310 188028, I/Os 0, RAM 492/983, VM 952/952, R/W 0/952
ERROR! Checksum of decompressed data is not the same as checksum of original data

F:\Temp>"C:\!\FreeArchiver\Compression\SREP\srep64i.exe" -d -mem500 F:\Temp\lp2.pcf.srep-r nul
Ratio: 7365197824 -> 4428665852: 60.13%. Cpu 285.963 mb/sec, real 202.580 mb/sec. Matches 4254 18705 190765, I/Os 0, RAM 156/459, VM 1440/1656, R/W 216/1656
ERROR! Checksum of decompressed data is not the same as checksum of original data

F:\Temp>"C:\!\FreeArchiver\Compression\SREP\srep64i.exe" -d -mem200 F:\Temp\lp2.pcf.srep-r nul
Ratio: 234881024 -> 146617058: 62.42%. Cpu 307.273 mb/sec, real 102.757 mb/sec. Matches 2939 3548 6594, I/Os 0, RAM 80/107, VM 0/0, R/W 0/0^CЗавершить выполнение пакетн
ого файла [Y(да)/N(нет)]? y



U:\>G:\f.cmd U:\lp2.pcf.srep-r

U:\>"C:\!\FreeArchiver\Compression\SREP\srep64i.exe" -d U:\lp2.pcf.srep-r nul
Ratio: 22069494174 -> 7008860732: 31.76%. Cpu 277.883 mb/sec, real 198.049 mb/sec. Matches 0 174390 1449482, I/Os 0, RAM 0/1919, VM 0/0, R/W 0/0

U:\>"C:\!\FreeArchiver\Compression\SREP\srep64i.exe" -d -mem1g U:\lp2.pcf.srep-r nul
Ratio: 22069494174 -> 7008860732: 31.76%. Cpu 264.975 mb/sec, real 176.744 mb/sec. Matches 0 174390 1482625, I/Os 0, RAM 0/983, VM 0/1000, R/W 1560/1560

U:\>"C:\!\FreeArchiver\Compression\SREP\srep64i.exe" -d -mem500 U:\lp2.pcf.srep-r nul
Ratio: 22069494174 -> 7008860732: 31.76%. Cpu 248.717 mb/sec, real 155.206 mb/sec. Matches 0 165382 1621776, I/Os 0, RAM 0/460, VM 0/1656, R/W 3768/3768

U:\>"C:\!\FreeArchiver\Compression\SREP\srep64i.exe" -d -mem200 U:\lp2.pcf.srep-r nul
Ratio: 2181038080 -> 1159031584: 53.14%. Cpu 265.293 mb/sec, real 143.418 mb/sec. Matches 6845 9046 87945, I/Os 0, RAM 128/159, VM 496/576, R/W 224/720^CЗавершить выпол
нение пакетного файла [Y(да)/N(нет)]? y



F:\Temp>G:\f.cmd F:\Temp\lp2.pcf.srep-r

F:\Temp>"C:\!\FreeArchiver\Compression\SREP\srep64i.exe" -d F:\Temp\lp2.pcf.srep-r nul
Ratio: 22069494174 -> 7008860732: 31.76%. Cpu 275.395 mb/sec, real 168.174 mb/sec. Matches 0 174390 1449482, I/Os 0, RAM 0/1919, VM 0/0, R/W 0/0

F:\Temp>"C:\!\FreeArchiver\Compression\SREP\srep64i.exe" -d -mem1g F:\Temp\lp2.pcf.srep-r nul
Ratio: 22069494174 -> 7008860732: 31.76%. Cpu 265.323 mb/sec, real 154.438 mb/sec. Matches 0 174390 1482625, I/Os 0, RAM 0/983, VM 0/1000, R/W 1560/1560

F:\Temp>"C:\!\FreeArchiver\Compression\SREP\srep64i.exe" -d -mem500 F:\Temp\lp2.pcf.srep-r nul
Ratio: 22069494174 -> 7008860732: 31.76%. Cpu 249.243 mb/sec, real 137.346 mb/sec. Matches 0 165382 1621776, I/Os 0, RAM 0/460, VM 0/1656, R/W 3768/3768

F:\Temp>"C:\!\FreeArchiver\Compression\SREP\srep64i.exe" -d -mem200 F:\Temp\lp2.pcf.srep-r nul
Ratio: 22069494174 -> 7008860732: 31.76%. Cpu 185.656 mb/sec, real 103.877 mb/sec. Matches 0 70888 2376056, I/Os 0, RAM 0/160, VM 0/2136, R/W 12120/12120

F:\Temp>"C:\!\FreeArchiver\Compression\SREP\srep64i.exe" -d -mem100 F:\Temp\lp2.pcf.srep-r nul
Ratio: 22069494174 -> 7008860732: 31.76%. Cpu 94.845 mb/sec, real 59.705 mb/sec. Matches 0 29368 4950862, I/Os 0, RAM 0/60, VM 0/2360, R/W 36760/36760
[/more]

WildGoblin
1. fa может использовать больше, а именно до 4 гб с опцией -lc- при ручном тьюнинге метода сжатия
2. fa может использовать внешний lzma-x64.exe, для него тоже потребуется -lc-, но ручной настройки -m вероятно не понадобится, хватит простого -mx

Bulat_Ziganshin
Спасибо за ответ!


Цитата:

1. fa может использовать больше до 4 гб с опцией -lc- при ручном тьюнинге метода сжатия

Я видел эту опцию, но после прочитанного подумал, что не в ней дело:

Цитата:

Если 75% от общего объёма физической памяти недостаточно для выбранного алгоритма сжатия, то программа автоматически уменьшает размер словаря/блока/... так, чтобы уместиться в этот объём памяти.

У меня 8gb ram так почему же FreeArc хочет использовать всего 2 гб?
(размер файлов которые упаковываю ~3,5 гб - в те же 75% их можно целиком загнать...)

P.S. Может заменить в TotalCommander MultiArc plugin ANSI на UTF-8, а то с ANSI не распаковывает архив если в его пути есть русские имена?
[more]
Код: [FreeArc]
ID=41 72 43 01
IDPos = 0, -38, -39, -40, <SeekID>
Extension=arc
Description="FreeArc 0.666"
Archiver=Arc.exe
List="%P v --noarcext -- %AQA"
Format0="yyyy tt dd hh mm ss aaaaaaa zzzzzzzzzzzzzzz ppppppppppppppp rrrrrrrr nnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnn"
Start="^--"
End="^--"
Test="%P t --noarcext -sclUTF-8 -- %AQA"
Add="%P a {-ap%RA} --noarcext -sclUTF-8 {%S} -- %AQA @%LA"
Move="%P m {-ap%RA} --noarcext -sclUTF-8 {%S} -- %AQA @%LA"
Extract="%P e -y --noarcext -sclUTF-8 -- %AQA @%LA"
ExtractWithPath="%P x -y --noarcext -sclUTF-8 -- %AQA @%LA"
Delete="%P d --noarcext -sclUTF-8 -- %AQA @%LA"
AskHistory0=-m2
AskHistory1=-mx
AskHistory2=-max
IgnoreErrors=0
Debug=0
UnixPath=1
SkipDirsInFileList=0
SkipEmptyNames=1
BatchUnpack=1
SearchForUglyDirs=0
AskMode=2
SkipLIST=1
SkipSfxHeader=1

Bulat_Ziganshin

Цитата:

могу объяснить эффект только тем, что диск в этом месте "протёрся"

ну это проверить можно, виктория или т.п. Вам в помощь.
посмотрел s-so123_512.srep (повезло что ещё не заменил на новый), так там всё красиво с поверхностью.
так что если дело в HDD, то наверно не в поверхности дело.

Bulat_Ziganshin
1. так ты отвечай своевременно сразу на мессаги, тогда и не будут они повторяться.
2. я что-то противоправное спрашиваю или правила какие-то нарушаются, чтобы игнорить мои мессаги?

3.
Цитата:

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

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

Цитата:

У меня 8gb ram так почему же FreeArc хочет использовать всего 2 гб?

потому что он ограничен макс. размером непрерывного блока памяти. в заголовке есть статья об этом ("....2 гб")


Цитата:

Может заменить в TotalCommander MultiArc plugin ANSI на UTF-8, а то с ANSI не распаковывает архив если в его пути есть русские имена?

а с utf-8 распаковывает? несколько лет назад этот плагин не держал utf-8, сделали наконец?

Bulat_Ziganshin

Цитата:

могу объяснить эффект только тем, что диск в этом месте "протёрся"

решил проверить гипотезу, но на RAM-drive, все файлы "лежат" на RAM-drive:
RAM-drive 1200МБ
xcmd_split.TAR.pcf 933МБ
xcmd_split.TAR.pcf.srep295_l64_a4 110МБ
Методика:
делаем распаковку с -nomd5, после проверяется md5 полученного файла.
srep295.exe -d -nomd5 xcmd_split.TAR.pcf.srep295_l64_a4 xcmd_split.TAR.pcf

Что представляет из себя файлик - xcmd_split.TAR.pcf.srep295_l64_a4
srep295.exe -m3f -l64 -a4 xcmd_split.TAR.pcf xcmd_split.TAR.pcf.srep295_l64_a4
srep295.exe -d -nomd5 xcmd_split.TAR.pcf.srep295_l64_a4 nul
Ratio: 978388288 -> 114967199: 11.75%. Cpu 182.556 mb/sec, real 171.049 mb/sec. Matches 0 67098 3299595, I/Os 0, RAM 0/21, VM 0/0, R/W 0/0

Запустил тест примерно в 7:00, поставил на паузу в 13:30, т.е. прошло 6.5часов, 1300 проходов.
В итоге получилось два сбойных прохода:
772_xcmd_split.TAR.pcf в 10:56
804_xcmd_split.TAR.pcf в 11:06

fc /b w:\xcmd_split.TAR.pcf 772_xcmd_split.TAR.pcf
Сравнение файлов W:\xcmd_split.TAR.pcf и 772_XCMD_SPLIT.TAR.PCF
2D35B6E0: 00 CC
2D43A71B: 00 CC
2D4D0778: 00 CC
2DD8FAE9: 00 CC
2DD93038: 00 CC
2DD930E3: 00 CC
2DD9B49D: 00 CC
2DE50932: 00 CC

fc /b w:\xcmd_split.TAR.pcf 804_xcmd_split.TAR.pcf
Сравнение файлов W:\xcmd_split.TAR.pcf и 804_XCMD_SPLIT.TAR.PCF
2DD03C20: 00 80
2E00BA62: 00 80

fc /b 772_xcmd_split.TAR.pcf 804_xcmd_split.TAR.pcf
Сравнение файлов 772_xcmd_split.TAR.pcf и 804_XCMD_SPLIT.TAR.PCF
2D35B6E0: CC 00
2D43A71B: CC 00
2D4D0778: CC 00
2DD03C20: 00 80
2DD8FAE9: CC 00
2DD93038: CC 00
2DD930E3: CC 00
2DD9B49D: CC 00
2DE50932: CC 00
2E00BA62: 00 80

Цитата:

потому что он  ограничен макс. размером непрерывного блока памяти. в заголовке есть статья об этом ("....2 гб")

Так макс блок можно расширить с помощью параметра IMAGE_FILE_LARGE_ADDRESS_AWARE. на 32bit - 3Gb а на 64bit вообще 4Gb. Почему вы не используете эту возможность???

egor23
логично для сравнения запустить так же распаковку rar -kb. и ещё распаковку 32-битным srep, ok?

vasulpr
вот при 4 гб адресного пространства размер макс. непрерывного блока будет как раз почти 2 гб

Добавлено:

Цитата:

Как дела с финальной версией ФА (0.70)? На оф. сайте висело сообщение что выйдет в декабре. В чем задержка?

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

Bulat_Ziganshin

Цитата:

и ещё распаковку 32-битным srep

и так 32-битный, точнее 32i

Цитата:

ак же распаковку rar -kb

добавил, но тесты завтра утром планирую запустить
а на ночь поставить memtest гонять