DWORD GetWindowThreadProcessId(
HWND hWnd,
LPDWORD lpdwProcessId
);
According to the docs, the return value is the identifier of the thread that created the window. What does that mean?
I guess I'm just wondering what a threadID has got to do with the processID, what is it and what is it there for - does it validate the processID in some way? I want to just discard it because the processID is what I'm after.
CodePudding user response:
Getting the literal question out of the way up front, GetWindowThreadProcessId
[r]etrieves the identifier of the thread that created the specified window and, optionally, the identifier of the process that created the window.
That's fairly self-explanatory, so long as you understand the underlying relationships:
- Windows are owned by threads. When a thread creates a window, both enter an inseparable relationship, that lasts until the window is destroyed.
- Threads are owned by processes. Once a thread is created in a particular process, it belongs to that process until it terminates.
In other words: Every window is owned by a single thread, which in turn belongs to a single process. That relationship is fixed for the lifetime of a window.
With the documentation talking about "the identifier" it sounds as if that were unambiguous. That is not the case as the system provides two distinct ways to identify a thread (or process): By ID and by handle.
IDs (as returned by this API) are simply numeric values, such as the value 42
. They can be freely passed around, returned by and provided to command line tools, and so on. They come with no strings attached. A corollary of this is, that the meaning of a particular value changes over time.
Handles, on the other hand, are tied to the actual object. As long as a client holds a handle, the system will keep the referenced object alive. Consequently, the referenced object doesn't change, allowing clients to make assumptions about lifetimes.