Главная страница
Top.Mail.Ru    Яндекс.Метрика
Текущий архив: 2003.01.13;
Скачать: CL | DM;

Вниз

Вопрос о адресном пространстве.   Найти похожие ветки 

 
Демонов Е.В. ©   (2002-11-26 05:36) [0]

Такой вопрос возник у меня когда я разбирался с работой с буфером обмена через API.

H:=GetClipboardData;
p:=GlobalLock(h);

//Работаем с p

ClobalUnlock(h);

Так вот не совсем понятно - Информация в буфере обмена находится вне адресного пространства моего процесса. А потом я получаю указатель p и работаю с ним - значит уже в моём адресном постранстве - Так вот не понятно или GetClipboardData перемещает данные буфера обмена в адресное пространство моего ппроцесса или GlobalLock ?

И второй вопрос - Функция GlobalAlloc выделяет память в адресном пространстве вызывающего её процесса или ?

P.S:Могут быть неточночти в названиях функций ну смысел понятен.


 
Демонов Е.В. ©   (2002-11-26 06:31) [1]

Мастера !?!?!?!?!?!?


 
Юрий Зотов ©   (2002-11-26 09:21) [2]

По всей видимости, при таких операциях система использует некую разделяемую память (memory mapped file с 0xFFFFFFFF), а наша программа просто получает доступ к ней путем ее отображения на адресное пространство программы.

По поводу GlobalAlloc:
The GlobalAlloc function allocates the specified number of bytes from the heap. In the linear Win32 API environment, there is no difference between the local heap and the global heap .


 
Демонов Е.В. ©   (2002-11-26 10:06) [3]

>>По поводу GlobalAlloc:
Ответьте - Да или Нет.
ClobalAlloc - Выделяет память в адресном пространстве вызывающего её процесса ?


 
Игорь Шевченко ©   (2002-11-26 12:15) [4]


> ClobalAlloc - Выделяет память в адресном пространстве вызывающего
> её процесса ?


Да


 
Юрий Зотов ©   (2002-11-26 13:01) [5]

> Демонов Е.В. © (26.11.02 10:06)

Ну сами прикиньте, что может означать фраза:
In the linear Win32 API environment, there is no difference between the local heap and the global heap.

В Win32 используются 32-битные адреса. Такой адрес может иметь значение от 0 до 4-х Gb (меньше 0 не бывает, а больше 4-х Gb просто не умещается в 32-х битах).

И адресное пространство процесса - тоже 4 Gb, ни больше, ни меньше. Стало быть, ЛЮБОЙ адрес внутри процесса может относиться ТОЛЬКО к его собственному адресному пространству, и ни к какому другому.

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

Поэтому любая функция, возвращающая АДРЕС, всегда возвращает его именно в контексте вызвавшего ее процесса. А уж с чем там этот адрес на самом деле связан - это процессу до лампочки, он работает со СВОИМ адресом, вот и все. С ЧУЖИМ он работать просто не может.

Потому и нет разницы между local и global хипами. Точнее, global хипа для процесса как бы просто не существует. С другой стороны, можно сказать и наоборот, что для процесса не существует local хипа. То есть, у процесса только одна память - она же local, она же global. И вся она - его собственная. Ни про какие другие "памяти" ему ничего не известно - как раз потому, что ему выделяется максимальное количество памяти, которое в принципе может быть адресовано.

Ну, вот, на пальцах примерно так.


 
Victor_Cr ©   (2002-11-26 13:12) [6]

2 Демонов Е.В. © (26.11.02 10:06)
На всякий случай добавлю. Это совсем не означает что твое приложение будет больше памяти кушать. В памяти всегда будет только один буфер обмена сколько раз бы ты не делал GlobalAlloc. Практически полная аналогия с ДЛЛ-ками. Однократно загруженый код многократно отображается различным процессам.



Страницы: 1 вся ветка

Текущий архив: 2003.01.13;
Скачать: CL | DM;

Наверх




Память: 0.48 MB
Время: 0.013 c
1-37197
Andy BitOff
2002-12-30 22:18
2003.01.13
ScrollBar


14-37275
hatchy
2002-12-25 15:37
2003.01.13
РаЗВЕ ЭТО НЕВОЗМОЖНО СДЕЛАТЬ?


4-37445
Spyx
2002-11-22 14:43
2003.01.13
Процессы


1-37126
Stas_a
2003-01-04 15:05
2003.01.13
Перехват OnCLick в компоненте.


8-37222
Hooch
2002-09-25 08:28
2003.01.13
Графическая библиотека