windows WaitForMultipleObjects / MsgWaitForMultipleObjects difference

I'm trying to understand the difference between MsgWaitFor and WaitFor functions.

1) I understand that the MsgWaitFor is running under a message loop, while the WaitFor does not?
2) Does the MsgWaitFor functions is better for an application that need to receive a sequence of events in a row? Does Windows queues the messages, so the application won't miss any events? Say application wants to receive event A and B which happens frequently. The application will open a thread:

while (1) {
  ret = WaitForMultipleObjects(...); // wait for events A and B
  if (ret == WAIT_OBJECT_0) {
    process_event();
  }
}

The question is, when the thread is busy with processing, meaning it is currently not blocked by WaitForMultipleObjects. How can the thread avoid missing the events until it goes back to waiting?

I'm trying to understand the difference between MsgWaitFor and WaitFor functions.

The main difference is MsgWaitForMultipleObjects/MsgWaitForMultipleObjectsEx can wait for messages (in message queue) in addition to the following object types:

• Change notification
• Console input
• Event
• Memory resource notification
• Mutex
• Process
• Semaphore
• Thread
• Waitable timer

So if you have a thread that creates windows, use MsgWaitForMultipleObjects or MsgWaitForMultipleObjectsEx, rather than WaitForMultipleObjectsEx.

The question is, when the thread is busy with processing, meaning it is currently not blocked by WaitForMultipleObjects. How can the thread avoid missing the events until it goes back to waiting?

Message has queue and the queue has a length (10,000 posted messages). So when processing messages too slow, the PostMessage may fails with ERROR_NOT_ENOUGH_QUOTA. But for receiver side, you will not miss messages and you can handle queued messages one by one.

Event object has no queue and it has two state: signaled and nonsignaled. Setting an event that is already set has no effect. So if this is a manual-reset event object, it remains signaled until it is set explicitly to the nonsignaled state by the ResetEvent function. There may be a miss at setting side instead of checking side.