nesco писал(а):
Вопрос -- а чем отличается ASCII строка от бинарного файлаВсем. Строка - текстовая, файл бинарный.
При этом строки ограничены размером памяти, а файл - размером диска. И что характерно, размер диска почти всегда больше
В этом и засада.
Конвертор потока в hex + подсчет crc в режиме hex работают отлично, но размер файла ограничен оперативкой.
Мне надо посчитать CRC32 для файла, размером больше оперативки. Пока копаюсь с маппингом. Надо почитать, как он устроен. Автоматом не работает.
Угу, кажется догнал.
Все работает автоматом, но размер области проецирования нужно выделять больше файла.
При ее увеличении постепенно все более большие файлы начинают обретать правильный crc.
Я всегда думал, что маппинг - это когда специальным механизмом в память проецируется небольшой кусок файла, и этот механизм двигает окно проецирования по файлу в зависимости от того, к какой части файла обращаются.
Оказалось все проще - просто проецируется весь файл (или кусок) в виртуальную память.
Думаю дальше справлюсь сам - осталось механизм автоматического определения размера прикрутить.
Ага. Справился. Вот алгоритм просчета crc32 со стандартным полиномом и мапингом.
Add(MultiElementEx,1265720,420,343)
{
@Hint=#50:Вычисляет CRC32 для файла по стандартному полиному|
}
BEGIN_SDK
Add(EditMultiEx,15924144,21,21)
{
WorkCount=#23:doCRC32=Вычисляет CRC32|
EventCount=#32:onCRC32=Выдает результат в поток|
VarCount=#24:CRC32=Содержит результат|
DataCount=#54:FileName=Имя файла, для которого нужно вычислить CRC32|
Width=251
Height=214
link(doCRC32,9801317:doEvent1,[(31,27)(31,55)])
link(CRC32,5481093:Var1,[(27,179)])
}
Add(CRC16_32,14272136,168,140)
{
Type=1
Metod=4
Polynom="$EDB88320"
Init="$FFFFFFFF"
link(onResult,3622167:doValue,[])
}
Add(StreamConvertor,5062690,126,140)
{
link(onResult,14272136:doCalcCRC,[])
link(Data,2681121:Stream,[])
}
Add(Hub,9801317,42,49)
{
OutCount=4
link(onEvent1,10646425:doWork2,[])
link(onEvent2,10615924:doValue,[(118,62)(118,97)])
link(onEvent3,4306968:doWork2,[])
link(onEvent4,12286570:doEvent1,[])
}
Add(Memory,3622167,210,140)
{
}
Add(SharedStream,2681121,126,49)
{
CoreName="ass"
Point(CountFileBlock)
Point(PageMem)
link(onOpen,10615924:doClear,[(171,55)(171,104)])
link(FileName,15924144:FileName,[(132,35)(27,35)])
link(PageMem,10615924:Value,[(160,40)(220,40)(220,130)(188,130)])
}
Add(DoData,4750086,210,189)
{
link(onEventData,15924144:onCRC32,[(251,195)(251,27)])
link(Data,5481093:Var2,[])
}
Add(GetDataEx,5481093,210,174)
{
link(Data,3622167:Value,[])
}
Add(Memory,10615924,182,91)
{
Default=Integer(1)
Point(Data)
link(Data,2681121:CountFileBlock,[(188,86)(153,86)])
}
Add(Hub,12286570,70,70)
{
OutCount=4
link(onEvent1,10646425:doWork3,[(95,76)])
link(onEvent2,5062690:doConvert,[(113,83)(113,146)])
link(onEvent3,4306968:doWork3,[(102,90)])
link(onEvent4,4750086:doData,[(102,97)(102,195)])
}
Add(HubEx,10646425,91,49)
{
link(onEvent,2681121:doOpen,[])
}
Add(HubEx,4306968,98,63)
{
link(onEvent,2681121:doClose,[])
}
END_SDK
Что делает: мапит 1 блок, смотрит сколько надо, закрывает файл и еще раз мапит, но полностью весь файл.
Мне хватит. Но если кто-то попытается сделать на его основе утилиту для массовой обработки - можно немного поднять скорость, если вместо двойного мапинга рассчитывать размер блока перед открытием "вручную". Либо при первом мапинге смотреть, если текущий размер >= необходимого - не мапить второй раз.
Поиск
Друзья
Администрация