Значит. Имеем: свою программу; чужую программу.
Хочется получить переменную-указатель, валидный в контексте нашей программы, и при этом, ссылающийся на память из адресного пространства чужой программы.
То есть, чтобы, например, чтение данных из памяти чужого процесса происходило не так:
То есть, для периодической проверки данных в памяти чужого процесса не требуется постоянного вызова РидПроцессМемори. И более того, для проверки значений отдельных полей структуры достаточно строчки "if (... dest_strunct->critical_field ...)"
"filertos" <46218@users.rsdn.ru> wrote in message news:1948644@news.rsdn.ru... > Вопрос простой. Ответа нет.
Так сделать нельзя. Два процесса имеют полностью независимые виртальные 2 или 3 Гб address space. Для того, чтобы данные можно было юзать из двух процессов придумали MMF.
Здравствуйте, wellwell, Вы писали:
W>"filertos" <46218@users.rsdn.ru> wrote in message news:1948644@news.rsdn.ru... >> Вопрос простой. Ответа нет.
W>Так сделать нельзя. Два процесса имеют полностью независимые виртальные 2 или 3 Гб address space.
2 или 3 это "пользовательская" память. а пространство 4Гб (для 32 битных)
W> Для того, чтобы данные можно было юзать из двух процессов придумали MMF.
W>Так сделать нельзя. Два процесса имеют полностью независимые виртальные 2 или 3 Гб address space. Для того, чтобы данные можно было юзать из двух процессов придумали MMF.
Можно ли расшифровать MMF? Достаточно до трех слов Дальше разберемся. Есть предположение, что это что-то типа Memory Mapping Files.
А по поводу того, что нельзя... нет ничего невозможного.
1. Можно, например, выделить память в адресном пространстве чужого процесса (с помощью VirtualAllocEx) с протекшном PAGE_EXECUTE_READWRITE; записать в эту память код своей функции; запустить thread, выполняющий эту функцию. Только тут возникает новая проблема: как получить адрес своей функции, чтобы ее можно было вызвать по инициативе собственного процесса.
2. А может быть даже есть какой-либо способ "прицепить" все адресное пространство чужого процесса к своему (возможно с убиением самого чужого процесса). А потом уже создать thread, который будет выполнять чужой процесс — а мы к тому времени будем иметь прямой доступ ко всей его памяти.
У такого способа обращения к чужой памяти 2 недостатка:
1. Нам надо постоянно обращаться к вызовам апи. А я полагаю, что это в десятки раз более медленный процесс, чем прямое обращение к требуемой памяти.
2. Если нас интересует динамический тип данных в памяти чужого процесса (скажем, список), слишком много действий нужно выполнить для проверки валидности полученных данных. Пример:
в памяти чужого процесса есть список: listhead -> {data, next} -> {data, next} -> {data, next}.
{data, next} — элемент списка (структура из двух полей), next указывает на следующий элемент списка.
Допустим, нас интересует всегда последний элемент списка. Тогда, число вызовов РидПроцессМемори будет пропорционально длине этого самого списка.
Здравствуйте, filertos, Вы писали:
F>Здравствуйте, Сергей Мухин, Вы писали:
СМ>>ReadProcessMemory СМ>>ms-help://MS.MSDNQTR.v80.en/MS.MSDN.v80/MS.WIN32COM.v10.en/debug/base/readprocessmemory.htm
F>У такого способа обращения к чужой памяти 2 недостатка: F>1. Нам надо постоянно обращаться к вызовам апи. А я полагаю, что это в десятки раз более медленный процесс, чем прямое обращение к требуемой памяти.