Сообщение Re[3]: VirtualAlloc и MapViewOfFile от 17.02.2018 11:46
Изменено 17.02.2018 13:30 Poseidon
Re[3]: VirtualAlloc и MapViewOfFile
Здравствуйте, Alexander G, Вы писали:
AG>AWE вообще не для этого, а чтобы получить доступ к большому объёму физической памяти.
AG>С учётом того, что x86 версии Windows всё равно ограничены 4 ГБ физической памяти,
AG>а на х64 можно получить её куда более простым способом, собрав 64-битное приложение, AWE сейчас вообще ни для чего не нужно.
спасибо! тогда еще такой вопрос. есть 2 сценария работы в моем приложении. какой лучше?
суть в том что создается максимально большой объем памяти, туда проецируются данные из основного файла, дополнительных файлов, обрабатываются и сохраняются в основном файле.
Сценарий 1 —
1. CreateFileMapping для основного файла, но максимально большого размера, БОЛЬШЕ самого файла.
2. MapViewOfFile также максимально большого размера
3. (по частям) маппим другие файлы в отдельный буфер и копируем (добавляем) его в область маппинга основного файла, обрабатываем
4. UnmapViewOfFile — сохраняем данные в файл с оригинальным именем, но большего размера чем оригинальный
Сценарий 2 —
1. создаем основной буфер максимально большого размера (VirtualAlloc)
2. (по частям) маппим ВСЕ файлы (включая основной) в отдельный буфер и затем копируем (добавляем) в основной, обрабатываем
3. сохраняем основной буфер на диск функцией WriteFile?
4. очистка VirtualFree
AG>AWE вообще не для этого, а чтобы получить доступ к большому объёму физической памяти.
AG>С учётом того, что x86 версии Windows всё равно ограничены 4 ГБ физической памяти,
AG>а на х64 можно получить её куда более простым способом, собрав 64-битное приложение, AWE сейчас вообще ни для чего не нужно.
спасибо! тогда еще такой вопрос. есть 2 сценария работы в моем приложении. какой лучше?
суть в том что создается максимально большой объем памяти, туда проецируются данные из основного файла, дополнительных файлов, обрабатываются и сохраняются в основном файле.
Сценарий 1 —
1. CreateFileMapping для основного файла, но максимально большого размера, БОЛЬШЕ самого файла.
2. MapViewOfFile также максимально большого размера
3. (по частям) маппим другие файлы в отдельный буфер и копируем (добавляем) его в область маппинга основного файла, обрабатываем
4. UnmapViewOfFile — сохраняем данные в файл с оригинальным именем, но большего размера чем оригинальный
Сценарий 2 —
1. создаем основной буфер максимально большого размера (VirtualAlloc)
2. (по частям) маппим ВСЕ файлы (включая основной) в отдельный буфер и затем копируем (добавляем) в основной, обрабатываем
3. сохраняем основной буфер на диск функцией WriteFile?
4. очистка VirtualFree
Re[3]: VirtualAlloc и MapViewOfFile
Здравствуйте, Alexander G, Вы писали:
AG>AWE вообще не для этого, а чтобы получить доступ к большому объёму физической памяти.
AG>С учётом того, что x86 версии Windows всё равно ограничены 4 ГБ физической памяти,
AG>а на х64 можно получить её куда более простым способом, собрав 64-битное приложение, AWE сейчас вообще ни для чего не нужно.
получается в 32 битном приложении нереально выделить область памяти более 1 гб без особых ухищрений? даже опция линкера не особо помогла, вместо 940 мегабайт система выделяет всего 1150
AG>AWE вообще не для этого, а чтобы получить доступ к большому объёму физической памяти.
AG>С учётом того, что x86 версии Windows всё равно ограничены 4 ГБ физической памяти,
AG>а на х64 можно получить её куда более простым способом, собрав 64-битное приложение, AWE сейчас вообще ни для чего не нужно.
получается в 32 битном приложении нереально выделить область памяти более 1 гб без особых ухищрений? даже опция линкера не особо помогла, вместо 940 мегабайт система выделяет всего 1150