CSDN博客

img seacloud

《编程高手箴言》读后 #3

发表于2004/1/4 10:14:00  1092人阅读

毕业也有几年了,也看了和学了不少东西。有时也想写点什么,但总是觉得头绪很多,一直没有
动笔。最近翻了翻梁先生的《编程高手箴言》,突然想写点什么,权且用读书笔记的形式写点东西。
等号上面的摘字《箴言》,下面则是笔者自己的感想。希望大家指教,但是谩骂就不必了,谢谢。
注:这一部分涉及《箴言》第三章。

所有的消息队列看上去是放在USER32的模块内,但是每个应用程序自己有一个USER32,因为
每个应用程序的内存都是从4000000B开始的,这样,每个GetMessage和PeekMessage都在
处理事件。实际上,每个GetMessage都会成为一个WaitsingleMessage,当有事件来后,就
直接进行处理,也不用做什么调度。
==================================================================================
是不是每个程序都有一个USER32,我觉得有可能不是这样,因为我用win32Dasm反汇编了一个
Win32 Console程序,并没有发现从USER32.dll里引入任何函数调用。当然,是不是在运行期
系统把USER32.dll映射进了程序的地址空间,我不是很有把握。至于《箴言》的说法是每个
程序的内存都是从400000B开始所以就都有USER32,我也想不出是什么因果关系。
事实上,GetMessage或者PeekMessage并不是在处理消息,而是负责将消息从当前线程的消息
队列里取出消息,调用TranslateMessage处理后,再调用DispatchMessage将消息发送到相应
的窗口处理程序。
之所以不需要应用程序做消息的调度不是因为消息不需要调度,而是系统在内部做了诸如同步、
调度等操作。举个例子,当你调用SendMessage的时候,如果当前线程就是创建窗口的线程,
那么SendMessage就会直接调用窗口函数来处理消息,如果不属于同一个线程,那么系统就会
挂起当前线程,知道目标线程处理完被发送的消息后,当前线程的SendMessage调用才会返回。
由此看出,系统在幕后为了支撑消息系统做了很多努力,从而简化了应用程序的编写。
并且,窗口处理函数是可重入的,在文章的最后部分,我会举个典型的Win32程序
来说明这些问题。

应为自己完成自己的消息处理,每个程序都是独立的,所以要用底层内核来实现页面的切换。
==================================================================================
呵呵,我怎么都看不出这其中有什么因果关系。程序的独立性是必然的,这也是现代操作系统
的基本特点之一。至于这种独立性是不是要通过CPU分页机制来实现,这也未必。只启用CPU
的分段功能,应该也可以实现进程的独立性了。
页面切换是不是要在内核实现呢,这也是不需要解释的事情,页面切换涉及的指令大多是一些
特权指令,如果在应用程序里可以执行这些指令的话,那么操作系统和应用程序相比就没有
特权了,应用程序想要整垮操作系统就轻而易举了,就像昔日的DOS那样。

当某一程序切入时,其他程序就会被切出。当切换出去时,整个消息队列也就切换出去了。
所以,整个消息的处理就很简单了。
==================================================================================
这一段实在是不清楚,不知道所谓的“切入”、“切出”是什么意思。也看不出所描述的因果关系
指什么。应用程序消息处理的简单化主要是应为USER32.dll在幕后做了很多的事情,具体的
说明大家可以在《Programming Applications for Microsoft Windows》一书里找到答案。
在这本书里,大家可以看到系统在幕后的一些工作。

注:老实说,Microsoft实在是麻烦,什么东西都是遮遮掩掩的。给段代码不就什么都OK了吗?
或者实在不行,出份详细的文档也可以啊。可偏偏MSDN里很多文档也是含含糊糊的。稍微想知道
的多一点就要用调试器自己摸了,就一个字,“累”啊。呵呵,当然了,现在有很多大牛都在网上
公布了自己的研究结果了,造福后来人啊:-)
记得当初第一次碰Linux的时候,感觉实在是好。几乎什么都有源代码,感觉在上面开发东西郁闷
的时间远远少于在Windows上做开发。
我想,什么时候不用再出诸如《Undocumented DOS Secretes》、《UnDocumented WinNT Secretes》
之类的书的话,广大同行们幸福的日子就来到了:-)
记得在WinXP DDK发布之前,国内外网站上关于如何有Intermedia Driver写一个虚拟网卡的问题
讨论的很多,并且好像一直都没有一个圆满的方案。等到XP DDK出来后,里面带了一个例子,一下子
就解决了所有问题。难道网上的这么多程序员都不如Microsoft聪明?!还好MFC是给源代码的,我想
如果当初没给源代码,那广大的Visual C++的程序员还不知道要被Microsoft怎么折磨呢!

从MSG的结构可以看出,每个消息都是对应一个窗口的。USER模块是管理窗口的,一般每个
窗口自己有一个消息队列。...... 当程序设计中用SendMessage来发送消息时,就会明确
指定窗口句柄,当运行此函数后,就会把消息放到此窗口的消息队列中。
==================================================================================
从MSG的结构来看,似乎应该每个消息都应该对应一个窗口。然而,MSG的结构中和窗口有关
的HWND hwnd可以为0啊。再说另一个和消息有关的函数PostThreadMessage并没有要求一个
窗口句柄,而是一个线程句柄。实际上,消息队列应该是属于线程的,而不是窗口的。
SendMessage一个很重要的特性是它不是简单的将消息送到消息队列里去,按照MSDN的说法,
If the specified window was created by the calling thread, the window procedure
is called immediately as a subroutine.If the specified window was created by a
different thread, the system switches to that thread and calls the appropriate
window procedure.
根据SendMessage的这个特性,有可能调用SendMessage的线程永远进入挂起状态了。具体的例子
大家参考《Programming Applications for Microsoft Windows》,这本书里面还介绍另外
几个函数,比如SendMessageTimeout,InSendMessage之类的,大家也可以直接参考MSDN。


下面贴出的代码是用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 
    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 //
    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 //
   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 
   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 
   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就是程序的
    入口点)
    这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++编程的同志。
    前面我们说到窗口过程是可以重入的,怎么证明?就用上面列的程序来说明。首先对上面的程序
    说明一下。上面的程序使用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这些慢速的方法绘制动画的时候就更需要这种技术了,否则就会出现讨厌的屏幕闪烁现象。在我们设计
自己的比较大的(外观比较大)控件的时候,有两个原则就特别重要,一是尽量只更新需要更新的区域,另外
就是双缓冲了。

一个线程就是一个执行程序的事例。线程允许一个程序同时在多于一个地方运行,这有些像多个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标准库时很容易导致
冲突。


当用_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机制。

0 0

相关博文

我的热门文章

img
取 消
img