You can use the IsWindow() function to determine if the window has been closed (i.e., destroyed).
Although this works in the most of the case, it is not "safe": when a window is destroyed its handle becomes invalid and the is ID (the handle value) can be reused by the system for another subsequently created window. If you don't look at all that while happening, IsWindow may return TRUE, but the window may not be the one you intended.
(I mean: "my name (handle) is the same of my grandfather, I was born after his death, and I live in what it was his house. But I'm not him"! But if you send a letter to him, I'll read it as mine and, hopefully, I can understand the misleading only from the context".)
I am looking for code sample which will explain how to actually pass handles from parent to child process.
A child process can inherit handles from its parent process. An inherited handle is valid only in the context of the child process. To enable a child process to inherit open handles from its parent process, use the following steps.
1.Create the handle with the bInheritHandle member of the SECURITY_ATTRIBUTES structure set to TRUE. 2.Create the child process using the CreateProcess function, with the bInheritHandles parameter set to TRUE.
Can someone please share some code sample which would help me understand how to actually use the passed handle in child process.
You described how to make the handle available in the child process, but you still need to tell the child the numerical value of the HANDLE. A common way of doing this is to pass the value as a command line parameter.
This is what I was looking for. Handles are copied in the process table of the child process if the inherit flag is set to true but how would the child process know which handle is pointing to which kernel object and which to use.
"To use a handle, the child process must retrieve the handle value and "know" the object to which it refers. Usually, the parent process communicates this information to the child process through its command line, environment block, or some form of interprocess communication."
I was looking for an sample code showing the above step(highlighted in bold).
When you create an object (like a mutex) you can specify a "name". (see CreateMutex[^]).
In the child process you can retrieve another handle to that same object with OpenMutex[^], or whatever similar and coherent with the type of object) by giving it that name (that is supposed to be unique at least between all your entangled processes).
Note that the returned value may be different, due to the fact the the handle value is an "index of a table of indexes" that is different in the various processes.
The documentation talks improperly of inheritance of handles. What are inherited are the objects the handle refers to.
After reading it, I would say you can apply the same principle to STL by using the registry entry “std\:\:.*=nostepinto” instead of “ATL\:\:.*=nostepinto”. I haven't tried though. In any case, before trying this I'd create a restore point or whatever else you usually do to undo an unlucky change. It is an undocumented feature after all, and even if it weren't, manually editing the registry isn't for the weak of heart.