Форум программистов «Весельчак У»
  *
Добро пожаловать, Гость. Пожалуйста, войдите или зарегистрируйтесь.
Вам не пришло письмо с кодом активации?

  • Рекомендуем проверить настройки временной зоны в вашем профиле (страница "Внешний вид форума", пункт "Часовой пояс:").
  • У нас больше нет рассылок. Если вам приходят письма от наших бывших рассылок mail.ru и subscribe.ru, то знайте, что это не мы рассылаем.
   Начало  
Наши сайты
Помощь Поиск Календарь Почта Войти Регистрация  
 
Страниц: [1]   Вниз
  Печать  
Автор Тема: ReadProcessMemory  (Прочитано 10985 раз)
0 Пользователей и 1 Гость смотрят эту тему.
Mfcer__
Команда клуба

ru
Offline Offline

« : 28-09-2004 22:56 » 

есть функция 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
Гость
« Ответ #1 : 16-10-2004 13:34 » 

Посмотри описание функции VirtualQueryEx
Записан
lapulya
Молодой специалист

ru
Offline Offline

« Ответ #2 : 18-10-2004 07:14 » new

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

С уважением Lapulya
lapulya
Молодой специалист

ru
Offline Offline

« Ответ #3 : 18-10-2004 07:24 » 

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

С уважением Lapulya
Mad
Гость
« Ответ #4 : 18-10-2004 11:07 » 

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


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

ru
Offline Offline

« Ответ #5 : 18-10-2004 12:10 » 

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), и процессор таким образом уведом ляет операционную систему об этой попытке. Тогда операционная система начинае! искать свободную страницу в оперативной памяти; если таковой нет, система вынуждена освободить одну из занятых страниц. Если занятая страница не модифицировалась, она просто освобождается; в ином случае она сначала копируется из оператив-

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

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



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

С уважением Lapulya
Страниц: [1]   Вверх
  Печать  
 

Powered by SMF 1.1.21 | SMF © 2015, Simple Machines