-1

I am trying to set hook on keyboard with SetWindowsHookEx and I want the program to keep running so I added while(TRUE) after the hook setted.

 int main()
 {
   SetHook();

   while (TRUE)
   {
   }

   return 0;
}

Now, this is not working for me so I searched about it and I saw this:

int main()
{
   SetHook();

   MSG msg;
   while (GetMessage(&msg, NULL, 0, 0))
   {
   }

   return 0;
}

Why is this working and while(TRUE) isn't?

Thanks

  • Can you please post a non working code too? – ptrlukas Mar 24 '18 at 10:08
  • The rest of the code is working, its a regular hook on keboard, nothing special. Its just making the program run without quit. – user3725519 Mar 24 '18 at 10:14
  • The OS cannot just arbitrarily interrupt your code, breaking into that while() loop, to make the callback. That would cause horrible re-entrancy bugs. It needs to know that the thread is in a safe state and waiting for a notification. GetMessage() is its cue. – Hans Passant Mar 24 '18 at 10:29
  • If Im understanding what you say,the while(true) its a blocking and nothing else would run, and GetMessage its like an event listener and it will listen at background and the program will keep running and performing the callback? Its the equivalent to listen in sockets that listens for connection and the program keep running, and the while(true) equivalents to recv that its a blocking call and it will stop the program from continuing – user3725519 Mar 24 '18 at 10:41
  • 1
    Sort of. GetMessage is part of the standard solution to the [producer-consumer problem](https://en.wikipedia.org/wiki/Producer%E2%80%93consumer_problem). – Hans Passant Mar 24 '18 at 11:02
  • 3
    Asking, why an API starts working, when following its documented contract, and stops working, when not following it, is not going to produce helpful answers. – IInspectable Mar 24 '18 at 13:55

2 Answers2

0

MSDN says that you need to pump messages because some hooks might be executed in your thread:

Because hooks run in the context of an application, they must match the "bitness" of the application. If a 32-bit application installs a global hook on 64-bit Windows, the 32-bit hook is injected into each 32-bit process (the usual security boundaries apply). In a 64-bit process, the threads are still marked as "hooked." However, because a 32-bit application must run the hook code, the system executes the hook in the hooking app's context; specifically, on the thread that called SetWindowsHookEx. This means that the hooking application must continue to pump messages or it might block the normal functioning of the 64-bit processes.

Anders
  • 97,548
  • 12
  • 110
  • 164
-1

while(GetMessage...) constantly retrieves pending messages from queue. Once keyboard button is pressed, associated message is retrieved by GetMessage function.

With while(TRUE) you just enter an empty loop. Thread is busy "doing nothing" so program keeps running.

ptrlukas
  • 246
  • 1
  • 8
  • `GetMesssage` is a blocking call. It usually just sits there, doing nothing. It does not *"constantly retrieve pending messages from queue"*. What's worse, this does nothing to explain, why a (low-level) keyboard hook will not be called, when the thread that installed the hook does not run a message loop. – IInspectable Mar 24 '18 at 13:58
  • I never suggested that GetMessage is non-blocking. Moreover documentation linked in my answer clearly states that it is blocking. – ptrlukas Mar 24 '18 at 14:32
  • If you cannot word it any better than the official documentation does, then don't. The way you put it reads just wrong. And none of that helps justifying, why this should be posted as an answer, as it doesn't attempt to answer the question at all. – IInspectable Mar 24 '18 at 14:36