串口通讯中的DCB结构

typedef struct _DCB {// dcb

DWORD DCBlength; // sizeof(DCB)

DORD BaudRate; // current baud rate　指定当前的波特率

DWORD fBinary: 1; // binary mode, no EOF check　指定是否允许二进制模式WIN95中须为TRUE
       

DWORD fParity: 1; // enable parity checking　指定奇偶校验是否允许

DWORD fOutxCtsFlow:1; // CTS output flow control 指定CTS是否用于检测发送控制。当为TRUE是CTS为OFF，发送将被挂起。

DWORD fOutxDsrFlow:1; // DSR output flow control   指定CTS是否用于检测发送控制。当为TRUE是CTS为OFF，发送将被挂起。

DWORD fDtrControl:2; // DTR flow control type

DTR_CONTROL_DISABLE 值将DTR置为OFF,DTR_CONTROL_ENABLE值将DTR置为ON, 

DTR_CONTROL_HANDSHAKE 允许DTR"握手",

DWORD fDsrSensitivity:1;// DSR sensitivity 当该值为TRUE时DSR为OFF时接收的字节被忽略

DWORD fTXContinueOnXoff:1; // XOFF continues Tx
    指定当接收缓冲区已满,并且驱动程序已经发送出XoffChar字符时发送是否停止。

    TRUE时，在接收缓冲区接收到缓冲区已满的字节XoffLim且驱动程序已经发送出XoffChar字      符中止接收字节之后，发送继续进行。
    FALSE时，在接收缓冲区接收到代表缓冲区已空的字节XonChar且驱动程序已经发送出恢复发送的XonChar之后，发送继续进行。

DWORD fOutX: 1; // XON/XOFF out flow control    TRUE时，接收到XoffChar之后便停止发送接收到XonChar之后将重新开始

DWORD fInX: 1; // XON/XOFF in flow control
             TRUE时，接收缓冲区接收到代表缓冲区满的XoffLim之后，XoffChar发送出去接收缓冲区接收到代表缓冲区空的XonLim之后，XonChar发送出去

DWORD fErrorChar: 1; // enable error replacement
        　该值为TRUE且fParity为TRUE时，用ErrorChar 成员指定的字符代替奇偶校验错误的接收字符

DWORD fNull: 1; // enable null stripping　　TRUE时，接收时去掉空（0值）字节

DWORD fRtsControl:2; // RTS flow control

DWORD fAbortOnError:1; // abort reads/writes on error　　TRUE时,有错误发生时中止读和写操作RTS_CONTROL_DISABLE时,RTS置为OFFRTS_CONTROL_ENABLE时, RTS置为ON

RTS_CONTROL_HANDSHAKE时,当接收缓冲区小于半满时RTS为ON当接收缓冲区超过四分之三满时RTS为OFF

RTS_CONTROL_TOGGLE时,当接收缓冲区仍有剩余字节时RTS为ON ,否则缺省为OFF

DWORD fDummy2:17; // reserved　　未使用

WORD wReserved; // not currently used　　未使用,必须为0

WORD XonLim; // transmit XON threshold   指定在XON字符发送这前接收缓冲区中可允许的最小字节数

WORD XoffLim; // transmit XOFF threshold  指定在XOFF字符发送这前接收缓冲区中可允许的最小字节数

BYTE ByteSize; // number of bits/byte, 4-8　　指定端口当前使用的数据位

BYTE Parity; // 0-4=no,odd,even,mark,space　指定端口当前使用的奇偶校验方法,可能为:
                            EVENPARITY,MARKPARITY,NOPARITY,ODDPARITY　BYTE

StopBits;      0,1,2 = 1, 1.5, 2 　　指定端口当前使用的停止位数,可能为:
                          ONESTOPBIT,ONE5STOPBITS,TWOSTOPBITS

char XonChar; // Tx and Rx XON character　　指定用于发送和接收字符XON的值

char XoffChar; // Tx and Rx XOFF character　　指定用于发送和接收字符XOFF值

char ErrorChar; // error replacement character本字符用来代替接收到的奇偶校验发生错误时的值

char EofChar; // end of input character　当没有使用二进制模式时,本字符可用来指示数据的结束

char EvtChar; // received event character　当接收到此字符时,会产生一个事件

WORD wReserved1; // reserved; do not use 未使用

} DCB;

Murali R. Krishnan
Microsoft Corporation

1999 年 2 月

摘要： 讨论常见的堆性能问题以及如何防范它们。（共 9 页）

前言

您是否是动态分配的 C/C++ 对象忠实且幸运的用户？您是否在模块间的往返通信中频繁地使用了“自动化”？您的程序是否因堆分配而运行起来很慢？不仅仅您遇到这样的问题。几乎所有项目迟早都会遇到堆问题。大家都想说，“我的代码真正好，只是堆太慢”。那只是部分正确。更深入理解堆及其用法、以及会发生什么问题，是很有用的。

什么是堆？

（如果您已经知道什么是堆，可以跳到“什么是常见的堆性能问题？”部分）

在程序中，使用堆来动态分配和释放对象。在下列情况下，调用堆操作：

1. 事先不知道程序所需对象的数量和大小。
   
   
2. 对象太大而不适合堆栈分配程序。

堆使用了在运行时分配给代码和堆栈的内存之外的部分内存。下图给出了堆分配程序的不同层。

GlobalAlloc/GlobalFree：Microsoft Win32 堆调用，这些调用直接与每个进程的默认堆进行对话。

LocalAlloc/LocalFree：Win32 堆调用（为了与 Microsoft Windows NT 兼容），这些调用直接与每个进程的默认堆进行对话。

COM 的 IMalloc 分配程序（或 CoTaskMemAlloc / CoTaskMemFree）：函数使用每个进程的默认堆。自动化程序使用“组件对象模型 (COM)”的分配程序，而申请的程序使用每个进程堆。

C/C++ 运行时 (CRT) 分配程序：提供了 malloc() 和 free() 以及 new 和 delete 操作符。如 Microsoft Visual Basic 和 Java 等语言也提供了新的操作符并使用垃圾收集来代替堆。CRT 创建自己的私有堆，驻留在 Win32 堆的顶部。

Windows NT 中，Win32 堆是 Windows NT 运行时分配程序周围的薄层。所有 API 转发它们的请求给 NTDLL。

Windows NT 运行时分配程序提供 Windows NT 内的核心堆分配程序。它由具有 128 个大小从 8 到 1,024 字节的空闲列表的前端分配程序组成。后端分配程序使用虚拟内存来保留和提交页。

在图表的底部是“虚拟内存分配程序”，操作系统使用它来保留和提交页。所有分配程序使用虚拟内存进行数据的存取。

分配和释放块不就那么简单吗？为何花费这么长时间？

堆实现的注意事项

传统上，操作系统和运行时库是与堆的实现共存的。在一个进程的开始，操作系统创建一个默认堆，叫做“进程堆”。如果没有其他堆可使用，则块的分配使用“进程堆”。语言运行时也能在进程内创建单独的堆。（例如，C 运行时创建它自己的堆。）除这些专用的堆外，应用程序或许多已载入的动态链接库 (DLL) 之一可以创建和使用单独的堆。Win32 提供一整套 API 来创建和使用私有堆。有关堆函数（英文）的详尽指导，请参见 MSDN。

当应用程序或 DLL 创建私有堆时，这些堆存在于进程空间，并且在进程内是可访问的。从给定堆分配的数据将在同一个堆上释放。（不能从一个堆分配而在另一个堆释放。）

在所有虚拟内存系统中，堆驻留在操作系统的“虚拟内存管理器”的顶部。语言运行时堆也驻留在虚拟内存顶部。某些情况下，这些堆是操作系统堆中的层，而语言运行时堆则通过大块的分配来执行自己的内存管理。不使用操作系统堆，而使用虚拟内存函数更利于堆的分配和块的使用。

典型的堆实现由前、后端分配程序组成。前端分配程序维持固定大小块的空闲列表。对于一次分配调用，堆尝试从前端列表找到一个自由块。如果失败，堆被迫从后端（保留和提交虚拟内存）分配一个大块来满足请求。通用的实现有每块分配的开销，这将耗费执行周期，也减少了可使用的存储空间。

Knowledge Base 文章 Q10758，“用 calloc() 和 malloc() 管理内存” （搜索文章编号）, 包含了有关这些主题的更多背景知识。另外，有关堆实现和设计的详细讨论也可在下列著作中找到：“Dynamic Storage Allocation: A Survey and Critical Review”，作者 Paul R. Wilson、Mark S. Johnstone、Michael Neely 和 David Boles；“International Workshop on Memory Management”, 作者 Kinross, Scotland, UK, 1995 年 9 月(http://www.cs.utexas.edu/users/oops/papers.html)（英文）。

Windows NT 的实现（Windows NT 版本 4.0 和更新版本） 使用了 127 个大小从 8 到 1,024 字节的 8 字节对齐块空闲列表和一个“大块”列表。“大块”列表（空闲列表[0]） 保存大于 1,024 字节的块。空闲列表容纳了用双向链表链接在一起的对象。默认情况下，“进程堆”执行收集操作。（收集是将相邻空闲块合并成一个大块的操作。）收集耗费了额外的周期，但减少了堆块的内部碎片。

单一全局锁保护堆，防止多线程式的使用。（请参见“Server Performance and Scalability Killers”中的第一个注意事项, George Reilly 所著，在 “MSDN Online Web Workshop”上（站点：http://msdn.microsoft.com/workshop/server/iis/tencom.asp（英文）。）单一全局锁本质上是用来保护堆数据结构，防止跨多线程的随机存取。若堆操作太频繁，单一全局锁会对性能有不利的影响。

什么是常见的堆性能问题？

以下是您使用堆时会遇到的最常见问题：

• 分配操作造成的速度减慢。光分配就耗费很长时间。最可能导致运行速度减慢原因是空闲列表没有块，所以运行时分配程序代码会耗费周期寻找较大的空闲块，或从后端分配程序分配新块。
  
  
• 释放操作造成的速度减慢。释放操作耗费较多周期，主要是启用了收集操作。收集期间，每个释放操作“查找”它的相邻块，取出它们并构造成较大块，然后再把此较大块插入空闲列表。在查找期间，内存可能会随机碰到，从而导致高速缓存不能命中，性能降低。
  
  
• 堆竞争造成的速度减慢。当两个或多个线程同时访问数据，而且一个线程继续进行之前必须等待另一个线程完成时就发生竞争。竞争总是导致麻烦；这也是目前多处理器系统遇到的最大问题。当大量使用内存块的应用程序或 DLL 以多线程方式运行（或运行于多处理器系统上）时将导致速度减慢。单一锁定的使用—常用的解决方案—意味着使用堆的所有操作是序列化的。当等待锁定时序列化会引起线程切换上下文。可以想象交叉路口闪烁的红灯处走走停停导致的速度减慢。

  竞争通常会导致线程和进程的上下文切换。上下文切换的开销是很大的，但开销更大的是数据从处理器高速缓存中丢失，以及后来线程复活时的数据重建。

• 堆破坏造成的速度减慢。造成堆破坏的原因是应用程序对堆块的不正确使用。通常情形包括释放已释放的堆块或使用已释放的堆块，以及块的越界重写等明显问题。（破坏不在本文讨论范围之内。有关内存重写和泄漏等其他细节，请参见 Microsoft Visual C++(R) 调试文档 。）
  
  
• 频繁的分配和重分配造成的速度减慢。这是使用脚本语言时非常普遍的现象。如字符串被反复分配，随重分配增长和释放。不要这样做，如果可能，尽量分配大字符串和使用缓冲区。另一种方法就是尽量少用连接操作。

竞争是在分配和释放操作中导致速度减慢的问题。理想情况下，希望使用没有竞争和快速分配/释放的堆。可惜，现在还没有这样的通用堆，也许将来会有。

在所有的服务器系统中（如 IIS、MSProxy、DatabaseStacks、网络服务器、 Exchange 和其他）, 堆锁定实在是个大瓶颈。处理器数越多，竞争就越会恶化。

尽量减少堆的使用

现在您明白使用堆时存在的问题了，难道您不想拥有能解决这些问题的超级魔棒吗？我可希望有。但没有魔法能使堆运行加快—因此不要期望在产品出货之前的最后一星期能够大为改观。如果提前规划堆策略，情况将会大大好转。调整使用堆的方法，减少对堆的操作是提高性能的良方。

如何减少使用堆操作？通过利用数据结构内的位置可减少堆操作的次数。请考虑下列实例：

struct ObjectA {
    // objectA 的数据
}
struct ObjectB {
    // objectB 的数据
}
// 同时使用 objectA 和 objectB
//
// 使用指针
//
struct ObjectB {
    struct ObjectA * pObjA;
    // objectB 的数据
}
//
// 使用嵌入
//
struct ObjectB {
    struct ObjectA pObjA;
    // objectB 的数据
}
//
// 集合 – 在另一对象内使用 objectA 和 objectB
//
struct ObjectX {
    struct ObjectA   objA;
    struct ObjectB   objB;
}

1. 避免使用指针关联两个数据结构。如果使用指针关联两个数据结构，前面实例中的对象 A 和 B 将被分别分配和释放。这会增加额外开销—我们要避免这种做法。
   
   
2. 把带指针的子对象嵌入父对象。当对象中有指针时，则意味着对象中有动态元素（百分之八十）和没有引用的新位置。嵌入增加了位置从而减少了进一步分配/释放的需求。这将提高应用程序的性能。
   
   
3. 合并小对象形成大对象（聚合）。聚合减少分配和释放的块的数量。如果有几个开发者，各自开发设计的不同部分，则最终会有许多小对象需要合并。集成的挑战就是要找到正确的聚合边界。
   
   
4. 内联缓冲区能够满足百分之八十的需要（aka 80-20 规则）。个别情况下，需要内存缓冲区来保存字符串/二进制数据，但事先不知道总字节数。估计并内联一个大小能满足百分之八十需要的缓冲区。对剩余的百分之二十，可以分配一个新的缓冲区和指向这个缓冲区的指针。这样，就减少分配和释放调用并增加数据的位置空间，从根本上提高代码的性能。
   
   
5. 在块中分配对象（块化）。块化是以组的方式一次分配多个对象的方法。如果对列表的项连续跟踪，例如对一个 {名称，值} 对的列表，有两种选择：选择一是为每一个“名称-值”对分配一个节点；选择二是分配一个能容纳（如五个）“名称-值”对的结构。例如，一般情况下，如果存储四对，就可减少节点的数量，如果需要额外的空间数量，则使用附加的链表指针。

   块化是友好的处理器高速缓存，特别是对于 L1-高速缓存，因为它提供了增加的位置 —不用说对于块分配，很多数据块会在同一个虚拟页中。

6. 正确使用 _amblksiz。C 运行时 (CRT) 有它的自定义前端分配程序，该分配程序从后端（Win32 堆）分配大小为 _amblksiz 的块。将 _amblksiz 设置为较高的值能潜在地减少对后端的调用次数。这只对广泛使用 CRT 的程序适用。

使用上述技术将获得的好处会因对象类型、大小及工作量而有所不同。但总能在性能和可升缩性方面有所收获。另一方面，代码会有点特殊，但如果经过深思熟虑，代码还是很容易管理的。

其他提高性能的技术

下面是一些提高速度的技术：

1. 使用 Windows NT5 堆

   由于几个同事的努力和辛勤工作，1998 年初 Microsoft Windows(R) 2000 中有了几个重大改进：

   • 改进了堆代码内的锁定。堆代码对每堆一个锁。全局锁保护堆数据结构，防止多线程式的使用。但不幸的是，在高通信量的情况下，堆仍受困于全局锁，导致高竞争和低性能。Windows 2000 中，锁内代码的临界区将竞争的可能性减到最小,从而提高了可伸缩性。
     
     
   • 使用 “Lookaside”列表。堆数据结构对块的所有空闲项使用了大小在 8 到 1,024 字节（以 8-字节递增）的快速高速缓存。快速高速缓存最初保护在全局锁内。现在，使用 lookaside 列表来访问这些快速高速缓存空闲列表。这些列表不要求锁定，而是使用 64 位的互锁操作，因此提高了性能。
     
     
   • 内部数据结构算法也得到改进。

   这些改进避免了对分配高速缓存的需求，但不排除其他的优化。使用 Windows NT5 堆评估您的代码；它对小于 1,024 字节 (1 KB) 的块（来自前端分配程序的块）是最佳的。GlobalAlloc() 和 LocalAlloc() 建立在同一堆上，是存取每个进程堆的通用机制。如果希望获得高的局部性能，则使用 Heap(R) API 来存取每个进程堆，或为分配操作创建自己的堆。如果需要对大块操作，也可以直接使用 VirtualAlloc() / VirtualFree() 操作。

   上述改进已在 Windows 2000 beta 2 和 Windows NT 4.0 SP4 中使用。改进后，堆锁的竞争率显著降低。这使所有 Win32 堆的直接用户受益。CRT 堆建立于 Win32 堆的顶部，但它使用自己的小块堆，因而不能从 Windows NT 改进中受益。（Visual C++ 版本 6.0 也有改进的堆分配程序。）

2. 使用分配高速缓存

   分配高速缓存允许高速缓存分配的块，以便将来重用。这能够减少对进程堆（或全局堆）的分配/释放调用的次数，也允许最大限度的重用曾经分配的块。另外，分配高速缓存允许收集统计信息,以便较好地理解对象在较高层次上的使用。

   典型地，自定义堆分配程序在进程堆的顶部实现。自定义堆分配程序与系统堆的行为很相似。主要的差别是它在进程堆的顶部为分配的对象提供高速缓存。高速缓存设计成一套固定大小（如 32 字节、64 字节、128 字节等）。这一个很好的策略，但这种自定义堆分配程序丢失与分配和释放的对象相关的“语义信息”。

   与自定义堆分配程序相反，“分配高速缓存”作为每类分配高速缓存来实现。除能够提供自定义堆分配程序的所有好处之外，它们还能够保留大量语义信息。每个分配高速缓存处理程序与一个目标二进制对象关联。它能够使用一套参数进行初始化，这些参数表示并发级别、对象大小和保持在空闲列表中的元素的数量等。分配高速缓存处理程序对象维持自己的私有空闲实体池（不超过指定的阀值）并使用私有保护锁。合在一起，分配高速缓存和私有锁减少了与主系统堆的通信量，因而提供了增加的并发、最大限度的重用和较高的可伸缩性。

   需要使用清理程序来定期检查所有分配高速缓存处理程序的活动情况并回收未用的资源。如果发现没有活动，将释放分配对象的池，从而提高性能。

   可以审核每个分配/释放活动。第一级信息包括对象、分配和释放调用的总数。通过查看它们的统计信息可以得出各个对象之间的语义关系。利用以上介绍的许多技术之一，这种关系可以用来减少内存分配。

   分配高速缓存也起到了调试助手的作用，帮助您跟踪没有完全清除的对象数量。通过查看动态堆栈返回踪迹和除没有清除的对象之外的签名，甚至能够找到确切的失败的调用者。

3. MP 堆

   MP 堆是对多处理器友好的分布式分配的程序包，在 Win32 SDK（Windows NT 4.0 和更新版本）中可以得到。最初由 JVert 实现，此处堆抽象建立在 Win32 堆程序包的顶部。MP 堆创建多个 Win32 堆，并试图将分配调用分布到不同堆，以减少在所有单一锁上的竞争。

   本程序包是好的步骤 —一种改进的 MP-友好的自定义堆分配程序。但是，它不提供语义信息和缺乏统计功能。通常将 MP 堆作为 SDK 库来使用。如果使用这个 SDK 创建可重用组件，您将大大受益。但是，如果在每个 DLL 中建立这个 SDK 库，将增加工作设置。

4. 重新思考算法和数据结构

   要在多处理器机器上伸缩，则算法、实现、数据结构和硬件必须动态伸缩。请看最经常分配和释放的数据结构。试问，“我能用不同的数据结构完成此工作吗？”例如，如果在应用程序初始化时加载了只读项的列表，这个列表不必是线性链接的列表。如果是动态分配的数组就非常好。动态分配的数组将减少内存中的堆块和碎片，从而增强性能。

   减少需要的小对象的数量减少堆分配程序的负载。例如，我们在服务器的关键处理路径上使用五个不同的对象，每个对象单独分配和释放。一起高速缓存这些对象，把堆调用从五个减少到一个，显著减少了堆的负载，特别当每秒钟处理 1,000 个以上的请求时。

   如果大量使用“Automation”结构，请考虑从主线代码中删除“Automation BSTR”，或至少避免重复的 BSTR 操作。（BSTR 连接导致过多的重分配和分配/释放操作。）

摘要

对所有平台往往都存在堆实现，因此有巨大的开销。每个单独代码都有特定的要求，但设计能采用本文讨论的基本理论来减少堆之间的相互作用。

1. 评价您的代码中堆的使用。
   
   
2. 改进您的代码，以使用较少的堆调用：分析关键路径和固定数据结构。
   
   
3. 在实现自定义的包装程序之前使用量化堆调用成本的方法。
   
   
4. 如果对性能不满意，请要求 OS 组改进堆。更多这类请求意味着对改进堆的更多关注。
   
   
5. 要求 C 运行时组针对 OS 所提供的堆制作小巧的分配包装程序。随着 OS 堆的改进，C 运行时堆调用的成本将减小。
   
   
6. 操作系统（Windows NT 家族）正在不断改进堆。请随时关注和利用这些改进。

Murali Krishnan 是 Internet Information Server (IIS) 组的首席软件设计工程师。从 1.0 版本开始他就设计 IIS，并成功发行了 1.0 版本到 4.0 版本。Murali 组织并领导 IIS 性能组三年 (1995-1998), 从一开始就影响 IIS 性能。他拥有威斯康星州 Madison 大学的 M.S.和印度 Anna 大学的 B.S.。工作之外，他喜欢阅读、打排球和家庭烹饪。

MFC本身的CView类是支持拖放操作的，通过研究CView类的源码，大体知道它的实现原理是这样的：CView类中有一个COleDropTarget类的对象，在视图窗口初始化时，调用COleDropTarget类成员函数Register()，以此在系统中注册该视图窗口为拖放接收窗口。当进行拖放操作的鼠标指针处于视图窗口范围内时，COleDropTarge类会做出反应，它的OnDragEnter、OnDragOver、OnDropEx、OnDrop等成员函数被依次调用，这些函数默认均是调用与其相对应的CView类成员函数OnDragEnter、OnDragOver、OnDropEx、OnDrop等，程序员只需重载这些CView类成员函数，即可对拖动的过程及结果进行控制。

因为COleDropTarget默认只对CView提供支持，所以如果要让其他的窗口支持拖放，我们必须同时对要支持拖放的窗口类和COleDropTarget类进行派生。把对拖放操作具体进行处理的代码封装成派生窗口类的成员函数，然后重载COleDropTarget中对应的五个虚函数，当它接收到拖放动作时，调用窗口派生类的处理函数即可。但这里有一个问题，就是我们怎么知道何时调用派生类的处理函数呢？答案是运用RTTI技术。如果COleDropTarget派生类收到的窗口指针类型，就是我们派生的窗口类，那么就调用它的处理函数，否则调用基类进行处理。

首先生成一个对话框工程，添加二个新类。

第一个类名为CListCtrlEx，父类为CListCtrl。添加完毕后，在CListCtrlEx的定义头文件中加入DECLARE_DYNAMIC(CListCtrlEx)，在其实现文件中加入IMPLEMENT_DYNAMIC(CListCtrlEx,CListCtrl)，这样就对CListCtrlEx类添加了RTTI运行期类型识别（Run Time Type Information）支持。

第二个类名为COleDropTargetEx，父类为COleDataTarget。

在CListCtrlEx中添加COleDropTargetEx类的对象，并添加下列公有虚函数的声明：

       virtual BOOL Initialize();

       virtual DROPEFFECT OnDragOver(CWnd* pWnd, COleDataObject* pDataObject, DWORD dwKeyState, CPoint point);

       virtual DROPEFFECT OnDropEx(CWnd* pWnd, COleDataObject* pDataObject, DROPEFFECT dropEffect, DROPEFFECT dropList, CPoint point);

       virtual BOOL OnDrop(CWnd* pWnd, COleDataObject* pDataObject, DROPEFFECT dropEffect, CPoint point);

       virtual void OnDragLeave(CWnd* pWnd);

Initialize函数用于注册CListCtrlEx成为拖放接收窗口；

OnDragOver在拖放鼠标进入窗口时被调用。此函数的返回值决定了后续的动作的类型：如果返回DROPEFFECT_MOVE，则产生一个剪切动作；如果返回DROPEFFECT_COPY，则产生一个复制动作，如果返回DROPEFFECT_NONE，则不会产生拖放动作，因为OnDropEx、OnDrop函数将不会被调用（OnDragLeave函数仍会被调用）。

OnDropEx函数会在OnDrop函数之前调用，如果OnDropEx函数没有对拖放动作进行处理，则应用程序框架会接着调用OnDrop函数进行处理。所以必须要在派生类中重载OnDropEx函数——即使什么动作都都没有做——否则我们的OnDrop函数将不会被执行到，因为没有重载的话，将会调用基类的OnDropEx函数，而基类的OnDropEx函数对拖放是进行了处理的——尽管不是我们所想要的动作。当然你也可以把对拖放进行处理的动作放在OnDropEx中——那样就不需要重载OnDrop了。

OnDragLeave函数会在鼠标离开窗口时被调用，在此可以进行一些简单的清理工作。譬如在OnDragEnter或者OnDragOver函数中，我们改变了光标的形态，那么此时我们就应该把光标恢复过来。

这些函数中最重要的是OnDrop函数，拖放动作将在此进行处理，它的全部源码如下：

BOOL CListCtrlEx::OnDrop(CWnd* pWnd, COleDataObject* pDataObject, DROPEFFECT dropEffect, CPoint point)

{

       UINT              nFileCount = 0;

       HDROP           hDropFiles = NULL;

       HGLOBAL        hMemData = NULL;

       AfxMessageBox("OnDrop");

       if(pDataObject->IsDataAvailable(CF_HDROP))

       {

              hMemData = pDataObject->GetGlobalData(CF_HDROP);

              hDropFiles = (HDROP)GlobalLock((HGLOBAL)hMemData); //锁定内存块

              if(hDropFiles != NULL)

              {

                     char chTemp[_MAX_PATH+1] = {0};

                     nFileCount = DragQueryFile(hDropFiles, 0xFFFFFFFF, NULL, 0);

                     for(UINT nCur=0; nCur<nFileCount; ++nCur) //遍历取得每个文件名

                     {

                            ZeroMemory(chTemp, _MAX_PATH+1);

                DragQueryFile(hDropFiles, nCur, (LPTSTR)chTemp, _MAX_PATH+1);

                            AddAllFiles(chTemp);

                     }

              }

              GlobalUnlock(hMemData);

              return TRUE;

       }

       else

       {

              return FALSE;

       }

}

在第二个类COleDropTarget中添加如下对应的函数：

    virtual DROPEFFECT OnDragEnter(CWnd* pWnd, COleDataObject* pDataObject, DWORD dwKeyState, CPoint point);

    virtual DROPEFFECT OnDragOver(CWnd* pWnd, COleDataObject* pDataObject, DWORD dwKeyState, CPoint point);

       virtual DROPEFFECT OnDropEx(CWnd* pWnd, COleDataObject* pDataObject, DROPEFFECT dropEffect, DROPEFFECT dropList, CPoint point);

       virtual BOOL OnDrop(CWnd* pWnd, COleDataObject* pDataObject, DROPEFFECT dropEffect, CPoint point);

       virtual void OnDragLeave(CWnd* pWnd);

它们的动作都差不多：先用RTTI判断窗口指针pWnd的类型，如果是CListCtrlEx，则调用CListCtrlEx中对应的处理函数，否则调用基类的处理函数。以OnDrop为例：

BOOL COleDropTargetEx::OnDrop(CWnd* pWnd, COleDataObject* pDataObject, DROPEFFECT dropEffect, CPoint point)

{

       CListCtrlEx*     pListCtrlEx = NULL;

       ASSERT_VALID(this);

       ASSERT(IsWindow(pWnd->m_hWnd));

       if(pWnd->IsKindOf(RUNTIME_CLASS(CListCtrlEx)))

       {

              pListCtrlEx = (CListCtrlEx*)pWnd;

              return pListCtrlEx->OnDrop(pWnd, pDataObject, dropEffect, point);

       }

       else

       {

              return COleDropTarget::OnDrop(pWnd, pDataObject, dropEffect, point);    

       }

}

//倒霉的64K限制，只能再截断了：（

至此，我们成功地为CListCtrlEx添加了文件拖入操作的支持。一个完整的拖放操作，还包括拖出动作，所以必须要为该类再添加拖出操作，即，将列表中的某一项或者多项拖出成为一个文件。这就需要用到另一个类：COleDataSource。具体步骤如下：

在CListCtrlEx中加入一个COleDataSource的实例，并映射列表框的LVN_BEGINDRAG消息处理函数，在此我们添加拖出操作的代码。

实现拖出非常简单，只需要依次调用COleDataSource的三个函数即可：Empty用于清空原先对象中缓存的数据，CacheGlobalData用来缓存数据以进行拖放操作，最后调用DoDragDrop启动本次拖放操作。

但在调用之前，必须要做一些准备工作。主要的任务就是创建一个DROPFILES结构体，并拷贝要拖放的文件名到结构体后的内存中。DROPFILES结构体定义了CF_HDROP剪贴板格式，紧跟它后面的是一系列被拖放文件的路径名。它的定义如下：

typedef struct _DROPFILES

{

    DWORD     pFiles;  //文件名起始地址

    POINT      pt;     //鼠标放下的位置，坐标由fNC成员指定

    BOOL        fNC;    //为TRUE表示适用屏幕坐标系，否则使用客户坐标系

    BOOL        fWide;  //文件名字符串是否使用宽字符

} DROPFILES, FAR* LPDROPFILES;

拖放之前的准备动作的代码如下：

uBufferSize = sizeof(DROPFILES) + uBufferSize + 1;

    hMemData = GlobalAlloc(GPTR,uBufferSize);

    ASSERT(hMemData != NULL);

       lpDropFiles = (LPDROPFILES)GlobalLock(hMemData); //锁定之,并设置相关成员

       ASSERT(lpDropFiles != NULL);

       lpDropFiles->pFiles = sizeof(DROPFILES);

#ifdef _UNICODE

       lpDropFiles->fWide = TRUE;

#else

       lpDropFiles->fWide = FALSE;

#endif

       //把选中的所有文件名依次复制到DROPFILES结构体后面(全局内存中)

       pItemPos = strSelectedList.GetHeadPosition();

       pszStart = (char*)((LPBYTE)lpDropFiles + sizeof(DROPFILES));

       while(pItemPos != NULL)

       {

              lstrcpy(pszStart, (LPCTSTR)strSelectedList.GetNext(pItemPos));

        pszStart = strchr(pszStart,'\0') + 1; //下次的起始位置是上一次结尾+1

       }

准备完毕之后就可以进行拖放了，拖放动作有DoDragDrop函数触发，其原型如下：

DROPEFFECT DoDragDrop(

DWORD dwEffects = DROPEFFECT_COPY|DROPEFFECT_MOVE|DROPEFFECT_LINK, LPCRECT lpRectStartDrag = NULL,

COleDropSource* pDropSource = NULL

);

这里，dwEffects指定了允许施加于本COleDataSource实例之上的动作集：剪切、复制或无动作。

    lpRectStartDrag指示拖放操作真正开始的矩形，如果鼠标没有移出该矩形，则拖放操作视作放弃处理。如果本成员设为NULL，则该起始矩形将为一个像素大小。

    pDropSource表明拖放所使用的COleDataSource对象。

而该函数的返回值，则表明本次拖放操作所实际产生的效果，至于具体产生何种效果，则由系统决定。譬如在拖放时按住Shift键，将产生剪切效果；按住Ctrl键，将产生复制效果，等等。

拖放的代码如下：

       m_oleDataSource.Empty();

       m_oleDataSource.CacheGlobalData(CF_HDROP, hMemData);

       DropResult = m_oleDataSource.DoDragDrop(DROPEFFECT_MOVE|DROPEFFECT_COPY);

最后一点要注意的是，在Windows NT 4.0以上的系统中，即使实际产生的是DROPEFFECT_MOVE动作，DoDragDrop函数也只返回DROPEFFECT_NONE。产生这个问题的原因在于，Windows NT 4.0的Shell会直接移动文件本身来对移动操作进行优化。返回值DROPEFFECT_MOVE最初的含义，就是通知执行拖放操作的应用程序去删除原位置上的文件。但是因为Shell已经替应用程序完成了这个（删除）动作，所以，函数返回DROPEFFECT_NONE。要想知道文件是否真的被移动了也很简单，只要在函数返回之后检查一下原位置上的文件是否存在就可以了。

Windows 9x系列的操作系统也会对移动进行同样的优化动作，但是它不会返回DROPEFFECT_NONE来代替DROPEFFECT_MOVE。详细的解释参见MS知识库Q182219。

类成员方法是一个比较特殊的函数，它在编译时会被转化成普通函数，比如有TMyClass类:
class TMyClass{
    void Func();
};

这个TMyClass::Func最终会转化成 void Func(TMyClass *this); 也就是说在原第一个参数前插入指向对象本身的this指针。

我们可以利用这个特性写一个非静态类成员方法来直接作为线程回调函数，先看_beginthread函数的定义:
unsigned long _RTLENTRY _EXPFUNC _beginthread (void (_USERENTRY *__start)(void *),unsigned __stksize, void *__arg);
其中的第一个参数就是作为线程执行主体的回调函数。它的原型是:void Func(void *)，这个void*参数是作为自定义数据传入的。对比一下上面所说的TMyClass::Func的最终形式，它正好可以符合这里的要求。

现在做个实验:
#include <stdio.h>
#include <process.h>

class TMyClass{
    int m_nCount;
    int m_nId;
public:
    TMyClass(int nId,int nCount)
        :m_nId(nId),m_nCount(nCount)
    {
    }

    void _USERENTRY ThreadProc()            // 类成员方法
    {
        for(int i=0; i<m_nCount; i++)       // 根据m_nCount成员打印一排数字
        {
            printf("Class%d : %d\n",m_nId,i);
        }
    }
};

int main(int argc, char* argv[])
{
    union {                                // 联合类，用于转换类成员方法指针到普通函数指针（试过编译器不允许在这两种函数之间强制转换），不知道有没有更好的方法。
        void (_USERENTRY *ThreadProc)(void *);
        void (_USERENTRY TMyClass::*MemberProc)();
    } Proc;                                // 尽管联合里的两种函数类型现在看起来有很大不同，但它们的最终形式是相同的。

    TMyClass MyClass1(1,10),MyClass2(2,5); // 产生两个TMyClass对象

    Proc.MemberProc = &TMyClass::ThreadProc;   // 转换，Proc.ThreadProc就是对应的普通函数指针了

    _beginthread(Proc.ThreadProc,4096,&MyClass1);   // 开始线程，这里的Proc.ThreadProc实际上是TMyClass::ThreadProc, 它要的this指针是我们给的&MyClass1。
    _beginthread(Proc.ThreadProc,4096,&MyClass2);
    system("pause");
    return 0;
}

运行！神奇吧？:-)

其实不止线程回调函数，其实只要是形如Func(void*,...)的回调函数都可以用这种方法直接使用类成员方法。(前提是第一个void*是自定义数据，也就是说它不能有其它功能)。

转自:http://blog.csdn.net/waiting4you/archive/2007/12/29/2000796.aspx

GetDc函数：用于获得hWnd参数所指定窗口的客户区域的一个设备环境。

所获得的设备环境可以是通用、类或者私有类型，具体由指定窗口的类风格决定。对于通用设备环境，GetDc函数每次获取一个设备环境时都会用默认属性对它进行初始化。该函数获得的类和私有设备环境会与它们最后一次的设置保持一致。当设备环境不再需要时，应该调用ReleaseDC函数将其释放。   
    
GetWindowDC函数：返回hWnd参数所指定的窗口的设备环境。

获得的设备环境覆盖了整个窗口（包括非客户区），例如标题栏、菜单、滚动条，以及边框。这使得程序能够在非客户区域实现自定义图形，例如自定义标题或者边框。当不再需要该设备环境时，需要调用ReleaseDC函数释放设备环境。注意，该函数只获得通用设备环境，该设备环境的任何属性改变都不会反映到窗口的私有或者类设备环境中（如果窗口有的话）   
    
   ----------摘自《Delphi    Win32核心API参考》

=============================================================