Windows apps can painlessly create new threads of execution and operate user interfaces from within those threads of execution. There are no special demands on this type of thread in order to process hardware events and/or window messages.
Under win3, one application essentially represents one thread. Each thread had an input queue created for it automatically as part of the application initialization sequence. This thread would create windows; this thread would process window messages to those windows.
Under Win32, one application may represent many threads. Any thread will be allowed to create a window; the creator thread will be the recipient of window messages sent or posted to windows it created.
PostMessage(hwnd, . . . ) will post window messages to a queue associated with the thread which created hwnd. This means that each thread that creates a window can potentially have a message queue. This queue is an implied handle to many functions; the `message queue' is bound to a thread and can be called the `thread message queue'.
Thread message queues are created on demand in the function. This retains the semantics and parameters of the existing functions; thread message queues are not present as external object types.
The functions GetMessage/PeekMessage, which normally return messages from the application queue, now return messages with the thread queue. Threads that call GetMessage/PeekMessage return messages from their own thread message queue.