CODEWITHSUNDEEP
cwindows
t0m9er
t0m9er

Reputation: 143

Return convention in windows

I came across this function:

DWORD WINAPI GetWindowThreadProcessId(
  _In_      HWND    hWnd,
  _Out_opt_ LPDWORD lpdwProcessId
);

GetWindowThreadProcessId:

This is a function that gets as input a handle to a window, and a pointer.

When it returns, *pointer hold the PID of the process which the hWnd belong to. The return value is the TID of the thread which the hWnd belong to.

What makes MS engineers choose to return the TID as return value, and write the to the address given as a parameter the PID? Why not the other way around? Return PID and write TID? Why not return both in a pointer to a struct which holds struct{TID,PID}?

What govern those choices? is there logic behind it?

Upvotes: 0

Views: 96

Answers (1)

Adrian McCarthy
Adrian McCarthy

Reputation: 47962

Windows are owned by threads and threads are owned by processes.

If you want just the thread ID, you don't want to waste any time getting the process ID. And if you want the process ID, you're going to have to get the thread ID first.

This maps directly to the GetWindowThreadProcessId API:

  • If all you need is the thread ID, you can ask for it and not pay the cost of also looking up the process ID (by setting lpdwProcessId to null).
  • If you need the process ID, then there's no harm in also getting the thread ID, since it's a necessary intermediate step.

So I hope this explains why it returns the TID and indirectly stores the PID through a pointer (and not the other way around). This should also make it clear why it doesn't return a struct with both values.

Why not have two separate functions: GetWindowThreadID and GetThreadIDProcessID? If you need the thread ID, you call the first, and if you need the process ID, you call both. My guess is that GetWindowThreadProcessId can do the second step a little more efficiently than if you had to do it as a distinct step.

Upvotes: 2

Related Questions