ReadProcessMemory

[Mfcer__]

есть функция ReadProcessMemory() которая в msdn описана так

Код:

BOOL ReadProcessMemory)
  HANDLE hProcess,
  LPCVOID lpBaseAddress,
  LPVOID lpBuffer,
  SIZE_T nSize,
  SIZE_T* lpNumberOfBytesRead
:;

соответственно параметр lpBaseAddress описан так

lpBaseAddress
[in] Pointer to the base address in the specified process from which to read. Before any data transfer occurs, the system verifies that all data in the base address and memory of the specified size is accessible for read access. If this is the case, the function proceeds; otherwise, the function fails.

Но не пойму откуда брать этот lpBaseAddress,
еслия укажу 0, то будет читаться с самомого начала процесса?
И как мне узнать до скольки максисмум это значение можно увеличивать, то есть сколько всего занимает в памяти процесс?

если кто то с этим работал ... буду рад помощи  

[Mad]

Посмотри описание функции VirtualQueryEx

[lapulya]

Читай рихтера, у него описано в каких ОС какие адреса валидны (точнее доступны для чнения, а какие для записи и т.д.) по поводу размера хехехе в твоем распоряжении 4Гб (речь идет о 32 разрядных платформах) если конечно процесс адекватный (дело в том что есть процессы, правда таких не много, которые могут адресовать например более 4 Гб адресного пространства и т.д.)

[lapulya]

Mfcer__, Кстати, я никогда этим не занимался, но знаю что VirtualQueryEx - далекооо не самая быстрая функция..., но одна из не многих, которая способна помочь при работе с распределением и т.д. памяти

[Mad]

Читай рихтера, у него описано в каких ОС какие адреса валидны (точнее доступны для чнения, а какие для записи и т.д.) по поводу размера хехехе в твоем распоряжении 4Гб (речь идет о 32 разрядных платформах) если конечно процесс адекватный (дело в том что есть процессы, правда таких не много, которые могут адресовать например более 4 Гб адресного пространства и т.д.)

В Windows реализован зашишенный режим, с постраничной адрисацией. Таким образом память процесса разделенна на страницы, и у каждой страницы свой номер (сегментный адрес) и свой дескриптор доступа. Кстати и свой размер, так что если ты будеш предполагать что доступно 4Гб, а на самом деле размер страницы 4Кб, то очен скоро получеш ошибку зашиты

[lapulya]

Mad, есть физический адрес и виртуальный (логический) это так называемое вируальное адресное пространство (и кстати от оно то как раз и защищено цитирую

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

), так вот оно едино и не делимо с точки зрения программиста, когда программист прикладного ПО пишет программу он большей частью общается и менно с виртуальной памятью (вот в частности те адреса что ты видишь в дебаггере это чистой воды виртуальная память) и к физической памяти ни какого отношения не имеет(точнее имеет но только косвенное ниже объясню)!!! (не надо путать теплое с мягким :!: ), так вот процессу доступно 4Гб если есть сомнения   ... берем рихтера и читаем

ЧАСТЬ III УПРАВЛЕНИЕ ПАМЯТЬЮ
ГЛАВА 13
Каждому процессу выделяется собственное виртуальное адресное пространство. Для 32-разрядных процессов его размер составляет 4 Гб. Соответственно 32-битный указатель может быть любым числом от 0x00000000 до 0xFFFFFFFF Всего, таким образом, указатель может принимать 4 294 967 296 значений, что как раз и перекрывает четырехгигабайтовый диапазон. Для 64-разрядных процессов размер адресного пространства равен 16 экзабайтам, поскольку 64-битный указатель может быть любым числом от 0x00000000 00000000 до 0xFFFFFFFF FFFFFFFF и принимать 18 446 744 073 709 551 616 значений, охватывая диапазон в 16 экзабайтов, Весьма впечатляюще!

если заинтересовало читай всю главу...
относится

Вот смотри что у нас есть ... Трансляция виртуального адреса на физический !!! чувствуешь чем пахнет....

вот еще пояснения к сожалению без картинки

Теперь посмотрим, что происходит, когда поток пытается получитьдоступ к блокуданных в адресном пространстве своего процесса. А произойти может одно из двух (рис. 13-2).
В первом сценарии данные, к которым обращается поток, находятся в оперативной памяти. В этом случае процессор проецирует виртуальный адрес данных на физический, и поток получает доступ к нужным ему данным.

Во втором сценарии данные, к которым обращается поток, отсутствуют в оперативной памяти, но размещены где-то в страничном файле. Попытка доступа к данным генерирует ошибку страницы (page fault), и процессор таким образом уведом ляет операционную систему об этой попытке. Тогда операционная система начинае! искать свободную страницу в оперативной памяти; если таковой нет, система вынуждена освободить одну из занятых страниц. Если занятая страница не модифицировалась, она просто освобождается; в ином случае она сначала копируется из оператив-

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

Чем чаще системе приходится копировать страницы памяти в страничный файл и наоборот, тем болыпе нагрузка на жесткий диск и тем медленнее работает операционная система (При этом может получиться так, что операционная система будет гратить все свое время на подкачку страниц вместо выполнения программ.)

короче рекомендую почитать рихтера...