|
1回顶部 注：这一部分涉及《箴言》第三章。 所有的消息队列看上去是放在USER32的模块内，但是每个应用程序自己有一个USER32，因为每个应用程序的内存都是从4000000B开始的，这样，每个GetMessage和PeekMessage都在处理事件。实际上，每个GetMessage都会成为一个WaitsingleMessage，当有事件来后，就直接进行处理，也不用做什么调度。 2回顶部 当某一程序切入时，其他程序就会被切出。当切换出去时，整个消息队列也就切换出去了。所以，整个消息的处理就很简单了。 =================================================== 这一段实在是不清楚，不知道所谓的“切入”、“切出”是什么意思。也看不出所描述的因果关系指什么。应用程序消息处理的简单化主要是应为USER32.dll在幕后做了很多的事情，具体的说明大家可以在《Programming Applications for Microsoft Windows》一书里找到答案。在这本书里，大家可以看到系统在幕后的一些工作。 注：老实说，Microsoft实在是麻烦，什么东西都是遮遮掩掩的。给段代码不就什么都OK了吗？或者实在不行，出份详细的文档也可以啊。可偏偏MSDN里很多文档也是含含糊糊的。稍微想知道的多一点就要用调试器自己摸了，就一个字，“累”啊。呵呵，当然了，现在有很多大牛都在网上公布了自己的研究结果了，造福后来人啊:-) 3回顶部 下面贴出的代码是用VC的向导生成的，《箴言》在消息循环一节中只给出了窗口处理函数的代码，可能是为了节约纸张，给大家省钱，网上嘛，我就多贴一点了，呵呵。 1 #include "stdafx.h" 2 #include "resource.h" 3 #include <stdio.h> 4 5 #define MAX_LOADSTRING 100 6 7 // Global Variables: 8 HINSTANCE hInst; // current instance 9 TCHAR szTitle[MAX_LOADSTRING]; // The title bar text 10 TCHAR szWindowClass[MAX_LOADSTRING]; // The title bar text 11 12 // Foward declarations of functions included in this code module: 13 ATOM MyRegisterClass(HINSTANCE hInstance); 14 BOOL InitInstance(HINSTANCE, int); 15 LRESULT CALLBACK WndProc(HWND, UINT, WPARAM, LPARAM); 16 LRESULT CALLBACK About(HWND, UINT, WPARAM, LPARAM); 17 18 int APIENTRY WinMain(HINSTANCE hInstance, 19 HINSTANCE hPrevInstance, 20 LPSTR lpCmdLine, 21 int nCmdShow) 22 { 23 // TODO: Place code here. 24 MSG msg; 25 HACCEL hAccelTable; 26 char str[256]; 27 static i = 0; 28 29 // Initialize global strings 30 LoadString(hInstance, IDS_APP_TITLE, szTitle, MAX_LOADSTRING); 31 LoadString(hInstance, IDC_TEST, szWindowClass, MAX_LOADSTRING); 32 MyRegisterClass(hInstance); 33 4回顶部 34 // Perform application initialization: 35 if (!InitInstance (hInstance, nCmdShow)) 36 { 37 return FALSE; 38 } 39 40 hAccelTable = LoadAccelerators(hInstance, (LPCTSTR)IDC_TESTA); 41 42 // Main message loop: 43 while (GetMessage(&msg, NULL, 0, 0)) 44 { 45 if (!TranslateAccelerator(msg.hwnd, hAccelTable, &msg)) 46 { 47 TranslateMessage(&msg); 48 DispatchMessage(&msg); 49 } 50 } 51 52 return msg.wParam; 53 } 54 55 56 57 // 58 // FUNCTION: MyRegisterClass() 59 // 60 // PURPOSE: Registers the window class. 61 // 62 // COMMENTS: 63 // 5回顶部 64 // This function and its usage is only necessary if you want this code 65 // to be compatible with Win32 systems prior to the 'RegisterClassEx' 66 // function that was added to Windows 95. It is important to call this function 67 // so that the application will get 'well formed' small icons associated 68 // with it. 69 // 70 ATOM MyRegisterClass(HINSTANCE hInstance) 71 { 72 WNDCLASSEX wcex; 73 74 wcex.cbSize = sizeof(WNDCLASSEX); 75 76 wcex.style = CS_HREDRAW | CS_VREDRAW; 77 wcex.lpfnWndProc = (WNDPROC)WndProc; 78 wcex.cbClsExtra = 0; 79 wcex.cbWndExtra = 0; 80 wcex.hInstance = hInstance; 81 wcex.hIcon = LoadIcon(hInstance, (LPCTSTR)IDI_TEST); 82 wcex.hCursor = LoadCursor(NULL, IDC_ARROW); 83 wcex.hbrBackground = (HBRUSH)(COLOR_WINDOW+1); 84 wcex.lpszMenuName = (LPCSTR)IDC_TEST; 85 wcex.lpszClassName = szWindowClass; 86 wcex.hIconSm = LoadIcon(wcex.hInstance, (LPCTSTR)IDI_SMALL); 87 88 return RegisterClassEx(&wcex); 89 } 90 91 // 92 // FUNCTION: InitInstance(HANDLE, int) 93 // 94 // PURPOSE: Saves instance handle and creates main window 95 // 96 // COMMENTS: 97 // 98 // In this function, we save the instance handle in a global variable and 99 // create and display the main program window. 100 // 6回顶部 101 BOOL InitInstance(HINSTANCE hInstance, int nCmdShow) 102 { 103 HWND hWnd; 104 105 hInst = hInstance; // Store instance handle in our global variable 106 107 hWnd = CreateWindow(szWindowClass, szTitle, WS_OVERLAPPEDWINDOW, 108 CW_USEDEFAULT, 0, CW_USEDEFAULT, 0, NULL, NULL, hInstance, NULL); 109 110 if (!hWnd) 111 { 112 return FALSE; 113 } 114 115 ShowWindow(hWnd, nCmdShow); 116 UpdateWindow(hWnd); 117 118 return TRUE; 119 } 120 121 // 122 // FUNCTION: WndProc(HWND, unsigned, WORD, LONG) 123 // 124 // PURPOSE: Processes messages for the main window. 125 // 126 // WM_COMMAND - process the application menu 127 // WM_PAINT - Paint the main window 128 // WM_DESTROY - post a quit message and return 129 // 130 // 131 LRESULT CALLBACK WndProc(HWND hWnd, UINT message, WPARAM wParam, LPARAM lParam) 132 { 133 int wmId, wmEvent; 134 PAINTSTRUCT ps; 135 HDC hdc; 136 TCHAR szHello[MAX_LOADSTRING]; 137 LoadString(hInst, IDS_HELLO, szHello, MAX_LOADSTRING); 138 7回顶部 139 static int i = 0; 140 char str[256]; 141 142 switch (message) 143 { 144 case WM_COMMAND: 145 wmId = LOWORD(wParam); 146 wmEvent = HIWORD(wParam); 147 // Parse the menu selections: 148 switch (wmId) 149 { 150 case IDM_ABOUT: 151 DialogBox(hInst, (LPCTSTR)IDD_ABOUTBOX, hWnd, (DLGPROC)About); 152 break; 153 case IDM_EXIT: 154 DestroyWindow(hWnd); 155 break; 156 default: 157 return DefWindowProc(hWnd, message, wParam, lParam); 158 } 159 break; 160 case WM_PAINT: 161 hdc = BeginPaint(hWnd, &ps); 162 // TODO: Add any drawing code here... 163 RECT rt; 164 GetClientRect(hWnd, &rt); 165 DrawText(hdc, szHello, strlen(szHello), &rt, DT_CENTER); 166 EndPaint(hWnd, &ps); 167 break; 168 case WM_DESTROY: 169 PostQuitMessage(0); 170 break; 171 default: 172 return DefWindowProc(hWnd, message, wParam, lParam); 173 } 174 return 0; 175 } 176 8回顶部 177 // Mesage handler for about box. 178 LRESULT CALLBACK About(HWND hDlg, UINT message, WPARAM wParam, LPARAM lParam) 179 { 180 switch (message) 181 { 182 case WM_INITDIALOG: 183 return TRUE; 184 185 case WM_COMMAND: 186 if (LOWORD(wParam) == IDOK || LOWORD(wParam) == IDCANCEL) 187 { 188 EndDialog(hDlg, LOWORD(wParam)); 189 return TRUE; 190 } 191 break; 192 } 193 return FALSE; 194 } 一个普通Win32 GUI程序，你只要不去关它，它就总是存在。显然，这里需要一个类似循环的东西存在，来保证我们的程序总是在运行。看看代码第43行开始的几行： 43 while (GetMessage(&msg, NULL, 0, 0)) 44 { 45 if (!TranslateAccelerator(msg.hwnd, hAccelTable, &msg)) 46 { 47 TranslateMessage(&msg); 48 DispatchMessage(&msg); 49 } 50 } 呵呵，我们找到这个循环了，就是这短短的8行代码，保持了我们的程序在系统里存在，一旦这个循环被打破了，那么我们的程序就推出了。至于怎么才能打破这个循环，去看看GetMessage的说明就一清二楚了。(注：在普通的Win32程序里，大致可以认为WinMain就是程序的入口点) 9回顶部 这8行的含义就是不断的从系统里取消息，拿到后再调用系统的服务处理后发给相应的窗口过程。这个过程循环进行，直到推出程序。这就是所谓“消息循环”名字的由来。那么窗口过程在哪里呢？好，我们看看我们创建的窗口的属性吧，从76行开始： 76 wcex.style = CS_HREDRAW | CS_VREDRAW; 77 wcex.lpfnWndProc = (WNDPROC)WndProc; 78 wcex.cbClsExtra = 0; 79 wcex.cbWndExtra = 0; 80 wcex.hInstance = hInstance; 81 wcex.hIcon = LoadIcon(hInstance, (LPCTSTR)IDI_TEST); 82 wcex.hCursor = LoadCursor(NULL, IDC_ARROW); 83 wcex.hbrBackground = (HBRUSH)(COLOR_WINDOW+1); 84 wcex.lpszMenuName = (LPCSTR)IDC_TEST; 85 wcex.lpszClassName = szWindowClass; 86 wcex.hIconSm = LoadIcon(wcex.hInstance, (LPCTSTR)IDI_SMALL); 其他我们暂时先不关心，看看第77行，lpfnWndProc是什么？根据匈牙利命名法，这是个函数指针！而(WNDPROC)WndProc就是我们定义的一个函数(第131行)。于是明白了，我们定义的一个函数被保存在窗口结构里传给系统了。再扫描一下前面列的程序，发现(WNDPROC)WndProc并没有被调用！这是怎么回事？原来系统是这样告诉我们的：有个函数你(应用程序)给我定义并实现一下，告诉我，然后你就别管了，我(系统)会根据情况来调用。所以，本质上讲，窗口函数只是系统定义的一个回调函数而已。大家要习惯这种回调函数，在Windows的很多地方都会定义类似的回调函数让你实现的。 以前在用Win32 API直接编程的时候，通常会在(WNDPROC)WndProc看到一个巨大switch/case结构，在这个巨大的结构里完成所感兴趣的消息的处理。那么到底有那些消息呢？查MSDN固然可以，但我是用Visual C++带的工具，Spy++来看的。当你在Spy++里用Ctrl+M打开Message Log窗口后，就可以在第二个tab页里看到几乎所有公开的消息了，并且是分了类的。推荐大家去浏览一下，不求记住，但最好有个大致的印象，尤其是用Visual C++编程的同志。 10回顶部 前面我们说到窗口过程是可以重入的，怎么证明？就用上面列的程序来说明。首先对上面的程序说明一下。上面的程序使用VC的向导生成的一个标准的“Win32 Application”，运行的结果是在一个窗口里打印楚“Hello World”。在菜单里选择Help/About...，会弹出一个“关于窗口”。看看第151行，这里会弹出“关于窗口”，并且 DialogBox这个函数在弹出窗口没关闭前是不会返回的。我们在菜单里选择“关于”后，就可以弹出这个对话框，现在拖着这个对话框在我们的主程序窗口里移动，我们就会发现这个窗口从被盖住的Hello World上移开后Hello World会重新出现。这说明了什么问题？在回答这个问题前有几点说明：1)在我们的程序里，只有在响应WM_PAINT的时候会绘制"Hello World"字符串。2)系统不会替我们保存窗口客户区的内容，系统客户区的内容全部要我们自己绘制，也就是说当覆盖"Hello World"的窗口移走后新出现的"Hello World"还是我们自己画的，而这段绘制代码只有在WM_PAINT的相应函数里才有。OK，综合上面两点，在“关于窗口”活动期间，显然我们程序是在第151行，而重绘窗口的代码是在165行，这只有一个解释：(WNDPROC)WndProc在返回前(也就是DialogBox返回前)，(WNDPROC)WndProc又被系统调用了用来处理WM_PAINT。也就是说DispatchMessage会导致(WNDPROC)WndProc的调用，系统在必要的时候也会调用(WNDPROC)WndProc，并且这两者的调用是异步进行的。所以有时候程序出现异常情况说不定就和这个有关。呵呵，不过这个情况我还没有遇到过。 对了，大家可以看看hInstance的值，是0x400000，和前面说得程序起始地址一样，呵呵，难道是巧合吗，大家可以研究一下。 另外补上一句，函数About是“关于窗口”的窗口函数，它是在DialogBox函数里传递给系统的。 GDI和DirectDraw的关系 =================================================== 本来以为《箴言》会指出两者在底层的实现上的关系，谁揽赐旰蟛胖赖扔谑裁炊济挥锌吹健！扼鹧浴分皇羌虻サ慕樯芰?其实都谈不上是介绍)DirectDraw，然后给出了一个24位图到16位图的转换程序。其实，GDI显然在DirectDraw之前出现的，而DirectDraw是Microsoft为了便于游戏，多媒体等需要快速访问显示设备而定义的一个软/硬件的规范。好像在最新的DirectX SDK里，DirectDraw已经被合到DirectShow中去了。《箴言》中提到的双缓冲技术是很重要的，DirectX直接支持显示缓冲的切换，我们在用GDI或者诸如Java AWT这些慢速的方法绘制动画的时候就更需要这种技术了，否则就会出现讨厌的屏幕闪烁现象。在我们设计自己的比较大的(外观比较大)控件的时候，有两个原则就特别重要，一是尽量只更新需要更新的区域，另外就是双缓冲了。 11回顶部 一个线程就是一个执行程序的事例。线程允许一个程序同时在多于一个地方运行，这有些像多个CPU，每一个CPU执行程序的一部分。在单处理器系统中，只有同时处理才出现线程。 =================================================== 线程应该是应用程序里的一个执行序列，而Windows在用CreateThread创建线程的时候，最重要的一个参数就是“Start Address”，这其实被定义为一个函数指针，原型是DWORD WINAPI ThreadProc(LPVOID lpParameter)。在多处理器机器中，理想的情况下，每个线程都在一个独立的CPU上运行，而在单处理器系统里，操作系统通过给每个线程一个运行时间片来模拟所谓的“同时运行”。但是这种“同时”是宏观上看起来的表现，实际上在某个特定的时刻只有一个线程在运行，这与多处理器的机器是不同的。在多处理器的机器上，有人就建议一个程序开的线程数量最多不要超过CPU的数量，应为系统在一个CPU上模拟多线程是要付出不小的开销的。有一点特别重要，单处理器机上，一个线程除非是自己要求挂起自己的，否则不能假设自己会在什么时候被切换出去。 不，每一个线程本身没有SS寄存器和相互依存，实际上，每一个线程在本身所在进程的地址空间内部有一个地址 空间。 =================================================== 《箴言》中这句话不知道如何理解。但是，每个线程拥有独立的堆栈显然是无比重要的，这是线程机制能够实现的基本要求之一。按照 尤晋元、史美林等编著的《Windows操作系统原理》中的论述，每个线程都和其相联系的进程共享地址空间，线程之间的通讯也及其直接，通过带锁的全局变量就可以安全的进行了。 线程于GDI的冲突：死机的主要原因。 =================================================== 对于这个论题，我写了个程序测试了一下，把结果给大家说说。程序是一个用VC向导生成的基于对话框的程序。然后程序生成11个线程，每个线程都一样，用对话框窗口的DC随机画直线，每个线程的两次循环里随机Sleep一个小时间片，其值是10毫秒到30毫秒之间。这个程序我运行了大概有10分钟，并且一直有其他程序窗口在对话框上移动。结果是并没有出现《箴言》中所说的死锁的情况。如果大家有像《箴言》中那样出现死锁的程序，请发一份给我，谢谢:-) 当线程用到C的标准库的时候，很容易导致冲突。 =================================================== 最原始的C标准库是不支持多线程的，其中最重要的原因就是C库里有全局变量。典型的就是这个表示错误号的errno，你想想，在多线程的环境里，大家都调C库，而errno是个全局变量，那么一旦错误发生，那么errno属于哪个线程呢？这个时候就必须链接C库的多线程版本了。所以应该是当线程用到单线程的C标准库时很容易导致冲突。 12回顶部 当用_beginThread来创建，而用CloseHandle来关闭线程时，这些复制的全局结构就不会释放，这就有了内存泄漏。 =================================================== 其实，一个正确的程序不会出现上面的情况，否则只能说明还没搞明白多线程的程序怎么写。为什么这么说呢？你如果在标准的C环境里，就用_beginthread好了，然而文档清清楚楚的说明了这个时候要用_endthread来结束线程，你如果用CloseHandle只能说明你是自作聪明了。在VC/MFC环境里，我就直接AfxBeginThread或者直接用CWinThread了，这样也同样没有问题。 其实看看VC带的CRT源码： /* * Allocate and initialize a per-thread data structure for the to- * be-created thread. */ if ( (ptd = _calloc_crt(1, sizeof(struct _tiddata))) == NULL ) goto error_return; 一切都是这个_calloc_crt引起的，不过话说回来，你按照规则走就不会出问题。 还有一种线程根本不会退出，它一直运行着循环的线程。 =================================================== 这里好像容易引起误解，其实线程就一种，至于你让不让它结束，何时让它结束，完全是程序员自己的事。这句话可能会给新手同志误解，还是说明一下了。 一个KERNEL32句柄只在进程自身内部有效，企图将一个进程柄用于另一个进程是没有意义的。 =================================================== 这句话不太准确，一些全局唯一的句柄，比如Process Handle，完全可以被别的进程使用。假如进程B知道了进程A的句柄，而且在权限允许的情况下，就可以用TerminateProcess来结束A线程。 一个真正的Win32程序不会耗尽CPU时间等待某些时间发生。 =================================================== 事实上，Win32系统里应用程序不会耗尽CPU时间的，因为现在的Windows不会象过去那样等待一个程序让出控制权，而是可以主动的剥夺一个程序的CPU时间片，只要是操作系统认为应该的时刻。你完全可以让你的程序 while (1); 而这个时候你的Winamp还会给你放mp3的，不会有任何停顿。但是通常我们不会用一个循环去不停的检测某个标志，尤其在消息处理函数里要避免这种做法，因为消息处理函数的停顿在外观上的表现就是你的程序“失去响应”。解决办法可以是开个线程去循环或者用event之类的notify机制。 |
正在阅读：《编程高手箴言》读后感(3)《编程高手箴言》读后感(3)
2004-04-07 10:02
出处：CSDN
责任编辑：sdq
