WinGetMsg operates essentially as a loop that waits for message activity and returns messages to the user. Conceptually the application's code acts as an inverted subroutine of WinGetMsg. This was illustrated in The PM Messaging Environment.

These are the essential steps in WinGetMsg processing:

• When WinGetMsg wakes, it first unlocks the System Queue if owned or if it is the active thread.

  The MQ of the current system queue owner is pointed to by pmqsyslock. This is set to zero if this points to the MQ of the current thread.

  The active thread is the thread that has the right to unlock to system queue if locked by another thread. Normally this is the thread that manages the MQ of the window in focus. Normally the thread that has locked the system queue is the active thread.

• The received list is checked.

  If SMSs are queued then each is removed successively and the corresponding window procedure is called.

  Received messages, that is messages sent via WinSendMsg to this thread, are not returned by WinGetMsg. The window procedure is called directly.

• The application's queue is checked for posted messages.

  If one is found it is dequeued and returned to the application.

• If no posted message is found then WinGetMsg tries to process the system queue.

• We attempt to lock the system queue if free.

  if pmqsyslock is zero it is set to the current thread's MQ address.

• If the lock was successful then we peek the next system queue message.

  If the lock was unsuccessful we return to the beginning of the loop and wait on the message queue semaphore.

• If the next system message is for this thread then it is dequeued and returned to the application with the system queue lock still held.

  The possibility of holding the system queue lock while running in user code is vital to note. While this happens only active thread can dequeue a system queue message. The reason for holding the system queue lock is for performance. It is likely that one system message will be followed by a sequence for the same thread. If the lock was released, unnecessary processing on other message queue threads would take place. More recently queued messages could not be processed out of turn anyway, since the interpretation of a system message depends upon the outcome of the preceding system message.

• If the next system message is for another application then the system queue is unlocked.

• The other application is made the current input receiver.

  PM distinguishes between current mouse, keyboard and event receiver. WinGetMsg makes the other application the current mouse, keyboard or event receiver depending upon the message category.

• Finally the other application's message queue semaphore is posted. WinGetMsg returns to the beginning of its message loop by waiting on its own message semaphore for more message activity.

This processing is illustrated in the following diagram: