★电脑综合★ 2010-04-17 14:18:39 阅读196 评论0    字号：大中小 订阅

TCP使用三次握手 （ three-way handshake ） 协议来建立连接，图 3-10 描述了三次握手的报文序列。这三次握手为：

       请求端（通常称为客户）发送一个 SYN 报文段（ SYN 为 1 ）指明客户打算连接的服务器的端口，以及初始顺序号（ ISN ）。

       服务器发回包含服务器的初始顺序号的 SYN 报文段（ SYN 为 1 ）作为应答。同时，将确认号设置为客户的 ISN 加 1 以对客户的 SYN 报文段进行确认（ ACK 也为 1 ）。

       客户必须将确认号设置为服务器的 ISN 加 1 以对服务器的 SYN 报文段进行确认（ ACK 为 1 ），该报文通知目的主机双方已完成连接建立。

       三次握手协议是连接两端正确同步的充要条件。因为 TCP 建立在不可靠的分组传输服务之上，报文可能丢失、延迟、重复和乱序，因此协议必须使用超时和重传机制。如果重传的连接请求和原先的连接请求在连接正在建立时到达，或者当一个连接已经建立、使用和结束之后，某个延迟的连接请求才到达，就会出现问题。采用三次握手协议（加上这样的规则：在连接建立之后 TCP 就不再理睬又一次的连接请求）就可以解决这些问题。

　　三次握手协议可以完成两个重要功能：它确保连接双方做好传输准备，并使双方统一了初始顺序号。初始顺序号是在握手期间传输顺序号并获得确认：当一端为建立连接而发送它的 SYN 时，它为连接选择一个初始顺序号；每个报文段都包括了顺序号字段和确认号字段，这使得两台机器仅仅使用三个握手报文就能协商好各自的数据流的顺序号。一般来说， ISN 随时间而变化，因此每个连接都将具有不同的ISN 。

关闭一个 TCP 连接

       TCP 连接建立起来后，就可以在两个方向传送数据流。当 TCP 的应用进程再没有数据需要发送时，就发关闭命令。 TCP 通过发送控制位 FIN=1 的数据片来关闭本方数据流，但还可以继续接收数据，直到对方关闭那个方向的数据流，连接就关闭。

        TCP 协议使用修改的三次握手协议来关闭连接， 如图 3-11 所示，即终止一个连接要经过 4 次握手。这是因为 TCP 的半关闭（ half-close ）造成的。由于一个 TCP 连接是全双工（即数据在两个方向上能同时传递），因此每个方向必须单独地进行关闭。关闭的原则就是当一方完成它的数据发送任务后就能发送一个 FIN 来终止这个方向连接。当一端收到一个 FIN ，它必须通知应用层另一端已经终止了那个方向的数据传送。发送 FIN 通常是应用层进行关闭的结果。

　　从一方的 TCP 来说，连接的关闭有三种情况：

　　本方启动关闭

　　收到本方应用进程的关闭命令后， TCP 在发送完尚未处理的报文段后，发 FIN ＝ 1 的报文段给对方，且 TCP 不再受理本方应用进程的数据发送。在 FIN 以前发送的数据字节，包括 FIN ，都需要对方确认，否则要重传。注意 FIN 也占一个顺序号。一旦收到对方对 FIN 的确认以及对方的 FIN 报文段，本方 TCP 就对该 FIN 进行确认，在等待一段时间，然后关闭连接。等待是为了防止本方的确认报文丢失，避免对方的重传报文干扰新的连接。

　　 对方启动关闭

        TCP 收到对方发来的 FIN 报文时，发 ACK 确认此 FIN 报文，并通知应用进程连接正在关闭。应用进程将以关闭命令响 应。 TCP 在发送完尚未处理的报文段后，发一个 FIN 报文给对方 TCP ，然后等待对方对 FIN 的确认，收到确认后关闭连接。若对方的确认未及时到达，在等待一段时间后也关闭连接。

　　双方同时启动关闭

       连接双方的应用进程同时发关闭命令，则双方 TCP 在发送完尚未处理的报文段后，发送 FIN 报文。各方 TCP 在 FIN 前所发报文都得到确认后，发 ACK 确认它收到的 FIN 。各方在收到对方对 FIN 的确认后，同样等待一段时间再关闭连接。这称之为同时关闭（ simultaneous close ）。

TCP 状态机

　　TCP 协议的操作可以使用一个具有 11 种状态的有限状态机（ Finite State Machine ）来表示，图 3-12 描述了 TCP 的有限状态机，图中的圆角矩形表示状态，箭头表示状态之间的转换，各状态的描述如表 3-2 所示。图中用粗线表示客户端主动和被动的服务器端建立连接的正常过程：客户端的状态变迁用粗实线，服务器端的状态变迁用粗虚线。细线用于不常见的序列，如复位、同时打开、同时关闭等。图中的每条状态变换线上均标有“事件／动作”：事件是指用户执行了系统调用（ CONNECT 、 LISTEN 、 SEND 或 CLOSE ）、收到一个报文段（ SYN 、 FIN 、 ACK 或 RST ）、或者是出现了超过两倍最大的分组生命期的情况；动作是指发送一个报文段（ SYN 、 FIN 或 ACK ）或什么也没有（用“－”表示）。

图 3-12 TCP 有限状态机。粗实线表示客户的正常路径；
粗虚线表示服务器的正常路径；细线表示不常见的事件。

　　每个连接均开始于CLOSED 状态。当一方执行了被动的连接原语LISTEN或主动的连接原语CONNECT时，它便会脱离CLOSED状态。如果此时另一方执行了相对应的连接原语，连接便建立了，并且状态变为ESTABLISHED 。任何一方均可以首先请求释放连接，当连接被释放后，状态又回到了CLOSED 。

表 3-2 TCP 状态表

1. 正常状态转换

我们用图3-13 来显示在正常的TCP 连接的建立与终止过程中，客户与服务器所经历的不同状态。读者可以对照图 3-12 来阅读，使用图3-12 的状态图来跟踪图3-13 的状态变化过程，以便明白每个状态的变化：

• 服务器端首先执行LISTEN 原语进入被动打开状态（LISTEN），等待客户端连接；

• 当客户端的一个应用程序发出CONNECT命令后，本地的TCP 实体为其创建一个连接记录并标记为SYN SENT 状态，然后给服务器发送一个SYN 报文段；

• 服务器收到一个 SYN 报文段，其TCP 实体给客户端发送确认 ACK 报文段同时发送一个 SYN 信号，进入 SYN RCVD 状态；

• 客户端收到SYN + ACK 报文段，其TCP 实体给服务器端发送出三次握手的最后一个 ACK 报文段，并转换为ESTABLISHED状态；

• 服务器端收到确认的ACK报文段，完成了三次握手，于是也进入ESTABLISHED 状态。

　　 在此状态下，双方可以自由传输数据。当一个应用程序完成数据传输任务后，它需要关闭TCP连接。假设仍由客户端发起主动关闭连接。

• 客户端执行CLOSE原语，本地的TCP 实体发送一个FIN 报文段并等待响应的确认进入状态FIN WAIT 1 ；

• 服务器收到一个 FIN 报文段，它确认客户端的请求发回一个 ACK 报文段，进入CLOSE WAIT状态；

• 客户端收到确认ACK报文段，就转移到FIN WAIT 2状态，此时连接在一个方向上就断开了；

• 服务器端应用得到通告后，也执行CLOSE原语关闭另一个方向的连接，其本地TCP 实体向客户端发送一个 FIN 报文段，并进入LAST ACK 状态，等待最后一个 ACK 确认报文段；

• 客户端收到FIN报文段并确认，进入TIMED WAIT 状态，此时双方连接均已经断开，但TCP 要等待一个2倍报文段最大生存时间MSL（ Maximum Segment Lifetime ），确保该连接的所有分组全部消失，以防止出现确认丢失的情况。当定时器超时后，TCP 删除该连接记录，返回到初始状态（CLOSED）。

• 服务器收到最后一个确认 ACK 报文段，其TCP 实体便释放该连接，并删除连接记录，返回到初始状态（ CLOSED ）。

2. 同时打开：

尽管发生的可能性极小，两个应用程序同时彼此执行主动打开的情况还是可能的。每一方必须发送一个 SYN ，且这些 SYN 必须传递给对方。这需要每一方使用一个对方周知的端口作为本地端口。例如，主机 A 中的一个应用程序使用本地端口 7777 ，并与主机 B 的端口 8888 执行主动打开。主机 B 中的应用程序则使用本地端口 8888 ，并与主机 A 的端口 7777 执行主动打开。 TCP 是特意设计为了可以处理同时打开，对于同时打开它仅建立一条连接而不是两条连接（其他的协议族，最突出的是 OSI 传输层，在这种情况下将建立两条连接而不是一条连接）。

　　当出现同时打开的情况时，状态变迁与图 3-13 所示的不同。两端几乎在同时发送 SYN ，并进入 SYN_SENT 状态。当每一端收到 SYN 时，状态变为 SYN_RCVD ，同时它们都再发 SYN 并对收到的 SYN 进行确认。当双方都收到 SYN 及相应的 ACK 时，状态都变迁为 ESTABLISHED 。图 3-14 显示了这些状态变迁过程。

图 3-14 同时打开期间报文段的交换

　　一个同时打开的连接需要交换 4 个报文段，比正常的三次握手多一个。此外，要注意的是我们没有将任何一端称为客户或服务器，因为每一端既是客户又是服务器。

3. 同时关闭：

       正常情况下都是由一方（通常但不总是客户方）发送第一个 FIN 执行主动关闭，但双方都执行主动关闭也是可能的， TCP 协议也允许这样的同时关闭。

       在图3-12 中，当两端应用层同时发出关闭命令时，两端均从ESTABLISHED 变为FIN_WAIT_1 。这将导致双方各发送一个FIN ，两个FIN 经过网络传送后分别到达另一端。收到FIN 后，状态由FIN_WAIT_1变迁到 CLOSING ，并发送最后的ACK 。当收到最后的ACK 时，状态变化为TIME_WAIT 。图3-15 总结了这些状态的变化，从图中可以看出同时关闭与正常关闭使用的报文段交换数目相同。

图 3-15 同时关闭期间的报文段交换

4. 其它情况：

服务方打开：从LISTEN到SYN_SENT的变迁是正确的，它由服务器端主动发出 SYN 报文段，但 Berkeley 版的 TCP 软件并不支持它。

重置连接（复位）：只有当 SYN_RCVD 状态是从LISTEN 状态（正常情况）进入，而不是从SYN_SENT状态（同时打开）进入时，从SYN_RCVD 回到LISTEN 的状态变迁才是有效的。这意味着如果我们执行被动打开（进入 LISTEN ），收到一个 SYN ，发送一个带ACK 的SYN（进入 SYN_RCVD ），然后收到一个 RST ，而不是一个 ACK ，便又回到 LISTEN 状态并等待另一个连接请求的到来。

快速关闭：在主动关闭后的FIN_WAIT_1状态，如果收到的报文段不仅是ACK ，而且还包括对方的 FIN 信号，则直接进入 TIME_WAIT 状态，给对方发送 ACK 报文段，然后等待超时。

　　另外， TIME_WAIT 状态的等待超时需要再详细解释一下，因为它直接影响到网络应用程序的表现。

每个具体 TCP 实现必须选择一个报文段最大生存时间 MSL （ Maximum Segment Lifetime ），它是任何报文段被丢弃前在网络内的最长时间。我们知道这个时间是有限的，因为 TCP 报文段以 IP 数据报在网络内传输，而 IP 数据报有限制其生存时间的 TTL 字段。 RFC 793 [Postel 1981c ] 指出 MSL 为 2 分钟。然而，实现中的常用值是 30 秒、 1 分钟、或 2 分钟。

　　对一个具体实现所给定的 MSL 值，处理的原则是：当 TCP 执行一个主动关闭，并发回最后一个 ACK ，该连接必须在 TIME_WAIT 状态停留的时间为 2 倍的 MSL ，因此 TIME_WAIT 状态也称为 2MSL 等待状态。在这段时间内，如果最后的 ACK 丢失，对方会超时并重发最后的 FIN ，这样本地 TCP 可以再次发送 ACK 报文段（这也是它唯一可以发送的报文，并重置 2MSL 定时器）。

　　这种 2MSL 等待的另一个结果是这个 TCP 连接在 2MSL 等待期间，定义这个连接的套接字（ socket ，客户的 IP 地址和端口号，服务器的 IP 地址和端口号）不能再被使用。这个连接只能在 2MSL 结束后才能再被使用。在连接处于 2MSL 等待时，任何迟到的报文段将被丢弃。

　　我们假设图 3-12 中是客户执行主动关闭并进入 TIME_WAIT ，这是正常的情况，因为服务器通常执行被动关闭，不会进入 TIME_WAIT 状态。这暗示如果我们终止一个客户程序，并立即重新启动这个客户程序，则这个新客户程序将不能重用相同的本地端口。这不会带来什么问题，因为客户使用本地端口，而并不关心这个端口号是什么。然而，对于服务器，情况就有所不同，因为服务器使用周知端口。如果我们终止一个已经建立连接的服务器程序，并试图立即重新启动这个服务器程序，服务器程序将不能把它的这个周知端口赋值给它的端点，因为那个端口是处于 2MSL 连接的一部分。在重新启动服务器程序前，它需要在 1~4 分钟。这就是很多网络服务器程序被杀死后不能够马上重新启动的原因（错误提示为“ Address already in use ”）。

对关注性能的程序开发人员而言，一个好的计时部件既是益友，也是良师。计时器既可以作为程序组件帮助程序员精确的控制程序进程，又是一件有力的调试武器，在有经验的程序员手里可以尽快的确定程序的性能瓶颈，或者对不同的算法作出有说服力的性能比较。   
    
  　　在Windows平台下，常用的计时器有两种，一种是timeGetTime多媒体计时器，它可以提供毫秒级的计时。但这个精度对很多应用场合而言还是太粗糙了。另一种是QueryPerformanceCount计数器，随系统的不同可以提供微秒级的计数。对于实时图形处理、多媒体数据流处理、或者实时系统构造的程序员，善用QueryPerformanceCount/QueryPerformanceFrequency是一项基本功。   
    
  　　本文要介绍的，是另一种直接利用Pentium   CPU内部时间戳进行计时的高精度计时手段。以下讨论主要得益于《Windows图形编程》一书，第   15页－17页，有兴趣的读者可以直接参考该书。关于RDTSC指令的详细讨论，可以参考Intel产品手册。本文仅仅作抛砖之用。   
  　　在   Intel   Pentium以上级别的CPU中，有一个称为“时间戳（Time   Stamp）”的部件，它以64位无符号整型数的格式，记录了自CPU上电以来所经过的时钟周期数。由于目前的CPU主频都非常高，因此这个部件可以达到纳秒级的计时精度。这个精确性是上述两种方法所无法比拟的。   
    
  　　在Pentium以上的CPU中，提供了一条机器指令RDTSC（Read   Time   Stamp   Counter）来读取这个时间戳的数字，并将其保存在EDX:EAX寄存器对中。由于EDX:EAX寄存器对恰好是Win32平台下C++语言保存函数返回值的寄存器，所以我们可以把这条指令看成是一个普通的函数调用。像这样：   
    
  inline   unsigned   __int64   GetCycleCount()   
  {   
    __asm   RDTSC   
  }   
    
  但是不行，因为RDTSC不被C++的内嵌汇编器直接支持，所以我们要用_emit伪指令直接嵌入该指令的机器码形式0X0F、0X31，如下：   
    
  inline   unsigned   __int64   GetCycleCount()   
  {   
    __asm   _emit   0x0F   
    __asm   _emit   0x31   
  }   
    
  以后在需要计数器的场合，可以像使用普通的Win32   API一样，调用两次GetCycleCount函数，比较两个返回值的差，像这样：   
    
  unsigned   long   t;   
  t   =   (unsigned   long)GetCycleCount();   
  //Do   Something   time-intensive   ...   
  t   -=   (unsigned   long)GetCycleCount();   
    
  　　《Windows图形编程》第15页编写了一个类，把这个计数器封装起来。有兴趣的读者可以去参考那个类的代码。作者为了更精确的定时，做了一点小小的改进，把执行RDTSC指令的时间，通过连续两次调用GetCycleCount函数计算出来并保存了起来，以后每次计时结束后，都从实际得到的计数中减掉这一小段时间，以得到更准确的计时数字。但我个人觉得这一点点改进意义不大。在我的机器上实测，这条指令大概花掉了几十到100多个周期，在   Celeron   800MHz的机器上，这不过是十分之一微秒的时间。对大多数应用来说，这点时间完全可以忽略不计；而对那些确实要精确到纳秒数量级的应用来说，这个补偿也过于粗糙了。   
    
  这个方法的优点是：   
    
  1.高精度。可以直接达到纳秒级的计时精度（在1GHz的CPU上每个时钟周期就是一纳秒），这是其他计时方法所难以企及的。   
    
  2.   成本低。timeGetTime   函数需要链接多媒体库winmm.lib，QueryPerformance*   函数根据MSDN的说明，需要硬件的支持（虽然我还没有见过不支持的机器）和KERNEL库的支持，所以二者都只能在Windows平台下使用（关于DOS平台下的高精度计时问题，可以参考《图形程序开发人员指南》，里面有关于控制定时器8253的详细说明）。但RDTSC指令是一条CPU指令，凡是i386平台下Pentium以上的机器均支持，甚至没有平台的限制（我相信i386版本UNIX和Linux下这个方法同样适用，但没有条件试验），而且函数调用的开销是最小的。   
    
  3.   具有和CPU主频直接对应的速率关系。一个计数相当于1/(CPU主频Hz数)秒，这样只要知道了CPU的主频，可以直接计算出时间。这和   QueryPerformanceCount不同，后者需要通过QueryPerformanceFrequency获取当前计数器每秒的计数次数才能换算成时间。   
    
  这个方法的缺点是：   
    
  1.现有的C/C++编译器多数不直接支持使用RDTSC指令，需要用直接嵌入机器码的方式编程，比较麻烦。   
    
  2.数据抖动比较厉害。其实对任何计量手段而言，精度和稳定性永远是一对矛盾。如果用低精度的timeGetTime来计时，基本上每次计时的结果都是相同的；而RDTSC指令每次结果都不一样，经常有几百甚至上千的差距。这是这种方法高精度本身固有的矛盾。   
    
  关于这个方法计时的最大长度，我们可以简单的用下列公式计算：   
    
  自CPU上电以来的秒数   =   RDTSC读出的周期数   /   CPU主频速率（Hz）   
    
  64位无符号整数所能表达的最大数字是1.8×10^19，在我的Celeron   800上可以计时大约700年（书中说可以在200MHz的Pentium上计时117年，这个数字不知道是怎么得出来的，与我的计算有出入）。无论如何，我们大可不必关心溢出的问题。   
    
  下面是几个小例子，简要比较了三种计时方法的用法与精度   
    
  //Timer1.cpp   使用了RDTSC指令的Timer类//KTimer类的定义可以参见《Windows图形编程》P15   
  //编译行：CL   Timer1.cpp   /link   USER32.lib   
  #include   &ltstdio.h>   
  #include   "KTimer.h"   
  main()   
  {   
    unsigned   t;   
    KTimer   timer;   
    timer.Start();   
    Sleep(1000);   
    t   =   timer.Stop();   
    printf("Lasting   Time:   %d\n",t);   
  }   
    
  //Timer2.cpp   使用了timeGetTime函数   
  //需包含&ltmmsys.h>，但由于Windows头文件错综复杂的关系   
  //简单包含&ltwindows.h>比较偷懒：）   
  //编译行：CL   timer2.cpp   /link   winmm.lib     
  #include   &ltwindows.h>   
  #include   &ltstdio.h>   
    
  main()   
  {   
    DWORD   t1,   t2;   
    t1   =   timeGetTime();   
    Sleep(1000);   
    t2   =   timeGetTime();   
    printf("Begin   Time:   %u\n",   t1);   
    printf("End   Time:   %u\n",   t2);   
    printf("Lasting   Time:   %u\n",(t2-t1));   
  }   
    
  //Timer3.cpp   使用了QueryPerformanceCounter函数   
  //编译行：CL   timer3.cpp   /link   KERNEl32.lib   
  #include   &ltwindows.h>   
  #include   &ltstdio.h>   
    
  main()   
  {   
    LARGE_INTEGER   t1,   t2,   tc;   
    QueryPerformanceFrequency(&tc);   
    printf("Frequency:   %u\n",   tc.QuadPart);   
    QueryPerformanceCounter(&t1);   
    Sleep(1000);   
    QueryPerformanceCounter(&t2);   
    printf("Begin   Time:   %u\n",   t1.QuadPart);   
    printf("End   Time:   %u\n",   t2.QuadPart);   
    printf("Lasting   Time:   %u\n",(   t2.QuadPart-   t1.QuadPart));   
  }   
    
  ////////////////////////////////////////////////   
  //以上三个示例程序都是测试1秒钟休眠所耗费的时间   
  file://测/试环境：Celeron   800MHz   /   256M   SDRAM       
  //                     Windows   2000   Professional   SP2   
  //                     Microsoft   Visual   C++   6.0   SP5   
  ////////////////////////////////////////////////   
    
  以下是Timer1的运行结果，使用的是高精度的RDTSC指令   
  Lasting   Time:   804586872   
    
  以下是Timer2的运行结果，使用的是最粗糙的timeGetTime   API   
  Begin   Time:   20254254   
  End   Time:   20255255   
  Lasting   Time:   1001   
    
  以下是Timer3的运行结果，使用的是QueryPerformanceCount   API   
  Frequency:   3579545   
  Begin   Time:   3804729124   
  End   Time:   3808298836   
  Lasting   Time:   3569712  

转自：http://blog.csdn.net/bbs598598/article/details/7441687

我去写了个简单的.Net程序来测试了一下，可以知道那个StreamReader是一个FileStream来的，而且那个CanTimeout等属性都表明不是一个可以异步读取的流。难道真没有办法监测到这个流中是否有数据可读的状态吗？ 根据常识知道，这个流应该是“匿名管道”来的，去找了一下MSDN中关于管道的api函数，还真让我找到了一个，那就是PeekNamedPipe http://msdn.microsoft.com/en-us/library/aa365779(VS.85).aspx。

根据它的说明，来看看这个

The PeekNamedPipe function is similar to the ReadFile function with the following exceptions:

• The data is read in the mode specified with CreateNamedPipe. For example, create a pipe with PIPE_TYPE_MESSAGE | PIPE_READMODE_MESSAGE. If you change the mode to PIPE_READMODE_BYTE with SetNamedPipeHandleState, ReadFile will read in byte mode, but PeekNamedPipe will continue to read in message mode.
• The data read from the pipe is not removed from the pipe's buffer.
• The function can return additional information about the contents of the pipe.
• The function always returns immediately in a single-threaded application, even if there is no data in the pipe. The wait mode of a named pipe handle (blocking or nonblocking) has no effect on the function.

Note   The PeekNamedPipe function can block thread execution the same way any I/O function can when called on a synchronous handle in a multi-threaded application. To avoid this condition, use a pipe handle created for asynchronous I/O.

If the specified handle is a named pipe handle in byte-read mode, the function reads all available bytes up to the size specified in nBufferSize. For a named pipe handle in message-read mode, the function reads the next message in the pipe. If the message is larger than nBufferSize, the function returns TRUE after reading the specified number of bytes. In this situation, lpBytesLeftThisMessage will receive the number of bytes remaining in the message.

这个函数不管命名管道是不是阻塞模式的，都会立即返回（除了在多线程环境下的某种情况下会阻塞，大概就是http://my.donews.com/yeyanbo/tag/peeknamedpipe/这个文章发现的问题。），文档又说所有的”匿名管道“其实都是一个“命名管道”来实现的，所以操作“命名管道”的函数对“匿名管道”也是有效的。这个函数明显是我想要的，可以用来检测process标准输出流中是否有数据可以读，又不会阻塞。在vb.net的测试代码里面试了一下，应该是可以工作，测试代码如下：

总结一下 ：感觉。Net对这个“命名管道“”匿名管道“的支持明显不够，API中都有监测到管道是否有数据可以读到函数。.Net里面却连管道对应的类都没有实现，所以相应的这种阻塞情况就也没法处理了。可能这部分的封装有待完善吧。

后来有用Reflector工具反汇编看了看系统Process几个类的相应实现代码，可以看到他是CreatePipe创建一个管道，然后DuplicateHandle复制了一个文件句柄的，跟我事先的猜测是一样的。Linux的输出重定向使用也要类似的这样两个步骤。如果你自己看他的代码，可以看到创建的是一个只读的、不支持异步的FileSteam来的，他代码是这样写的：

中间省略一部分

   if (startInfo.RedirectStandardInput)

    前两天有朋友问：“如何监控自己的程序创建的子进程所发生的异常？”一开始，我以为这子进程是他自己编写的程序，所以直接就说：“在子进程的代码中使用“SetUnhandledExceptionFilter”这个API，注册一个未处理异常的回调函数，然后在回调函数中做相应处理就可以了。”实际上，现在大部分应用程序也都使用了这个API来监控自己的程序的崩溃情况。例如QQ、遨游等，在崩溃的时候都会提示需要发送一个错误报告文件，这个错误报告文件就是用这种方式生成的。

    但是，随后这位朋友说，这个子进程并不是他编写的，没办法修改程序的代码。实际上他是需要做计算机病毒分析，要对一些病毒程序的运行情况进行监控。

    在这样的状况下，我想到了这样一个思路：就是将他的监控程序注册为系统中的实时调试器，这样系统中有任何进程发生崩溃时，Windows都会将该进程的PID传递给这个监控程序。至于崩溃进程是否是他的子进程，只需要根据PID就可以简单地判断出来了。

    所谓“实时调试”（英语叫Just-In-Time debugging），其实就是Visual Studio以及Windbg等调试程序将自己注册为系统中的默认调试器的机制。用过Visual Studio的都知道，安装了这玩意之后，每当程序崩溃，VS都可以直接跳出来询问是否对该进程进行调试，这就是“实时调试”的能力。

    具体的注册方式其实很简单，修改注册表就可以实现。打开[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AeDebug]这个键，在其下建立“Debugger”的字符串值，具体内容填写“监控进程的全路径 -p %ld -e %ld”，例如“c:\exceptionMonitor.exe -p %ld -e %ld”。监控程序要支持两个参数，一个是“-p”，一个是“-e”，当有程序崩溃时，系统会把用程序的PID替换参数中的“%ld”，传递给监控程序。

    但还有一些其他的问题，这就是系统只能设置一个实时调试器。如果系统中已经有VS等程序注册过了，我们去修改这个值不就影响了这些程序的监控吗？这个问题其实也好解决，只要采取计算机安全领域里用到烂大街的“Hook”思想就可以了。具体方式是首先将VS等其他程序注册的“Debugger”值保存到另外一个键值下，例如取名为“PreviousDebugger”，然后再把我们的程序写到真正的“Debugger”键值下。当系统中的程序发生崩溃并被我们的监控程序截获后，我们首先进行自己的处理，处理完毕再根据“PreviousDebugger”中记录的调试程序路径，将崩溃的程序“扔”给后续的调试程序。如此一来，大家都有机会进行处理，各取所需，皆大欢喜了。

    最后要说明的是，在[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AeDebug]下面还有一个Auto值，如果这个值为“0”的话，那么当程序崩溃的时候系统会弹出一个对话框，让用户选择是否启动调试器。要是用户选择不启动，我们的监控程序就等于是“白给”了。所以，我们务必要把这个值设为“1”啊，切记切记。

获得程序或者一段代码运行的时间

转载▼

作者：杨老师

下载源代码

一、摘要
　　在我们编写的程序中，如果想要实现对浏览器打开的网页进行监视、模拟操纵、动态提取用户输入、动态修改......等功能，那么请你抽出宝贵的时间，继续往下阅读。本文介绍的知识和示例程序都是围绕如何遍历 HTML 中的表单(form)并枚举出表单域的属性为目标的，对于网页中的其它元素，比如图象、连接、脚本等等，应用同样的方法都可以轻松实现。

二、网页的文档层次结构
　　IE 浏览器，采用 DOM（文档对象模型）来管理网页的数据。它通过一个容器（IWebBrowser2/IHTMLWindow2）来装载网页文档（IHTMLDocument2），而一个文档，又可以由 0 或多个贞(frame)组成，管理这些贞的接口叫“框架集合（IHTMLFramesCollection2）”,而每个贞的容器又是IHTMLWindow2，和IWebBrowser2一样，它也装载着各自的文档（IHTMLDocument2）。因此，我们的第一个任务，就是想方设法能够得到IHTMLDocument2的接口。因为文档可能包含贞，而贞又包含着子文档，子文档可能再包含贞......，如此要得到所有的文档，这里有一个递归遍历的处理过程。
　　得到文档（IHTMLDocument2）后，下一步任务就是要设法取得表单了（IHTMLFormElement）。因为在一个文档中可以包含 0 或多个表单(form)，而管理这些表单的又是一个表单集合（IHTMLElementCollection），所以必须先得到集合，然后再枚举出所有的表单条目了。
　　得到表单（IHTMLFormElement）后，接下来的事情就简单了，逐个提取表单中的元素（也叫表单域 IHTMLInputElement）就可以读写这些域的属性了。
　　说了半天，我估计初次接触的朋友一定没有听懂:( 呵呵，还是用图的方式表示一下吧，这样比较清晰一些。
 

三、程序实现

<1> 取得 IHTMLDocument2 的接口指针。根据IE浏览器的运行方式，有多种不同的方式可以获取文档指针。
  <1.1> 如果你在程序中使用MFC的 CHtmlView 视来浏览网页。
        取得文档的方法最简单，调用 CHtmlView::GetHtmlDocument() 函数。
  <1.2> 如果你的程序中使用了“Web 浏览器” 的ActiveX 控件。
        取得文档的方法也比较简单，调用 CWebBrowser2::GetDocument() 函数。
  <1.3> 如果你的程序是用 ATL 写的 ActiveX 控件。
        那么需要调用 IOleClientSite::GetContainer 得到 IOleContainer 接口，然后就可以通过 QueryInterface() 查询得到 IHTMLDocument2 的接口。主要代码如下： 

CComPtr < IOleContainer > spContainer;
m_spClientSite->GetContainer( &spContainer );
CComQIPtr < IHTMLDocument2 > spDoc = spContainer;
if ( spDoc )
{
     // 已经得到了 IHTMLDocument2 的接口指针
}

#include < atlbase.h >
#include < mshtml.h >

void FindFromShell() 
{
	CComPtr< IShellWindows > spShellWin;
	HRESULT hr = spShellWin.CoCreateInstance( CLSID_ShellWindows );
	if ( FAILED( hr ) )    return;

	long nCount=0;
	spShellWin->get_Count(&nCount);   // 取得浏览器实例个数

	for(long i=0; i<nCount; i++)
       {
              CComPtr< IDispatch ><nCount; i++)
	{
		CComPtr< IDispatch ><nCount; i++)
       {
              CComPtr< IDispatch > spDisp;
		hr=spShellWin->Item(CComVariant( i ), &spDisp );
		if ( FAILED( hr ) )   continue;

		CComQIPtr< IWebBrowser2 > spBrowser = spDisp;
		if ( !spBrowser )     continue;

		spDisp.Release();
		hr = spBrowser->get_Document( &spDisp );
		if ( FAILED ( hr ) )  continue;

		CComQIPtr< IHTMLDocument2 > spDoc = spDisp;
		if ( !spDoc )         continue;

		// 程序运行到此，已经找到了 IHTMLDocument2 的接口指针
	}
}

  <1.6> IE 浏览器控件被一个进程包装在一个子窗口中。那么你首先要得到那个进程的顶层窗口句柄（使用 FindWindow() 函数，或其它任何可行的方法），然后枚举所有子窗口，通过判断窗口类名是否是“Internet Explorer_Server”，从而得到浏览器的窗口句柄，再向窗口发消息取得文档的接口指针。主要代码如下： 

#include < atlbase.h >
#include < mshtml.h >
#include < oleacc.h >
#pragma comment ( lib, "oleacc" )

BOOL CALLBACK EnumChildProc(HWND hwnd,LPARAM lParam)
{
	TCHAR szClassName[100];

	::GetClassName( hwnd,  &szClassName,  sizeof(szClassName) );
	if ( _tcscmp( szClassName,  _T("Internet Explorer_Server") ) == 0 )
	{
		*(HWND*)lParam = hwnd;
		return FALSE;		// 找到第一个 IE 控件的子窗口就停止
	}
	else	return TRUE;		// 继续枚举子窗口
};

void FindFromHwnd(HWND hWnd) 
{
	HWND hWndChild=NULL;
	::EnumChildWindows( hWnd, EnumChildProc, (LPARAM)&hWndChild );
	if(NULL == hWndChild)	return;

	UINT nMsg = ::RegisterWindowMessage( _T("WM_HTML_GETOBJECT") );
	LRESULT lRes;
	::SendMessageTimeout( hWndChild, nMsg, 0L, 0L, SMTO_ABORTIFHUNG, 1000, (DWORD*) &lRes );

	CComPtr < IHTMLDocument2 > spDoc;
	HRESULT hr = ::ObjectFromLresult ( lRes, IID_IHTMLDocument2, 0 , (LPVOID *) &spDoc );
	if ( FAILED ( hr ) )	return;

	// 程序运行到此，已经找到了 IHTMLDocument2 的接口指针
}

// 假设 spDisp 是由IHTMLElementCollection::item() 得到的 IDispatch 指针
CComQIPtr < IHTMLInputTextElement >     spInputText(spDisp);
CComQIPtr < IHTMLInputButtonElement >   spInputButton(spDisp);
CComQIPtr < IHTMLInputHiddenElement >   spInputHidden(spDisp);
......
if ( spInputText )
{
   //如果是文本输入表单域
}
else if ( spInputButton )
{
   //如果是按纽输入表单域
}
else if ( spInputHiddent )
{
   //如果是隐藏输入表单域
}
else if ........    //其它输入类型

#include < atlbase.h >
CComModule  _Module;	// 由于需要使用 CComDispatchDriver 的 IDispatch 包装类ATL智能指针，所以这个是必须的
#include < atlcom.h >
......
long nElemCount=0;		//表单域的总数目
spFormElement->get_length( &nElemCount );

for(long j=0; j< nElemCount; j++)
{
	CComDispatchDriver spInputElement;	// IDispatch 的智能指针
	spFormElement->item( CComVariant( j ), CComVariant(), &spInputElement );

	CComVariant vName,vVal,vType;	// 域名称，域值，域类型
	spInputElement.GetPropertyByName( L"name", &vName );
	spInputElement.GetPropertyByName( L"value",&vVal  );
	spInputElement.GetPropertyByName( L"type", &vType );
	// 使用 IDispatch 的智能指针的好处就是：象上面这样读取、设置属性很简单
	// 另外调用 Invoke 函数也异常方便，Invoke0(),Invoke1(),Invoke2()....
	......
}

下载源代码

Microsoft© Active Accessibility 2.0 is a COM-based technology that improves the  way accessibility aids work with applications running on Microsoft Windows?. It  provides dynamic-link libraries that are incorporated into the operating system  as well as a COM interface and application programming elements that provide  reliable methods for exposing information about user interface elements.      

HWND hWndMainWindow; IAccessible *paccMainWindow = NULL; HRESULT hr; //得到标题为"运行"的窗口的句柄 if(NULL == (hWndMainWindow = FindWindow(NULL, "运行"))) { 	MessageBox(NULL, "没有发现窗口！", "错误", MB_OK); } else { 	//通过窗口句柄得到窗口的 IAccessible 接口指针。 	if(S_OK == (hr = AccessibleObjectFromWindow(hWndMainWindow,  	                                            OBJID_WINDOW,  	                                            IID_IAccessible, 	                                            (void**)&paccMainWindow))) 	{ 		//……我们可以通过这个指针paccMainWindow进行操作。 		paccMainWindow->Release();         } }    

Name = "打开(O):" Role = "可编辑文字" Window className = "Edit"  

IAccessible*	paccControl = NULL;//输入框的 IAccessible 接口 VARIANT		varControl;    		//子ID。  FindChild( paccMainWindow,             "打开(O):",             "可编辑文字",             "Edit",             &paccControl,             &varControl )    

BOOL FindChild (IAccessible* paccParent,                           LPSTR szName, LPSTR szRole,                           LPSTR szClass,                           IAccessible** paccChild,                           VARIANT* pvarChild) { 	HRESULT hr; 	long numChildren; 	unsigned long numFetched; 	VARIANT varChild; 	int index; 	IAccessible* pCAcc = NULL; 	IEnumVARIANT* pEnum = NULL; 	IDispatch* pDisp = NULL; 	BOOL found = false; 	char szObjName[256], szObjRole[256], szObjClass[256], szObjState[256]; 	 		//得到父亲支持的IEnumVARIANT接口 	hr = paccParent -> QueryInterface(IID_IEnumVARIANT, (PVOID*) & pEnum); 	 	if(pEnum) 		pEnum -> Reset(); 	 //取得父亲拥有的可访问的子的数目 	paccParent -> get_accChildCount(&numChildren); 	 //搜索并比较每一个子ID，找到名字、角色、类与输入相一致的。 	for(index = 1; index <= numChildren && !found; index++) 	{ 		pCAcc = NULL;		 		// 如果支持IEnumVARIANT接口，得到下一个子ID //以及其对应的 IDispatch 接口 		if (pEnum) 			hr = pEnum -> Next(1, &varChild, &numFetched);	 		else 	{ 		//如果一个父亲不支持IEnumVARIANT接口，子ID就是它的序号 			varChild.vt = VT_I4; 			varChild.lVal = index; 		} 		 		// 找到此子ID对应的 IDispatch 接口 		if (varChild.vt == VT_I4) 		{ 			//通过子ID序号得到对应的 IDispatch 接口 			pDisp = NULL; 			hr = paccParent -> get_accChild(varChild, &pDisp); 		} 		else 			//如果父支持IEnumVARIANT接口可以直接得到子IDispatch 接口 			pDisp = varChild.pdispVal; 		 		// 通过 IDispatch 接口得到子的 IAccessible 接口 pCAcc 		if (pDisp) 		{ 			hr = pDisp->QueryInterface(IID_IAccessible, (void**)&pCAcc); 			hr = pDisp->Release(); 		} 		 		// Get information about the child 		if(pCAcc) 		{ 			//如果子支持IAccessible 接口，那么子ID就是CHILDID_SELF 			VariantInit(&varChild); 			varChild.vt = VT_I4; 			varChild.lVal = CHILDID_SELF; 			 			*paccChild = pCAcc; 		} 		else 			//如果子不支持IAccessible 接口 			*paccChild = paccParent; 		 		//跳过了有不可访问状态的元素 		GetObjectState(*paccChild,  		               &varChild,  		               szObjState,  		               sizeof(szObjState)); 		if(NULL != strstr(szObjState, "unavailable")) 		{ 			if(pCAcc) 				pCAcc->Release(); 			continue; 		} 		//通过get_accName得到Name 		GetObjectName(*paccChild, &varChild, szObjName, sizeof(szObjName)); 		//通过get_accRole得到Role 		GetObjectRole(*paccChild, &varChild, szObjRole, sizeof(szObjRole)); 		//通过WindowFromAccessibleObject和GetClassName得到Class 		GetObjectClass(*paccChild, szObjClass, sizeof(szObjClass)); 		//以上实现代码比较简单，大家自己看代码吧。  			//如果这些参数与输入相符或输入为NULL 		if ((!szName ||  		     !strcmp(szName, szObjName)) &&  		     (!szRole ||  		      !strcmp(szRole, szObjRole)) &&  		     (!szClass ||  		      !strcmp(szClass, szObjClass))) 		{ 			found = true; 			*pvarChild = varChild; 			break; 		} 		if(!found && pCAcc) 		{ 			// 以这次得到的子接口为父递归调用 			found = FindChild(pCAcc,  			                  szName,  			                  szRole,  			                  szClass,  			                  paccChild,  			                  pvarChild); 			if(*paccChild != pCAcc) 				pCAcc->Release(); 		} 	}//End for 	 	// Clean up 	if(pEnum) 		pEnum -> Release(); 	 	return found; }  // UI元素的状态也表示成整型形式。因为一个状态可以有多个值， //例如可选的、可做焦点的，该整数是反映这些值的位的或操作结果。 //将这些或数转换成相应的用逗号分割的状态字符串。 UINT GetObjectState(IAccessible* pacc,                      VARIANT* pvarChild,                      LPTSTR lpszState,                      UINT cchState) {     HRESULT hr;     VARIANT varRetVal; 	     *lpszState = 0; 	     VariantInit(&varRetVal); 	     hr = pacc->get_accState(*pvarChild, &varRetVal); 	 	if (!SUCCEEDED(hr))         return(0); 	 	DWORD dwStateBit; 	int cChars = 0;     if (varRetVal.vt == VT_I4) 	{ 		// 根据返回的状态值生成以逗号连接的字符串。         for (dwStateBit = STATE_SYSTEM_UNAVAILABLE;                 dwStateBit < STATE_SYSTEM_ALERT_HIGH;                 dwStateBit <<= 1)         {             if (varRetVal.lVal & dwStateBit)             {                 cChars += GetStateText(dwStateBit,                                         lpszState + cChars,                                         cchState - cChars); 				*(lpszState + cChars++) = '','';             }         } 		if(cChars > 1) 			*(lpszState + cChars - 1) = ''\0'';     }     else if (varRetVal.vt == VT_BSTR)     {         WideCharToMultiByte(CP_ACP,                              0,                              varRetVal.bstrVal,                              -1,                              lpszState,                             cchState,                              NULL,                              NULL);     } 	     VariantClear(&varRetVal); 	     return(lstrlen(lpszState)); }

//在文本输入框输入"regedit" if(1 == FindChild (paccMainWindow, "打开(O):",                     "可编辑文字",                     "Edit",                     &paccControl,                     &varControl)) { 	//在这里修改文本编辑框的值 	hr = paccControl->put_accValue(varControl,  	                                  CComBSTR("regedit")); 	paccControl->Release(); 	VariantClear(&varControl); } 		 // 找到确定按钮，并执行默认动作。 if(1 == FindChild (paccMainWindow,                     "确定",                     "按下按钮",                     "Button",                     &paccControl,                     &varControl)) { 	//这里执行按钮的默认动作，即"按下这个按钮" 	hr = paccControl->accDoDefaultAction(varControl); 	paccControl->Release(); 	VariantClear(&varControl); }

INPUT input[4];	 memset(input, 0, sizeof(input));  //设置模拟键盘输入 input[0].type = input[1].type = input[2].type = input[3].type = INPUT_KEYBOARD; input[0].ki.wVk  = input[2].ki.wVk = VK_MENU; input[1].ki.wVk  = input[3].ki.wVk = VK_F4;  // 释放按键，这非常重要 input[2].ki.dwFlags = input[3].ki.dwFlags = KEYEVENTF_KEYUP;  SendInput(4, input, sizeof(INPUT));

if(NULL == (hWndMainWindow = FindWindow(NULL, szMainTitle))) { hEventHook = SetWinEventHook( 	EVENT_MIN,	// eventMin ID 	EVENT_MAX,	// eventMax ID 	NULL,		// always NULL for outprocess hook 	WinCreateNotifyProc,		// call back function 	0,				// idProcess 	0,				// idThread           // always the same for outproc hook 	WINEVENT_SKIPOWNPROCESS | WINEVENT_OUTOFCONTEXT); }    

void CALLBACK WinCreateNotifyProc(  HWINEVENTHOOK  hEvent,  DWORD   event,  HWND    hwndMsg,  LONG    idObject,  LONG    idChild,  DWORD   idThread,  DWORD   dwmsEventTime  ) { 	 	if( event != EVENT_OBJECT_CREATE) 		return; 	 	char bufferName[256]; 	IAccessible *pacc=NULL; 	VARIANT varChild;     VariantInit(&varChild); 	//得到触发事件的 UI 元素的 IAccessible 接口/子ID对 	HRESULT hr= AccessibleObjectFromEvent(hwndMsg,  	                                      idObject,  	                                      idChild,  	                                      &pacc,  	                                      &varChild); 	 	if(!SUCCEEDED(hr)) 	{ 		VariantClear(&varChild); 		return; 	} 	//得到 UI 元素的Name，并比较，如果是"运行"就发送消息给主线程。 	GetObjectName(pacc, &varChild, bufferName, sizeof(bufferName)); 	if(strstr(bufferName, szMainTitle)) 		PostThreadMessage(GetCurrentThreadId(),  		                  WM_TARGET_WINDOW_FOUND,  		                  0,  		                  0); 	 	return; }    

• 1、 Dmitri Klementiev写的《Software Driving Software: Active Accessibility-Compliant Apps Give Programmers New Tools to Manipulate Software》及其源程序。http://msdn.microsoft.com/msdnmag/issues/0400/aaccess/default.aspx
• 2、 MSDN中的相关章节。 
  
  
  转自：http://www.vckbase.com/document/viewdoc/?id=883

         在Win16环境中，DLL的全局数据对每个载入它的进程来说都是相同的,因为所有的进程用的都收同一块地址空间；而在Win32环境中，情况却发生了变化，每个进程都有了它自己的地址空间，DLL函数中的代码所创建的任何对象（包括变量）都归调用它的进程所有。当进程在载入DLL时，操作系统自动把DLL地址映射到该进程的私有空间，也就是进程的虚拟地址空间，而且也复制该DLL的全局数据的一份拷贝到该进程空间。（在物理内存中，多进程载入DLL时，DLL的代码段实际上是只加载了一次，只是将物理地址映射到了各个调用它的进程的虚拟地址空间中，而全局数据会在每个进程都分别加载）。也就是说每个进程所拥有的相同的DLL的全局数据，它们的名称相同，但其值却并不一定是相同的，而且是互不干涉的。
因此，在Win32环境下要想在多个进程中共享数据，就必须进行必要的设置。在访问同一个Dll的各进程之间共享存储器是通过存储器映射文件技术实现的。也可以把这些需要共享的数据分离出来，放置在一个独立的数据段里，并把该段的属性设置为共享。必须给这些变量赋初值，否则编译器会把没有赋初始值的变量放在一个叫未被初始化的数据段中。

在DLL的实现文件中添加下列代码：

#pragma data_seg("DLLSharedSection")      // 声明共享数据段，并命名该数据段
   int SharedData = 123;       // 必须在定义的同时进行初始化!!!!
#pragma data_seg()

 在#pragma data_seg("DLLSharedSection")和#pragma data_seg()之间的所有变量将被访问该Dll的所有进程看到和共享。仅定义一个数据段还不能达到共享数据的目的，还要告诉编译器该段的属性，有三种方法可以实现该目的（其效果是相同的），一种方法是在.DEF文件中加入如下语句：

SETCTIONS
    DLLSharedSection READ WRITE SHARED

另一种方法是在项目设置的链接选项(Project Setting --〉Link)中加入如下语句：

/SECTION:DLLSharedSection,rws

还有一种就是使用指令：

那么这个数据节中的数据可以在所有DLL的实例之间共享了。所有对这些数据的操作都针对同一个实例的，而不是在每个进程的地址空间中都有一份。
 
当进程隐式或显式调用一个动态库里的函数时，系统都要把这个动态库映射到这个进程的虚拟地址空间里。这使得DLL成为进程的一部分，以这个进程的身份执行，使用这个进程的堆栈。

下面来谈一下在具体使用共享数据段时需要注意的一些问题：

·         所有在共享数据段中的变量，只有在数据段中经过了初始化之后，才会是进程间共享的。如果没有初始化，那么进程间访问该变量则是未定义的。
·         所有的共享变量都要放置在共享数据段中。如何定义很大的数组，那么也会导致很大的DLL。
·         不要在共享数据段中存放进程相关的信息。Win32中大多数的数据结构和值（比如HANDLE）只在特定的进程上下文中才是有效地。
·         每个进程都有它自己的地址空间。因此不要在共享数据段中共享指针，指针指向的地址在不同的地址空间中是不一样的。
·         DLL在每个进程中是被映射在不同的虚拟地址空间中的，因此函数指针也是不安全的。

当然还有其它的方法来进行进程间的数据共享，比如文件内存映射等，这就涉及到通用的进程间通信了，这里就不多讲了。

标 题: Windows系统编程之异步I/O和完成端口
作 者: 北极星2003
时 间: 2006-07-02 18:46 
链 接: http://bbs.pediy.com/showthread.php?threadid=28342 
详细信息:

Windows系统编程之异步I/O和完成端口
【作者】北极星2003
【来源】看雪技术论坛（bbs.pediy.com） 
【时间】2006年7月1日

一、  同步I/O和异步I/O

在介绍这部分内容之前先来认识下“异步I/O”。
  说起异步IO，很容易联想到同步I/O，对于同一个I/O对象句柄在同一时刻只允许一个I/O操作，其原理如下图所示：
 

  显然，当内核真正处理I/O的时间段（T2~T4），用户线程是处于等待状态的，如果这个时间段比较段的话，没有什么影响；倘若这个时间段很长的话，线程就会长时间处于挂起状态。事实上，该线程完全可以利用这段时间用处理其他事务。

  异步I/O恰好可以解决同步I/O中的问题，而且支持对同一个I/O对象的并行处理，其原理如下图所示：
 

  异步I/O在I/O请求完成时，可以使用让I/O对象或者事件对象受信来通知用户线程，而用户线程中可以使用GetOverlappedResult来查看I/O的执行情况。
  
由于异步I/O在进行I/O请求后会立即返回，这样就会产生一个问题：“程序是如何取得I/O处理的结果的？”。

  有多种方法可以实现异步I/O，其不同资料上的分类一般都不尽相同，但原理上都类似，这里我把实现异步I/O的方法分为3类，本文就针对这3类方法进行详细的讨论。
（1）重叠I/O
（2）异步过程调用（APC），扩展I/O
（3）使用完成端口（IOCP）

二、使用重叠I/O实现异步I/O
  
  同一个线程可以对多个I/O对象进行I/O操作，不同的线程也可以对同一个I/O对象进行操作，在我的理解中，重叠的命名就是这么来的。

  在使用重叠I/O时，线程需要创建OVERLAPPED结构以供I/O处理。该结构中最重要的成员是hEvent，它是作为一个同步对象而存在，如果hEvent为NULL，那么此时的同步对象即为文件句柄、管道句柄等I/O操作对象。当I/O完成后，会使这里的同步对象受信，从而通知用户线程。

  由于在进行I/O请求后会立即返回，但有时用户线程需要知道I/O当前的执行情况，此时就可以使用GetOverlappedResult。如果该函数的bWait参数为true,那么改函数就会阻塞线程直到目标I/O处理完成为止；如果bWait为false，那么就会立即返回，如果此时的I/O尚未完，调用GetLastError就会返回ERROR_IO_INCOMPLETE。

代码示例一：

代码:

DWORD   nReadByte ;
BYTE   bBuf[BUF_SIZE] ;
OVERLAPPED ov = { 0, 0, 0, 0, NULL } ;  // hEvent = NULL ;
HANDLE hFile = CreateFile ( ……, FILE_FLAG_OVERLAPPED, …… ) ;
ReadFile ( hFile, bBuf, sizeof(bBuf), &nReadByte, &ov ) ;
// 由于此时hEvent=NULL，所以同步对象为hFile,下面两句的效果一样
WaitForSingleObject ( hFile, INFINITE ) ;
//GetOverlappedResult ( hFile, &ov, &nRead, TRUE ) ;

 

这段代码在调用ReadFile后会立即返回，但在随后的WaitForSingleObject或者GetOverlappedResult中阻塞，利用同步对象hFile进行同步。

  这段代码在这里可以实现正常的异步I/O，但存在一个问题，倘若现在需要对hFile句柄进行多个I/O操作，就会出现问题。见下面这段代码。

代码示例二：

代码:

DWORD   nReadByte ;
BYTE   bBuf1[BUF_SIZE],bBuf2[BUF_SIZE],bBuf3[BUF_SIZE] ;
OVERLAPPED ov1 = { 0, 0, 0, 0, NULL } ;  
OVERLAPPED ov2 = { 0, 0, 0, 0, NULL } ;  
OVERLAPPED ov3 = { 0, 0, 0, 0, NULL } ;  
HANDLE hFile = CreateFile ( ……, FILE_FLAG_OVERLAPPED, …… ) ;
ReadFile ( hFile, bBuf1, sizeof(bBuf1), &nReadByte, &ov1 ) ;
ReadFile ( hFile, bBuf2, sizeof(bBuf2), &nReadByte, &ov2 ) ;
ReadFile ( hFile, bBuf3, sizeof(bBuf3), &nReadByte, &ov3 ) ;
//假设三个I/O处理的时间比较长，到这里还没有结束
GetOverlappedResult ( hFile, &ov1, &nRead, TRUE ) ;

 

  这里对于hFile有三个重叠的I/O操作，但他们的同步对象却都为hFile。使用GetOverlappedResult进行等待操作，这里看似在等待第一个I/O处理的完成，其实只要有任何一个I/O处理完成，该函数就会返回，相当于忽略了其他两个I/O操作的结果。

  其实，这里有一个很重要的原则：对于一个重叠句柄上有多于一个I/O操作的时候，应该使用事件对象而不是文件句柄来实现同步。正确的实现见示例三。
  
代码示例三：

代码:

DWORD   nReadByte ;
BYTE   bBuf1[BUF_SIZE],bBuf2[BUF_SIZE],bBuf3[BUF_SIZE] ;
HANDLE  hEvent1 = CreateEvent ( NULL, FALSE, FALSE, NULL ) ; 
HANDLE  hEvent2 = CreateEvent ( NULL, FALSE, FALSE, NULL ) ;
HANDLE  hEvent3 = CreateEvent ( NULL, FALSE, FALSE, NULL ) ;
OVERLAPPED ov1 = { 0, 0, 0, 0, hEvent1 } ;  
OVERLAPPED ov2 = { 0, 0, 0, 0, hEvent2 } ;  
OVERLAPPED ov3 = { 0, 0, 0, 0, hEvent3 } ;  
HANDLE hFile = CreateFile ( ……, FILE_FLAG_OVERLAPPED, …… ) ;
ReadFile ( hFile, bBuf1, sizeof(bBuf1), &nReadByte, &ov1 ) ;
ReadFile ( hFile, bBuf2, sizeof(bBuf2), &nReadByte, &ov2 ) ;
ReadFile ( hFile, bBuf3, sizeof(bBuf3), &nReadByte, &ov3 ) ;
//此时3个I/O操作的同步对象分别为hEvent1,hEvent2,hEvent3
GetOverlappedResult ( hFile, &ov1, &nRead, TRUE ) ;

 

  这样，这个GetOverlappedResult就可以实现对第一个I/O处理的等待
关于重叠I/O的就讨论到这里，关于重叠I/O的实际应用，可以参考《Windows系统编程之进程通信》其中的命名管道实例。
http://bbs.pediy.com/showthread.php?s=&threadid=26252
 
三、  使用异步过程调用实现异步I/O

异步过程调用（APC），即在特定的上下文中异步的执行一个调用。在异步I/O中可以使用APC，即让操作系统的IO系统在完成异步I/O后立即调用你的程序。（在有些资料中，把异步I/O中的APC称为“完成例程”，感觉这个名称比较贴切，下文就以“完成例程”来表述。另外通常APC是作为线程同步这一块的内容，这里尽量淡化这个概念以免混淆。关于APC的详细内容到线程同步时再介绍 ）

这里需要注意三点：
（1）  APC总是在调用线程中被调用；
（2）  当执行APC时，调用线程会进入可变等待状态；
（3）  线程需要使用扩展I/O系列函数，例如ReadFileEx,WriteFileEx, 另外可变等待函数也是必须的（至少下面其中之一）：
WaitForSingleObjectEx
WaitForMultipleObjectEx
SleepEx
SignalObjectAndWait
MsgWaitForMultipleObjectsEx
  
  在使用ReadFileEx,WriteFileEx时，重叠结构OVERLAPPED中的hEvent成员并非一定要指定，因为系统会忽略它。当多个IO操作共用同一个完成例程时，可以使用hEvent来携带序号等信息，用于区别不同的I/O操作，因为该重叠结构会传递给完成例程。如果多个IO操作使用的完成例程都不相同时，则直接把hEvent设置为NULL就可以了。

在系统调用完成例程有两个条件：
（1）  I/O操作必须完成
（2）  调用线程处于可变等待状态

对于第一个条件比较容易，显然完成例程只有在I/O操作完成时才调用；至于第二个条件就需要进行认为的控制，通过使用可变等待函数，让调用线程处于可变等待状态，这样就可以执行完成例程了。这里可以通过调节调用可变等待函数的时机来控制完成例程的执行，即可以确保完成例程不会被过早的执行。

当线程具有多个完成例程时，就会形成一个队列。使用可变等待函数使线程进入可变等待状态时有一个表示超时值的参数，如果使用INFINITE，那么只有所有排队的完成例程被执行或者句柄获得信号时该等待函数才返回。

上面已经对利用完成例程实现异步I/O的一些比较重要的细节进行的简洁的阐述，接下来就以一个实例来说明完成例程的具体实现过程。



实例一：使用完成例程的异步I/O示例

1、  设计目标
体会完成例程的异步I/O实现原理及过程。

2、  问题的分析与设计
设计流程图如下：
 
示图说明：
  三个IO操作分别是IO_A, IO_B, IO_C, 他们的完成例程分别是APC_A, APC_B, APC_C。IO_A, IO_B是两个很短的IO操作，IO_C是一个比较费时的IO操作。
3、  详细设计（关键代码如下,具体参见附件中的源代码CompletionRoutine）

代码:

VOID WINAPI APC_A ( DWORD dwError, DWORD cbTransferred, LPOVERLAPPED lpo )
{
  pTempInfo.push_back ( "执行IO_A的完成例程" ) ;
}
VOID WINAPI APC_B ( DWORD dwError, DWORD cbTransferred, LPOVERLAPPED lpo )
{
  pTempInfo.push_back ( "执行IO_B的完成例程" ) ;
}
VOID WINAPI APC_C ( DWORD dwError, DWORD cbTransferred, LPOVERLAPPED lpo )
{
  pTempInfo.push_back ( "执行IO_C的完成例程" ) ;
}

void CCompletionRoutineDlg::OnTest() 
{
  // TODO: Add your control notification handler code here
  HANDLE    hFile_A, hFile_B, hFile_C ;
  OVERLAPPED  ov_A = {0}, ov_B = {0}, ov_C = {0} ;

#define C_SIZE 1024 * 1024 * 32

  string  szText_A = "Sample A !" ;
  string  szText_B = "Sampel B !" ;
  string  szText_C ;
  szText_C.resize ( C_SIZE ) ;
  memset ( &(szText_C[0]), 0x40, C_SIZE ) ;
  
  pTempInfo.clear () ;

  hFile_A = CreateFile ( "A.txt", GENERIC_WRITE, 0, NULL, \
              CREATE_ALWAYS, FILE_FLAG_OVERLAPPED, NULL ) ;
  hFile_B = CreateFile ( "B.txt", GENERIC_WRITE, 0, NULL, \
              CREATE_ALWAYS, FILE_FLAG_OVERLAPPED, NULL ) ;
  hFile_C = CreateFile ( "C.txt", GENERIC_WRITE, 0, NULL, \
              CREATE_ALWAYS, FILE_FLAG_OVERLAPPED, NULL ) ;

  WriteFileEx ( hFile_A, &(szText_A[0]), szText_A.length(), &ov_A, APC_A ) ;
  pTempInfo.push_back ( "启动IO_A, 并立即返回" ) ;

  WriteFileEx ( hFile_B, &(szText_B[0]), szText_B.length(), &ov_B, APC_B ) ;
  pTempInfo.push_back ( "启动IO_B, 并立即返回" ) ;

  WriteFileEx ( hFile_C, &(szText_C[0]), szText_C.size(), &ov_C, APC_C ) ;
  pTempInfo.push_back ( "启动IO_C, 并立即返回" ) ;

  pTempInfo.push_back ( "进入可变等待状态" ) ;
  SleepEx ( 1, true ) ;
  pTempInfo.push_back ( "结束可变等待状态" ) ;

  pTempInfo.push_back ( "进入可变等待状态" ) ;
  SleepEx ( 10000, true ) ;
  pTempInfo.push_back ( "结束可变等待状态" ) ;

  CloseHandle ( hFile_A ) ;
  CloseHandle ( hFile_B ) ;
  CloseHandle ( hFile_C ) ;

  m_ListBox.ResetContent () ;
  
  list<string>::iterator p ;
  for ( p = pTempInfo.begin(); p != pTempInfo.end(); p++ )
  {
    m_ListBox.AddString ( p->data() ) ;
  }

  DeleteFile ( "A.txt" ) ;
  DeleteFile ( "B.txt" ) ;
  DeleteFile ( "C.txt" ) ;
}

 

执行后的效果如下（WinXP+SP2+VC6.0）：
 

4、  心得体会
每当一个IO操作结束时会产生一个完成信息，如果该IO操作有完成例程的话就添加到完成例程队列。一旦调用线程进入可变等待状态，就会依次执行队列中的完成例程。
在这个示例中还有一个问题，如果把这个软件放在系统分区的文件目录下可以正常执行，而放在其他盘符下就会出现问题，执行结果就不同，真是奇怪了。


四、使用完成端口（IOCP）

实例二、使用IOCP的异步I/O示例
1、设计目标
体会完成端口的异步I/O实现原理及过程。

2、  问题的分析与设计


说明：
  每个客户端与一个管道进行交互，而在交互过程中I/O操作结束后产生的完成包就会进入“I/O完成包队列”。完成端口的线程队列中的线程使用GetQueuedCompletionStatus来检测“I/O完成包队列”中是否有完成包信息。 
3、详细设计（关键代码如下，具体见附件中的源码）

代码:

UINT ServerThread ( LPVOID lpParameter )
{
  ……
  while ( true )
  {
    GetQueuedCompletionStatus ( pMyDlg->hCompletionPort, &cbTrans, &dwCompletionKey, &lpov, INFINITE ) ;
    if ( dwCompletionKey == -1 )
      break ;
    // 读取管道信息
    // 响应管道信息（写入）
  }
  return 0 ;
}

void CMyDlg::OnStart() 
{
  // 创建完成端口
  hCompletionPort = CreateIoCompletionPort ( INVALID_HANDLE_VALUE, NULL, 0, nMaxThread ) ;

  CString lpPipeName = "\\\\.\\Pipe\\NamedPipe" ;
  for ( UINT i = 0; i < nMaxPipe; i++ )
  {
    // 创建命名管道
    PipeInst[i].hPipe =  CreateNamedPipe ( lpPipeName, PIPE_ACCESS_DUPLEX|FILE_FLAG_OVERLAPPED, \
          PIPE_TYPE_BYTE|PIPE_READMODE_BYTE|PIPE_WAIT, nMaxPipe, 0, 0, INFINITE, NULL ) ;
    ……
    // 把命名管道与完成端口关联起来
    HANDLE hRet = CreateIoCompletionPort ( PipeInst[i].hPipe, hCompletionPort, i, nMaxThread ) ;
    ……
    // 等待连接
    ConnectNamedPipe ( PipeInst[i].hPipe, &(PipeInst[i].ov) ) ;
  }
  // 创建线程
  for ( i = 0; i < nMaxThread; i++ )
  {
    hThread[i] = AfxBeginThread ( ServerThread, NULL, THREAD_PRIORITY_NORMAL ) ;
  }
  ……
}
void CMyDlg::OnStop() 
{
  for ( UINT i = 0; i < nMaxThread; i++ )
  {
    // 用来唤醒线程的虚假I/O完成包
    PostQueuedCompletionStatus ( hCompletionPort, 0, -1, NULL ) ;
    CloseHandle ( hThread[i] ) ;
  }
  for ( i = 0; i < nMaxPipe; i++ )
  {
    DisconnectNamedPipe ( PipeInst[i].hPipe ) ;
    CloseHandle ( PipeInst[i].hPipe ) ;
  }
  ……
}

 

4、心得体会
  上面这个例子是关于完成端口的简单应用。可以这样来理解完成端口，它与三种资源相关分别是管道、I/O完成包队列、线程队列，它的作用是协调这三种资源。
【参考文献】
[1]. Windows系统编程. Johnson M.Hart著
【版权声明】必须注明来源看雪技术论坛(bbs.pediy.com) 及作者，并保持文章的完整性。

类型double大小为8字节，即64位，内存布局如下：
符号位（1 bit） 指数（11 bit） 尾数（52 bit）

 
符号位决定浮点数的正负，0正1负。
指数和尾数均从浮点数的二进制科学计数形式中获取。
如，十进制浮点数2.5的二进制形式为10.1，转换为科学计数法形式为(1.01)*(10^1)，由此可知指数为1，尾数（即科学计数法的小数部分）为01。
根据浮点数的存储标准（IEEE制定），float类型指数的起始数为127（二进制0111 1111），double类型指数的起始数为1023(二进制011 1111 1111)，在此基础上加指数，得到的就是内存中指数的表示形式。尾数则直接填入，如果空间多余则以0补齐，如果空间不够则0舍1入。所以float和double类型分别表示的2.5如下（二进制）：
符号位 指数 尾数
0 1000 0000 010 0000 0000 0000 0000 0000
0 100 0000 0000 0100 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000

浮点数2.5可以用二进制小数准确表示（2.5=1*(2^1)+0*(2^0)+1*(2^-1)），但很多小数不可以准确表示，其二进制形式的小数部分会无限循环，如浮点数-1.2表示如下（二进制）：
符号位 指数 尾数
1 0111 1111 0011 0011 0011 0011 0011 010
1 011 1111 1111 0011 0011 0011 0011 0011 0011 0011
0011 0011 0011 0011 0011 0011

由于对无限循环尾数的截取遵循0舍1入，尾数的第21~24位为0011，第53~56位为0011，而float尾数容量为23位，double尾数容量为52位，所以，float形式的最后三位因进位而成010，double形式则没有进位发生。
 
类型float和double通过==,>,<等比较不会引起编译错误，但是非常可能得到错误的结果。这是因为它们的内存分布不同，不可以直接比较。正确的方法是转换为同一类型后比较两者差值，如果结果小于规定的小值，则视为相等。
如，一个比较double的实现：
http://metasharp.net/index.php?title=How_to_compare_double_or_float_in_Cpp
另外，本文参考了如下webs：
http://cdatatype.blogspot.com/2008/01/memory-map-of-floatdouble.html
http://blog.csdn.net/hzb1983/archive/2007/09/24/1798555.aspx
 
P.S.
1)
IEEE浮点数标准：     4字节浮点数：1位符号位，8位阶数（基数为127的移码），23位尾数；     8字节浮点数：1位符号位，11位阶数（基数为1023的移码），52位尾数
2 )
在VC中： float数值范围约在 -10e38~10e38，并提供7位有效数字位，绝对值小于10e38地数被处理成零值 double数值范围约在-10e308~10e308，并提供15~16位有效数字，绝对值小于10e308地数被处理成零值

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/vinsendai/archive/2008/06/27/2593035.aspx

得到KERNEL32.DLL基址的方法
assume fs:nothing             ;打开FS寄存器
mov eax,fs:[30h]            ;得到PEB结构地址
mov eax,[eax + 0ch]        ;得到PEB_LDR_DATA结构地址
mov esi,[eax + 1ch]        ;InInitializationOrderModuleList
lodsd                      ;得到KERNEL32.DLL所在LDR_MODULE结构的InInitializationOrderModuleList地址
mov edx,[eax + 8h]         ;得到BaseAddress，既Kernel32.dll基址 

转自：http://blog.csdn.net/xbin8/archive/2008/03/08/2158762.aspx

一、概念和区别

     在windows系统中，每个窗口对象都对应有一个数据结构，形成一个list链表。系统的窗口管理器通过这个list来获取窗口信息和管理每个窗口。这个数据结构中有四个数据用来构建list，即child、sibling、parent、owner四个域。
     所以我们可以看到，窗口之间的关系有两种：owner-owned 关系和 parent-child关系。前者称之为拥有/被拥有关系，后者称之为父/子关系。在这篇文字中，我把owner窗口称之所有者窗口。换句话说，一个窗口在有一个父窗口（parent)的同时，还可能被不同的窗口拥有（owner)，也可以有自己的子窗口(child)。在MFC 的CWnd类中，所有者窗口保存在m_hWndOwner成员变量中，父窗口则保存在m_hParent中，但是这两个值并不一定和窗口对象数据结构中的值相对应。
    
     窗口之间的关系，决定了窗口的外在表现。比如显示、销毁等。

     如果一个窗口数据的owner域非NULL，则它和该窗口建立了owner-owned 关系，拥有关系决定了：
     （1）被拥有的窗口永远显示在拥有它的那个窗口的前面；
     （2）当所有者窗口最小化的时候，它所拥有的窗口都会被隐藏；
     （3）当所有者窗口被销毁的时候，它所拥有的窗口都会被销毁。
     需要注意的是，隐藏所有者窗口并不会影响它所拥有的窗口的可见状态。比如：如果窗口 A 拥有窗口B,窗口B拥有窗口C,则当窗口A最小化的时候，窗口B被隐藏，但是窗口 C还是可见。

     如果一个窗口的parent域非NULL，则它和该窗口之间就建立了parent-child关系。父子决定了：
     （1）窗口在屏幕上面的显示位置。父窗口提供了用来定位子窗口的坐标系统，一个子窗口只能显示在它的父窗口的客户区中，之外的部分将被裁减。这个裁减法则决定了如果父窗口不可见，则子窗口肯定不可见。如果父窗口移动到了屏幕之外，子窗口也一样。
     （2）当父窗口被隐藏时，它的所有子窗口也被隐藏。
     （3）父窗口被销毁的时候，它所拥有的子窗口都会被销毁。
      注意！最小化父窗口不会影响子窗口的可见状态，子窗口会随着父窗口被最小化，但是它的WS_VISIBLE属性不会变。

     Windows系统为什么要使用两种关系呢？这是为了更加灵活的管理窗口。举个例子：组合框（combobox)的下拉列表框（list box）可以超出组合框的父窗口的客户区，这样有利于显示，因此系统创建该list box的时候，是作为控制台窗口（desktop window）的子窗口，它的父窗口hWndParent是NULL，这样，list box的显示区域是限制在整个屏幕内，但是该list box的所有者却是组合框的第一个非子窗口祖先（比如对话框），当它的所有者窗口销毁后，该 list box自动销毁。

     另外，窗口之间消息的传递也和窗口关系有关，通常，一个窗口会把自己的通知消息发送给它的父窗口，但不全是这样，比如，CToolBar发送通知消息给它的所有者窗口而不是父窗口。这样以来，就可以允许工具条作为一个窗口（比如一个 OLE 容器程序窗口）的子窗口的同时，能够给另一个窗口（比如in-place框架窗口）发送消息。至于某类窗口到底是把消息发送给谁，是父窗口还是所有者窗口，microsoft并没有明示。还有，在现场（in-place）编辑的情况下，当一个 server 窗口激活或者失效的时候，框架窗口所拥有的子窗口自动隐藏或者显示，这也是通过直接调用SetOwner函数实现的。

  
二、窗口类型的说明和限制

（1）控制台窗口（desktop window）。这是系统最早创建的窗口。可以认为它是所有 WS_OVERLAPPED 类型窗口的所有者和父窗口。Kyle Marsh在他的文章“Win32 Window Hierarchy and Styles”中指出，当系统初始化的时候，它首先创建控制台窗口，大小覆盖整个屏幕。所有其它窗口都在这个控制台窗口上面显示。窗口管理器所用的窗口list中第一个就是这个控制台。它的下一层窗口叫做顶级窗口（top-level），顶级窗口是指所有非child、没有父窗口，或者父窗口是desktop的窗口，它们没有WS_CHILD属性。

（2）WS_OVERLAPPED类型的窗口可以显示在屏幕的任何地方。它们的所有者窗口是控制台。

      Overlapped 类型的窗口属于顶级窗口，一般作为应用程序的主窗口。不论是否给出了WS_CAPTION、WS_BORDER属性，这类窗口创建后都有标题栏和边框。Overlapped窗口可以拥有其它顶级窗口或者被其它顶级窗口所拥有。所有overlapped窗口都有WS_CLIPSIBLINGS属性。系统可以自动设置 overlapped窗口的大小和初始位置。

     当系统 shuts down的时候，它将销毁所有overlapped类型的窗口。

（3）WS_POPUP类型的窗口可以显示在屏幕任何地方，它们一般没有父窗口，但是如果明确调用SetParent，这类窗口也可以有父窗口。

      WS_POPUP类型的窗口的所有者是在CreateWindow函数中通过设置hWndParent参数给定的，如果hWndParent不是子窗口，则该窗口就成为这个新的弹出式窗口的owner，否则，系统从hWndParent的父窗口向上找，直到找到第一个非子窗口，把它作为该弹出窗口的owner。当owner窗口销毁的时候，系统自动销毁这个弹出窗口。

      Pop-up类型的窗口也属于顶级窗口，它和 overlapped 窗口的主要区别是弹出式窗口不需要有标题栏，也不必有边框。弹出式可以拥有其它顶级窗口或者被拥有。所有弹出式窗口也都有 WS_CLIPSIBLINGS属性。

（4）所有者窗口（owner)只能是 overlapped 或者 pop-up 类型的窗口，子窗口不能是所有者窗口，也就是说子窗口不能拥有其它窗口。

     overlapped 或者 pop-up 类型的窗口在拥有其它窗口的同时，也可以被拥有。

     在使用CreateWindowEx创建 WS_OVERLAPPED 或者 WS_POPUP类型的窗口时，可以在 hwndParent 参数中给出它的所有者窗口的句柄。如果 hwndParent 给出的是一个child 类型的窗口句柄，则系统自动将新创建窗口的所有权交给该子窗口的顶级父窗口。在这种情况下，参数hwndParent被保存在新建窗口的parent域中，而它的所有者窗口句柄则保存在owner域中。

（5）缺省情况下，对话框和消息框属于 owned 窗口，除非在创建它们的时候明确给出了WS_CHILD属性，（比如对话框中嵌入对话框的情形）
否则由系统负责给它们指定owner窗口。需要注意的是，一旦创建了owned类型的窗口，就无法再改变其所有关系，因为WIN32没有没有提供改变窗口所有者的方法。

      而且在Win32中，由于有多线程的存在，所以要注意保证父子窗口或者owner/owned 窗口要同属于一个线程。

（6）对于 WS_CHILD类型的窗口，它的父窗口就是它的所有者窗口。一个子窗口的父窗口也是在CreateWindow函数中用hWndParent参数指定的。子窗口只能在父窗口的客户区中显示，并随父窗口一起销毁。
      子窗口必须有一个父窗口，这是它和overlapped 以及 pop-up 窗口之间的主要区别。父窗口可以是顶级窗口，也可以是其它子窗口。

三、几个相关函数的说明

（1）获取/设置所有者窗口

     win32 API提供了函数GetWindow函数（GW_OWNER 标志）来获取一个窗口的所有者窗口句柄。
     GetWindow(hWnd, GW_OWNER)永远返回窗口的所有者(owner)。对于子窗口，函数返回 NULL，因为它们的父窗口就相当于所有者（注意，是“相当于”）。因为Windows系统没有维护子窗口的所有者信息。

     MFC中则是通过如下函数得到所有者窗口指针：
     _AFXWIN_INLINE CWnd* CWnd::GetOwner() const
       { return m_hWndOwner != NULL ? CWnd::FromHandle(m_hWndOwner) : GetParent(); }
     从上述代码我们可以看出，它返回的值和GetWindow返回的有所区别，如果当前窗口没有owner，那么将返回它的父窗口指针。

     但是Windows没有提供改变窗口所有者的方法。MFC中则提供了改变所有者的方法：
     _AFXWIN_INLINE void CWnd::SetOwner(CWnd* pOwnerWnd)
       { m_hWndOwner = pOwnerWnd != NULL ? pOwnerWnd->m_hWnd : NULL; }

     另外，mfc还提供了CWnd::GetSafeOwner( CWnd* pParent, HWND* pWndTop );函数，可以用来得到参数pParent的第一个非child属性的父窗口指针。如果这个参数是NULL，则返回当前线程的主窗口(通过AfxGetMainWnd得到)。框架经常使用这个函数查找对话框或者属性页的所有者窗口。

（2）获取/设置父窗口

      WIN32 API给出了函数GetParent和SetParent。而mfc也是完全封装了这两个函数：

     _AFXWIN_INLINE CWnd* CWnd::SetParent(CWnd* pWndNewParent)
       { ASSERT(::IsWindow(m_hWnd)); return CWnd::FromHandle(::SetParent(m_hWnd,
    pWndNewParent->GetSafeHwnd())); }

     _AFXWIN_INLINE CWnd* CWnd::GetParent() const
       { ASSERT(::IsWindow(m_hWnd)); return CWnd::FromHandle(::GetParent(m_hWnd)); }

     对于SetParent，msdn里面说明了父子窗口必须是同一个进程的。但是由于窗口句柄是系统全局唯一的，不属于同一个进程的情况下，也可以成功调用，但是后果未知。
     GetParent的返回值比较复杂，对于overlapped类型的窗口，它返回0，对于WS_CHILD类型，它返回其父窗口，对于WS_POPUP类型，它返回其所有者窗口，如果想得到创建它时所传递进去的那个hwndParent参数，应该用GetWindowWord(GWW_HWNDPARENT)函数。

（3）GetWindowWord(hWnd, GWW_HWNDPARENT)返回一个窗口的父窗口，如果没有，则返回其所有者。

（4）上面谈到，当一个owner窗口被最小化后，系统自动隐藏它所拥有的窗口。当owner窗口被恢复的时候，系统自动显示它所拥有的窗口。在这两种情况下，系统都会发送（send）WM_SHOWWINDOW消息给被拥有的窗口。某些时候，我们可能需要隐藏 owned窗口，但并不想最小化其所有者窗口，这时候，可以通过ShowOwnedPopups函数来实现，该函数设置或者删除当前窗口所拥有的窗口的WS_VISIBLE属性，然后发送WM_SHOWWINDOW消息更新窗口显示。

2.2 异步完成端口介绍

如果一个服务器应用程序不能同时支持多个客户端，那是毫无意义的，为此，通常使用异步I/O请求和多线程。根据定义，一个异步I/O请求会立即返回，而留下I/O请求处于等待状态。有时，I/O异步请求的结果必须与主线程同步。这可以通过几种不同方式解决。同步可以通过下面的方式实现：

> 使用事件 – 当异步请求结束时会马上触发一个信号。这种方式的缺点是线程必须检查并等待事件被触发
> 使用GetOverlappedResult函数 – 这种方式与上一种方式有相同的缺点。
> 使用Asynchronous Procedure Calls（或APC） – 这种方式有几个缺点。首先，APC总是在请求线程的上下文中被请求；第二，为了执行APC，请求线程必须在可变等候状态下挂起。
> 使用IOCP – 这种方式的缺点是必须解决很多实际的棘手的编程问题。编写IOCP可能有点麻烦。

2.2.1 为什么使用IOCP？
通过使用IOCP，我们可以解决“每个客户端占用一个线程”的问题。通常普遍认为如果软件不能运行在真正的多处理器机器上，执行能力会严重降低。线程是系统资源，而这些资源既不是无限的，也不是低价的。

IOCP提供了一种方式来使用几个线程“公平的”处理多客户端的输入/输出。线程被挂起，不占用CPU周期直到有事可做。

2.3 什么是IOCP？
我们已经看到IOCP只是一个线程同步对象，类似于信号灯，因此IOCP并不是一个复杂的概念。一个IOCP对象与几个支持待定异步I/O请求的I/O对象绑定。一个可以访问IOCP的线程可以被挂起，直到一个待定的异步I/O请求结束。

3 IOCP是怎样工作的？
要使用IOCP，你必须处理三件事情，绑定一个socket到完成端口，创建异步I/O请求，并与线程同步。为从异步I/O请求获得结果，如那个客户端发出的请求，你必须传递两个参数：CompletionKey参数和OVERLAPPED结构。

3.1 关键参数
第一个参数：CompletionKey，是一个DWORD类型的变量。你可以传递任何你想传递的唯一值，这个值将总是同该对象绑定。正常情况下会传递一个指向结构或类的指针，该结构或类包含了一些客户端的指定对象。在源码中，传递的是一个指向ClientContext的指针。

3.2 OVERLAPPED参数

BOOL IOCPS::AssociateSocketWithCompletionPort(SOCKET socket,  HANDLE hCompletionPort, DWORD dwCompletionKey)
{
HANDLE h = CreateIoCompletionPort((HANDLE) socket,  hCompletionPort, dwCompletionKey, m_nIOWorkers);
return h == hCompletionPort;
}

BOOL bSuccess = PostQueuedCompletionStatus(m_hCompletionPort,
pOverlapBuff->GetUsed(),
(DWORD) pContext,
&pOverlapBuff->m_ol);

BOOL GetQueuedCompletionStatus(   HANDLE CompletionPort, // handle to completion port
LPDWORD lpNumberOfBytes, // bytes transferred
PULONG_PTR lpCompletionKey, // file completion key
LPOVERLAPPED *lpOverlapped, // buffer
DWORD dwMilliseconds // optional timeout value
);

使用IOCP时会出现一些问题，其中有一些不是很直观的。在使用IOCP的多线程编程中，一个线程函数的控制流程不是笔直的，因为在线程和通讯直接没有关系。在这一章节中，我们将描述四个不同的问题，可能在使用IOCP开发客户端/服务器应用程序时会出现，分别是：

The WSAENOBUFS error problem.（WSAENOBUFS错误问题）
The package reordering problem.（包重构问题）
The access violation problem.（访问非法问题）

这个问题通常很难靠直觉发现，因为当你第一次看见的时候你或许认为是一个内存泄露错误。假定已经开发完成了你的完成端口服务器并且运行的一切良好，但是当你对其进行压力测试的时候突然发现服务器被中止而不处理任何请求了，如果你运气好的话你会很快发现是因为WSAENOBUFS 错误而影响了这一切。

每当我们重叠提交一个send或receive操作的时候，其中指定的发送或接收缓冲区就被锁定了。当内存缓冲区被锁定后，将不能从物理内存进行分页。操作系统有一个锁定最大数的限制，一旦超过这个锁定的限制，那么就会产生WSAENOBUFS 错误了。

如果一个服务器提交了非常多的重叠的receive在每一个连接上，那么限制会随着连接数的增长而变化。如果一个服务器能够预先估计可能会产生的最大并发连接数，服务器可以投递一个使用零缓冲区的receive在每一个连接上。因为当你提交操作没有缓冲区时，那么也不会存在内存被锁定了。使用这种办法后，当你的receive操作事件完成返回时，该socket底层缓冲区的数据会原封不动的还在其中而没有被读取到receive操作的缓冲区来。此时，服务器可以简单的调用非阻塞式的recv将存在socket缓冲区中的数据全部读出来，一直到recv返回 WSAEWOULDBLOCK 为止。 这种设计非常适合那些可以牺牲数据吞吐量而换取巨大 并发连接数的服务器。当然，你也需要意识到如何让客户端的行为尽量避免对服务器造成影响。在上一个例子中，当一个零缓冲区的receive操作被返回后使 用一个非阻塞的recv去读取socket缓冲区中的数据，如果服务器此时可预计到将会有爆发的数据流，那么可以考虑此时投递一个或者多个receive 来取代非阻塞的recv来进行数据接收。（这比你使用1个缺省的8K缓冲区来接收要好的多。）

源码中提供了一个简单实用的解决WSAENOBUF错误的办法。我们执行了一个零字节缓冲的异步WSARead(...)(参见 OnZeroByteRead(..))。当这个请求完成，我们知道在TCP/IP栈中有数据，然后我们通过执行几个有MAXIMUMPACKAGESIZE缓冲的异步WSARead(...)去读，解决了WSAENOBUFS问题。但是这种解决方法降低了服务器的吞吐量。

总结：

解决方法一：

投递使用空缓冲区的 receive操作，当操作返回后，使用非阻塞的recv来进行真实数据的读取。因此在完成端口的每一个连接中需要使用一个循环的操作来不断的来提交空缓冲区的receive操作。

解决方法二：

在投递几个普通含有缓冲区的receive操作后，进接着开始循环投递一个空缓冲区的receive操作。这样保证它们按照投递顺序依次返回，这样我们就总能对被锁定的内存进行解锁。

3.6.2 包重构问题
... ... 尽管使用IO完成端口的待发操作将总是按照他们发送的顺序来完成，线程调度安排可能使绑定到完成端口的实际工作不按指定的顺序来处理。例如，如果你有两个I/O工作者线程，你可能接收到“字节块2，字节块1，字节块3”。这就意味着：当你通过向I/O完成端口提交请求数据发送数据时，数据实际上用重新排序过的顺序发送了。

这可以通过只使用一个工作者线程来解决，并只提交一个I/O请求，等待它完成。但是如果这么做，我们就失去了IOCP的长处。

解决这个问题的一个简单实用办法是给我们的缓冲类添加一个顺序数字，如果缓冲顺序数字是正确的，则处理缓冲中的数据。这意味着：有不正确的数字的缓冲将被存下来以后再用，并且因为执行原因，我们保存缓存到一个HASH MAP对象中（如m_SendBufferMap 和 m_ReadBufferMap）。

获取这种解决方法的更多信息，请查阅源码，仔细查看IOCPS类中如下的函数：

GetNextSendBuffer (..) and GetNextReadBuffer(..), to get the ordered send or receive buffer.
IncreaseReadSequenceNumber(..) and IncreaseSendSequenceNumber(..), to increase the sequence numbers.

3.6.3 异步等待读 和 字节块包处理问题

最通用的服务端协议是一个基于协议的包，首先X个字节代表包头，包头包含了详细的完整的包的长度。服务端可以读包头，计算出需要多少数据，继续读取直到读完一个完整的包。当服务端同时只处理一个异步请求时工作的很好。但是，如果我们想发挥IOCP服务端的全部潜能，我们应该启用几个等待的异步读事件，等待数据到达。这意味着几个异步读操作是不按顺序完成的，通过等待的读事件返回的字节块流将不会按顺序处理。而且，一个字节块流可以包含一个或几个包，也可能包含部分包，如下图所示：


这个图形显示了部分包（绿色）和完整包（黄色）是怎样在不同字节块流中异步到达的。
这意味着我们必须处理字节流来成功的读取一个完整的包。而且，我们必须处理部分包（图表中绿色的部分）。这就使得字节流的处理更加困难。这个问题的完整解决方法在IOCPS类的ProcessPackage(…)函数中。

3.6.4 访问非法问题
这是一个较小的问题，代码设计导致的问题更胜于IOCP的特定问题。假设一个客户端连接已经关闭并且一个I/O请求返回一个错误标志，然后我们知道客户端已经关闭。在参数CompletionKey中，我们传递了一个指向结构ClientContext的指针，该结构中包含了客户端的特定数据。如果我们释放这个ClientContext结构占用的内存，并且同一个客户端处理的一些其它I/O请求返回了错误代码，我们通过转换参数CompletionKey为一个指向ClientContext结构的指针并试图访问或删除它，会发生什么呢？一个非法访问出现了！

这个问题的解决方法是添加一个数字到结构中，包含等待的I/O请求的数量（m_nNumberOfPendingIO），然后当我们知道没有等待的I/O请求时删除这个结构。这个功能通过函数EnterIoLoop(…) 和ReleaseClientContext(…)来实现。

3.7 源码略读
源码的目标是提供一系列简单的类来处理所有IOCP编码中的问题。源码也提供了一系列通信和C/S软件中经常使用的函数，如文件接收/传送函数，逻辑线程池处理，等等。


上图功能性的图解说明了IOCP类源码。

我们有几个IO工作者线程通过完成端口来处理异步IO请求，这些工作者线程调用一些虚函数，这些虚函数可以把需要大量计算的请求放到一个工作队列中。逻辑工作者通过类中提供的这些函数从队列中取出任务、处理并发回结果。GUI经常与主类通信，通过Windows消息（因为MFC不是线程安全的）、通过调用函数或通过使用共享的变量。

图三

上图显示了类结构纵览。

图3中的类说明如下：

> CIOCPBuffer：管理异步请求的缓存的类。
> IOCPS：处理所有通信的主类。
> JobItem：保存逻辑工作者线程要处理的任务的结构。
> ClientContex：保存客户端特定信息的结构（如状态、数据，等等）。

3.7.1 缓冲设计 - CIOCPBuffer类
使用异步I/O调用时，我们必须提供私有的缓冲区供I/O操作使用。
当我们将帐号信息放入分配的缓冲供使用时有许多情况需要考虑：

.分配和释放内存代价高，因此我们应重复使用以及分配的缓冲(内存)，
因此我们将缓冲保存在列表结构中，如下所示：

// Free Buffer List..
CCriticalSection m_FreeBufferListLock;
CPtrList m_FreeBufferList;
// OccupiedBuffer List.. (Buffers that is currently used)
CCriticalSection m_BufferListLock;
CPtrList m_BufferList;
// Now we use the function AllocateBuffer(..)
// to allocate memory or reuse a buffer.

以上所有问题都在CIOCPBuffer中解决。

3.8 如何使用源代码
从IOCP继承你自己的类（如图3），实现IOCPS类中的虚函数（例如，threadpool），
在任何类型的服务端或客户端中实现使用少量的线程有效地管理大量的连接。

3.8.1 启动和关闭服务端/客户端

BOOL Start(int nPort=999,int iMaxNumConnections=1201,
int iMaxIOWorkers=1,int nOfWorkers=1,
int iMaxNumberOfFreeBuffer=0,
int iMaxNumberOfFreeContext=0,
BOOL bOrderedSend=TRUE,
BOOL bOrderedRead=TRUE,
int iNumberOfPendlingReads=4);

nPort
服务端侦听的端口. ( -1 客户端模式.)

iMaxNumConnections
允许最大的连接数. (使用较大的数.)

iMaxIOWorkers
I/O工作线程数

nOfWorkers
逻辑工作者数量Number of logical workers. (可以在运行时改变.)

iMaxNumberOfFreeBuffer
重复使用的缓冲最大数. (-1 不使用, 0= 不限)

iMaxNumberOfFreeContext
重复使用的客户端信息对象数 (-1 for 不使用, 0= 不限)

bOrderedRead
顺序读取. (我们已经在 3.6.2. 处讨论过)

bOrderedSend
顺序写入. (我们已经在 3.6.2. 处讨论过)

iNumberOfPendlingReads
等待读取数据时未决的异步读取循环数

连接到远程服务器（客户端模式nPort=-1），调用函数：
CodeConnect(const CString &strIPAddr, int nPort)

.strIPAddr
远程服务器的IP地址

.nPort
端口

调用ShutDown()关闭连接

if(!m_iocp.Start(-1,1210,2,1,0,0))
AfxMessageBox("Error could not start the Client");
….
m_iocp.ShutDown();

4.1 源代码描述
更多关于源代码的信息请参考代码里的注释。

4.1.1 虚函数
NotifyNewConnection
新的连接已接受

NotifyNewClientContext
空的ClientContext结构被分配

NotifyDisconnectedClient
客户端连接断开

ProcessJob
逻辑工作者需要处理一个工作

NotifyReceivedPackage
新的包到达

NotifyFileCompleted
文件传送完成。

4.1.2 重要变量
所有变量共享使用时必须加锁避免存取违例，所有需要加锁的变量，名称为XXX则锁变量名称为XXXLock。

m_ContextMapLock;
保存所有客户端数据（socket,客户端数据,等等）

ContextMap m_ContextMap;
m_NumberOfActiveConnections
保存已连接的连接数

4.1.3 重要函数
GetNumberOfConnections()
返回连接数

CString GetHostAdress(ClientContext* p)
提供客户端上下文，返回主机地址

BOOL ASendToAll(CIOCPBuffer *pBuff);
发送缓冲上下文到所有连接的客户端

DisconnectClient(CString sID)
根据客户端唯一编号，断开指定的客户端

CString GetHostIP()
返回本地IP

JobItem* GetJob()
将JobItem从队列中移出, 如果没有job，返回 NULL

BOOL AddJob(JobItem *pJob)
添加Job到队列

BOOL SetWorkers(int nThreads)
设置可以任何时候调用的逻辑工作者数量

DisconnectAll();
断开所有客户端

ARead(…)
异步读取

ASend(…)
异步发送，发送数据到客户端

ClientContext* FindClient(CString strClient)
根据字符串ID寻找客户（非线程安全）

DisconnectClient(ClientContext* pContext, BOOL bGraceful=FALSE);
端口客户

DisconnectAll()
端口所有客户

StartSendFile(ClientContext *pContext)
根据ClientContext结构发送文件（使用经优化的transmitfile(..) 函数）

PrepareReceiveFile(..)
接收文件准备。调用该函数时，所有进入的字节流已被写入到文件。

PrepareSendFile(..)
打开文件并发送包含文件信息的数据包。函数禁用ASend(..)函数，直到文件传送关闭或中断。

DisableSendFile(..)
禁止发送文件模式

DisableRecevideFile(..)
禁止文件接收模式

5.1 文件传输
文件传输使用Winsock 2.0 中的TransmitFile函数。TransmitFile函数通过连接的socket句柄传送文件数据。函数使用操作系统的高速缓冲管理器(cache manager)接收文件数据,通过sockets提供高性能的文件数据传输。异步文件传输要点：
在TransmitFile函数返回前，所有其他发送或写入到该socket的操作都将无法执行，因为这将使文件数据混乱。
因此，在PrepareSendFile()函数调用之后，所有ASend都被禁止。
因为操作系统连续读取文件数据，你可以使用FILE_FLAG_SEQUENTIAL_SCAN参数来优化高速缓冲性能。
发送文件时我们使用了内核异步操作(TF_USE_KERNEL_APC)。TF_USE_KERNEL_APC的使用可以更好地提升性能。有可能, 无论如何,TransmitFile在线程中的大量使用，这种情形可能会阻止APCs的调用.

文件传输按如下顺序执行：服务器调用PrepareSendFile(..)函数初始化文件传输。客户端接收文件信息时，调用PrepareReceiveFile(..)作接收前的准备，并发送一个包到服务器告知开始文件传送。当包到达服务器端，服务器端调用StartSendFile(..)采用高性能的TransmitFile函数发送指定文件。

6 源代码示例
提供的源代码演示代码是一个echo客户端/服务器端程序，并提供了对文件传输的支持（图4）。在代码中，MyIOCP类从IOCP继承，处理客户端/服务器端的通讯，所涉及的虚函数可以参见4.1.1处。
客户端或服务器端最重要的部分是虚函数NotifyReceivedPackage，定义如下：

void MyIOCP::NotifyReceivedPackage(CIOCPBuffer *pOverlapBuff,
int nSize,ClientContext *pContext)
{
BYTE PackageType=pOverlapBuff->GetPackageType();
switch (PackageType)
{
case Job_SendText2Client :
Packagetext(pOverlapBuff,nSize,pContext);
break;
case Job_SendFileInfo :
PackageFileTransfer(pOverlapBuff,nSize,pContext);
break;
case Job_StartFileTransfer:
PackageStartFileTransfer(pOverlapBuff,nSize,pContext);
break;
case Job_AbortFileTransfer:
DisableSendFile(pContext);
break;
};
}

函数接收进入的信息并执行远程连接发送的请求。这种情况，只是简单的echo或文件传输的情形。服务器端和客户端源代码分成两个工程，IOCP和IOCPClient。

6.1 编译问题
使用VC++6.0或VC.NET编译，你可能在编译CFile时得到一些奇怪的错误，如：

这个问题可以通过更新头文件(*.h)或VC++ 6.0的版本或改变类型转换错误来解决，在修正了错误后，服务器端/客户端源代码可以在不需MFC的情况下使用。

7 特别的考虑和经验总结
当你在其他类型的程序中使用本代码，有一些可以避免的编程陷阱和多线程问题。
非确定错误指的是那些随机出现的错误，很难通过执行相同顺序的任务来重现这些错误。
这是最坏的错误类型，通常，错误出现在内部源代码的设计中。当服务器端有多个IO工作线程在运行，
为客户端提供连接，如果程序员没有考虑多线程环境，可能会发生存取违例等不确定错误。

经验 #1:
在未对上下文加锁时，不要读写客户上下文（例如：ClientContext）。
通知函数（例如：Notify*(ClientContext *pContext)）已经是线程安全，处理成员变量ClientContext可以不需要解锁、解锁。

//不要这样使用
// …
If(pContext->m_bSomeData)
pContext->m_iSomeData=0;
// …

// 应该这样使用
//….
pContext->m_ContextLock.Lock();
If(pContext->m_bSomeData)
pContext->m_iSomeData=0;
pContext->m_ContextLock.Unlock();
//…

大家都知道的，当你锁定上下文，其他线程或GUI都将等待它。

经验#2:
避免使用复杂的和其他类型的"上下文锁"，应为容易造成死锁（例如：A在等待B，B在等待C，C在等待A，A死锁）

pContext-> m_ContextLock.Lock();
//… code code ..
pContext2-> m_ContextLock.Lock();
// code code..
pContext2-> m_ContextLock.Unlock();
// code code..
pContext-> m_ContextLock.Unlock();

以上代码可能导致死锁

经验 #3:
不要在通知函数(例如：Notify*(ClientContext *pContext))以外处理客户上下文，如果你需要这样做，你
要放入
m_ContextMapLock.Lock();
…
m_ContextMapLock.Unlock();
参考如下代码：

ClientContext* pContext=NULL ;
m_ContextMapLock.Lock();
pContext = FindClient(ClientID);
// safe to access pContext, if it is not NULL
// and are Locked (Rule of thumbs#1:)
//code .. code..
m_ContextMapLock.Unlock();
// Here pContext can suddenly disappear because of disconnect.
// do not access pContext members here.

一、数据传输指令
　　它们在存贮器和寄存器、寄存器和输入输出端口之间传送数据.
　　1. 通用数据传送指令.
　　　　MOV　　传送字或字节.
　　　　MOVSX　先符号扩展,再传送.
　　　　MOVZX　先零扩展,再传送.
　　　　PUSH　　把字压入堆栈.
　　　　POP　　把字弹出堆栈.
　　　　PUSHA　把AX,CX,DX,BX,SP,BP,SI,DI依次压入堆栈.
　　　　POPA　　把DI,SI,BP,SP,BX,DX,CX,AX依次弹出堆栈.
　　　　PUSHAD　把EAX,ECX,EDX,EBX,ESP,EBP,ESI,EDI依次压入堆栈.
　　　　POPAD　把EDI,ESI,EBP,ESP,EBX,EDX,ECX,EAX依次弹出堆栈.
　　　　BSWAP　交换32位寄存器里字节的顺序
　　　　XCHG　　交换字或字节.( 至少有一个操作数为寄存器,段寄存器不可作为操作数)
　　　　CMPXCHG 比较并交换操作数.( 第二个操作数必须为累加器AL/AX/EAX )
　　　　XADD　　先交换再累加.( 结果在第一个操作数里 )
　　　　XLAT　　字节查表转换.
　　　　　　　　── BX 指向一张 256 字节的表的起点, AL 为表的索引值 (0-255,即
　　　　　　　　0-FFH); 返回 AL 为查表结果. ( [BX+AL]->AL )
　　2. 输入输出端口传送指令.
　　　　IN　　　I/O端口输入. ( 语法: IN 累加器, {端口号│DX} )
　　　　OUT　　I/O端口输出. ( 语法: OUT {端口号│DX},累加器 )
　　　　　输入输出端口由立即方式指定时, 其范围是 0-255; 由寄存器 DX 指定时,
　　　　　其范围是 0-65535.
　　3. 目的地址传送指令.
　　　　LEA　　装入有效地址.
　　　　　例: LEA DX,string　;把偏移地址存到DX.
　　　　LDS　　传送目标指针,把指针内容装入DS.
　　　　　例: LDS SI,string　;把段地址:偏移地址存到DS:SI.
　　　　LES　　传送目标指针,把指针内容装入ES.
　　　　　例: LES DI,string　;把段地址:偏移地址存到ES:DI.
　　　　LFS　　传送目标指针,把指针内容装入FS.
　　　　　例: LFS DI,string　;把段地址:偏移地址存到FS:DI.
　　　　LGS　　传送目标指针,把指针内容装入GS.
　　　　　例: LGS DI,string　;把段地址:偏移地址存到GS:DI.
　　　　LSS　　传送目标指针,把指针内容装入SS.
　　　　　例: LSS DI,string　;把段地址:偏移地址存到SS:DI.
　　4. 标志传送指令.
　　　　LAHF　　标志寄存器传送,把标志装入AH.
　　　　SAHF　　标志寄存器传送,把AH内容装入标志寄存器.
　　　　PUSHF　标志入栈.
　　　　POPF　　标志出栈.
　　　　PUSHD　32位标志入栈.
　　　　POPD　　32位标志出栈.
二、算术运算指令

　　　　ADD　　加法.
　　　　ADC　　带进位加法.
　　　　INC　　加 1.
　　　　AAA　　加法的ASCII码调整.
　　　　DAA　　加法的十进制调整.
　　　　SUB　　减法.
　　　　SBB　　带借位减法.
　　　　DEC　　减 1.
　　　　NEC　　求反(以 0 减之).
　　　　CMP　　比较.(两操作数作减法,仅修改标志位,不回送结果).
　　　　AAS　　减法的ASCII码调整.
　　　　DAS　　减法的十进制调整.
　　　　MUL　　无符号乘法.
　　　　IMUL　　整数乘法.
　　　　　以上两条,结果回送AH和AL(字节运算),或DX和AX(字运算),
　　　　AAM　　乘法的ASCII码调整.
　　　　DIV　　无符号除法.
　　　　IDIV　　整数除法.
　　　　　以上两条,结果回送:
　　　　　　　商回送AL,余数回送AH, (字节运算);
　　　　　或　商回送AX,余数回送DX, (字运算).
　　　　AAD　　除法的ASCII码调整.
　　　　CBW　　字节转换为字. (把AL中字节的符号扩展到AH中去)
　　　　CWD　　字转换为双字. (把AX中的字的符号扩展到DX中去)
　　　　CWDE　　字转换为双字. (把AX中的字符号扩展到EAX中去)
　　　　CDQ　　双字扩展.　　(把EAX中的字的符号扩展到EDX中去)

三、逻辑运算指令

　　 　AND　　与运算.
　　　　OR　　　或运算.
　　　　XOR　　异或运算.
　　　　NOT　　取反.
　　　　TEST　　测试.(两操作数作与运算,仅修改标志位,不回送结果).
　　　　SHL　　逻辑左移.
　　　　SAL　　算术左移.(=SHL)
　　　　SHR　　逻辑右移.
　　　　SAR　　算术右移.(=SHR)
　　　　ROL　　循环左移.
　　　　ROR　　循环右移.
　　　　RCL　　通过进位的循环左移.
　　　　RCR　　通过进位的循环右移.
　　　　　以上八种移位指令,其移位次数可达255次.
　　　　　　　移位一次时, 可直接用操作码.　如 SHL AX,1.
　　　　　　　移位>1次时, 则由寄存器CL给出移位次数.
　　　　　　　　如　MOV CL,04
　　　　　　　　　　SHL AX,CL

四、串指令

　DS:SI　源串段寄存器　:源串变址.
　　　　　　ES:DI　目标串段寄存器:目标串变址.
　　　　　　CX　　　重复次数计数器.
　　　　　　AL/AX　扫描值.
　　　　　　D标志　0表示重复操作中SI和DI应自动增量; 1表示应自动减量.
　　　　　　Z标志　用来控制扫描或比较操作的结束.
　　　　MOVS　　串传送.
　　　　　　( MOVSB　传送字符.　　MOVSW　传送字.　　MOVSD　传送双字. )
　　　　CMPS　　串比较.
　　　　　　( CMPSB　比较字符.　　CMPSW　比较字. )
　　　　SCAS　　串扫描.
　　　　　　把AL或AX的内容与目标串作比较,比较结果反映在标志位.
　　　　LODS　　装入串.
　　　　　　把源串中的元素(字或字节)逐一装入AL或AX中.
　　　　　　( LODSB　传送字符.　　LODSW　传送字.　　LODSD　传送双字. )
　　　　STOS　　保存串.
　　　　　　是LODS的逆过程.
　　　　REP　　　　　　当CX/ECX<>0时重复.
　　　　REPE/REPZ　　　当ZF=1或比较结果相等,且CX/ECX<>0时重复.
　　　　REPNE/REPNZ　　当ZF=0或比较结果不相等,且CX/ECX<>0时重复.
　　　　REPC　　　　　当CF=1且CX/ECX<>0时重复.
　　　　REPNC　　　　　当CF=0且CX/ECX<>0时重复.

五、程序转移指令

　　1>无条件转移指令 (长转移)
　　　　JMP　　无条件转移指令
　　　　CALL　　过程调用
　　　　RET/RETF过程返回.
　　2>条件转移指令 (短转移,-128到+127的距离内)
　　　　( 当且仅当(SF XOR OF)=1时,OP1<OP2 )
　　　　JA/JNBE 不小于或不等于时转移.
　　　　JAE/JNB 大于或等于转移.
　　　　JB/JNAE 小于转移.
　　　　JBE/JNA 小于或等于转移.
　　　　　以上四条,测试无符号整数运算的结果(标志C和Z).
　　　　JG/JNLE 大于转移.
　　　　JGE/JNL 大于或等于转移.
　　　　JL/JNGE 小于转移.
　　　　JLE/JNG 小于或等于转移.
　　　　　以上四条,测试带符号整数运算的结果(标志S,O和Z).
　　　　JE/JZ　等于转移.
　　　　JNE/JNZ 不等于时转移.
　　　　JC　　　有进位时转移.
　　　　JNC　　无进位时转移.
　　　　JNO　　不溢出时转移.
　　　　JNP/JPO 奇偶性为奇数时转移.
　　　　JNS　　符号位为 "0" 时转移.
　　　　JO　　　溢出转移.
　　　　JP/JPE　奇偶性为偶数时转移.
　　　　JS　　　符号位为 "1" 时转移.
　　3>循环控制指令(短转移)
　　　　LOOP　　　　　　CX不为零时循环.
　　　　LOOPE/LOOPZ　　CX不为零且标志Z=1时循环.
　　　　LOOPNE/LOOPNZ　CX不为零且标志Z=0时循环.
　　　　JCXZ　　　　　　CX为零时转移.
　　　　JECXZ　　　　　ECX为零时转移.
　　4>中断指令
　　　　INT　　中断指令
　　　　INTO　　溢出中断
　　　　IRET　　中断返回
5>处理器控制指令
　　　　HLT　　处理器暂停, 直到出现中断或复位信号才继续.
　　　　WAIT　　当芯片引线TEST为高电平时使CPU进入等待状态.
　　　　ESC　　转换到外处理器.
　　　　LOCK　　封锁总线.
　　　　NOP　　空操作.
　　　　STC　　置进位标志位.
　　　　CLC　　清进位标志位.
　　　　CMC　　进位标志取反.
　　　　STD　　置方向标志位.
　　　　CLD　　清方向标志位.
　　　　STI　　置中断允许位.
　　　　CLI　　清中断允许位.
六、伪指令
DW　　　定义字(2字节).
　　　　PROC　　定义过程.
　　　　ENDP　　过程结束.
　　　　SEGMENT 定义段.
　　　　ASSUME　建立段寄存器寻址.
　　　　ENDS　　段结束.
　　　　END　　程序结束.

        不知哪位大哥总结的，先借来用一下，免得老是翻书^_^ 
附一个汇编的在线学习网站

数据传输指令
───────────────────────────────────────
它们在存贮器和寄存器、寄存器和输入输出端口之间传送数据.
1. 通用数据传送指令.
MOV 传送字或字节.
MOVSX 先符号扩展,再传送.
MOVZX 先零扩展,再传送.
PUSH 把字压入堆栈.
POP 把字弹出堆栈.
PUSHA 把AX,CX,DX,BX,SP,BP,SI,DI依次压入堆栈.
POPA 把DI,SI,BP,SP,BX,DX,CX,AX依次弹出堆栈.
PUSHAD 把EAX,ECX,EDX,EBX,ESP,EBP,ESI,EDI依次压入堆栈.
POPAD 把EDI,ESI,EBP,ESP,EBX,EDX,ECX,EAX依次弹出堆栈.
BSWAP 交换32位寄存器里字节的顺序
XCHG 交换字或字节.( 至少有一个操作数为寄存器,段寄存器不可作为操作数)
CMPXCHG 比较并交换操作数.( 第二个操作数必须为累加器AL/AX/EAX )
XADD 先交换再累加.( 结果在第一个操作数里 )
XLAT 字节查表转换.
── BX 指向一张 256 字节的表的起点, AL 为表的索引值 (0-255,即
0-FFH); 返回 AL 为查表结果. ( [BX+AL]->AL )
2. 输入输出端口传送指令.
IN I/O端口输入. ( 语法: IN 累加器, {端口号│DX} )
OUT I/O端口输出. ( 语法: OUT {端口号│DX},累加器 )
输入输出端口由立即方式指定时, 其范围是 0-255; 由寄存器 DX 指定时,
其范围是 0-65535.
3. 目的地址传送指令.
LEA 装入有效地址.
例: LEA DX,string ;把偏移地址存到DX.
LDS 传送目标指针,把指针内容装入DS.
例: LDS SI,string ;把段地址:偏移地址存到DS:SI.
LES 传送目标指针,把指针内容装入ES.
例: LES DI,string ;把段地址:偏移地址存到ES:DI.
LFS 传送目标指针,把指针内容装入FS.
例: LFS DI,string ;把段地址:偏移地址存到FS:DI.
LGS 传送目标指针,把指针内容装入GS.
例: LGS DI,string ;把段地址:偏移地址存到GS:DI.
LSS 传送目标指针,把指针内容装入SS.
例: LSS DI,string ;把段地址:偏移地址存到SS:DI.
4. 标志传送指令.
LAHF 标志寄存器传送,把标志装入AH.
SAHF 标志寄存器传送,把AH内容装入标志寄存器.
PUSHF 标志入栈.
POPF 标志出栈.
PUSHD 32位标志入栈.
POPD 32位标志出栈.

二、算术运算指令
───────────────────────────────────────
ADD 加法.
ADC 带进位加法.
INC 加 1.
AAA 加法的ASCII码调整.
DAA 加法的十进制调整.
SUB 减法.
SBB 带借位减法.
DEC 减 1.
NEC 求反(以 0 减之).
CMP 比较.(两操作数作减法,仅修改标志位,不回送结果).
AAS 减法的ASCII码调整.
DAS 减法的十进制调整.
MUL 无符号乘法.
IMUL 整数乘法.
以上两条,结果回送AH和AL(字节运算),或DX和AX(字运算),
AAM 乘法的ASCII码调整.
DIV 无符号除法.
IDIV 整数除法.
以上两条,结果回送:
商回送AL,余数回送AH, (字节运算);
或 商回送AX,余数回送DX, (字运算).
AAD 除法的ASCII码调整.
CBW 字节转换为字. (把AL中字节的符号扩展到AH中去)
CWD 字转换为双字. (把AX中的字的符号扩展到DX中去)
CWDE 字转换为双字. (把AX中的字符号扩展到EAX中去)
CDQ 双字扩展. (把EAX中的字的符号扩展到EDX中去)

三、逻辑运算指令
───────────────────────────────────────
AND 与运算.
OR 或运算.
XOR 异或运算.
NOT 取反.
TEST 测试.(两操作数作与运算,仅修改标志位,不回送结果).
SHL 逻辑左移.
SAL 算术左移.(=SHL)
SHR 逻辑右移.
SAR 算术右移.(=SHR)  当值为负时，高位补 1 ；当值为正时，高位补 0
ROL 循环左移.
ROR 循环右移.
RCL 通过进位的循环左移.
RCR 通过进位的循环右移.
以上八种移位指令,其移位次数可达255次.
移位一次时, 可直接用操作码. 如 SHL AX,1.
移位>1次时, 则由寄存器CL给出移位次数.
如 MOV CL,04
SHL AX,CL

四、串指令
───────────────────────────────────────
DS:SI 源串段寄存器 :源串变址.
ES:DI 目标串段寄存器:目标串变址.
CX 重复次数计数器.
AL/AX 扫描值.
D标志 0表示重复操作中SI和DI应自动增量; 1表示应自动减量.
Z标志 用来控制扫描或比较操作的结束.
MOVS 串传送.
( MOVSB 传送字符. MOVSW 传送字. MOVSD 传送双字. )
CMPS 串比较.
( CMPSB 比较字符. CMPSW 比较字. )
SCAS 串扫描.
把AL或AX的内容与目标串作比较,比较结果反映在标志位.
LODS 装入串.
把源串中的元素(字或字节)逐一装入AL或AX中.
( LODSB 传送字符. LODSW 传送字. LODSD 传送双字. )
STOS 保存串.
是LODS的逆过程.
REP 当CX/ECX<>0时重复.
REPE/REPZ 当ZF=1或比较结果相等,且CX/ECX<>0时重复.
REPNE/REPNZ 当ZF=0或比较结果不相等,且CX/ECX<>0时重复.
REPC 当CF=1且CX/ECX<>0时重复.
REPNC 当CF=0且CX/ECX<>0时重复.

五、程序转移指令
───────────────────────────────────────
1>无条件转移指令 (长转移)
JMP 无条件转移指令
CALL 过程调用
RET/RETF过程返回.
2>条件转移指令 (短转移,-128到+127的距离内)
( 当且仅当(SF XOR OF)=1时,OP1 JA/JNBE 不小于或不等于时转移.
JAE/JNB 大于或等于转移.
JB/JNAE 小于转移.
JBE/JNA 小于或等于转移.
以上四条,测试无符号整数运算的结果(标志C和Z).
JG/JNLE 大于转移.
JGE/JNL 大于或等于转移.
JL/JNGE 小于转移.
JLE/JNG 小于或等于转移.
以上四条,测试带符号整数运算的结果(标志S,O和Z).
JE/JZ 等于转移.
JNE/JNZ 不等于时转移.
JC 有进位时转移.
JNC 无进位时转移.
JNO 不溢出时转移.
JNP/JPO 奇偶性为奇数时转移.
JNS 符号位为 "0" 时转移.
JO 溢出转移.
JP/JPE 奇偶性为偶数时转移.
JS 符号位为 "1" 时转移.
3>循环控制指令(短转移)
LOOP CX不为零时循环.
LOOPE/LOOPZ CX不为零且标志Z=1时循环.
LOOPNE/LOOPNZ CX不为零且标志Z=0时循环.
JCXZ CX为零时转移.
JECXZ ECX为零时转移.
4>中断指令
INT 中断指令
INTO 溢出中断
IRET 中断返回
5>处理器控制指令
HLT 处理器暂停, 直到出现中断或复位信号才继续.
WAIT 当芯片引线TEST为高电平时使CPU进入等待状态.
ESC 转换到外处理器.
LOCK 封锁总线.
NOP 空操作.
STC 置进位标志位.
CLC 清进位标志位.
CMC 进位标志取反.
STD 置方向标志位.
CLD 清方向标志位.
STI 置中断允许位.
CLI 清中断允许位.

六、伪指令
─────────────────────────────────────
DW 定义字(2字节).
PROC 定义过程.
ENDP 过程结束.
SEGMENT 定义段.
ASSUME 建立段寄存器寻址.
ENDS 段结束.
END 程序结束.

在32位微机系统中，除了支持前面的七种寻址方式外，又提供了一种更灵活、方便，但也更复杂的内存寻址方式，从而使内存地址的寻址范围得到了进一步扩大。

在用16位寄存器来访问存储单元时，只能使用基地址寄存器(BX和BP)和变址寄存器(SI和DI)来作为地址偏移量的一部分，但在用32位寄存器寻址时，不存在上述限制，所有32位寄存器(EAX、EBX、ECX、EDX、ESI、EDI、EBP和ESP)都可以是地址偏移量的一个组成部分。

当用32位地址偏移量进行寻址时，内存地址的偏移量可分为三部分：一个32位基址寄存器，一个可乘1、2、4或8的32位变址寄存器，一个8位/32位的偏移常量，并且这三部分还可进行任意组合，省去其中之一或之二。

32位基址寄存器是：EAX、EBX、ECX、EDX、ESI、EDI、EBP和ESP；
32位变址寄存器是：EAX、EBX、ECX、EDX、ESI、EDI和EBP(除ESP之外)。

如：[EBX EBP]中的EBX是基址寄存器，EBP是变址寄存器，而[EBP EBX]中的EBP是基址寄存器，EBX是变址寄存器；

2、默认段寄存器的选用取决于基址寄存器；

3、基址寄存器是EBP或ESP时，默认的段寄存器是SS，否则，默认的段寄存器是DS；

4、在指令中，如果使用段前缀的方式，那么，显式段寄存器优先。

下面列举几个32位地址寻址指令及其内存操作数的段寄存器。

程序例子

1、普通调用（cdecl）。

    调用方 C++ 代码：

    生成的汇编码：

    调用方代码总结：

• 参数从右向左依次入栈。
• 栈指针（ESP）从底部向顶部依次减小。也就是说，栈顶地址小；栈底地址大。
• 如果参数是结构（struct），则直接移动栈顶指针，预留出结构的大小；然后用 mov 指令逐步将成员拷贝到预留出来的栈空间！
• call 指令调用目标地址
• 调用方清栈
• 获得返回值

    函数中生成的汇编码