Details of the Windows messaging mechanism

For Windows programming, there are a few key words to note here: message, message loop, window procedure.
 
The so-called Windows messaging mechanism is similar to a real-life logistics company. When the sender (such as mouse and keyboard) delivers the package (message) to the logistics company (Windows system), the logistics company (Windows system) will sort it out and distribute it (the sorting and distribution is mainly completed by the message cycle) to the corresponding Courier (window process) for processing. After the Courier (window process) gets the package (message), there are many ways to deal with it, such as giving it to the recipient immediately, waiting for a day to give it to the recipient, or delivering it to another Courier, which needs to be distinguished by swich/case in the window process.
 
Message loop:

When the initialization is complete, the main function of WinMain enters the message loop:

While(GetMessage(&msg,...))
{
TranslateMessage(&msg);//Transform keyboard message
DispatchMessage(&msg);//The dispatch message
}

Window process:

LRESULT CALLBACK WndProc(...)
{
...
switch( msg )
{
case 1:
...
case 2:
...
Default:
...
}
return 0;
}

The following is a detailed summary in the form of two questions.
 
Question 1: what are the different ways of categorizing messages?
(1) Queued and non-queued messages
The queue message is sent to the system message queue and then to the thread message queue. Windows maintains a system message queue, and each GUI thread also has a thread message queue. This includes the keyboard and mouse messages, WM_PAINT, WM_TIMER, and WM_QUIT.
The vast majority of messages outside of these queue messages are non-queue messages.

Note here: the messages placed in the message queue are in the form of a MSG structure, which consists of: window handle, message id, two parameters of the message (WPARAM and LPARAM), the time the message was sent (POST), and the position of the mouse. In addition, the obtained message information can be stored using the ::GetMessage function and the ::PeekMessage function.
Non-queued messages are sent directly to the destination window procedure.

(2) System and application messages
System message ID range 0X8000~0XBFFF
The application cancels the ID range 0XC000~0XFFFF
For the ID uniqueness of an application message, you can use: : RegisterWindowMessage to get a specific ID.  

Question 2: how are messages delivered, received, and processed?
The input to the Windows application is sent by the Windows system as a message to the Windows of the application, which receives and processes the message through the window procedure, and then returns the control to Windows.

Note here: the window process in which the non-queue message is sent directly to the destination window and the queue message is sent to the destination window by ::DispatchMessage. When the window procedure is invoked, it receives four parameters: the window handle, the message id, and two 32-bit message parameters. In the window procedure, the switch/case branch processing statements are used to identify and process messages.

After the main window is created, each GDI application enters a message loop to accept user input, interpret, and process messages. The message loop gets the message from the message queue, and if it is not a shortcut or dialog message, the message is converted and dispatched, leaving the window process of the destination window to process it. Exit the message loop when you get the message WM_QUIT or ::GetMessage error.