Извиняюсь если спрашиваю очевидные вещи, но:
вызываю с MEM_RESERVE на дофига памяти, после прога узнает сколько ей реально требуется и - MEM_COMMIT сколько надо. Вопрос: как сократить НЕПРЕРЫВНОЕ ЗАРЕЗЕРВИРОВАННОЕ пространство?

VirtualFree

Етить, похоже не понятно написал.
У Free два флага: MEM_DECOMMIT и MEM_RELEASE. DECOMMIT освобождает выделенную память. RELEASE освобождает ВСЁ пространство адресов. Мне надо УМЕНЬШИТЬ пространство адресов до необходимых размеров, например было 512МБ, а стало 10КБ - не выделенной памяти, а непрерывного адресного пространства.

IMHO можно вообще не сокращать НЕПРЕРЫВНОЕ ЗАРЕЗЕРВИРОВАННОЕ пространство:
- если далее нет XXXAlloc, то всё ОК.
- если далее есть XXXAlloc, то всёравно прога должна учитывать вариант, когда вся MEM_RESERVE будет сделана MEM_COMMIT, инече зачем так много MEM_RESERVE?

Резон: делаю VirtualAllocEx (512MB) MEM_RESERVE в WarCraftIII, гружу следующую миссию - варчик вылетает.

LocTb
>"как сократить НЕПРЕРЫВНОЕ ЗАРЕЗЕРВИРОВАННОЕ пространство?"
>"RELEASE освобождает ВСЁ пространство адресов."
Поэтому никак.
S_T_A_S_ уже ответил, что можно ничего не сокращать, т.к. зарезервированное пространство "каши не просит" и раз ты его выделил, то наверное не от балды, а в расчете на то что оно может заполнится. Вот и рассчитывай дальнейшую логику из того что оно заполнено.

А общих подходов может быть несколько. Самый простой это тот о котором ты говоришь. Прикинули сколько максимум может понадобиться и зарезервировали один раз. Если пожадничал и оказалось нужно больше, то либо выдавай exception, либо резервируй новый увеличенный блок и переписывай все в него. Если и пространство сэкономить хочется и не переписывать данные, тогда переходим к резервированию блоками, например по 1Мб (минимум 64 кБ, но уж никак не 10). Здесь опять два случая. Если больше никаких явных или скрытых аллоков не делается, то в итоге все блоки образуют один непрерывный массив. Поэтому с данными можно работать как обычно, а усложняется только управление выделением и освобожденим блоков памяти. Если же между твоими блоками данных, может втиснуться "посторонний", то придется усложнять и управление памятью и данными, т.е. если с ними нужно работать как с массивом или стримом, то придется учитывать переходы адресов между блоками.

leo
Большое спасибо, а то уж стал думать что с ума схожу- именно такие мысли и приходили в голову. Просто думал есть аналогия Realloc для резервирования. Остановился на таком методе- резервирую дофига, после выделив сколько надо- резервирую и выделяю в новом месте и копирую туда данные, старый большой блок - RELEASE. Если есть лучшие идеи -поделитесь пожалуйста.

LocTb
> "Если есть лучшие идеи - поделитесь пожалуйста"
Чтобы были идеи нужно уточнить задачу. Из слов "гружу следующую миссию" можно сделать вывод, что тебе нужно последовательно выделять несколько блоков памяти заранее неизвестных размеров. Но тогда вопрос: а почему для каждого блока нужно делать отдельный резерв. Почему нельзя писать все блоки в одно пространство: делаешь один большой резерв, а затем только commit.
И еще не совсем понятно как происходит загрузка и почему размер становится известным только в конце.

leo
Да нет, я имел ввиду вот что: зарезервировав много памяти, я в игре жму "продолжить", и после трещания винта у меня stack overflow.
С проблемой- разобрался, я просто поприбивал у некоторых страниц PAGE_GUARDE.
>"Почему нельзя писать все блоки в одно пространство: делаешь один большой резерв, а затем только commit"
Именно так и делаю.
>"И еще не совсем понятно как происходит загрузка и почему размер становится известным только в конце"
Написал прогу типа ArtMoney, оптимизированную для XP/2003- вот по-этому и не знаю сколько надо вначале памяти.
PS.: Хоть и всё работает, но теперь вначале резерв = 64МБ:)