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.