Using handle between two process
-
Hamid. wrote:
You can use of EnumWindows instead FindWindow
Correct:
EnumWindowsis usually a better choice thanFindWindow, but, Hamid, you're digressing... :-DIf the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
[my articles] -
CPallini wrote:
I disagree. A window handle is unique on the system. You can post messages to the window whose that handle is assigned. At the end PostMessage is an IPC mechanism.
There is a translation mechanism. :)
CPallini wrote:
BTW handles technically are not memory addresses.
:confused: The type
void*is memory address.typedef void* HANDLE;
Maxwell Chen
Maxwell Chen wrote:
There is a translation mechanism.
Maxwell Chen wrote:
The type void* is memory address.
The type
void*is a number that may contain a memory address. Since the window handle of a particular window is the same on different process (this, for instance, allows you to use in your application the handle found withSpy++tool) and the processes have different address spaces, then window handles cannot be valid memory pointers in the context of such processes (at least IMHO ;) ). :)If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
[my articles] -
If ashtwin said what does he want to do was better than ask a general question.
Just kidding :rose:. Anyway his question is clear, he missed only the question mark:
ashtwin. wrote:
Can anybody tell is that correct or any problem in using the handle of a window in one process from some other process.
:)
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
[my articles] -
Yes you can use it. But when using it, take care about the operations. You cant use all APIs, or messages directly.
- NS - [ODBaseBtn]
Hi, thanks u all for replying. Currently i am using FindWindow() to get the handle of a dialog and using that handle i am sending the message(using PostMessage api)to this dialog(which is part of seperate process). As of now it is working fine. Thanks
-
Hi, thanks u all for replying. Currently i am using FindWindow() to get the handle of a dialog and using that handle i am sending the message(using PostMessage api)to this dialog(which is part of seperate process). As of now it is working fine. Thanks
-
Hi, thanks u all for replying. Currently i am using FindWindow() to get the handle of a dialog and using that handle i am sending the message(using PostMessage api)to this dialog(which is part of seperate process). As of now it is working fine. Thanks
ashtwin wrote:
Currently i am using FindWindow() to get the handle of a dialog and using that handle i am sending the message(using PostMessage api)to this dialog(which is part of seperate process). As of now it is working fine.
It should work fine. :)
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
[my articles] -
Hi, i am using FindWindow() function to get the handle of a dialog in one process from some other process. Can anybody tell is that correct or any problem in using the handle of a window in one process from some other process. Thanks
ashtwin wrote:
Hi, i am using FindWindow() function to get the handle of a dialog in one process from some other process. Can anybody tell is that correct or any problem...
Technically it will work, but you risk a deadlock situation if the target window is in a blocked state.
"Normal is getting dressed in clothes that you buy for work and driving through traffic in a car that you are still paying for, in order to get to the job you need to pay for the clothes and the car and the house you leave vacant all day so you can afford to live in it." - Ellen Goodman
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
-
Maxwell Chen wrote:
There is a translation mechanism.
Maxwell Chen wrote:
The type void* is memory address.
The type
void*is a number that may contain a memory address. Since the window handle of a particular window is the same on different process (this, for instance, allows you to use in your application the handle found withSpy++tool) and the processes have different address spaces, then window handles cannot be valid memory pointers in the context of such processes (at least IMHO ;) ). :)If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
[my articles]CPallini wrote:
The type void* is a number that may contain a memory address.
I am not sure, but if it is just a number, a
ULONGis just fine. Since it is defined as a pointer type (void*), it must be some address pointing to something.CPallini wrote:
Since the window handle of a particular window is the same on different process (this, for instance, allows you to use in your application the handle found with Spy++ tool) and the processes have different address spaces, then window handles cannot be valid memory pointers in the context of such processes (at least IMHO ).
I guess that creating handle and free handle are something related with global allocating memory blocks in the heap. Maybe it would be similar (not 100%) to this kind of thing below (I do not have VC++ now,
not sure). :)// Process A.
struct MyBlock
{
int a;
};
void main()
{
MyBlock* p = new MyBlock; // p = 0x00A30210
p->a = 3;
// No delete to let it being kept.
}
// Process B.
struct MyBlock
{
int a;
};
void main()
{
void* p = reinterpret_cast<void*>(0x00A30210);
cout << reinterpret_cast<myblock*>(p)->a;
}
Maxwell Chen
-
CPallini wrote:
The type void* is a number that may contain a memory address.
I am not sure, but if it is just a number, a
ULONGis just fine. Since it is defined as a pointer type (void*), it must be some address pointing to something.CPallini wrote:
Since the window handle of a particular window is the same on different process (this, for instance, allows you to use in your application the handle found with Spy++ tool) and the processes have different address spaces, then window handles cannot be valid memory pointers in the context of such processes (at least IMHO ).
I guess that creating handle and free handle are something related with global allocating memory blocks in the heap. Maybe it would be similar (not 100%) to this kind of thing below (I do not have VC++ now,
not sure). :)// Process A.
struct MyBlock
{
int a;
};
void main()
{
MyBlock* p = new MyBlock; // p = 0x00A30210
p->a = 3;
// No delete to let it being kept.
}
// Process B.
struct MyBlock
{
int a;
};
void main()
{
void* p = reinterpret_cast<void*>(0x00A30210);
cout << reinterpret_cast<myblock*>(p)->a;
}
Maxwell Chen
Maxwell Chen wrote:
I am not sure, but if it is just a number, a ULONG is just fine. Since it is defined as a pointer type (void*), it must be some address pointing to something.
(1) Just a number? a memory address is a number. An window handle is more than a memory address: it is a unique number in the system context (i.e. the same for all processes) identifying a window.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
[my articles] -
Maxwell Chen wrote:
I am not sure, but if it is just a number, a ULONG is just fine. Since it is defined as a pointer type (void*), it must be some address pointing to something.
(1) Just a number? a memory address is a number. An window handle is more than a memory address: it is a unique number in the system context (i.e. the same for all processes) identifying a window.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
[my articles] -
CPallini wrote:
The type void* is a number that may contain a memory address.
I am not sure, but if it is just a number, a
ULONGis just fine. Since it is defined as a pointer type (void*), it must be some address pointing to something.CPallini wrote:
Since the window handle of a particular window is the same on different process (this, for instance, allows you to use in your application the handle found with Spy++ tool) and the processes have different address spaces, then window handles cannot be valid memory pointers in the context of such processes (at least IMHO ).
I guess that creating handle and free handle are something related with global allocating memory blocks in the heap. Maybe it would be similar (not 100%) to this kind of thing below (I do not have VC++ now,
not sure). :)// Process A.
struct MyBlock
{
int a;
};
void main()
{
MyBlock* p = new MyBlock; // p = 0x00A30210
p->a = 3;
// No delete to let it being kept.
}
// Process B.
struct MyBlock
{
int a;
};
void main()
{
void* p = reinterpret_cast<void*>(0x00A30210);
cout << reinterpret_cast<myblock*>(p)->a;
}
Maxwell Chen
Maxwell Chen wrote:
I am not sure, but if it is just a number, a ULONG is just fine. Since it is defined as a pointer type (void*), it must be some address pointing to something.
(1) Just a number? a memory address is a number. A window handle is more than a memory address: it is a unique number in the system context (i.e. the same for all processes) identifying one particular window. Even supposing it is a memory address it cannot be a memory address in the context of any process in the user space, i.e. deferencing it in such processes is meaningless.
Maxwell Chen wrote:
I guess that creating handle and free handle are something related with global allocating memory blocks in the heap
There's no hope to obtain shared memory the way you depicted. the
reinterpret_casthas nothing to do with it (BTW it acts always in the context of the running process and it doesn't changes the pointer address). If you want shared memory you've to askWindowsaHANDLE, i.e. a number: theOSitself will never return to you a direct pointer to. MSDN [^] states: Memory objects allocated by GlobalAlloc and LocalAlloc are in private, committed pages with read/write access that cannot be accessed by other processes. Memory allocated by using GlobalAlloc with GMEM_DDESHARE is not actually shared globally as it is in 16-bit Windows. This value has no effect and is available only for compatibility. Applications requiring shared memory for other purposes must use file-mapping objects. Multiple processes can map a view of the same file-mapping object to provide named shared memory. For more information, see File Mapping. [added] See also http://en.wikibooks.org/wiki/Windows_Programming/Handles_and_Data_Types[^] [/added] :)If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
-
I mean why it is not defined as below? :confused:
typedef ULONG HANDLE;
Maxwell Chen
I don't know, but I can guess that 64-bit version of
Windowsuse 64-bitHANDLEs. :)If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
[my articles] -
Maxwell Chen wrote:
I am not sure, but if it is just a number, a ULONG is just fine. Since it is defined as a pointer type (void*), it must be some address pointing to something.
(1) Just a number? a memory address is a number. A window handle is more than a memory address: it is a unique number in the system context (i.e. the same for all processes) identifying one particular window. Even supposing it is a memory address it cannot be a memory address in the context of any process in the user space, i.e. deferencing it in such processes is meaningless.
Maxwell Chen wrote:
I guess that creating handle and free handle are something related with global allocating memory blocks in the heap
There's no hope to obtain shared memory the way you depicted. the
reinterpret_casthas nothing to do with it (BTW it acts always in the context of the running process and it doesn't changes the pointer address). If you want shared memory you've to askWindowsaHANDLE, i.e. a number: theOSitself will never return to you a direct pointer to. MSDN [^] states: Memory objects allocated by GlobalAlloc and LocalAlloc are in private, committed pages with read/write access that cannot be accessed by other processes. Memory allocated by using GlobalAlloc with GMEM_DDESHARE is not actually shared globally as it is in 16-bit Windows. This value has no effect and is available only for compatibility. Applications requiring shared memory for other purposes must use file-mapping objects. Multiple processes can map a view of the same file-mapping object to provide named shared memory. For more information, see File Mapping. [added] See also http://en.wikibooks.org/wiki/Windows_Programming/Handles_and_Data_Types[^] [/added] :)If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
:)
Maxwell Chen
-
A handle is actually a memory address. The handle (AKA: memory address) which you get from another process may be invalid to current process, because each process has its own view to memory (memory paging issue).
Maxwell Chen
That really is wrong. Handles in Windows are opaque - they can be anything the system implements them as. Whether they are pointers, indexes, integers, floats, or anything else is irrelevant to the programmer. All Windows handles are documented as to whether they are local to a process or system-wide. Window handles (HWND) are system-wide, so they are the same regardless of the process using them. Mark
Mark Salsbery Microsoft MVP - Visual C++ :java:
-
ashtwin wrote:
Hi, i am using FindWindow() function to get the handle of a dialog in one process from some other process. Can anybody tell is that correct or any problem...
Technically it will work, but you risk a deadlock situation if the target window is in a blocked state.
"Normal is getting dressed in clothes that you buy for work and driving through traffic in a car that you are still paying for, in order to get to the job you need to pay for the clothes and the car and the house you leave vacant all day so you can afford to live in it." - Ellen Goodman
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
-
Hi, in ur view which API can cause the deadlock(FindWindow() or PostMessage()). I don't think that PostMessage() can cause a deadlock. Thanks
FindWindow()internally sends each top-level window aWM_GETTEXTmessage. But if the thread that owns that window is blocked (e.g., a Semaphore, a Mutex, an Event, an I/O operation),SendMessage()will block until that thread frees up and runs. Since this could potentially never happen,FindWindow()will block forever."Normal is getting dressed in clothes that you buy for work and driving through traffic in a car that you are still paying for, in order to get to the job you need to pay for the clothes and the car and the house you leave vacant all day so you can afford to live in it." - Ellen Goodman
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
