From click button to pop up a messagebox, what's going on behind (each UI thread has a THREADINFO structure that contains 4 queues and some flag bits)

Think of one of the simplest program behaviors: we have a button on our dialog, and when the user clicks the button with the mouse, we pop up a messagebox.

This seemingly simple behavior, who can say clearly how it works, what happened behind it? Here are my personal answers: (1) Our mouse Click event arrives at the driver of the device, and the driver puts the message into the system hardware input queue Shiq (systems hardware input queues). (2) The mouse event is sent to the corresponding window via the system's original input thread RIT (raw input threads). Here we have to understand that the window is alive in the thread, deciding which threads the mouse message is sent to, depending on the window where the mouse is located, deciding which thread the keyboard message will be sent to according to which window gets the focus (that is, which thread is currently bound to RIT). (3) The mouse click message is placed into the virtual input queue of the button thread. Each UI thread has a THREADINFO structure that contains 4 queues and some flag bits, including the enlistment Message Queue (POST), the sending message queue (send), the virtual input queue (input), and the reply message Queue (Reply). When the mouse click message is placed into the virtual input queue, the system sets the Qs_mouse flag in the Threadinfo, telling the thread that there is a mouse message. (4) When the message loop of a button thread calls GetMessage or PeekMessage, the function's internal detection qs_mouse flag is set and attempts to fetch messages from the virtual input queue. Note that getmessage or PeekMessage extract the message has a certain algorithm: first try to fetch the message sent over; If there is no send message, try to fetch the post message, then try to detect if the QS_QUIT flag is set, the Wm_quit message is returned with the setting, the input message is followed, the WM_PAINT message, and finally the WM_TIMER message. (5) After taking a mouse click message from the virtual input queue, and then distributing it through dispatchmessage to the button's message handler (in effect, the message handler function is found based on the window handle and then called directly), the button receives the WM_ Lbuttondown and WM_LBUTTONUP messages,When Wm_lbuttonup is received, it sends a WM_COMMAND (bn_clicked) message to the button's parent window (dialog box).   (6) because the button and our dialog are the same thread, the WM_COMMAND message sent by the button causes the message handler function of the dialog to be called directly. Note that if it is a different thread, the send message is placed in the receive thread's send Message queue, and then the QS_SENDMESSAGE flag is set, and the sending thread waits until the message is processed by the receiving thread.   (7) dialog box Message handler function call MessageBox, what will the MessageBox function do?      The process is like this: first it will give its parent window (our Inside dialog box) to disable out, so that it cannot be clicked, then it will show the MessageBox window itself, then it will create a message loop, Keep the call stack from returning until the MessageBox window is processed .  (8) When we click on the button in the MessageBox, we start our initial process, but this time the mouse message is running in the message loop of the MessageBox.   (9) After the MessageBox is closed, its internal message loop exits, and then enable our dialog, dialog can continue to respond to the input message.    below is an entire call stack from mouse click to popup messagebox, we can see the entire calling process from bottom to top:  0041f3e8 74d462fa 0001090e 00000046 00000000 dpitest! wndproc+0x28 (FPO: [Non-fpo]) (conv:stdcall) [F:\test\dpitest\dpitest\dpitest.cpp @ 243]0041f414 74d47316 012911f4 0001090e 00000046 user32! internalcallwinproc+0x230041f48c 74d46de8 00000000 012911f4 0001090e user32! Usercallwinproccheckwow+0xd8 (FPO: [Non-fpo]) 0041f4e8 74d48f09 013a4b00 00000000 00000046 USER32! DISPATCHCLIENTMESSAGE+0XE0 (FPO: [Non-fpo])  //Distribute the message to the corresponding window0041f520 773a010a 0041f538 00000000 0041fae0 user32!__fninoutlpwindowpos+0x2e (FPO: [Non-fpo]) 0041f534 013a4b00 00000000 00000046 00000000 ntdll! KIUSERCALLBACKDISPATCHER+0X2E (FPO: [0,0,0]) Warning:frame IP not on any known module. Following frames may be wrong.0041f598 74d50751 0041f5ec 00000000 00000000 0x13a4b000041f5c4 74d6ccee 0041f5ec 00000000 00 000000 user32! peekmessagew+0x108 (FPO: [Non-fpo])//messagebox also has its own message loop.0041f614 74d6cf5c 0008032c 0001090e 00000000 user32! DIALOGBOX2+0XFC (FPO: [Non-fpo]) 0041f640 74d9f73c 74d30000 0086f210 0001090e user32! Internaldialogbox+0xe5 (FPO: [Non-fpo]) 0041f6f4 74d9fa18 00000000 0041fa4c 0041f90c user32! softmodalmessagebox+0x757 (FPO: [Non-fpo]) 0041f84c 74d9fb1f 0041f858 00000028 0001090e user32! messageboxworker+0x269 (FPO: [Non-fpo]) 0041f8b8 74d9fd15 0001090e 00000000 00000000 user32! messageboxtimeoutw+0x52 (FPO: [Non-fpo]) 0041f8d8 74d9fd57 0001090e 00000000 00000000 user32! MESSAGEBOXEXW+0X1B (FPO: [Non-fpo]) 0041f8f4 01294a0c 0001090e 00000000 00000000 user32! messageboxw+0x18 (FPO: [Non-fpo])  //received WM_COMMAND message after we play messagebox0041fa4c 74d462fa 0001090e 00000111 00000000 dpitest! WNDPROC+0XDC (FPO: [Non-fpo]) (conv:stdcall) [F:\test\dpitest\dpitest\dpitest.cpp @ 256]0041fa78 74d46d3a 012911f4 0001090e 00000111 user32! Internalcallwinproc+0x230041faf0 74d4965e 00000000 012911f4 0001090e user32! usercallwinproccheckwow+0x109 (FPO: [Non-fpo]) 0041fb34 74d496c5 013A4B00 00000000 012911f4 user32! sendmessageworker+0x581 (FPO: [Non-fpo]) 0041fb58 74d85fbb 0001090e 0000011100000000 user32! sendmessagew+0x7f (FPO: [Non-fpo])//button send Wm_command (0x111) message to the parent window 0041fb70 74D860FC 013a6250 00000000 00000000 USER32!XXXBUTTONNOTIFYPARENT+0X66 (FPO: [Non-fpo]) 0041fb98 74d7312e 0085f750 00000000 00000001 USER32! xxxbnreleasecapture+0x138 (FPO: [Non-fpo]) 0041fc34 74d870b2 013a6250 00000000 00000202 user32! Buttonwndprocworker+0xa07 (FPO: [Non-fpo]) 0041fc5c 74D462FA 000109120000020200000000 user32! buttonwndprocw+0x54 (FPO: [Non-fpo])//button received Wm_lbuttonup (0x202) message 0041fc88 74d46d3a 74d8705e 00010912 00000202 user32! internalcallwinproc+0x230041fd00 74d477c4 00000000 7723716c 00010912 user32! usercallwinproccheckwow+0x109 (FPO: [Non-fpo]) 0041fd60 74d4788a 7723716c 00000000 0041fe98 user32! DISPATCHMESSAGEWORKER+0X3BC (FPO: [Non-fpo]) 0041fd70 012919cc 0041fe58 00000000 00000000 user32! DISPATCHMESSAGEW+0XF (FPO: [Non-fpo])//main message loop0041fe98 01292b8b 01280000 00000000 00822126 dpitest!wwinmain+0x10c (FPO: [Non-fpo]) (conv:stdcall) [f:\test\dpitest\ Dpitest\dpitest.cpp @ 154]0041ff48 012928ef 0041ff5c 769c336a 7efde000 dpitest!__tmaincrtstartup+0x28b (conv:cdecl) [F : \dd\vctools\crt_bld\self_x86\crt\src\crtexe.c @ 578]0041ff50 769c336a 7efde000 0041ff9c 773c9f72 DPItest! WWINMAINCRTSTARTUP+0XF (CONV:CDECL) [f:\dd\vctools\crt_bld\self_x86\crt\src\crtexe.c @ 403]0041ff5c 773c9f72 7efde000 771cde92 00000000 kernel32! Basethreadinitthunk+0xe (FPO: [Non-fpo]) 0041ff9c 773c9f45 012912ad 7efde000 00000000 ntdll!__rtluserthreadstart+0x70 ( FPO: [Non-fpo]) 0041ffb4 00000000 012912ad 7efde000 00000000 ntdll!_rtluserthreadstart+0x1b (FPO: [Non-fpo])   We can see that even a mesagebox function, there are layers of calls inside: messageboxw->messageboxexw->messageboxtimeoutw->messageboxworker-> softmodalmessagebox->internaldialogbox->dialogbox2.  Simple Summary, the operating system through a layer of encapsulation, hiding too much things, a lot of seemingly simple behavior, There are actually very complex layers of calls behind them. Understanding these principles will allow you to reach a certain depth of knowledge and help you solve problems better.   Note: Above is just a personal understanding,If there is an incorrect place, please correct me.

Http://www.cnblogs.com/weiym/p/3646835.html

From click button to pop up a messagebox, what's going on behind (each UI thread has a THREADINFO structure that contains 4 queues and some flag bits)