$GetMessage-PeekMessage-SendMessage内核解析.docx

《$GetMessage-PeekMessage-SendMessage内核解析.docx》由会员分享，可在线阅读，更多相关《$GetMessage-PeekMessage-SendMessage内核解析.docx（44页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、$GetMessage-PeekMessage-SendMessage内核解析最近忙公司的项目（或是毕设吧），发觉很长时间没有总结了。是该换换脑子了。“为什么没有SendThreadMessage呢？”这个问题，就来自自己平常实现的一些程序逻辑中。在一些详细的场景中，对像我这样的初学者来说，往往喜爱通过windwos的消息机制来完成UI线程和worker线程之间的同步，而不是去通过信号量或其他的去做。所以，这个问题始终困惑了自己很久。而现在，就来搞明白这个、 google一下，这个问题，在一个大牛（Raymond Chen） Chen自己的看法。”想象中的SendThreadMessage是如

2、何工作的呢？调用SendMessage 把消息干脆分发给窗口过程？但是我们没有看到消息泵，想象中的SendThreadMessage将会把消息分发给谁呢？因为我们没有thread window procedure这样的东东去处理我们的消息。是的，我们可以自己在我们的线程中做一个消息泵，但是，想象中的SendThreadMessage，须要等待这个消息处理完毕。但是，我们怎么能够知道这个消息处理完毕了？因为我们不行能等待DispatchMessage返回，而DispatchMessage失败则是因为我们并不知道应当往哪一个窗口分发消息。window manager给线程发送一个消息，仅此而已。你

3、可能会认为，我们可以等待知道下一个GetMessage or PeekMessage，这样我们可以确定这个消息解决了。但是，我们却不能保证下一个消息检索函数(GetMessage PeekMessage)，是来自我们之前的消息泵。比如，我们这个线程消息，启动了一个模态窗口，是的。当我们的消息检索函数告知我们这个消息已经处理完毕了。但是，事实上那个模态窗口还在，因为他自己又创建了一个消息泵。“ 这段虽然不长，但是却另我头大无比。GetMessage ， DispatchMessage。这2个基本的函数，每天用，但是却对他们的行为知之甚少，算上第一次写HelloWorld 到现在，至少也有1年了，

4、依旧朦胧，感到非常惭愧。而这也就是这篇总结要做的。而这的确是一个浩大的工程，因为要了解这2个函数，须要把握windows的消息机制。而windwos 并没有给我们源代码参考，这里参考ReactOS的实现，虽然不是windows正统，但是，应当差不远，至少是和win2003的相像。起先步入正题。我们首先须要了解的是，UI线程 和我们的一般的Worker线程之间的区分是什么。msdn ”To avoid the overhead of creating a message queue for nonGUI threads, all threads are created initially wit

5、hout a message queue. The system creates a thread-specific message queue only when the thread makes its first call to one of the specific user functions; no GUI function calls result in the creation of a message queue.“ 既然，系统创建每一个线程时都是一般的nonGUI thread，直到GDI， User函数调用，才为线程创建消息队列，那么我们就从这些函数调用起先。windwo

6、s在起先时，和linux一样 图形这部分是在用户空间中的进程负责，后面为了削减进程之间的环境切换，而放入了内核中。那么在系统调用这层，我们就看到了有2种状况。一种调用是原来的”内核”的调用，而另一种是新加进来的原来在用户空间的调用，这部分被称为扩充系统调用，这部分代码被放在了可以动态安装的模块win32k.sys。与之对应，系统的调用表就有了2个，一个是只包括之前的”来自内核的系统调用“，另一个则在之前的基础上，增加了图形图像的系统调用。当我们的系统调用被发觉是扩充系统调用时，也就是，原来的的表不能满意我们的要求。windwos会将会扩充系统调用表。并装载win32k.sys模块。那么，我们的

7、普一般通的线程就起先变为GUI线程了。激烈人心的旅程就从这里起先了。开源代码就是好，随意都能够贴出来。NTSTATUS NTAPI PsConvertToGuiThread(VOID) ULONG_PTR NewStack; PVOID OldStack; PETHREAD Thread = PsGetCurrentThread(); PEPROCESS Process = PsGetCurrentProcess(); NTSTATUS Status; PAGED_CODE(); /* Validate the previous mode */ if (KeGetPreviousMode()

8、= KernelMode) return STATUS_INVALID_PARAMETER; /* If no win32k, crashes later */ ASSERT(PspW32ProcessCallout != NULL); /* Make sure win32k is here */ if (!PspW32ProcessCallout) return STATUS_ACCESS_DENIED; /* Make sure its not already win32 */ if (Thread->Tcb.ServiceTable != KeServiceDescriptorTa

9、ble) /* Were already a win32 thread */ return STATUS_ALREADY_WIN32; /* Check if we dont already have a kernel-mode stack */ if (!Thread->Tcb.LargeStack) /* We dont create one */ NewStack = (ULONG_PTR)MmCreateKernelStack(TRUE, 0); if (!NewStack) /* Panic in user-mode */ NtCurrentTeb()->LastErro

10、rValue = ERROR_NOT_ENOUGH_MEMORY; return STATUS_NO_MEMORY; /* Were about to switch stacks. Enter a guarded region */ KeEnterGuardedRegion(); /* Switch stacks */ OldStack = KeSwitchKernelStack(PVOID)NewStack, (PVOID)(NewStack - KERNEL_STACK_SIZE); /* Leave the guarded region */ KeLeaveGuardedRegion()

11、; /* Delete the old stack */ MmDeleteKernelStack(OldStack, FALSE); /* This check is bizare. Check out win32k later */ if (!Process->Win32Process) /* Now tell win32k about us */ Status = PspW32ProcessCallout(Process, TRUE); if (!NT_SUCCESS(Status) return Status; /* Set the new service table */ Thr

12、ead->Tcb.ServiceTable = KeServiceDescriptorTableShadow; ASSERT(Thread->Tcb.Win32Thread = 0); /* Tell Win32k about our thread */ Status = PspW32ThreadCallout(Thread, PsW32ThreadCalloutInitialize); if (!NT_SUCCESS(Status) /* Revert our table */ Thread->Tcb.ServiceTable = KeServiceDescriptorTa

13、ble; /* Return status */ return Status; 之前没有提到的是，这里推断了一下线程system stack的大小，因为GUI线程要比一般的线程增加了更多的嵌套调用，从而须要更多的system stack。MmCreateKernelStack就是安排空间的函数。这里只是安排了64K的大小，一般的thread system stack大小为12K。当然，根据惯例，这里64K的堆栈，只是提交了其中12K的大小。并设置好guard page。超过12K则产生异样然后再安排空间。一个进程，假如有一个线程是GUI线程，那么这个进程就是GUI 进程，那么，假如不是GUI进

14、程，我们当然先得把进程转过来。PspW32ProcessCallout是一个函数指针，指向Win32kProcessCallback。这里就是干这个了，会初始化一系列的结构体，键盘格式，GDI 句柄表等等。我们这里略过这些细微环节。我们看到，系统的ServiceTable换成了大的表。而PspW32ThreadCallout指向Win32kThreadCallback，这里就完成了把一般线程转换成GUI线程的过程。对于操作系统这么困难的东东来说，要初始化的结构体真是茫茫的多。我们这里关注一点，在Win32kThreadCallback中，我们找到了创建消息队列的入口。Win32Thread-&

15、gt;MessageQueue = MsqCreateMessageQueue(Thread); 系统有了消息队列，但是，并不能构成真正的win32应用程序。我们开发者，还须要在自己的窗口程序中构造一个简洁的Message Dump，让我们看看这个GetMessage，究竟做了什么。GetMessage，最终会调用NtUserGetMessage。BOOL APIENTRY NtUserGetMessage(PMSG pMsg, HWND hWnd, UINT MsgFilterMin, UINT MsgFilterMax ) MSG Msg; BOOL Ret; if ( (MsgFilte

16、rMin|MsgFilterMax) WM_MAXIMUM ) EngSetLastError(ERROR_INVALID_PARAMETER); return FALSE; UserEnterExclusive(); RtlZeroMemory(Msg, sizeof(MSG); Ret = co_IntGetPeekMessage(Msg, hWnd, MsgFilterMin, MsgFilterMax, PM_REMOVE, TRUE); UserLeave(); if (Ret) _SEH2_TRY ProbeForWrite(pMsg, sizeof(MSG), 1); RtlCo

17、pyMemory(pMsg, Msg, sizeof(MSG); _SEH2_EXCEPT(EXCEPTION_EXECUTE_HANDLER) SetLastNtError(_SEH2_GetExceptionCode(); Ret = FALSE; _SEH2_END; return Ret; 宽恕我略过一些茫茫多的细微环节。BOOL FASTCALL co_IntGetPeekMessage( PMSG pMsg, HWND hWnd, UINT MsgFilterMin, UINT MsgFilterMax, UINT RemoveMsg, BOOL bGMSG ) /. do Pre

18、sent = co_IntPeekMessage( pMsg, Window, MsgFilterMin, MsgFilterMax, RemoveMsg, bGMSG ); if (Present) /* GetMessage or PostMessage must never get messages that contain pointers */ ASSERT(FindMsgMemory(pMsg->message) = NULL); if (pMsg->message != WM_PAINT pMsg->message != WM_QUIT) pti->tim

19、eLast = pMsg->time; pti->ptLast = pMsg->pt; / The WH_GETMESSAGE hook enables an application to monitor messages about to / be returned by the GetMessage or PeekMessage function. co_HOOK_CallHooks( WH_GETMESSAGE, HC_ACTION, RemoveMsg PM_REMOVE, (LPARAM)pMsg); if ( bGMSG ) Present = (WM_QUIT

20、!= pMsg->message); break; if ( bGMSG ) if ( !co_IntWaitMessage(Window, MsgFilterMin, MsgFilterMax) ) Present = -1; break; else if (!(RemoveMsg PM_NOYIELD) IdlePing(); / Yield this thread! UserLeave(); ZwYieldExecution(); UserEnterExclusive(); / Fall through to exit. IdlePong(); break; while( bGMS

21、G !Present ); / Been spinning, time to swap vinyl. if (pti->pClientInfo->cSpins >= 100) / Clear the spin cycle to fix the mix. pti->pClientInfo->cSpins = 0; /if (!(pti->TIF_flags TIF_SPINNING) FIXME need to swap vinyl. return Present; IntGetPeekMessage，就是一个循环，不断的调用co_IntPeekMessage

22、 从消息队列中取出消息，假如没有消息，那么我们就调用co_IntWaitMessage等待消息，然后往复，除非我们遇到了WM_QUIT。co_IntPeekMessage 看来是实现的关键,而他也是PeekMessage的关键部分。同样,略过那些繁琐的细微环节。当然，这并不是指那些不重要，而是实在是太多了。这个函数是整个消息机制的核心部分。须要渐渐来。说了这么多，我们还不知道消息队列是啥模样了。typedef struct _USER_MESSAGE_QUEUE /* Reference counter, only access this variable with interlocked f

23、unctions! */ LONG References; /* Owner of the message queue */ struct _ETHREAD *Thread; /* Queue of messages sent to the queue. */ LIST_ENTRY SentMessagesListHead; /被“发送”的消息队列 /* Queue of messages posted to the queue. */ LIST_ENTRY PostedMessagesListHead; /被“Post“的消息队列 /* Queue for hardware messages

24、 for the queue. */ LIST_ENTRY HardwareMessagesListHead; /来自硬件的消息队列 /. /* messages that are currently dispatched by other threads */ LIST_ENTRY DispatchingMessagesHead; / 已经发送而对方尚未处理的消息队列 /* messages that are currently dispatched by this message queue, required for cleanup */ LIST_ENTRY LocalDispatch

25、ingMessagesHead; / 本地正在分发的消息队列 /. USER_MESSAGE_QUEUE, *PUSER_MESSAGE_QUEUE; SentMessagesListHead 这个队列的东西是发送到我们这个消息队列的消息。也就是，当其他地方调用SendMessage到我们这个消息队列时，那个消息会放在这个队列中。PostedMessagesListHead 同理，是其他地方调用PostMessage，然后把他那个消息放在了这个队列中。PostMessage这个函数比较简单实现，我们只须要挂在目标的PostedMessagesListHead队列中就可以了。但是SendMess

26、age就要困难许多了。假如发送方和接收方是在一个线程中，那么SendMessage会干脆调用本窗口的窗口过程函数来处理这个消息。假如发送方和接收方不在一个线程中，那么发送方就必需要等待接收方的运行结果之后，才能接着执行。而这个，就形成了一个感觉上是同步的一个过程。感觉上这个好像也不是很困难。但也不是一个很简洁的线程同步问题。想一下这个问题，当GUI线程A向GUI线程B发送一个消息时，线程B处理A这个消息时，又须要向线程A发送一个消息。那么，这2个线程会死锁么？ 当然不会。要知道，windwos搞这一套为的就是构造一个完整的消息驱动机制，更抽象的讲，这个消息机制也算的上是一个线程通信机制。而这一

27、套东东，最困难的是在于，这些东东须要用户程序结合到一起，才能真正的运行起来。也就是说，我们的应用程序，必需符合windwos程序的规范，才能和windwos消息机制参加起来。而这个参加中最重要的东东就是我们之前提到的GetMessage，DispatchingMessagesHead 和 LocalDispatchingMessagesHead 则是实现这一套机制中特别重要的部分。DispatchingMessagesHead 当我们自己SendMessage到其他地方时，我们的消息是须要等待对面的结果，那么这个须要等待的消息就被放置到这里。这里可能会对一些windwos菜鸟觉得困惑，困惑这个

28、为什么能够形成一个队列呢？这里先把问题留下来。让我们站在接受者的消息队列的角度来看，当有人给我们SendMessage了，我们须要在这里处理，也就是Message Dispatch，当我们搞出这个消息的返回值时，我们接受方，还必需等待对面的人把我们的这个消息的返回值拿走，这个消息才算是搞定了。这里由于可能是不同线程，甚至是不同进程之间数据传递。所以这些东西必需要考虑在内，而这些消息放在哪里呢？LocalDispatchingMessagesHead 就跳出来解决这个问题。总的说一下，当我们SendMessage一个消息时，会挂在接收方的SentMessagesListHead队列中，并挂在发送

29、方的DispatchingMessagesHead。接受方先查看SentMessagesListHead 是否有消息，有的话，则从SendMessageListHead中删除掉，并添加到LocalDispatchingMessagesHead队列中，等我们把这个消息处理完毕，从LocalDispatchingMessagesHead将这个消息删除。我们首先关注这4个队列。那个硬件的队列主要是鼠标和键盘的东东。第一次看这个可能有点晕，不急。有一个笼统的概念之后，我们在来看细微环节。这部分还不是特别困难。/* * Internal version of PeekMessage() doing al

30、l the work */ BOOL FASTCALL co_IntPeekMessage( PMSG Msg, PWND Window, UINT MsgFilterMin, UINT MsgFilterMax, UINT RemoveMsg, BOOL bGMSG ) /. do /. /* Dispatch sent messages here. */ while ( co_MsqDispatchOneSentMessage(ThreadQueue) ) /. /. /* Now check for normal messages. */ if (ProcessMask QS_POSTM

31、ESSAGE) MsqPeekMessage( ThreadQueue, RemoveMessages, Window, MsgFilterMin, MsgFilterMax, ProcessMask, Msg ) return TRUE; /* Now look for a quit message. */ if (ThreadQueue->QuitPosted) /* According to the PSDK, WM_QUIT messages are always returned, regardless of the filter specified */ Msg->hw

32、nd = NULL; Msg->message = WM_QUIT; Msg->wParam = ThreadQueue->QuitExitCode; Msg->lParam = 0; if (RemoveMessages) ThreadQueue->QuitPosted = FALSE; ClearMsgBitsMask(ThreadQueue, QS_POSTMESSAGE); pti->pcti->fsWakeBits = QS_ALLPOSTMESSAGE; pti->pcti->fsChangeBits = QS_ALLPOSTM

33、ESSAGE; return TRUE; /* Check for hardware events. */ if (ProcessMask QS_MOUSE) co_MsqPeekMouseMove( ThreadQueue, RemoveMessages, Window, MsgFilterMin, MsgFilterMax, Msg ) return TRUE; if (ProcessMask QS_INPUT) co_MsqPeekHardwareMessage( ThreadQueue, RemoveMessages, Window, MsgFilterMin, MsgFilterMa

34、x, ProcessMask, Msg) return TRUE; /* Check for sent messages again. */ while ( co_MsqDispatchOneSentMessage(ThreadQueue) ) if (HIWORD(RemoveMsg) !bGMSG) Hit = TRUE; if (Hit) return FALSE; /* Check for paint messages. */ if (ProcessMask QS_PAINT) pti->cPaintsReady IntGetPaintMessage( Window, MsgFi

35、lterMin, MsgFilterMax, pti, Msg, RemoveMessages) return TRUE; /* This is correct, check for the current threads timers waiting to be posted to this threads message queue. If any we loop again. */ if (ProcessMask QS_TIMER) PostTimerMessages(Window) continue; return FALSE; while (TRUE); return TRUE; c

36、o_MsqDispatchOneSentMessage 这里做的就是从SendMessageListHead 中取出一个别人SendMessage到我们这里的一个消息。当我们把这些别人SendMessage给我们的消息处理完，就跳出那个循环，MsqPeekMessage 则去搞定别人PostMessage给我们的消息，最终再次检查一次co_MsqDispatchOneSentMessage，有没有人给我们发送了SendMessage消息，因为这之间的间隔是有可能有新的SendMessage消息。然后是IntGetPaintMessage 和PostTimerMessages这个名字就很简单理解

37、了。而且，这里我们也看出了消息的优先级，为了提高Paint的效率，Paint是统一处理的。而且我们也看到了Timer消息，事实上我们看出他的优先级低于Paint，这样，我们就可以在timer中绘制函数，因为，我们每一次处理timer之前，我们能够保证我们的Paint消息已经被处理了。而且，我们也看出timer的确不准，在他前面有太多的东西要做了。我们还须要了解下，我们的消息结构。是的，这个Post消息是要挂在队列中的。typedef struct _USER_MESSAGE LIST_ENTRY ListEntry; MSG Msg; DWORD QS_Flags; USER_MESSAGE, *PUSER_MESSAGE; Send的消息这里就要麻烦许多了。typedef struct _USER_SENT_MESSAGE LIST_ENTRY ListEntry; /接受方的队列 MSG Msg; DWORD QS_Flags; / Original QS bits used to create this message. PKEVENT CompletionEvent; /这个用来做线程的唤醒操作 LRESULT* Result; LRESULT lResult; struct _U