Как правильно выставить параметры в функции MapViewOfFile если нужно только часть файла В одном из уроков Iczelion'а Win32 API. Урок 13. Memory Mapped файлы Расказывается как можно пpомэппиpовать файл при помощи функции CreateFileMapping Код (Text): invoke CreateFileMapping,hFileRead,NULL,PAGE_READONLY,0,0,NULL Там же пишется что сpазу же после создания выходного файла, мы вызываем MapViewOfFile, чтобы пpомэппиpовать желаемую поpцию MMF в память. Код (Text): invoke MapViewOfFile,hMapFile,FILE_MAP_READ,0,0,0 В последних трёх параметрах выставлены нули Что означает что в этом примере файл читается весь После вызова MapViewOfFile получаете указатель на блок памяти, котоpый содеpжит данные из файла. Пробывал у себя протестировать всё получается нормально функция возвращает адрес как и положено Но если мне нужен не весь файл а только его часть (например начиная с пятисотого байта) Как я не пытался подставлять в последних параметрах числа Например вот так: Код (Text): invoke MapViewOfFile,hMapFile,FILE_MAP_READ,0,500,0 Всё равно функция возвращает ноль Подскажите пожалуйста как правильно нужно записывать последнии три параметра
AllocationGranularity = 65536 Только как и что записать в параметрах чтобы загнал в память именно с пятисотого байта честно говоря не понял
C пятисотого не получится. Только блоками кратными granularity. А в чем проблема адресовать пятисотый байт в блоке?
Partner Спасибо за подсказки. Более менее с твоей помощью разобрался. Отображать файл только блоками кратными granularity это не слишком удобно (хотя не исключено что я ошибаюсь). В принцыпи я так понял что (например для моих целей) лучше не заморачиватся, а ставить последними параметрами одни нули, то есть отображать в память весь файл, ну и работать с ней как с обычной памятью стандартными средствами. Например так: Код (Text): invoke CreateFileMapping,hFileRead,NULL,PAGE_READONLY,0,0,NULL mov hMapFile,eax invoke MapViewOfFile,hMapFile,FILE_MAP_READ,0,0,0 mov pMemory,eax mov esi,pMemory add esi,500 Ещё раз спасибо.
В отображении файла в память вообще только одно "удобство" - автоматическая подгрузка данных с диска по мере обращения к ним. Если ты собираешься обрабатывать не часть(части) файла, а весь целиком, то и маппинг тут по большому счету не нужен - проще самому выделить память и считать в нее файл целиком
leo В свете "последних событий" такими советами лучше просто так не бросаться. Мегабайта по четыре за раз с отключённой буферизацией, как Вы сами когда-то советовали. И ну не в кучу же.
l_inc Ну если речь идет о копировании больших файлов, то ес-но незачем ими засорять память А вот насчет "не в кучу же" - не понял, или я, или ты Непосредственно в куче выделяются блоки размером не более 512К (и смысла нет, и структура виндовой кучи не позволяет), а все, что больше по любому выделяется отдельно через VirtualAlloc и в куче хранится только список адресов этих виртуал-блоков
leo Речь не совсем об этом. Даже если бы эти четыре метра выделялись в самой куче, это не особо бы повлияло на её фрагментацию. Тут скорее проблема в том, что создаются дополнительные структуры данных для нового блока (например, в том же выделенном через VirtualAlloc блоке), а указатель возвращается не особо-то выравненный, что, например, важно для небуферизованного чтения. Ну и к тому же на страницу больше нужного выделяется.
