欧美日韩一区在线观看视频,国产精品ⅴa在线观看h,国产精品久久久亚洲一区

SEH异常处理学习�ȝ��

Thu, 21 Mar 2013 07:43:00 GMT

前一�D�|��_��在看异常处理一章内容的时候，发现�q�一部分�q�真的挺有尿��_��Q�所以上�|�搜了一下有兛_��容，呦嗬�Q�还��Z��富的。当然有些自��p��是看不懂�Q�现在就��这些宝贝拿出来跟大家共享一下�?br />首先我们看一下��用异常处理的几种情况�Q?br />A�Q?用来处理非致命的错误
B�Q?对API函数的参数合法性的��验（假设参数都是合法的，只有遇到异常的时候进行合法性检验）
C�Q?处理致命错误�Q�退出时最好的选择�Q�但是有的时候可以用异常处理函数在程序退出前释放资源�Q�删除��时文件等�Q�甚臛_��以详�l�记录��生异常的指��o位置和环境）
D�Q?处理“计划�?#8221;的异常（我们可能更关心这�U�情况，因�ؓ可以做很多的手脚�Q�哈哈）
接着我们看看Windows下异常处理的两种方式�Q?使用�{�选器2 SEH异常处理
一�?使用�{�选器
因�ؓ�q�里我要重点��x��的是SEH的处理方式，所以还是简单的提一下筛选器处理方式。筛选器异常处理是通过异常回调函数来指定程序处理异常。这�U�方式的回调函数必须是唯一的，讄��新的回调函数后以前的��失效。适用于进�E�范围。看一下这个函数的定义
Invoke SetUnhandledExecpionFilter,offset_Handler
Mov lpPrevHandler,eax
(先到�q�里吧有些难受，明天接着�?
######题外话：惌��v“��o”的一句话�Q�觉得挺有道理：明天不一定美好，但是更美好的明天一定会到来�Q�祝��所有的朋友�?#####

上午有会�Q�什么也没有做，下午�Q�还有会�Q�我tm晕了�Q�中午不睡觉了，不把事情做不完心里不�t�实�?br />回调函数的格式：
_Handlerproc pExecptionInfo
看看pExecptionInfo�q�个指针参数指向的一个数据结�?br />EXCEPTION_POINTERS STRUCT
              pExceptionRecord  DWORD      ?
              ContextRecord    DWORD      ?
            EXCEPTION_POINTERS ENDS
下面介绍 EXCEPTION_RECORD和CONTEXT�l�构的定�?

;//===================== 以下是两个成员的详细�l�构=========================

        EXCEPTION_RECORD STRUCT
          ExceptionCode        DWORD      ?      ;//异常�?nbsp;
          ExceptionFlags        DWORD      ?      ;//异常标志
          pExceptionRecord      DWORD      ?      ;//指向另外一个EXCEPTION_RECORD的指�?nbsp;
          ExceptionAddress      DWORD      ?      ;//异常发生的地址
          NumberParameters      DWORD      ?      ;//下面ExceptionInformation所含有的dword数目
          ExceptionInformation  DWORD EXCEPTION_MAXIMUM_PARAMETERS dup(?)
   EXCEPTION_RECORDENDS            ;//EXCEPTION_MAXIMUM_PARAMETERS ==15

;//=============================具体解释================================

ExceptionCode 异常�c�d��,SDK里面有很多类�?你可以在windows.inc里查找STATUS_来找到更多的异常�c�d��,下面只给出hex�?具体标识定义��h��阅windows.inc,你最可能遇到的几�U�类型如�?

              C0000005h----��d��内存冲突
              C0000094h----非法�?
              C00000FDh----堆栈溢出或者说��界
              80000001h----由Virtual Alloc建立��h��的属性页冲突
              C0000025h----不可持箋异常,�E�序无法恢复执行,异常处理例程不应处理�q�个�?nbsp;    �?nbsp;
              C0000026h----在异常处理过�E�中�pȝ��使用的代�?如果�pȝ��从某个例�E�莫名奇妙的�q�回,则出现此代码, 如果RtlUnwind时没有Exception Record参数也同样会填入�q�个代码
              80000003h----调试时因代码中int3中断
              80000004h----处于被单步调试状�?nbsp;

              �?也可以自己定义异�总��?遵��@如下规则:
              ____________________________________________________________________

              �?      31~30            29~28          27~16          15~0
              ____________________________________________________________________
              含义:    严重�E�度          29�?nbsp;           功能代码        异常代码
                        0==成功        0==Mcrosoft    MICROSOFT定义  用户定义
                        1==通知        1==客户
                        2==警告          28�?nbsp;
                        3==错误        被保留必��Mؓ0
ExceptionFlags 异常标志
              0----可修复异�?nbsp;
              1----不可修复异常
              2----正在展开,不要试图修复什�?需要的�?释放必要的资�?nbsp;
pExceptionRecord 如果�E�序本��n��D��异常,指向那个异常�l�构
ExceptionAddress 发生异常的eip地址
ExceptionInformation 附加消息,在调用RaiseException可指定或者在异常号�ؓC0000005h卛_��存异常时含义如下
              �W�一个dword 0==��d��H?nbsp;1==写冲�H?nbsp;
              �W�二个dword ��d��冲突地址
;//================================解释�l�束============================
                                                          off.
        CONTEXT STRUCT                   ; _
          ContextFlags  DWORD      ?     ;  |            +0
          iDr0          DWORD      ?       ;  |            +4
          iDr1          DWORD      ?      ;  |            +8
          iDr2          DWORD      ?      ;  >调试寄存�?nbsp; +C
          iDr3          DWORD      ?      ;  |            +10
          iDr6          DWORD      ?      ;  |            +14
          iDr7          DWORD      ?      ; _|            +18
          FloatSave    FLOATING_SAVE_AREA <>  ;��点寄存器区 +1C~~~88h
          regGs        DWORD      ?      ;--|            +8C
          regFs        DWORD      ?      ;  |/�D�寄存器    +90
          regEs        DWORD      ?      ;  |/            +94
          regDs        DWORD      ?      ;--|            +98
          regEdi        DWORD      ?      ;____________    +9C
          regEsi        DWORD      ?      ;      |  通用  +A0
          regEbx        DWORD      ?      ;      |  �?nbsp;   +A4
          regEdx        DWORD      ?      ;      |  �?nbsp;   +A8
          regEcx        DWORD      ?      ;      |  �?nbsp;   +AC
          regEax        DWORD      ?      ;_______|___�l�_  +B0
          regEbp        DWORD      ?      ;++++++++++++++++ +B4
          regEip        DWORD      ?      ;    |控制        +B8
          regCs        DWORD      ?      ;    |寄存        +BC
          regFlag      DWORD      ?      ;    |器组        +C0
          regEsp        DWORD      ?      ;    |            +C4
          regSs        DWORD      ?      ;++++++++++++++++ +C8
          ExtendedRegisters db MAXIMUM_SUPPORTED_EXTENSION dup(?)
        CONTEXT ENDS
;//============================以上是两个成员的详细�l�构============
�E�序使用�{�选器异常处理时可以通过查看上面�l�构中的regEip来找��C�生异常的地址�Q�调试的时候可以改变EIP的��g��辑ֈ��过异常�E�序�Q��{�?#8220;安全”的地斏V�?br />最后看一下筛选器异常处理回调函数的返回�?br />EXECPTION_EXECUTE_HANDLER           1�Q�进�E�被�l�止�Q�终止前不会出现提示错误的对话框
EXECPTION_CONTINUE_SEARCH 0�Q�同��L��止程序，昄��错误对话�?br />EXECPTION_CONTINUE_EXECUTION -1�Q�系�l�将CONTECT讄��回去�Q��l�执行程�?br />
使用�{�选器�E�序是最��单的处理异常�Ҏ��Q�不��I��1 不便于封装�? 处理是全局性的也就是无法对每个�U�程或子�E�序讄��一个私有的异常处理�E�序�q�行异常处理�?br />�q�入正题�Q�SEH异常处理
首先解释一下什么是SEH异常处理�Q�SEH("Structured Exception Handling",即结构化异常处理.是操作系�l�提供给�E�序设计者的强有力的处理�E�序错误或异常的武器�?br />下面�l�合冷雨飘心的一个SEH异常处理�E�序来说明具体的用法�Q?br />;//====================================================================
;// ex. 2,by Hume,2001  �U�程相关的异常处�?nbsp;
;//====================================================================
.386
.model flat, stdcall
option casemap :none  ; case sensitive
include hd.h          ;//相关的头文�g�Q�你自己�l�护一个吧
;//============================
.data
szCap    db "By Hume[AfO],2001...",0
szMsgOK db "It's now in the Per_Thread handler!",0
szMsgERR1 db "It would never Get here!",0
buff    db 200 dup(0)

.code
_start:
;//========prog begin====================
  ASSUME FS:NOTHING
        push    offset perThread_Handler
       push    fs:[0]
        mov    fs:[0],esp          ;//建立SEH的基本ERR�l�构,如果不明�?��׃��l�研�I�一下吧
        xor    ecx,ecx
        mov    eax,200
        cdq                �Q?/双字扩展到四个字节，因�ؓ是除�?br />       div    ecx
                                                  ;//以下永远不会被执�?nbsp;
invoke  MessageBox,NULL,addr szMsgERR1,addr szCap,MB_OK+MB_ICONINFORMATION
        pop    fs:[0]
        add    esp,4
        invoke    ExitProcess,NULL

;//============================
perThread_Handler:
invoke    MessageBox,NULL,addr szMsgOK,addr szCap,MB_OK+MB_ICONINFORMATION
        mov    eax,1          ;//ExceptionContinueSearch,不处�?由其他例�E�或�pȝ��处理
        ;mov    eax,0          ;//ExceptionContinueExecution,表示已经修复CONTEXT,可从异常发生处��l�执�?nbsp;
    ret                        ;//�q�里如果�q�回0,你会陷入��d�@�?不断跛_��对话�?...

;//=============================Prog Ends==============
end _start
�E�序本��n很简单，注释也很详细。我们来看看是如何注册回调函数的
push    offset perThread_Handler
       push    fs:[0]
        mov    fs:[0],esp
仅仅三个语句��p��决了~那么��Z��么要用fs�q�个�D�寄存器呢？�q�里又涉及一个重要的内容�Q�TIB�Q�Thread Information Block�U�程信息块）。我们来看看�q�个重要的数据结构（引用了《罗聪浅谈利用SEB实现反跟�t�》的部分内容�Q?br />TEB(Thread Environment Block) �?nbsp;Windows 9x �p?列中被称�?nbsp;TIB(Thread Information Block)�Q�它记录了线�E�的重要信息�Q�而且每一个线�E�都会对应一�?nbsp;TEB �l?构�?nbsp;Matt Pietrek 大牛已经�l�我们列��Z��它的�l�构�Q�我��׃��多说啦，见下�Q�（�?�?nbsp;Matt Pietrek �?nbsp;Under The Hood - MSJ 1996�Q?nbsp;

//===========================================================
// file: TIB.H
// Author: Matt Pietrek
// From: Microsoft Systems Journal "Under the Hood", May 1996
//===========================================================
#pragma pack(1)

typedef struct _EXCEPTION_REGISTRATION_RECORD
{
  struct _EXCEPTION_REGISTRATION_RECORD * pNext;
  FARPROC                                pfnHandler;
} EXCEPTION_REGISTRATION_RECORD, *PEXCEPTION_REGISTRATION_RECORD;

typedef struct _TIB
{
PEXCEPTION_REGISTRATION_RECORD pvExcept; // 00h Head of exception record list
PVOID  pvStackUserTop;        // 04h Top of user stack
PVOID  pvStackUserBase;        // 08h Base of user stack

union                          // 0Ch (NT/Win95 differences)
{
  struct  // Win95 fields
  {
      WORD    pvTDB;          // 0Ch TDB
      WORD    pvThunkSS;      // 0Eh SS selector used for thunking to 16 bits
      DWORD  unknown1;      // 10h
  } WIN95;

  struct  // WinNT fields
  {
      PVOID SubSystemTib;    // 0Ch
      ULONG FiberData;        // 10h
  } WINNT;
} TIB_UNION1;

PVOID  pvArbitrary;            // 14h Available for application use
struct _tib *ptibSelf;          // 18h Linear address of TIB structure

union                          // 1Ch (NT/Win95 differences)
{
  struct  // Win95 fields
  {
      WORD    TIBFlags;          // 1Ch
      WORD    Win16MutexCount;    // 1Eh
      DWORD  DebugContext;      // 20h
      DWORD  pCurrentPriority;  // 24h
      DWORD  pvQueue;            // 28h Message Queue selector
  } WIN95;

  struct  // WinNT fields
  {
      DWORD unknown1;            // 1Ch
      DWORD processID;            // 20h
      DWORD threadID;            // 24h
      DWORD unknown2;            // 28h
  } WINNT;
} TIB_UNION2;

PVOID*  pvTLSArray;            // 2Ch Thread Local Storage array

union                          // 30h (NT/Win95 differences)
{
  struct  // Win95 fields
  {
      PVOID*  pProcess;      // 30h Pointer to owning process database
  } WIN95;
} TIB_UNION3;

} TIB, *PTIB;
#pragma pack()
让我们抬头看看上面的 Matt Pietrek 的代码，其中有这么一行：

PEXCEPTION_REGISTRATION_RECORD pvExcept; // 00h Head of exception record list

�?意到 PEXCEPTION_REGISTRATION_RECORD �q�个定义�Q�它表示 pvExcept �q�个变量�?�?nbsp;exception record list 的入口，�q�个入口位于整个�l�构�?nbsp;0 偏移处。同�Ӟ�� ?nbsp;M �?nbsp;Intel i386 Windows NT/2K/XP 内核中，每当创徏一个线�E�，OS 均会为每个线�E�分�?nbsp;TEB �Q��?�?nbsp;TEB 永远攑֜� fs �D�选择器指定的数据�D늚� 0 偏移处�?nbsp;
�q�样一来，你就明白�?nbsp;SEH 注册的偏�U�Mؓ什么是�?nbsp;fs:[0] 了吧�Q?nbsp;
事实�?nbsp;Windows �pȝ��都是通过�q�种�Ҏ��来�ؓ应用�E�序提供信息的，比如有这��L��例子�Q?nbsp;
struct _tib *ptibSelf;          // 18h Linear address of TIB structure
DWORD threadID;                // 24h

Windows 提供了一�?nbsp;API �Q�GetCurrentThreadID()�Q�它的内部工作原理其实是�q�样的：�Q�利用了上面的这两个地址�Q?nbsp;

mov eax, fs:[18h]    ;因�ؓ 18h 偏移处是 TIB �l�构的线性偏�U�d��址
mov eax, [eax + 24h] ;因�ؓ 24h 偏移处是 threadID 的地址
ret                  ;�?nbsp;eax 中储存的 threadID 地址�q�回
注：��Z��么要声明assume fs:nothing?因�ؓmasm�~�译器默认将fs�D�寄存器定义为error�Q�所以程序在使用fs前必��d��它启动！
接下来看看SEH的回调函�?br />_Handler proc _lpExecptionRecord, _lpSEH,lp_context,lp_DispatcherContext

_lpExecptionRecord指向一个EXECPTION_RECORD�l�构�?br />lp_context 指向一个CONTEXT�l�构�?br />_lpSEH  指向注册回调函数时��用的EXXCEPTION_REGISTRATION�l�构的地址�?br />�q�回值有四种取��|��
ExecptionContinueExecution ( 0 �Q�系�l�将�U�程环境讄��为_lpContext指向的CONTEXT�l�构�q��l�执行�?br />ExceptionContinueSearch�Q?�Q�：回调函数拒绝处理�q�个异常�Q�系�l�通过EXECPTION_REGISTRATION�l�构的prev字段得到前一个回调函数的地址�q�调用它�?br />ExecptionNestedExecption �Q?�Q�：发生异常嵌套�?br />ExecptionCollidedUnwind  �Q?�Q�：异常展开操作。这一个部分不做多�Ԍ��有兴��的可以看看�|�云彬的书，其实是很重要的一部分�?br />如果一个程序既有筛选器异常处理又有SEH异常处理�Q�而且�pȝ��q�有默认的异常处理机�Ӟ��那么他们被调用的先后�ơ序是怎么��L��呢？
发生异常时系�l�的处理��序(by Jeremy Gordon):
    1.�pȝ��首先判断异常是否应发送给目标�E�序的异常处理例�E?如果军_��应该发�?�q�且目标�E�序正在被调�?则系�l�挂��L��序�ƈ向调试器发送EXCEPTION_DEBUG_EVENT消息.呵呵,�q�不是正好可以用来探��调试器的存在吗?
    2.如果你的�E�序没有被调试或者调试器未能处理异常,�pȝ��׃��l�箋查找你是否安装了�U�程相关的异常处理例�E?如果你安装了�U�程相关的异常处理例�E?�pȝ��把异常发送给你的�E�序seh处理例程,交由其处�?
    3.每个�U�程相关的异常处理例�E�可以处理或者不处理�q�个异常,如果他不处理�q�且安装了多个线�E�相关的异常处理例程,可交由链��h��的其他例�E�处�?
    4.如果�q�些例程均选择不处理异�?如果�E�序处于被调试状�?操作�pȝ��仍会再次挂�v�E�序通知debugger.
    5.如果�E�序未处于被调试状态或者debugger没有能够处理,�q�且你调用SetUnhandledExceptionFilter安装了最后异常处理例�E�的�?�pȝ��转向对它的调�?
6.如果你没有安装最后异常处理例�E�或者他没有处理�q�个异常,�pȝ��会调用默认的�pȝ��处理�E�序,通常昄��一个对话框, 你可以选择关闭或者最后将光��加到调试器上的调试按�?如果没有调试器能被附加于其上或者调试器也处理不�?�pȝ��p��用ExitProcess�l�结�E�序.
    7.不过在终�l�之�?�pȝ��仍然对发生异常的�U�程异常处理句柄来一�ơ展开,�q�是�U�程异常处理例程最后清理的��Z��.

说了�q�么多你也许会问SEH异常处理到底有什么用处呢�Q�呵呵，且听��生慢慢道来~~~
�W�一道菜�Q�病毒程序��y用SEH
�q�里��单的说一下如何利用SEH异常处理�E�序来躲避下毒��Y件的反病毒引擎。一个反病毒引擎在一个程序运行的时候会模拟�E�序的代码，当发现程序代码的疑点比较多的时候会报告成病毒。看看下面这�D늨�序：
start:call Set_SEH;�q�句其实��是 push offset CONTINUE
;      JMP Set_SEH
CONTINUE:mov esp, [esp+8]; [ESP+8]存储的是旧的堆栈地址�?br />push offset Start_Virus ;----_ 把Start_Virus 的地址压栈�Q�当作返回地址
ret;----跛_��Start_Virus去，是不是很magic?

Set_SEH:sub edx, edx            ;Edx =0
Assume fs:nothing
push dword ptr fs:[edx];把指�?nbsp;_EXCEPTIONAL_REGISTRATION_RECORD �l�构的指针入�?br />mov fs:[edx], esp;安装一个seh
mov [edx],edx;引�v一个内存读写冲�H�，发生异常因�ؓedx=0
;如果反病毒引擎不处理异常�Q�不�q�入seh 处理�E�序(�?nbsp;CONTINUE: �Q��l�模
;拟下个指令，也就是jmp start�Q�那么就�q�入一个死循环�Q�可能会引�v��L��?nbsp;
jmp start
Start_Virus:    .....
是不是很��单呢�Q�就是让反病毒引擎不处理�q�个��Zؓ的异常时�q�入��d�@环~�Q�！
�W�二道菜�Q�TEB反跟�t�初�?br />如果你的记性够好的话一定记得上面介�l�过的TEB�Q�TIB�Q�线�E�信息块�l�构中有�q�么一句：
PVOID*  pProcess;      // 30h Pointer to owning process database
�q?个偏�U�d��址处的内容非常有用�Q�它指向本线�E�的拥有者的 PDB(Process Database) 的线性地址。当你用动态调试器�Q�例 �?nbsp;OllyDbg 的时候，调试器是把调试的对象作�ؓ一个子�U�程�q�行跟踪的，在这�U�情况下�Q�被调试的对象的“拥有�?#8221;��是调试器本�w�，也就是说�Q�它 �?nbsp;TEB �?nbsp;30h 处的偏移指向的内容肯定不�?nbsp;0 �Q�这��P��我们��可以利用这一点，判断 30h 偏移指向的内容，来判断是否有调试器跟�t��?nbsp;
最后给��Z��?nbsp;Anti-Debug 的例子程序，�?nbsp;MASM �~�译完成后，��L�� OllyDbg 来加载调试一下，看看与正常的�q�行�l�果有什么不同�?nbsp;
;*********************************************************
;�E�序名称�Q�演�C�利�?nbsp;TEB �l�构�q�行 Anti-Debug
;          ��L�� OllyDbg �q�行调试
;适用OS�Q�Windows NT/2K/XP
;作者：�|�聪
;日期�Q?003-2-9
;出处�Q?img alt="::URL::" src="http://www.blogcn.com/images/aurl.gif" align="absBottom" border="0" hspace="2" />http://www.LuoCong.com�Q�老罗的缤�U�天圎ͼ�
;注意事项�Q�如�Ʋ�{载，请保持本�E�序的完��_��q�注明：
;转蝲�?#8220;老罗的缤�U�天�?#8221;�Q?img alt="::URL::" src="http://www.blogcn.com/images/aurl.gif" align="absBottom" border="0" hspace="2" />http://www.LuoCong.com�Q?/a>
;*********************************************************

.386
.model flat, stdcall
option casemap:none

include /masm32/include/windows.inc
include /masm32/include/kernel32.inc
include /masm32/include/user32.inc
includelib /masm32/lib/kernel32.lib
includelib /masm32/lib/user32.lib

.data
szCaption  db  "Anti-Debug Demo by LC, 2003-2-9", 0
szDebugged  db  "Hah, let me guess... U r dEBUGGINg me! ", 0
szFine      db  "Good boy, no dEBUGGEr detected!", 0

.code
main:
  assume  fs:nothing
  mov    eax, fs:[30h]              ;指向 PDB(Process Database)
  movzx  eax, byte ptr [eax + 2h]�Q�无�W�号数带零扩�?br />  or      al, al
  jz      _Fine
_Debugged:
  push    MB_OK or MB_ICONHAND
  push    offset szCaption
  push    offset szDebugged
  jmp    _Output
_Fine:
  push    MB_OK or MB_ICONINformATION
  push    offset szCaption
  push    offset szFine
_Output:
  push    NULL
  call    MessageBoxA
  invoke  ExitProcess, 0
end main
�W�三道菜�Q�利用SEH执行shellcode
假设异常处理例程入口00401053,�E�序刚开始执行时esp�?012ffc4,以前的fs:[0]�?012ffe0
建立了TIB�l�构的第一个成员后堆栈的情况如�?

  内存低地址

| E0 |12ffbc(esp)
| FF |
| 12 |  --ERR�l�构的第一个成�?br />|_00_|
| 53 |12ffc0
| 10 |
| 40 |  --ERR�l�构的第二个成员
| 00 |

  内存高地址

  好了然后�E�序CALL一个函�?函数里面有一个局部变量�ƈ且在往其分配的�I�间中写入的数据时��生溢�?�q�时堆栈如下

____
|    |12f000 局部变量分配的�I�间,�q�且�?2ffc0方向溢出�?
|    |
....
....
|_EBP|12ffb4 函数中保存老的EBP
| xx |
| xx |
| xx |
|_EIP|12ffb8 call函数时EIP�q�栈
| xx |
| xx |
|_xx_|
| E0 |12ffbc(esp)   {当SEH起作用的时候EBX刚好指向�q�个地址(也可说��L��指向当前ERR�l�构)}
| FF |
| 12 |  --ERR�l�构的第一个成�?br />|_00_|
| 53 |12ffc0
| 10 |
| 40 |  --ERR�l�构的第二个成员
|_00_|
|    |12ffc4
   �l?�l�看,假设溢出代码一直到�?2ffc4,然后call的函数该�q�回�?因�ؓ保存的EIP被溢��Z��码代替所以程序出�?不会不出错吧?),�q�样ESH开�?起作用了(�?在这期间�pȝ��要执行一些操�?所以EBX才会指向当前ERR).�q�样一来程序就会蟩�?2ffc0里的地址��L��?�?2ffc0里的东东早已不是原来�?0401053�?�q�样我们不就改变了程序的��向了么.12ffc0中该写入什么内容呢?应是内存中JMP EBX的代码的地址.�q�样�?�?下后最�l�就会蟩�?2ffbc��L��?�q�个四字节可是宝�늚��?img src="http://www.blogcn.com/images/smile.gif" alt="" border="0" hspace="2" vspace="2" />现在假设JMP EBX�q�个指��o在内存中的地址�?x77e33f4d
那下具体看一下现在堆栈的情况:

| EB |12ffbc(esp)   {当ESH起作用的时候EBX刚好指向�q�个地址(也可说��L��指向当前ERR�l�构)}
| 06 |
| 90 |  --ERR�l�构的第一个成�?执行JMP EBX后就到这儿来执行�?EB 06是短跌��{JMP 12FFC4的机器码)
|_90_|  后面�?0是nop�I�指令的机器�?
| 4D |12ffc0
| 3F |
| E3 |  --ERR�l�构的第二个成员,出错处理函数的入口地址(现在成了JMP EBX的地址)
|_77_|
|    |12ffc4
....

  好现在来看看12ffc4里面有些什么代�?(��单的说这�D�代码的作用是计��真正的shellcode的�v始地址,然后跌��L��?

低地址

|    |12f000(shellcode开始地址)
....
....
| 81 |12ffc4
| C3 |  add ebx,FFFFF03Ch(ebx=12ffc4,指��o长度6,作用计算计算shellcode地址)
| 3C |
| F0 |
| FF |
| FF |
| FF |12ffca jmp ebx
| D3 |

高地址

��试�E�序

-------------------------SEH.ASM------------------
.386
.model flat,stdcall
option casemap:none

include        ../include/user32.inc
includelib    ../lib/user32.lib
include        ../include/kernel32.inc
includelib    ../lib/kernel32.lib

.data
hello        db '利用一个读INI文�g的API来演�C�WIN2000本地溢出',0
lpFileName    db './seh.ini',0
lpAppName    db 'iam',0
lpKeyName    db 'czy',0
lpDefault    db 'ddd',0
szCap     db "SEH TEST",0
szMsgOK db "OK,the exceptoin was handled by final handler!",0
szMsgERR1 db "It would never Get here!",0

.code

testov    proc
    local   lpReturnedString[2224] : byte    ;�q�回的字串搞成本地变量这样就和C语言一样了,它是在栈�?nbsp;
    invoke    GetPrivateProfileString,offset    lpAppName,offset�Q�lpKeyName,offset lpDefault,ADDR lpReturnedString,2249,offset lpFileName
    invoke    MessageBox,0,addr lpReturnedString,addr lpReturnedString,1
    ret
testov    endp

start:
    ASSUME fs:NOTHING
    invoke  MessageBox,0,addr szMsgERR1,addr szCap,30h+1000h ;下断�?nbsp;
    push    offset Final_Handler    ;压入正常的出错处理程序入口地址
    push    FS:[0]                  ;把前一个TIB的地址压入
    mov    fs:[0],esp
    call    testov
    pop     fs:[0]                     ;�q�原FS:[0]

Final_Handler:   ;�׃��溢出了下面的代码不会被执�?
       invoke       MessageBox,0,addr szMsgOK,addr szCap,30h
       invoke       ExitProcess,0
       mov       eax,1
       ret
end start
�P?br />-----------------end-------------

1如何更好的在内存中找JMP EBX的代�?
     在softice中执行S 10:0 L FFFFFFFF FF D3��可以了,但实际上�q�样扑ֈ��?br />地址可能不能执行代码.所以用下面的方�?
   map32 kernel32(在当前进�E�中查找映射的kernel32 DLL的信�?
一般有如下昄��:
  Owner        Obj Name    Obj#    Address        Size     TYPE
kernel32    .text        0001    001b:77b61000    0005d1ae code RO
......
  然后
S 77b61000 L 5d1ae FF D3
如果昄��如下说明扑ֈ��?
  Pattern Found at 0023:77e61674 ....

2)关于�~�冲区的大小的问�?
  利用SEH的办法就��L��要设�?000个字节多,你的shellcode才不会被不知哪来的数据覆�?
�q�道菜czy做的不好吃：�Q�我感觉理解��h��有些困难~�Q�因为关于缓冲区溢出自己接触的太��，不过好东西要保留的，以后回过头看�Q?br />�W�四道菜�Q�用 SEH 技术实�?nbsp;API Hook
�q�一部分不想展开了，�l�大家一个链接吧�?br />
http://www.luocong.com/articles/show_article.asp?Article_ID=25

最后作为结束语说说的缺点吧�Q�）一个�h只有正视自己的缺�Ҏ��能不断地�q�步�Q�呵�?br />�?SEH异常处理链中最后一个被装蝲的SEH异常处理�E�序��L��被第一个调用，��x��如果自己�׃��一个星期才写出来一个异常处理程序，能够完美处理所有异�?�q?希望异常全部�׃��来处�?但很不幸,比如你调用了一个外部模�?而这个模块自己安装了一个ugly的seh处理例程,他的动作是只要有异常发生��q��单地�l?止程序，哈哈�Q�那��死悄悄了。又比如你想在你的加壳程序里面加密目标程序代码段,然后发生无效指��o异常的时候用你自己安装的处理句柄来解密代码段�l�箋�?�?听�v来这的确是一个好��L��,但遗憄��是大多数C/C++代码都用_try{}_except{}块来保证其正��运�?而这些异常处理例�E�是在你��x��?的例�E�之后安装的,因而也��在铄��前面,无效指��o一执行,首先是C/C++�~�译器本�w�提供的处理例程或者程序其他的异常处理例程来处�?可能��单结束程�?或�?...
好篏�Q�~~~~~~
写了两天�Q�错了，应该是剪�?消化了两天，有很多的�E�序和文字是从hume,老罗�Q�还有czy那里“剽窃”的：�Q�希望高手们不要生气~~天下书籍一大抄。你们的必将是我的，当然我的也会�׃�n�l�你们的。呵呵，现在�q�不行，�U�别不够啊�?/div>转自:

http://blog.csdn.net/toberooter/article/details/308365

��果�?/a> 2013-03-21 15:43 发表评论

Sat, 19 Mar 2011 08:48:00 GMT

1. 安装VS2010,WDK7.60�Q�GRMWDK_EN_7600_1�Q?/p>

2. 新徏VC 控制台项�?选择为空��目)

3. 新徏��目配置“driver” �Q�点��M��拉按�?点击�Q�配�|�管理器�Q?/p>

输入名称�Q�driver�Q�点�ȝ��定就可以了，其他的不要动哦！

完成后的效果�Q?/p>

点击��定按钮之后呈现出来的画�?/p>

鼠标叛_��新徏的driver属性，会弹��Z��下窗口！

4. 讄��VC++路径

<我把wdk安装在E盘下>
a. 配置可执行文件目�?E:\WinDDK\7600.16385.1\bin\x86;
b. 配置包含目录�Q�E:\WinDDK\7600.16385.1\inc\ddk
                        E:\WinDDK\7600.16385.1\inc\crt
                        E:\WinDDK\7600.16385.1\inc\api
c. 配置库目�?    E:\WinDDK\7600.16385.1\lib\win7\i3865

新徏C/C++文�g 不然无C/C++讄��选项

<刚开始我们创��Z��一个空的项目所以项目里没有c++文�g�Q�现在要做的��是在空的项�?源文�?��d��一个新建项c++文�g>

常规
目标文�g扩展名：.sys //必�?

6. 讄��C/C++选项
常规选项�?/span>
1 调试信息格式(C7 兼容(/Z7)        //可�?
2 警告�{��     �Q? �U?/W2)          //可�?
3 ��警告视为错�?nbsp; (�?/wx)         //可�?

优化选项�?/span>
优化(��用/Od)                          //可�?

预处理器
预处理器定义�Q�WIN32=100;_X86_=1;WINVER=0x501;DBG=1         //必�?

代码生成
       启用最��重新生成：�?nbsp;                                       //可�?nbsp;

       基本�q�行时检查：默认�?nbsp;                                    //可�?
       �q�行时库�Q�多�U�程调试(/MTd) �?nbsp; 多线�E?/MT)                 //��?span color="#0000ff" style="color: #0000ff;"> <本�h选择的是多线�E�调�?/MTd)>
       �~�冲区安全检查：�?nbsp;                                           //可�?
(可避免出�?nbsp; LINK : error LNK2001: 无法解析外部�W�号 __security_cookie)
高��
     调用�U�定 __stdcall(/Gz)                                       //必�?

7. 链接器设�|?
常规
     启用增量链接�Q�否(/INCREMENTAL:NO)                           //�� 选上
     忽略导入库：�?nbsp;                                                 // 可�?nbsp;
     ( 讄��为此值时�Q�必��d��附加库目录中加： E:\WinDDK\7600.16385.1\lib\win7\i3865 �q�样��目��׃��会依�?IDE 环境的设 �|?

如果�?nbsp; ( 讄��为此值时�Q�将依赖 IDE 的环境的相关讄�� )

输入
附加依赖��?
ntoskrnl.lib;Hal.lib;wdm.lib;wdmsec.lib;wmilib.lib;ndis.lib;MSVCRT.LIB;LIBCMT.LIB //必�?nbsp;

//NT式驱�?nbsp; ntoskrnl.lib WDM式驱�?nbsp; wdm.lib
( HalXXX 函数在Hal.lib�Q?WmiXXX 函数�?nbsp; wmilib.lib �Q?NdisXXX函数�?nbsp; ndis.lib )
( 必要旉��要增加微软的标准�?nbsp; MSVCRT.LIB MSVCRTD.LIB(调试�? LIBCMT.LIBIBCMTD.LIB(调试�? )
( 如果源码中有 source 文�g�Q�那么该文�g�?nbsp; TARGETLIBS 字段会列��?目需要的�?nbsp; )

忽略所有默认库�Q?nbsp; �?(/NODEFAULTLIB) //必�?nbsp;

清单文�g�Q?
启用用户账户控制�Q�UAC�Q?nbsp; �?nbsp; //必�?nbsp;

不然会出�?nbsp; >LINK : fatal error LNK1295: “/MANIFESTUAC”�?#8220;/DRIVER”规范不兼容；链接时不使用“/MANIFESTUAC”

     调试�Q?
生成调试信息 �?/DEBUG)                                              //可�?
生成映像文�g�Q�是(/MAP)                                               //可�?
映像文�g名：$(TargetDir)$(TargetName).map                     //可�?

    �pȝ��(System)
     子系�l? 控制�?/SUBSYSTEM:CONSOLE)                                //必�?
     堆栈保留大小�Q?194304                                              //可�?
     堆栈提交大小�Q?nbsp; 4096                                                //可�?
     驱动�E�序:    驱动�E�序(/DRIVER)                                        //必�?nbsp;
      高��Q?/span>
    入口点：DriverEntry                                                    //必�?
    随机基址:清空           //把框里的数据删掉。（yes也不是no也不是就是要一个干�q�净净的文本框�Q?/span>   //必�?
    不然会出�?nbsp; e:\xxx.sys : fatal error LNK1295:
“/DYNAMICBASE”�?#8220;/DRIVER”规范不兼容；链接时不使用“/DYNAMICBASE”

    数据执行保护(DEP): 清空 //把框里的数据删掉。（yes也不是no也不是就是要一个干�q�净净的文本框�Q?/span> //必�?nbsp;
     不然会出�?nbsp; e:\xxx.sys : fatal error LNK1295:
“/NXCOMPAT:NO”�?#8220;/DRIVER”规范不兼容；链接时不使用“/NXCOMPAT:NO”

讄��效应和：�?/RELEASE) //可�?

基址�Q?x10000                                           //��选上

命��o行：/SECTION:INIT,D /IGNORE:4078        �Q�徏议不要写�q�去�Q�会报错�Q�）

最后给��Z��个超�U�简单的代码来测试一下我们配�|�的是否成功�Q�？

#include "ntddk.h"

NTSTATUS
DriverEntry(PDRIVER_OBJECT DriverObject,PUNICODE_STRING RegistryPath)
{
return STATUS_UNSUCCESSFUL;
}

如果没有报错那么恭喜你配�|�成功了�Q?

��果�?/a> 2011-03-19 16:48 发表评论

PE学习�ȝ��

Tue, 12 Oct 2010 09:22:00 GMT

摘要: Code highlighting produced by Actipro CodeHighlighter (freeware)http://www.CodeHighlighter.com/-->#include "windows.h"#include using namespace std;#define NTSI... 阅读全文

��果�?/a> 2010-10-12 17:22 发表评论

PE文�g格式(�?(�?

Tue, 12 Oct 2010 08:38:00 GMT

摘要

　　 Windows NT 3.1引入了一�U�名为PE文�g格式的新可执行文件格式。PE文�g格式的规范包含在了MSDN的CD中（Specs and Strategy, Specifications, Windows NT File Format Specifications�Q�，但是它非�怹�晦�ӆ�?
　　然而这一的文��ƈ未提供��够的信息�Q�所以开发者们无法很好地弄懂PE格式。本文旨在解册��一问题�Q�它会对整个的PE文�g格式作一个十分彻底的解释�Q�另外，本文中还带有�Ҏ��有必需�l�构的描�q�C��及示范如何��用这些信息的源码�C�Z��?
��Z��获得PE文�g中所包含的重要信息，我编写了一个名为PEFILE.DLL的动态链接库�Q�本文中所有出现的源码�C�Z��亦均摘自于此。这个DLL和它的源�? 码都作�ؓPEFile�C�Z��E�序的一部分包含在了CD中（译注�Q�示例程序请在MSDN中寻找，本站恕不提供�Q�，你可以在你自��q��应用�E�序中��用这个DLL�Q? 同样�Q�你亦可以依你所愿地使用�q�构建它的源码。在本文末尾�Q�你会找到PEFILE.DLL的函数导出列表和一个如何��用它们的说明。我觉得你会发现�q�些�? ��C��让你从容应付PE文�g格式的�?

介绍

Windows操作�pȝ��家族最�q�增加的Windows NT为开发环境和应用�E�序本��n带来了很大的改变�Q�这之中一个最为重大的当属PE文�g格式了。新的PE文�g格式主要来自于UNIX操作�pȝ��所通用的COFF 规范�Q�同时�ؓ了保证与旧版本MS-DOS及Windows操作�pȝ��的兼容，PE文�g格式也保留了MS-DOS中那熟悉的MZ头部�?
　　在本文之中，PE文�g格式是以自顶而下的顺序解释的。在你从头开始研�I�文件内容的�q�程之中�Q�本文会详细讨论PE文�g的每一个组成部分�?
许多单独的文件成分定义都来自于Microsoft Win32 SDK开发包中的WINNT.H文�g�Q�在�q�个文�g中你会发现用来描�q�文件头部和数据目录�{�各�U�成分的�l�构�c�d��定义。但是，在WINNT.H中缺��对PE�? 件结构��够的定义�Q�在�q�种情况下，我定义了自己的结构来存取文�g数据。你会在PEFILE.DLL工程的PEFILE.H中找到这些结构的定义�Q�整套的 PEFILE.H开发文件包含在PEFile�C�Z��E�序之中�?
本文配套的示例程序除了PEFILE.DLL�C�Z��代码之外�Q�还有一个单独的Win32�C�Z��应用�E�序�Q�名为EXEVIEW.EXE。创��一�C�Z��目的有二�Q? 首先�Q�我需要测试PEFILE.DLL的函敎ͼ��q�且某些情况要求我同时查看多个文�Ӟ��其次�Q�很多解决PE文�g格式的工作和直接观看数据有关。例如，要弄�? 导入地址名称表是如何构成的，我就得同时查�?idata�D�头部、导入映像数据目录、可选头部以及当前的.idata�D�实体，而EXEVIEW.EXE��? 是查看这些信息的最佳示例�?
　　闲话��叙�Q�让我们开始吧�?

PE文�g�l�构

PE文�g格式被组�l��ؓ一个线性的数据��，它由一个MS-DOS头部开始，接着是一个是模式的程序残余以及一个PE文�g标志�Q�这之后紧接着PE文�g头和可�? 头部。这些之后是所有的�D�头部，�D�头部之后跟随着所有的�D�实体。文件的�l�束处是一些其它的区域�Q�其中是一些�؜杂的信息�Q�包括重分配信息、符可��信息、行�? 信息以及字串表数据。我��所有这些成分列于图1�?br>
�?.PE文�g映像�l�构
从MS-DOS文�g头结构开始，我将按照PE文�g格式各成分的出现��序依次对其�q�行讨论�Q��ƈ且讨论的大部分是以示例代码�ؓ基础来示范如何获得文件的信息的。所有的源码均摘自PEFILE.DLL模块的PEFILE.C文�g。这些示例都利用了Windows NT最��L��特色之一——内存映��文�Ӟ��q�一特色允许用户使用一个简单的指针来存取文件中所包含的数据，因此所有的�C�Z��都��用了内存映射文�g来存取PE文�g 中的数据�?
　　注意�Q�请查阅本文末尾关于如何使用PEFILE.DLL的那一�D�c�?

MS-DOS头部/实模式头�?/strong>

如上所�q�ͼ�PE文�g格式的第一个组成部分是MS-DOS头部。在PE文�g格式中，它�ƈ非一个新概念�Q�因为它与MS-DOS 2.0以来��已有的MS-DOS头部是完全一��L��。保留这个相同结构的最主要原因是，当你��试在Windows 3.1以下或MS-DOS 2.0以上的系�l�下装蝲一个文件的时候，操作�pȝ��能够��d��q�个文�g�q�明白它是和当前�pȝ��不相兼容的。换句话��_��当你在MS-DOS 6.0下运行一个Windows NT可执行文件时�Q�你会得到这样一条消息：“This program cannot be run in DOS mode.”如果MS-DOS头部不是作�ؓPE文�g格式的第一部分的话�Q�操作系�l�装载文件的时候就会失败，�q�提供一些完全没用的信息�Q�例如：“The name specified is not recognized as an internal or external command, operable program or batch file.”
　　 MS-DOS头部占据了PE文�g的头64个字节，描述它内容的�l�构如下�Q?
//WINNT.H typedef struct _IMAGE_DOS_HEADER { // DOS�?EXE头部 USHORT e_magic; // ��术数字 USHORT e_cblp; // 文�g最后页的字节数 USHORT e_cp; // 文�g��|�� USHORT e_crlc; // 重定义元素个�? USHORT e_cparhdr; // 头部��寸�Q�以�D�落为单�? USHORT e_minalloc; // 所需的最��附加段 USHORT e_maxalloc; // 所需的最大附加段 USHORT e_ss; // 初始的SS��|��相对偏移量） USHORT e_sp; // 初始的SP�? USHORT e_csum; // 校验�? USHORT e_ip; // 初始的IP�? USHORT e_cs; // 初始的CS��|��相对偏移量） USHORT e_lfarlc; // 重分配表文�g地址 USHORT e_ovno; // 覆盖�? USHORT e_res[4]; // 保留�? USHORT e_oemid; // OEM标识�W�（相对e_oeminfo�Q? USHORT e_oeminfo; // OEM信息 USHORT e_res2[10]; // 保留�? LONG e_lfanew; // 新exe头部的文件地址 } IMAGE_DOS_HEADER, *PIMAGE_DOS_HEADER;
�W�一个域e_magic�Q�被�U�Cؓ��术数字�Q�它被用于表�C�Z�� 个MS-DOS兼容的文件类型。所有MS-DOS兼容的可执行文�g都将�q�个��D��?x5A4D�Q�表�C�ASCII字符MZ。MS-DOS头部之所以有的时�? 被称为MZ头部�Q�就是这个缘故。还有许多其它的域对于MS-DOS操作�pȝ��来说都有用，但是对于Windows NT来说�Q�这个结构中只有一个有用的域——最后一个域e_lfnew�Q�一�?字节的文件偏�U�量�Q�PE文�g头部��是由它定位的。对于Windows NT的PE文�g来说�Q�PE文�g头部是紧跟在MS-DOS头部和实模式�E�序�D�余之后的�?

实模式残余程�?/strong>

实模式残余程序是一个在装蝲时能够被MS-DOS�q�行的实际程序。对于一个MS-DOS的可执行映像文�g�Q�应用程序就是从�q�里执行的。对�? Windows、OS/2、Windows NT�q�些操作�pȝ��来说�Q�MS-DOS�D�余�E�序��׃��替了�ȝ��序的位置被放在这里。这�U�残余程序通常什么也不做�Q�而只是输��Z��行文本，例如�Q?#8220;This program requires Microsoft Windows v3.1 or greater.”当然�Q�用户可以在此放入�Q何的�D�余�E�序�Q�这��意味着你可能经常看到像�q�样的东西：“You can''t run a Windows NT application on OS/2, it''s simply not possible.”
　　当�ؓWindows 3.1构徏一个应用程序的时候，链接器将向你的可执行文�g中链接一个名为WINSTUB.EXE的默认残余程序。你可以用一个基于MS-DOS的有效程�? 取代WINSTUB�Q��ƈ且用STUB模块定义语句指示链接器，�q�样��p��够取代链接器的默认行为。�ؓWindows NT开发的应用�E�序可以通过使用-STUB:链接器选项来实现�?

PE文�g头部与标�?/strong>

　　 PE文�g头部是由MS-DOS头部的e_lfanew域定位的�Q�这个域只是�l�出了文件的偏移量，所以要��定PE头部的实际内存映��地址�Q�就需要添加文件的内存映射基地址。例如，以下的宏是包含在PEFILE.H源文件之中的�Q?

//PEFILE.H #define NTSIGNATURE(a) ((LPVOID)((BYTE *)a + \ ((PIMAGE_DOS_HEADER)a)->e_lfanew))
在处理PE文�g信息的时候，我发现文件之中有些位�|�需要经常查阅。既然这些位�|�仅仅是�Ҏ��件的偏移量，那么用宏来实现这些定位就比较�Ҏ��Q�因为它们较之函数有更好的表现�?
��h��意这个宏所获得的是PE文�g标志�Q�而�ƈ非PE文�g头部的偏�U�量。那是由于自Windows与OS/2的可执行文�g开始，.EXE文�g都被赋予了目标操作系�l�的标志。对于Windows NT的PE文�g格式而言�Q�这一标志在PE文�g头部�l�构之前。在Windows和OS/2的某些版本中�Q�这一标志是文件头的第一个字。同��P��对于PE文�g�? 式，Windows NT使用了一个DWORD倹{�?
以上的宏�q�回了文件标志的偏移量，而不��它是哪�U�类型的可执行文件。所以，文�g头部是在DWORD标志之后�Q�还是在WORD标志处，是由�q�个标志是否 Windows NT文�g标志所军_��的。要解决�q�个问题�Q�我�~�写了ImageFileType函数�Q�如下）�Q�它�q�回了映像文件的�c�d��Q?

//PEFILE.C DWORD WINAPI ImageFileType (LPVOID lpFile) { /* 首先出现的是DOS文�g标志 */ if (*(USHORT *)lpFile == IMAGE_DOS_SIGNATURE) { /* 由DOS头部军_��PE文�g头部的位�|?*/ if (LOWORD (*(DWORD *)NTSIGNATURE (lpFile)) == IMAGE_OS2_SIGNATURE || LOWORD (*(DWORD *)NTSIGNATURE (lpFile)) == IMAGE_OS2_SIGNATURE_LE) return (DWORD)LOWORD(*(DWORD *)NTSIGNATURE (lpFile)); else if (*(DWORD *)NTSIGNATURE (lpFile) == IMAGE_NT_SIGNATURE) return IMAGE_NT_SIGNATURE; else return IMAGE_DOS_SIGNATURE; } else /* 不明文�g�U�类 */ return 0; }
以上列出的代码立卛_��诉了你NTSIGNATURE宏有多么有用。对于比较不同文件类型�ƈ且返回一个适当的文件种�c�L��_��q�个宏就会�ɘq�两件事变得非常��单。WINNT.H之中定义的四�U�不同文件类型有�Q?
//WINNT.H #define IMAGE_DOS_SIGNATURE 0x5A4D // MZ #define IMAGE_OS2_SIGNATURE 0x454E // NE #define IMAGE_OS2_SIGNATURE_LE 0x454C // LE #define IMAGE_NT_SIGNATURE 0x00004550 // PE00
首先�Q�Windows的可执行文�g�c�d��没有出现在这一列表中，�q�一点看��h��很奇怪。但是，在稍微研�I�一下之后，��p��得到原因了：除了操作 �pȝ��版本规范的不同之外，Windows的可执行文�g和OS/2的可执行文�g实在没有什么区别。这两个操作�pȝ��拥有相同的可执行文�g�l�构�?
　　现在把我们的注意力�{向Windows NT PE文�g格式�Q�我们会发现只要我们得到了文件标志的位置�Q�PE文�g之后��׃��?个字节相跟随。下一个宏标识了PE文�g的头部：
//PEFILE.C #define PEFHDROFFSET(a) ((LPVOID)((BYTE *)a + \ ((PIMAGE_DOS_HEADER)a)->e_lfanew + \ SIZE_OF_NT_SIGNATURE))
�q�个宏与上一个宏的唯一不同是这个宏加入了一个常量SIZE_OF_NT_SIGNATURE。不�q�的是，�q�个帔R��q�未定义在WINNT.H之中�Q�于是我��它定义在了PEFILE.H中，它是一个DWORD的大��?
　　既然我们知道了PE文�g头的位置�Q�那么就可以��查头部的数据了。我们只需要把�q�个位置赋值给一个结构，如下�Q?
PIMAGE_FILE_HEADER pfh; pfh = (PIMAGE_FILE_HEADER)PEFHDROFFSET(lpFile);
在这个例子中�Q�lpFile表示一个指向可执行文�g内存映像基地址的指针，�q�就昑և�了内存映��文件的好处�Q�不需要执行文件的I/O�Q�只需使用指针pfh��p��存取文�g中的信息。PE文�g头结构被定义为：
//WINNT.H typedef struct _IMAGE_FILE_HEADER { USHORT Machine; USHORT NumberOfSections; ULONG TimeDateStamp; ULONG PointerToSymbolTable; ULONG NumberOfSymbols; USHORT SizeOfOptionalHeader; USHORT Characteristics; } IMAGE_FILE_HEADER, *PIMAGE_FILE_HEADER; #define IMAGE_SIZEOF_FILE_HEADER 20
��h��意这个文件头部的大小已经定义在这个包含文件之中了�Q�这样一来，惌��得到�q�个�l�构的大��就很方便了。但是我觉得对结构本�w��? sizeof�q�算�W�（译注�Q�原文�ؓ“function”�Q�更��单一些，因�ؓ�q�样的话我就不必��C��q�个帔R��的名�? IMAGE_SIZEOF_FILE_HEADER�Q�而只需要记住结构IMAGE_FILE_HEADER的名字就可以了。另一斚w��Q�记住所有结构的名字已经够有挑战性的了，��其在是�q�些�l�构只有WINNT.H中才有的情况下�?
PE文�g中的信息基本上是一些高�U�信息，�q�些信息是被操作�pȝ��或者应用程序用来决定如何处理这个文件的。第一个域是用来表�C��个可执行文�g被构建的目标�? 器种�c�，例如DEC(R) Alpha、MIPS R4000、Intel(R) x86或一些其它处理器。系�l��用这一信息来在��d��q�个文�g的其它数据之前决定如何处理它�?
Characteristics域表�C�Z��文�g的一些特征。比如对于一个可执行文�g而言�Q�分��调试文件是如何操作的。调试器通常使用的方法是��调试信息从 PE文�g中分��，�q�保存到一个调试文�Ӟ��.DBG�Q�中。要�q�么做的话，调试器需要了解是否要在一个单独的文�g中寻找调试信息，以及�q�个文�g是否已经��调�? 信息分离了。我们可以通过深入可执行文件�ƈ��L��调试信息的方法来完成�q�一工作。要使调试器不在文�g中查扄��话，��需要用�? IMAGE_FILE_DEBUG_STRIPPED�q�个特征�Q�它表示文�g的调试信息是否已�l�被分离了。这样一来，调试器可以通过快速查看PE文�g的头�? 的方法来军_��文�g中是否存在着调试信息�?
　　 WINNT.H定义了若�q�其它表�C�文件头信息的标讎ͼ��和以上的例子差不多。我把研�I�这些标记的事情留给读者作为练习，�׃��们来看看它们是不是很有趣�Q�这些标��C��于WINNT.H中的IMAGE_FILE_HEADER�l�构之后�?
PE文�g头结构中另一个有用的入口是NumberOfSections域，它表�C�如果你要方便地提取文�g信息的话�Q�就需要了解多��个�D�——更明确一�Ҏ�� _��有多��个�D�头部和多少个段实体。每一个段头部和段实体都在文�g中连�l�地排列着�Q�所以要军_��D�头部和�D�实体在哪里�l�束的话�Q�段的数目是必需的。以下的�? ��C��PE文�g头中提取了段的数目：
PEFILE.C int WINAPI NumOfSections(LPVOID lpFile) { /* 文�g头部中所表示出的�D�|��?*/ return (int)((PIMAGE_FILE_HEADER) PEFHDROFFSET (lpFile))->NumberOfSections); }
如你所见，PEFHDROFFSET以及其它宏用��h��非常方便�?br>
PE可选头�?/strong>

　　 PE可执行文件中接下来的224个字节组成了PE可选头部。虽然它的名字是“可选头�?#8221;�Q�但是请��信�Q�这个头部�ƈ�?#8220;可�?#8221;�Q�而是“必需”的。OPTHDROFFSET宏可以获得指向可选头部的指针�Q?
//PEFILE.H #define OPTHDROFFSET(a) ((LPVOID)((BYTE *)a + \ ((PIMAGE_DOS_HEADER)a)->e_lfanew + \ SIZE_OF_NT_SIGNATURE + \ sizeof(IMAGE_FILE_HEADER)))
可选头部包含了很多关于可执行映像的重要信息�Q�例如初始的堆栈大小、程序入口点的位�|�、首选基地址、操作系�l�版本、段寚w��的信息等�{�。IMAGE_OPTIONAL_HEADER�l�构如下�Q?
//WINNT.H typedef struct _IMAGE_OPTIONAL_HEADER { // // 标准�? // USHORT Magic; UCHAR MajorLinkerVersion; UCHAR MinorLinkerVersion; ULONG SizeOfCode; ULONG SizeOfInitializedData; ULONG SizeOfUninitializedData; ULONG AddressOfEntryPoint; ULONG BaseOfCode; ULONG BaseOfData; // // NT附加�? // ULONG ImageBase; ULONG SectionAlignment; ULONG FileAlignment; USHORT MajorOperatingSystemVersion; USHORT MinorOperatingSystemVersion; USHORT MajorImageVersion; USHORT MinorImageVersion; USHORT MajorSubsystemVersion; USHORT MinorSubsystemVersion; ULONG Reserved1; ULONG SizeOfImage; ULONG SizeOfHeaders; ULONG CheckSum; USHORT Subsystem; USHORT DllCharacteristics; ULONG SizeOfStackReserve; ULONG SizeOfStackCommit; ULONG SizeOfHeapReserve; ULONG SizeOfHeapCommit; ULONG LoaderFlags; ULONG NumberOfRvaAndSizes; IMAGE_DATA_DIRECTORY DataDirectory[IMAGE_NUMBEROF_DIRECTORY_ENTRIES]; } IMAGE_OPTIONAL_HEADER, *PIMAGE_OPTIONAL_HEADER;
如你所见，�q�个�l�构中所列出的域实在是冗长得�q�分。�ؓ了不让你�Ҏ��有这些域感到厌烦�Q�我会仅仅讨论有用的——就是说�Q�对于探�I�PE文�g格式而言有用的�?

标准�?/strong>

　　首先�Q�请注意�q�个�l�构被划分�ؓ“标准�?#8221;�?#8220;NT附加�?#8221;。所谓标准域�Q�就是和UNIX可执行文件的COFF格式所公共的部分。虽然标准域保留了COFF中定义的名字�Q�但是Windows NT仍然��它们用作了不同的目的——尽��换个名字更好一些�?
　　 ·Magic。我不知道这个域是干什么的�Q�对于示例程序EXEVIEW.EXE�C�Z��E�序而言�Q�这个值是0x010B�?67�Q�译注：0x010B�?EXE�Q?x0107为ROM映像�Q�这个信息我是从eXeScope上得来的�Q��?
　　 ·MajorLinkerVersion、MinorLinkerVersion。表�C�链接此映像的链接器版本。随Window NT build 438配套的Windows NT SDK包含的链接器版本�?.39�Q�十六进制�ؓ2.27�Q��?
　　 ·SizeOfCode。可执行代码��寸�?
　　 ·SizeOfInitializedData。已初始化的数据��寸�?
　　 ·SizeOfUninitializedData。未初始化的数据��寸�?
·AddressOfEntryPoint。在标准域中�Q�AddressOfEntryPoint域是对PE文�g格式来说最为有��的了。这个域表示应用�E? 序入口点的位�|�。�ƈ且，对于�pȝ��黑客来说�Q�这个位�|�就是导入地址表（IAT�Q�的末尾。以下的函数�C��了如何从可选头部获得Windows NT可执行映像的入口炏V�?
//PEFILE.C LPVOID WINAPI GetModuleEntryPoint(LPVOID lpFile) { PIMAGE_OPTIONAL_HEADER poh; poh = (PIMAGE_OPTIONAL_HEADER)OPTHDROFFSET(lpFile); if (poh != NULL) return (LPVOID)poh->AddressOfEntryPoint; else return NULL; }
·BaseOfCode。已载入映像的代码（“.text”�D�）的相对偏�U�量�?
　　 ·BaseOfData。已载入映像的未初始化数据（“.bss”�D�）的相对偏�U�量�?

Windows NT附加�?/strong>

　　 ��d��到Windows NT PE文�g格式中的附加域�ؓWindows NT特定的进�E�行为提供了装蝲器的支持�Q�以下�ؓ�q�些域的概述�?
　　 ·ImageBase。进�E�映像地址�I�间中的首选基地址。Windows NT的Microsoft Win32 SDK链接器将�q�个值默认设�?x00400000�Q�但是你可以使用-BASE:linker开��x��变这个倹{�?
　　 ·SectionAlignment。从ImageBase开始，每个�D�都被相�l�的装入�q�程的地址�I�间中。SectionAlignment则规定了装蝲时段能够占据的最��空间数量——就是说�Q�段是关于SectionAlignment寚w��的�?
　　 Windows NT虚拟内存��理器规定，�D�对齐不能少于页��寸�Q�当前的x86�q�_��?096字节�Q�，�q�且必须是成倍的��尺寸�?096字节是x86链接器的默认��|��但是它可以通过-ALIGN: linker开��x��讄��?
·FileAlignment。映像文仉��先装载的最��的信息块间隔。例如，链接器将一个段实体�Q�段的原始数据）加零扩展为文件中最接近�? FileAlignment边界。早先提及的2.39版链接器��映像文件以0x200字节的边界对齐，�q�个值可以被强制改�ؓ512�?5535�q�么多�?
　　 ·MajorOperatingSystemVersion。表�C�Windows NT操作�pȝ��的主版本��P��通常对Windows NT 1.0而言�Q�这个��D��设�ؓ1�?
　　 ·MinorOperatingSystemVersion。表�C�Windows NT操作�pȝ��的次版本��P��通常对Windows NT 1.0而言�Q�这个��D��设�ؓ0�?
　　 ·MajorImageVersion。用来表�C�应用程序的�ȝ��本号�Q�对于Microsoft Excel 4.0而言�Q�这个值是4�?
　　 ·MinorImageVersion。用来表�C�应用程序的�ơ版本号�Q�对于Microsoft Excel 4.0而言�Q�这个值是0�?
　　 ·MajorSubsystemVersion。表�C�Windows NT Win32子系�l�的�ȝ��本号�Q�通常对于Windows NT 3.10而言�Q�这个��D��设�ؓ3�?
　　 ·MinorSubsystemVersion。表�C�Windows NT Win32子系�l�的�ơ版本号�Q�通常对于Windows NT 3.10而言�Q�这个��D��设�ؓ10�?
　　 ·Reserved1。未知目的，通常不被�pȝ��使用�Q��ƈ被链接器设�ؓ0�?
·SizeOfImage。表�C��入的可执行映像的地址�I�间中要保留的地址�I�间大小�Q�这个数字很大程度上受SectionAlignment的媄响。例如，考虑一个拥有固定页��寸4096字节的系�l�，如果你有一�?1个段的可执行文�g�Q�它的每个段都少�?096字节�Q��ƈ且关�?5536字节边界寚w��Q�那么SizeOfImage域将会被设�ؓ11 * 65536 = 720896�Q?76��）。而如果一个相同的文�g关于4096字节寚w��的话�Q�那么SizeOfImage域的�l�果��是11 * 4096 = 45056�Q?1��）。这只是个简单的例子�Q�它说明每个�D�需要少于一个页面的内存。在现实中，链接器通过个别地计��每个段的方法来军_�� SizeOfImage��切的倹{��它首先军_��每个�D�需要多��字节，�q�且最后将��面��L��向上取整��x��接近的SectionAlignment边界�Q�然后��L�� 是每个�D�个别需求之和了�?
　　 ·SizeOfHeaders。这个域表示文�g中有多少�I�间用来保存所有的文�g头部�Q�包括MS-DOS头部、PE文�g头部、PE可选头部以及PE�D�头部。文件中所有的�D�实体就开始于�q�个位置�?
　　 ·CheckSum。校验和是用来在装蝲旉��证可执行文�g的，它是由链接器讄��q�检验的。由于创��些校验和的算法是�U�有信息�Q�所以在此不�q�行讨论�?
　　 ·Subsystem。用于标识该可执行文件目标子�pȝ��的域。每个可能的子系�l�取值列于WINNT.H的IMAGE_OPTIONAL_HEADER�l�构之后�?
　　 ·DllCharacteristics。用来表�C�Z��个DLL映像是否��E�和�U�程的初始化及终止包含入口点的标记�?
·SizeOfStackReserve、SizeOfStackCommit、SizeOfHeapReserve�? SizeOfHeapCommit。这些域控制要保留的地址�I�间数量�Q��ƈ且负责栈和默认堆的申诗��在默认情况下，栈和堆都拥有1个页面的甌��g��?6�? ��面的保留倹{��这些值可以��用链接器开�?STACKSIZE:�?HEAPSIZE:来设�|��?
　　 ·LoaderFlags。告知装载器是否在装载时中止和调试，或者默认地正常�q�行�?
　　 ·NumberOfRvaAndSizes。这个域标识了接下来的DataDirectory数组。请注意它被用来标识�q�个数组�Q�而不是数�l�中的各个入口数字，�q�一炚w��帔R��要�?
　　 ·DataDirectory。数据目录表�C�文件中其它可执行信息重要组成部分的位置。它事实上就是一个IMAGE_DATA_DIRECTORY�l�构的数�l�，位于可选头部结构的末尾。当前的PE文�g格式定义�?6�U�可能的数据目录�Q�这之中�?1�U�现在在使用中�?

数据目录

WINNT.H之中所定义的数据目录�ؓ�Q?
//WINNT.H // 目录入口 // 导出目录 #define IMAGE_DIRECTORY_ENTRY_EXPORT 0 // 导入目录 #define IMAGE_DIRECTORY_ENTRY_IMPORT 1 // 资源目录 #define IMAGE_DIRECTORY_ENTRY_RESOURCE 2 // 异常目录 #define IMAGE_DIRECTORY_ENTRY_EXCEPTION 3 // 安全目录 #define IMAGE_DIRECTORY_ENTRY_SECURITY 4 // 重定位基本表 #define IMAGE_DIRECTORY_ENTRY_BASERELOC 5 // 调试目录 #define IMAGE_DIRECTORY_ENTRY_DEBUG 6 // 描述字串 #define IMAGE_DIRECTORY_ENTRY_COPYRIGHT 7 // 机器��|��MIPS GP�Q? #define IMAGE_DIRECTORY_ENTRY_GLOBALPTR 8 // TLS目录 #define IMAGE_DIRECTORY_ENTRY_TLS 9 // 载入配置目录 #define IMAGE_DIRECTORY_ENTRY_LOAD_CONFIG 10
基本上，每个数据目录都是一个被定义为IMAGE_DATA_DIRECTORY的结构。虽然数据目录入口本�w�是相同的，但是每个特定的目录种�c�d��是完全唯一的。每个数据目录的定义在本文的以后部分被描�q�Cؓ“预定义段”�?
//WINNT.H typedef struct _IMAGE_DATA_DIRECTORY { ULONG VirtualAddress; ULONG Size; } IMAGE_DATA_DIRECTORY, *PIMAGE_DATA_DIRECTORY;
每个数据目录入口指定了该目录的尺寸和相对虚拟地址。如果你要定义一个特定的目录的话�Q�就需要从可选头部中的数据目录数�l�中军_��相对的地址�Q? 然后使用虚拟地址来决定该目录位于哪个�D�中。一旦你军_��了哪个段包含了该目录�Q�该�D늚��D�头部就会被用于查找数据目录的精��文件偏�U�量位置�?
　　所以要获得一个数据目录的话，那么首先你需要了解段的概��c��我在下面会对其�q�行描述�Q�这个讨��Z��后还有一个有兛_��何定位数据目录的�C�Z��?

PE文�g�D?/strong>

PE文�g规范��q��前�ؓ止定义的那些头部以及一个名�?#8220;�D?#8221;的一般对象组成。段包含了文件的内容�Q�包括代码、数据、资源以及其它可执行信息�Q�每个段都有一�? 头部和一个实体（原始数据�Q�。我��在下面描述�D�头部的有关信息�Q�但是段实体则缺��一个严格的文�g�l�构。因此，它们几乎可以被链接器按�Q何的�Ҏ��l�织�Q�只�? 它的头部填充了��够能够解释数据的信息�?

�D�头�?/strong>

　　 PE文�g格式中，所有的�D�头部位于可选头部之后。每个段头部�?0个字节长�Q��ƈ且没有�Q何的填充信息。段头部被定义�ؓ以下的结构：
//WINNT.H #define IMAGE_SIZEOF_SHORT_NAME 8 typedef struct _IMAGE_SECTION_HEADER { UCHAR Name[IMAGE_SIZEOF_SHORT_NAME]; union { ULONG PhysicalAddress; ULONG VirtualSize; } Misc; ULONG VirtualAddress; ULONG SizeOfRawData; ULONG PointerToRawData; ULONG PointerToRelocations; ULONG PointerToLinenumbers; USHORT NumberOfRelocations; USHORT NumberOfLinenumbers; ULONG Characteristics; } IMAGE_SECTION_HEADER, *PIMAGE_SECTION_HEADER;
你如何才能获得一个特定段的段头部信息�Q�既然段头部是被�q�箋的组�l��v来的�Q�而且没有一个特定的��序�Q�那么段头部必须由名�U�来定位。以下的函数�C��了如何从一个给定了�D�名�U�的PE映像文�g中获得一个段头部�Q?
//PEFILE.C BOOL WINAPI GetSectionHdrByName(LPVOID lpFile, IMAGE_SECTION_HEADER *sh, char *szSection) { PIMAGE_SECTION_HEADER psh; int nSections = NumOfSections (lpFile); int i; if ((psh = (PIMAGE_SECTION_HEADER)SECHDROFFSET(lpFile)) != NULL) { /* 由名�U�查找段 */ for (i = 0; i < nSections; i++) { if (!strcmp(psh->Name, szSection)) { /* 向头部复制数�?*/ CopyMemory((LPVOID)sh, (LPVOID)psh, sizeof(IMAGE_SECTION_HEADER)); return TRUE; } else psh++; } } return FALSE; }
�q�个函数通过SECHDROFFSET宏将�W�一个段头部定位�Q�然后它开始在所有段中��@环，�q�将要寻扄��D�名�U�和每个�D늚�名称相比较，直到�? ��C��正确的那一个�ؓ止。当扑ֈ�了段的时候，函数��内存映像文件的数据复制��C��入函数的�l�构中，然后IMAGE_SECTION_HEADER�l�构的各域就能够被直接存取了�?

�D�头部的�?/strong>

　　 ·Name。每个段都有一�?字符长的名称域，�q�且�W�一个字�W�必��L��一个句炏V�?
　　 ·PhysicalAddress或VirtualSize。第二个域是一个union域，现在已不使用了�?
·VirtualAddress。这个域标识了进�E�地址�I�间中要装蝲�q�个�D늚�虚拟地址。实际的地址由将�q�个域的值加上可选头部结构中的ImageBase 虚拟地址得到。切讎ͼ�如果�q�个映像文�g是一个DLL�Q�那么这个DLL��׃��一定会装蝲到ImageBase要求的位�|�。所以一旦这个文件被装蝲�q�入了一个进 �E�，实际的ImageBase值应该通过使用GetModuleHandle来检验�?
·SizeOfRawData。这个域表示了相对FileAlignment的段实体��寸。文件中实际的段实体��寸��少于或�{�于 FileAlignment的整倍数。一旦映像被装蝲�q�入了一个进�E�的地址�I�间�Q�段实体的尺寸将会变得少于或�{�于FileAlignment的整倍数�?
　　 ·PointerToRawData。这是一个文件中�D�实体位�|�的偏移量�?
　　 ·PointerToRelocations、PointerToLinenumbers、NumberOfRelocations、NumberOfLinenumbers。这些域在PE格式中不使用�?
　　 ·Characteristics。定义了�D늚�特征。这些值可以在WINNT.H及本光盘�Q�译注：MSDN的光盘）的PE格式规范中找到�?

�? 定义
0x00000020 代码�D?
0x00000040 已初始化数据�D?
0x00000080 未初始化数据�D?
0x04000000 该段数据不能被缓�?
0x08000000 该段不能被分��?
0x10000000 �׃�n�D?
0x20000000 可执行段
0x40000000 可读�D?
0x80000000 可写�D?

定位数据目录

　　数据目录存在于它们相应的数据�D�中。典型地来说�Q�数据目录是�D�实体中的第一个结构，但不是必需的。由于这个缘故，如果你需要定位一个指定的数据目录的话�Q�就需要从�D�头部和可选头部中获得信息�?
　　 ��Z��让这个过�E�简单一点，我编写了以下的函数来定位��M��一个在WINNT.H之中定义的数据目录�?
// PEFILE.C LPVOID WINAPI ImageDirectoryOffset(LPVOID lpFile, DWORD dwIMAGE_DIRECTORY) { PIMAGE_OPTIONAL_HEADER poh; PIMAGE_SECTION_HEADER psh; int nSections = NumOfSections(lpFile); int i = 0; LPVOID VAImageDir; /* 必须�?�?NumberOfRvaAndSizes-1)之间 */ if (dwIMAGE_DIRECTORY >= poh->NumberOfRvaAndSizes) return NULL; /* 获得可选头部和�D�头部的偏移�?*/ poh = (PIMAGE_OPTIONAL_HEADER)OPTHDROFFSET(lpFile); psh = (PIMAGE_SECTION_HEADER)SECHDROFFSET(lpFile); /* 定位映像目录的相对虚拟地址 */ VAImageDir = (LPVOID)poh->DataDirectory [dwIMAGE_DIRECTORY].VirtualAddress; /* 定位包含映像目录的段 */ while (i++ < nSections) { if (psh->VirtualAddress <= (DWORD)VAImageDir && psh->VirtualAddress + psh->SizeOfRawData > (DWORD)VAImageDir) break; psh++; } if (i > nSections) return NULL; /* �q�回映像导入目录的偏�U�量 */ return (LPVOID)(((int)lpFile + (int)VAImageDir. psh->VirtualAddress) + (int)psh->PointerToRawData); }
该函数首先确认被��h��的数据目录入口数字，然后它分别获取指向可选头部和�W�一个段头部的两个指针。它从可选头部决定数据目录的虚拟地址�Q? 然后它��用这个值来军_��数据目录定位在哪个段实体之中。如果适当的段实体已经被标识了�Q�那么数据目录特定的位置��可以通过��它的相对虚拟地址转换为文件中地址的方法来扑ֈ��?

��果�?/a> 2010-10-12 16:38 发表评论

Windows完成端口与Linux epoll技术简�?转蝲)

Fri, 27 Aug 2010 07:43:00 GMT

WINDOWS完成端口�~�程
1、基本概�?br> 2、WINDOWS完成端口的特�?br> 3、完成端口（Completion Ports �Q�相��x��据结构和创徏
4、完成端口线�E�的工作原理
5、Windows完成端口的实例代�?br> Linux的EPoll模型
1、�ؓ什么select落后
2、内�怸�提高I/O性能的新�Ҏ��epoll
3、epoll的优�?br> 4、epoll的工作模�?
5、epoll的��用方�?br> 6、Linux下EPOll�~�程实例
�ȝ��

WINDOWS完成端口�~�程
        摘要�Q�开发网�l�程序从来都不是一件容易的事情�Q�尽��只需要遵守很��的一些规�?创徏socket,发�v�q�接�Q�接受连接，发送和接受数据。真正的困难在于�Q? 让你的程序可以适应从单单一个连接到几千个连接乃至于上万个连接。利用Windows�q�_��完成端口�q�行重叠I/O的技术和Linux�?.6版本的内�怸� 引入的EPOll技术，可以很方便在在在Windows和Linux�q�_��上开发出支持大量�q�接的网�l�服务程序。本文介�l�在Windows和Linux�q�_�� 上��用的完成端口和EPoll模型开发的基本原理�Q�同时给出实际的例子。本文主要关注C/S�l�构的服务器端程序，因�ؓ一般来��_��开发一个大定w��Q�具可扩�? 性的winsock�E�序一般就是指服务�E�序�?br>
1、基本概�?br>     讑֤�---windows操作�pȝ��上允讔R��信的�Q何东西，比如文�g、目录、串行口、�ƈ行口、邮件槽、命名管道、无名管道、套接字、控制台、逻辑��盘、物�? ��盘�{�。绝大多��C��讑֤�打交道的函数都是CreateFile/ReadFile/WriteFile�{�。所以我们不能看�?*File函数��只惛_��文�g 讑֤�。与讑֤�通信有两�U�方式，同步方式和异步方式。同步方式下�Q�当调用ReadFile函数�Ӟ��函数会等待系�l�执行完所要求的工作，然后才返回；异步方式下，ReadFile�q�类函数会直接返回，�pȝ��自己��d��成对讑֤�的操作，然后以某�U�方式通知完成操作�?br> 重叠I/O----��֐�思义�Q�当你调用了某个函数�Q�比如ReadFile�Q�就立刻�q�回做自��q��其他动作的时候，同时�pȝ��也在对I/0讑֤��q�行你要求的�? 作，在这�D�|��间内你的�E�序和系�l�的内部动作是重叠的�Q�因此有更好的性能。所以，重叠I/O是用于异步方式下使用I/O讑֤�的�? 重叠I/O需要��用的一个非帔R��要的数据�l�构OVERLAPPED�?br>
2、WINDOWS完成端口的特�?br>    Win32重叠I/O(Overlapped I/O)机制允许发�v一个操作，然后在操作完成之后接受到信息。对于��U�需要很长时间才能完成的操作来说�Q�重叠IO机制��其有用�Q�因为发起重叠操作的�U�程在重叠请求发出后��可以自��q��做别的事情了。在WinNT和Win2000上，提供的真正的可扩展的I/O模型��是使用完成端口�Q�Completion Port�Q�的重叠I/O.完成端口---是一�U�WINDOWS内核对象。完成端口用于异步方式的重叠I/0情况下，当然重叠I/O不一定非使用完成端口�? 可，�q�有讑֤�内核对象、事件对象、告警I/0�{�。但是完成端口内部提供了�U�程池的��理�Q�可以避免反复创建线�E�的开销�Q�同时可以根据CPU的个数灵�zȝ��军_�� U�程个数�Q�而且可以让减��线�E�调度的�ơ数从而提高性能其实�c�M��于WSAAsyncSelect和select函数的机制更�Ҏ��兼容Unix�Q�但是难以实�? 我们惌��?#8220;扩展�?#8221;。而且windows的完成端口机制在操作�pȝ��内部已经作了优化�Q�提供了更高的效率。所以，我们选择完成端口开始我们的服务器程序的开发�?br> 1、发��h��作不一定完成，�pȝ��会在完成的时候通知你，通过用户在完成端口上的等待，处理操作的结果。所以要有检查完成端口，取操作结果的�U�程。在完成端口上守候的�U�程�pȝ��有优化，除非在执行的�U�程��d��Q�不会有新的�U�程被激�z�，以此来减��线�E�切换造成的性能代�h。所以如果程序中没有太多的阻塞操作，没有必要启动太多的线�E�，CPU数量的两倍，一般这��h��启动�U�程�?br> 2、操作与相关数据的绑定方式：在提交数据的时候用户对数据打相应的标记�Q�记录操作的�c�d��Q�在用户处理操作�l�果的时候，通过��查自己打的标记和�pȝ��的操作结果进行相应的处理�?
3、操作返回的方式:一般操作完成后要通知�E�序�q�行后箋处理。但写操作可以不通知用户�Q�此时如果用户写操作不能马上完成�Q�写操作的相��x��据会被暂存到到非交换�~�冲��Z��Q�在操作完成的时候，�pȝ��会自动释攄��冲区。此时发起完写操作，使用的内存就可以释放了。此时如果占用非交换�~�冲太多会�ɾpȝ��停止响应�?br>
3、完成端口（Completion Ports �Q�相��x��据结构和创徏
    其实可以把完成端口看成系�l�维护的一个队列，操作�pȝ��把重叠IO操作完成的事仉��知攑ֈ�该队列里�Q�由于是暴露 “操作完成”的事仉��知�Q�所以命名�ؓ“完成端口”�Q�COmpletion Ports�Q�。一个socket被创建后�Q�可以在��M��时刻和一个完成端口联�p��v来�?br> 完成端口相关最重要的是OVERLAPPED数据�l�构
typedef struct _OVERLAPPED {
    ULONG_PTR Internal;//被系�l�内部赋��|��用来表示�pȝ��状�?
    ULONG_PTR InternalHigh;// 被系�l�内部赋��|��传输的字节数
    union {
        struct {
            DWORD Offset;//和OffsetHigh合成一�?4位的整数�Q�用来表�C�Z��文�g头部的多��字节开�?
            DWORD OffsetHigh;//操作�Q�如果不是对文�gI/O来操作，则必��设定�ؓ0
        };
        PVOID Pointer;
    };
    HANDLE hEvent;//如果不��用，��务必设�?,否则误��一个有效的Event句柄
} OVERLAPPED, *LPOVERLAPPED;

下面是异步方式��用ReadFile的一个例�?
OVERLAPPED Overlapped;
Overlapped.Offset=345;
Overlapped.OffsetHigh=0;
Overlapped.hEvent=0;
//假定其他参数都已�l�被初始�?
ReadFile(hFile,buffer,sizeof(buffer),&dwNumBytesRead,&Overlapped);
�q�样��完成了异步方式��L��件的操作�Q�然后ReadFile函数�q�回�Q�由操作�pȝ��做自��q��事情�Q�下面介�l�几个与OVERLAPPED�l�构相关的函�?
�{�待重叠I/0操作完成的函�?
BOOL GetOverlappedResult (
HANDLE hFile,
LPOVERLAPPED lpOverlapped,//接受�q�回的重叠I/0�l�构
LPDWORD lpcbTransfer,//成功传输了多��字节数
BOOL fWait //TRUE只有当操作完成才�q�回�Q�FALSE直接�q�回�Q�如果操作没有完成，通过�?/用GetLastError ( )函数会返回ERROR_IO_INCOMPLETE
);
宏HasOverlappedIoCompleted可以帮助我们��试重叠I/0操作是否完成�Q�该宏对OVERLAPPED�l�构的Internal成员�q�行了测试，查看是否�{�于STATUS_PENDING倹{�?/p>
        一般来��_��一个应用程序可以创建多个工作线�E�来处理完成端口上的通知事�g。工作线�E�的数量依赖于程序的具体需要。但是在理想的情况下�Q�应该对应一个CPU 创徏一个线�E�。因为在完成端口理想模型中，每个�U�程都可以从�pȝ��获得一�?#8220;原子”性的旉��片，轮番�q�行�q�检查完成端口，�U�程的切换是额外的开销。在实际开发的时候，�q�要考虑�q�些�U�程是否牉|��到其他堵塞操作的情况。如果某�U�程�q�行堵塞操作�Q�系�l�则��其挂�v�Q�让别的�U�程获得�q�行旉��。因此，如果有这��L��情况�Q? 可以多创建几个线�E�来��量利用旉��?br> 应用完成端口�Q?br>     创徏完成端口�Q�完成端口是一个内核对象，使用时他��L��要和臛_��一个有效的讑֤�句柄�q�行兌��Q�完成端口是一个复杂的内核对象�Q�创建它的函数是�Q?br> HANDLE CreateIoCompletionPort(
    IN HANDLE FileHandle,
    IN HANDLE ExistingCompletionPort,
    IN ULONG_PTR CompletionKey,
    IN DWORD NumberOfConcurrentThreads
    );

通常创徏工作分两步：
�W�一步，创徏一个新的完成端口内核对象，可以使用下面的函敎ͼ�
       HANDLE CreateNewCompletionPort(DWORD dwNumberOfThreads)
{
          return CreateIoCompletionPort(INVALID_HANDLE_VALUE,NULL,NULL,dwNumberOfThreads);
};

�W�二步，��刚创徏的完成端口和一个有效的讑֤�句柄兌��h��Q�可以��用下面的函数�Q?br>        bool AssicoateDeviceWithCompletionPort(HANDLE hCompPort,HANDLE hDevice,DWORD dwCompKey)
{
          HANDLE h=CreateIoCompletionPort(hDevice,hCompPort,dwCompKey,0);
          return h==hCompPort;
};
说明
1�Q?CreateIoCompletionPort函数也可以一�ơ性的既创建完成端口对象，又关联到一个有效的讑֤�句柄
2�Q?CompletionKey是一个可以自己定义的参数�Q�我们可以把一个结构的地址赋给它，然后在合适的时候取出来使用�Q�最好要保证�l�构里面的内存不是分配在栈上�Q�除非你有十分的把握内存会保留到你要使用的那一刅R�?br> 3�Q? NumberOfConcurrentThreads通常用来指定要允许同时运行的的线�E�的最大个数。通常我们指定�?�Q�这��L��l�会�Ҏ��CPU的个数来�? 动确定。创建和兌��的动作完成后�Q�系�l�会��完成端口关联的讑֤�句柄、完成键作�ؓ一条纪录加入到�q�个完成端口的设备列表中。如果你有多个完成端口，��׃��有多个对应的讑֤�列表。如果设备句柄被关闭�Q�则表中自动删除该纪录�?br>
4、完成端口线�E�的工作原理
完成端口可以帮助我们��理�U�程池，但是�U�程池中的线�E�需要我们��用_beginthreadex来创建，凭什么通知完成端口��理我们的新�U�程呢？�{�案在函数GetQueuedCompletionStatus。该函数原型�Q?
BOOL GetQueuedCompletionStatus(
    IN HANDLE CompletionPort,
    OUT LPDWORD lpNumberOfBytesTransferred,
    OUT PULONG_PTR lpCompletionKey,
    OUT LPOVERLAPPED *lpOverlapped,
    IN DWORD dwMilliseconds
);
�q�个函数试图从指定的完成端口的I/0完成队列中抽取纪录。只有当重叠I/O动作完成的时候，完成队列中才有纪录。凡是调用这个函数的�U�程��被攑օ�到完�? 端口的等待线�E�队列中�Q�因此完成端口就可以在自��q��U�程池中帮助我们�l�护�q�个�U�程。完成端口的I/0完成队列中存放了当重叠I/0完成的结�?--- 一条纪录，该纪录拥有四个字�D�，前三��就对应GetQueuedCompletionStatus函数�?�?�?参数�Q�最后一个字�D�|��错误信息 dwError。我们也可以通过调用PostQueudCompletionStatus模拟完成了一个重叠I/0操作�?
当I/0完成队列中出��C��U�录�Q�完成端口将会检查等待线�E�队列，该队列中的线�E�都是通过调用GetQueuedCompletionStatus函数使自己加入队列的。等待线�E�队列很��单，只是保存了这些线�E�的ID。完成端口会按照后进先出的原则将一个线�E�队列的ID攑օ�到释攄��E�列表中�Q�同时该�U�程��从 �{�待GetQueuedCompletionStatus函数�q�回的睡眠状态中变�ؓ可调度状态等待CPU的调度。所以我们的�U�程要想成�ؓ完成端口��理的线 �E�，��必��要调用GetQueuedCompletionStatus函数。出于性能的优化，实际上完成端口还�l�护了一个暂停线�E�列表，具体�l�节可以参�? 《Windows高��~�程指南》，我们现在知道的知识，已经��_��了�? 完成端口�U�程间数据传递线�E�间传递数据最常用的办法是在_beginthreadex函数中将参数传递给�U�程函数�Q�或者��用全局变量。但是完成端口还有自 ��q��传递数据的�Ҏ��Q�答案就在于CompletionKey和OVERLAPPED参数�?br> CompletionKey被保存在完成端口的设备表中，是和讑֤�句柄一一对应的，我们可以��与讑֤�句柄相关的数据保存到CompletionKey中，或者将CompletionKey表示为结构指针，�q�样��可以传递更加丰富的内容。这些内容只能在一开始关联完成端口和讑֤�句柄的时候做�Q�因此不能在以后动态改变�?br> OVERLAPPED参数是在每次调用ReadFile�q�样的支持重叠I/0的函数时传递给完成端口的。我们可以看刎ͼ�如果我们不是�Ҏ��件设备做操作�Q�该 �l�构的成员变量就�Ҏ��们几乎毫无作用。我们需要附加信息，可以创徏自己的结构，然后��OVERLAPPED�l�构变量作�ؓ我们�l�构变量的第一个成员，然后�? 递第一个成员变量的地址�l�ReadFile函数。因为类型匹配，当然可以通过�~�译。当GetQueuedCompletionStatus函数�q�回�Ӟ��? 们可以获取到�W�一个成员变量的地址�Q�然后一个简单的强制转换�Q�我们就可以把它当作完整的自定义�l�构的指针��用，�q�样��可以传递很多附加的数据了。太好了�Q? 只有一点要注意�Q�如果跨�U�程传递，��h��意将数据分配到堆上，�q�且接收端应该将数据用完后释放。我们通常需要将ReadFile�q�样的异步函数的所需要的�~? 冲区攑ֈ�我们自定义的�l�构中，�q�样当GetQueuedCompletionStatus被返回时�Q�我们的自定义结构的�~�冲区变量中��存放了I/0操作�? 数据。CompletionKey和OVERLAPPED参数�Q�都可以通过GetQueuedCompletionStatus函数获得�?br> �U�程的安全退�?br>        很多�U�程��Z��不止一�ơ的执行异步数据处理�Q�需要��用如下语�?br> while (true)
{
       ......
       GetQueuedCompletionStatus(...);
        ......
}
那么如何退出呢�Q�答案就在于上面曾提到的PostQueudCompletionStatus函数�Q�我们可以用它发送一个自定义的包含了OVERLAPPED成员变量的结构地址�Q�里面包含一个状态变量，当状态变量�ؓ退出标志时�Q�线�E�就执行清除动作然后退出�?br>
5、Windows完成端口的实例代码：
DWORD WINAPI WorkerThread(LPVOID lpParam)
{
ULONG_PTR *PerHandleKey;
OVERLAPPED *Overlap;
OVERLAPPEDPLUS *OverlapPlus,
*newolp;
DWORD dwBytesXfered;
while (1)
{
ret = GetQueuedCompletionStatus(
hIocp,
&dwBytesXfered,
(PULONG_PTR)&PerHandleKey,
&Overlap,
INFINITE);
if (ret == 0)
{
// Operation failed
continue;
}
OverlapPlus = CONTAINING_RECORD(Overlap, OVERLAPPEDPLUS, ol);
switch (OverlapPlus->OpCode)
{
case OP_ACCEPT:
// Client socket is contained in OverlapPlus.sclient
// Add client to completion port
CreateIoCompletionPort(
(HANDLE)OverlapPlus->sclient,
hIocp,
(ULONG_PTR)0,
0);
// Need a new OVERLAPPEDPLUS structure
// for the newly accepted socket. Perhaps
// keep a look aside list of free structures.
newolp = AllocateOverlappedPlus();
if (!newolp)
{
// Error
}
newolp->s = OverlapPlus->sclient;
newolp->OpCode = OP_READ;
// This function divpares the data to be sent
PrepareSendBuffer(&newolp->wbuf);
ret = WSASend(
newolp->s,
&newolp->wbuf,
1,
&newolp->dwBytes,
0,
&newolp.ol,
NULL);
if (ret == SOCKET_ERROR)
{
if (WSAGetLastError() != WSA_IO_PENDING)
{
// Error
}
}
// Put structure in look aside list for later use
FreeOverlappedPlus(OverlapPlus);
// Signal accept thread to issue another AcceptEx
SetEvent(hAcceptThread);
break;
case OP_READ:
// Process the data read
// Repost the read if necessary, reusing the same
// receive buffer as before
memset(&OverlapPlus->ol, 0, sizeof(OVERLAPPED));
ret = WSARecv(
OverlapPlus->s,
&OverlapPlus->wbuf,
1,
&OverlapPlus->dwBytes,
&OverlapPlus->dwFlags,
&OverlapPlus->ol,
NULL);
if (ret == SOCKET_ERROR)
{
if (WSAGetLastError() != WSA_IO_PENDING)
{
// Error
}
}
break;
case OP_WRITE:
// Process the data sent, etc.
break;
} // switch
} // while
} // WorkerThread

查看以上代码�Q�注意如果Overlapped操作立刻��p�|�Q�比如，�q�回SOCKET_ERROR或其他非WSA_IO_PENDING的错误）�Q�则没有��M��完成通知旉��会被攑ֈ�完成端口队列里。反之，则一定有相应的通知旉��被放到完成端口队列。更完善的关于Winsock的完成端口机�Ӟ��可以参�? MSDN的Microsoft PlatFormSDK�Q�那里有完成端口的例子。访�?a target="_blank">http://msdn.microsoft.com/library/techart/msdn_servrapp.htm可以获得更多信息�?/p>
Linux的EPoll模型
Linux 2.6内核中提高网�l�I/O性能的新�Ҏ��-epoll I/O多�\复用技术在比较多的TCP�|�络服务器中有��用，��x��较多的用到select函数�?br>
1、�ؓ什么select落后
首先�Q�在Linux内核中，select所用到的FD_SET是有限的�Q�即内核中有个参数__FD_SETSIZE定义了每个FD_SET的句柄个敎ͼ�在我用的2.6.15-25-386内核中，该值是1024�Q�搜索内核源代码得到�Q?br> include/linux/posix_types.h:#define __FD_SETSIZE         1024
也就是说�Q�如果想要同时检��?025个句柄的可读状态是不可能用select实现的。或者同时检��?025个句柄的可写状态也是不可能的。其�ơ，内核中实现select是用轮询�Ҏ��Q�即每次��都会遍历所有FD_SET中的句柄�Q�显�Ӟ��select函数执行旉��与FD_SET中的句柄个数有一个比例关�p�，即select要检��的句柄数越多就会越�Ҏ��。当�Ӟ��在前文中我�ƈ没有提及poll�Ҏ��Q�事实上用select的朋友一定也试过poll�Q�我个�h觉得 select和poll大同��异�Q�个人偏好于用select而已�?/p>
2、内�怸�提高I/O性能的新�Ҏ��epoll
epoll是什么？按照man手册的说法：是�ؓ处理大批量句柄而作了改�q�的poll。要使用epoll只需要这三个�pȝ��调用�Q�epoll_create(2)�Q?epoll_ctl(2)�Q?epoll_wait(2)�?br> 当然�Q�这不是2.6内核才有的，它是�?.5.44内核中被引进�?epoll(4) is a new API introduced in Linux kernel 2.5.44)

Linux2.6内核epoll介绍
先介�l?本书《The Linux Networking Architecture--Design and Implementation of Network Protocols in the Linux Kernel》，�?.4内核讲解Linux TCP/IP实现�Q�相当不�?作�ؓ一个现实世界中的实玎ͼ�很多时候你必须作很多权衡，�q�时候参考一个久�l�考验的系�l�更有实际意义。�D个例�?linux�? �怸�sk_buff�l�构��Z��q�求速度和安全，牺牲了部分内存，所以在发送TCP包的时候，无论应用层数据多�?sk_buff最��也�?72的字�?其实对于socket应用层程序来��_��另外一本书《UNIX Network Programming Volume 1》意义更大一�?2003�q�的时候，�q�本书出了最新的�W?版本�Q�不�q�主要还是修订第2版本。其中第6章《I/O Multiplexing》是最重要的。Stevens�l�出了网�l�IO的基本模型。在�q�里最重要的莫�q�于select模型和Asynchronous I/O模型.从理��Z��_��AIO��g��是最高效的，你的IO操作可以立即�q�回�Q�然后等待os告诉你IO操作完成。但是一直以来，如何实现��没有一个完��的�? 案。最著名的windows完成端口实现的AIO,实际上也是内部用�U�程池实现的�|�了�Q�最后的�l�果是IO有个�U�程池，你应用也需要一个线�E�池...... 很多文��其实已经指出了这带来的线�E�context-switch带来的代仗��在linux �q�_��上，关于�|�络AIO一直是改动最多的地方�Q?.4的年代就有很多AIO内核patch,最著名的应该算是SGI那个。但是一直到2.6内核发布�Q�网�l? 模块的AIO一直没有进入稳定内核版�?大部分都是��用用��L��E�模拟方法，在��用了NPTL的linux上面其实和windows的完成端口基本上差不�? �?�?.6内核所支持的AIO�Ҏ��盘的AIO---支持io_submit(),io_getevents()以及对Direct IO的支�?��是�l�过VFS�pȝ��buffer直接写硬盘，对于��服务器在内存��^�E�x��上有相当帮�?�?br> 所以，剩下的select模型基本上就是我们在linux上面的唯一选择�Q�其实，如果加上no-block socket的配�|�，可以完成一�?�?AIO的实玎ͼ�只不�q�推动力在于你而不是os而已。不�q�传�l�的select/poll函数有着一些无法忍受的�~? 点，所以改�q�一直是2.4-2.5开发版本内核的��d��Q�包�?dev/poll�Q�realtime signal�{�等。最�l�，Davide Libenzi开发的epoll�q�入2.6内核成�ؓ正式的解��x��?br>
3、epoll的优�?/strong>
<1>支持一个进�E�打开大数目的socket描述�W?FD)
select 最不能忍受的是一个进�E�所打开的FD是有一定限制的�Q�由FD_SETSIZE讄��Q�默认值是2048。对于那些需要支持的上万�q�接数目的IM服务器来说显然太��了。这时候你一是可以选择修改�q�个宏然后重新编译内核，不过资料也同时指��样会带来�|�络效率的下降，二是可以选择多进�E�的解决�Ҏ��(传统�? Apache�Ҏ��)�Q�不�q�虽然linux上面创徏�q�程的代��h��较小�Q�但仍旧是不可忽视的�Q�加上进�E�间数据同步�q�比不上�U�程间同步的高效�Q�所以也不是一�U�完 ��的�Ҏ��。不�q? epoll则没有这个限�Ӟ��它所支持的FD上限是最大可以打开文�g的数目，�q�个数字一般远大于2048,举个例子,�?GB内存的机器上大约�?0万左叻I��具体数目可以cat /proc/sys/fs/file-max察看,一般来说这个数目和�pȝ��内存关系很大�?br> <2>IO效率不随FD数目增加而线性下�?br> 传统的select/poll另一个致命弱点就是当你拥有一个很大的socket集合�Q�不�q�由于网�l��g�Ӟ��M��旉��只有部分的socket�?�z�跃"的，但是select/poll每次调用都会�U�性扫描全部的集合�Q�导致效率呈现线性下降。但是epoll不存在这个问题，它只会对"�z�跃"的socket�q�行操作---�q�是因�ؓ在内核实��C��epoll是根据每个fd上面的callback函数实现的。那么，只有"�z�跃"的socket才会��d��的去调用 callback函数�Q�其他idle状态socket则不会，在这点上�Q�epoll实现了一�?�?AIO�Q�因��时候推动力在os内核。在一�? benchmark中，如果所有的socket基本上都是活跃的---比如一个高速LAN环境�Q�epoll�q�不比select/poll有什么效率，�? 反，如果�q�多使用epoll_ctl,效率相比�q�有�E�微的下降。但是一旦��用idle connections模拟WAN环境,epoll的效率就�q�在select/poll之上了�?br> <3>使用mmap加速内�怸�用户�I�间的消息传递�?br> �q�点实际上涉及到epoll的具体实��C��。无论是select,poll�q�是epoll都需要内核把FD消息通知�l�用��L��_��如何避免不必要的内存拯��? 很重要，在这点上�Q�epoll是通过内核于用��L��间mmap同一块内存实现的。而如果你��x��一样从2.5内核��关注epoll的话�Q�一定不会忘记手�? mmap�q�一步的�?br> <4>内核微调
�q�一点其实不��epoll的优点了�Q�而是整个linux�q�_��的优炏V��也�怽�可以怀疑linux�q�_��Q�但是你无法回避linux�q�_��赋予你微调内核的能力�? 比如�Q�内核TCP/IP协议栈��用内存池��理sk_buff�l�构�Q�那么可以在�q�行时期动态调整这个内存pool(skb_head_pool)的大��?- - 通过echo XXXX>/proc/sys/net/core/hot_list_length完成。再比如listen函数的第2个参�?TCP完成3�ơ握�? 的数据包队列长度)�Q�也可以�Ҏ��你��^台内存大��动态调整。更甚至在一个数据包面数目巨大但同时每个数据包本�w�大��却很小的特�D�系�l�上��试最新的NAPI�|? 卡驱动架构�?br> 4、epoll的工作模�?br> 令�h高兴的是�Q?.6内核的epoll比其2.5开发版本的/dev/epoll��z�了许多�Q�所以，大部分情况下�Q�强大的东西往往是简单的。唯一有点�ȝ��是epoll�?�U�工作方�?LT和ET�?br> LT(level triggered)是缺省的工作方式�Q��ƈ且同时支持block和no-block socket.在这�U�做法中�Q�内核告诉你一个文件描�q�符是否��q�A了，然后你可以对�q�个��q�A的fd�q�行IO操作。如果你不作��M��操作�Q�内核还是会�l�箋通知�? 的，所以，�q�种模式�~�程出错误可能性要��一炏V��传�l�的select/poll都是�q�种模型的代表．
ET (edge-triggered)是高速工作方式，只支持no-block socket。在�q�种模式下，当描�q�符从未��q�A变�ؓ��q�A�Ӟ��内核通过epoll告诉你。然后它会假设你知道文�g描述�W�已�l�就�l�，�q�且不会再�ؓ那个文�g描述 �W�发送更多的��q�A通知�Q�直��C��做了某些操作��D��那个文�g描述�W�不再�ؓ��q�A状态了(比如�Q�你在发送，接收或者接收请求，或者发送接收的数据��于一定量时导�? 了一个EWOULDBLOCK 错误�Q�。但是请注意�Q�如果一直不对这个fd作IO操作(从而导致它再次变成未就�l?�Q�内�怸�会发送更多的通知(only once),不过在TCP协议中，ET模式的加速效用仍需要更多的benchmark��认�?br> epoll只有epoll_create,epoll_ctl,epoll_wait 3个系�l�调用，具体用法请参�?a target="_blank">http://www.xmailserver.org/linux-patches/nio-improve.html �Q�在http://www.kegel.com/rn/也有一个完整的例子�Q�大家一看就知道如何使用�?br> Leader/follower模式�U�程pool实现�Q�以及和epoll的配合�?br>
5�?epoll的��用方�?/strong>
    首先通过create_epoll(int maxfds)来创��Z��个epoll的句柄，其中maxfds��Z��epoll所支持的最大句柄数。这个函��C��q�回一个新的epoll句柄�Q�之后的所有操�? ��通过�q�个句柄来进行操作。在用完之后�Q�记得用close()来关闭这个创建出来的epoll句柄�? 之后在你的网�l�主循环里面�Q�每一帧的调用epoll_wait(int epfd, epoll_event events, int max events, int timeout)来查询所有的�|�络接口�Q�看哪一个可以读�Q�哪一个可以写了。基本的语法为：
nfds = epoll_wait(kdpfd, events, maxevents, -1);
其中kdpfd为用epoll_create创徏之后的句柄，events是一个epoll_event*的指针，当epoll_wait�q�个函数操作�? 功之后，epoll_events里面��储存所有的��d��事�g。max_events是当前需要监听的所有socket句柄数。最后一个timeout�? epoll_wait的超�Ӟ��?的时候表�C�马上返回，�?1的时候表�C�Z��直等下去�Q�直到有事�g范围�Q��ؓ��L��正整数的时候表�C�等�q�么长的旉��Q�如果一直没有事�Ӟ��则范围。一般如果网�l�主循环是单独的�U�程的话�Q�可以用-1来等�Q�这样可以保证一些效率，如果是和主逻辑在同一个线�E�的话，则可以用0来保证主循环的效率�?/p>
epoll_wait范围之后应该是一个��@环，遍利所有的事�g�Q?
for(n = 0; n < nfds; ++n) {
                if(events[n].data.fd == listener) { //如果是主socket的事件的话，则表�C�有新连接进入了�Q�进行新�q�接的处理�?
                    client = accept(listener, (struct sockaddr *) &local,
                                    &addrlen);
                    if(client < 0){
                        perror("accept");
                        continue;
                    }
                    setnonblocking(client); // ��新�q�接�|�于非阻塞模�?
                    ev.events = EPOLLIN | EPOLLET; // �q�且��新�q�接也加入EPOLL的监听队列�?
注意�Q�这里的参数EPOLLIN | EPOLLET�q�没有设�|�对写socket的监听，如果有写操作的话�Q�这个时候epoll是不会返回事件的�Q�如果要对写操作也监听的话，应该是EPOLLIN | EPOLLOUT | EPOLLET
                    ev.data.fd = client;
                    if (epoll_ctl(kdpfd, EPOLL_CTL_ADD, client, &ev) < 0) {
// 讄��好event之后�Q�将�q�个新的event通过epoll_ctl加入到epoll的监听队列里面，�q�里用EPOLL_CTL_ADD来加一个新�? epoll事�g�Q�通过EPOLL_CTL_DEL来减��一个epoll事�g�Q�通过EPOLL_CTL_MOD来改变一个事件的监听方式�?
                        fprintf(stderr, "epoll set insertion error: fd=%d0,
                                client);
                        return -1;
                    }
                }
                else // 如果不是主socket的事件的话，则代表是一个用户socket的事�Ӟ��则来处理�q�个用户socket的事情，比如说read(fd,xxx)之类的，或者一些其他的处理�?
                    do_use_fd(events[n].data.fd);
}

对，epoll的操作就�q�么��单，��d��不过4个API�Q�epoll_create, epoll_ctl, epoll_wait和close�?
如果您对epoll的效率还不太了解�Q�请参考我之前关于�|�络游戏的网�l�编�E�等相关的文章�?/p>

以前公司的服务器都是使用HTTP�q�接�Q�但是这��L��话，在手机目前的�|�络情况下不但显得速度较慢�Q�而且不稳定。因此大家一致同意用SOCKET来进行连接。虽然��用SOCKET之后�Q�对于用��L��费用可能会增�?�׃��是用了CMNET而非CMWAP)�Q�但是，�U�着用户体验至上的原则，�怿�大家�q�是能够接受 �?希望那些玩家月末收到帐单不后能够保持克制...)�?br> �q�次的服务器设计中，最重要的一个突��_��是��用了EPOLL模型�Q�虽然对之也是一知半解，但是既然在各大PC�|�游中已�l�经�q�了如此严酷的考验�Q�相信他不会让我们失望，使用后的�l�果�Q�确实也是表现相当不错。在�q�里�Q�我�q�是主要大致介绍一下这个模型的�l�构�?br> 6、Linux下EPOll�~�程实例
EPOLL模型��g��只有一�U�格式，所以大家只要参考我下面的代码，��p��够对EPOLL有所了解了，代码的解释都已经在注释中�Q?/p>
while (TRUE)
{
int nfds = epoll_wait (m_epoll_fd, m_events, MAX_EVENTS, EPOLL_TIME_OUT);//�{�待EPOLL旉��的发生，相当于监听，至于相关的端口，需要在初始化EPOLL的时候绑定�?br> if (nfds <= 0)
continue;
m_bOnTimeChecking = FALSE;
G_CurTime = time(NULL);
for (int i=0; i
{
try
{
if (m_events.data.fd == m_listen_http_fd)//如果新监��到一个HTTP用户�q�接到绑定的HTTP端口�Q�徏立新的连接。由于我们新采用了SOCKET�q�接�Q�所以基本没用�?br> {
OnAcceptHttpEpoll ();
}
else if (m_events.data.fd == m_listen_sock_fd)//如果新监��到一个SOCKET用户�q�接��C��l�定的SOCKET端口�Q�徏立新的连接�?br> {
OnAcceptSockEpoll ();
}
else if (m_events.events & EPOLLIN)//如果是已�l�连接的用户�Q��ƈ且收到数据，那么�q�行��d��?br> {
OnReadEpoll (i);
}

OnWriteEpoll (i);//查看当前的活动连接是否有需要写出的数据�?br> }
catch (int)
{
PRINTF ("CATCH捕获错误\n");
continue;
}
}
m_bOnTimeChecking = TRUE;
OnTimer ();//�q�行一些定时的操作�Q�主要就是删除一些短�U�用��L��?br> }
其实EPOLL的精华，也就是上�q�的几段短短的代码，看来时代真的不同了，以前如何接受大量用户�q�接的问题，现在却被如此��L��的搞定，真是让�h不得不感叹，对哪�?/p>
�ȝ��
Windows完成端口与Linux epoll技术方案是�q?个��^��C��实现异步IO和设计开发一个大定w��Q�具可扩展性的winsock�E�序指服务程序的很好的选择�Q�本文对�q?中技术的实现原理和实际的使用�Ҏ��做了一个详�l�的介绍

��果�?/a> 2010-08-27 15:43 发表评论

Wed, 28 Apr 2010 02:59:00 GMT

HANDLE hThreadParent;
    //CreateThread(NULL,0,ChildThread,(PVOID)hThreadParent,0,NULL);
    DuplicateHandle(GetCurrentProcess(),GetCurrentThread(),GetCurrentProcess(),&hThreadParent,
        0,false,DUPLICATE_SAME_ACCESS);
    _beginthreadex(NULL,0,ChildThread,(PVOID)hThreadParent,0,NULL);

��果�?/a> 2010-04-28 10:59 发表评论

枚�D应用�E�序(转蝲microsoft)

Tue, 27 Apr 2010 04:47:00 GMT
     摘要: Code highlighting produced by Actipro CodeHighlighter (freeware)http://www.CodeHighlighter.com/-->枚�D��层�H�口如果��枚举进�E�与枚�D桌面上的��层�H�口�q�行比较�Q�那么枚��N��层窗口可能更�Ҏ��一些。要枚�D��层�H�口�Q�请使用 EnumWindows() 函数。不要��?nbsp;GetWindo...  阅读全文

��果�?/a> 2010-04-27 12:47 发表评论

操作�pȝ��版本

Tue, 27 Apr 2010 03:10:00 GMT

#include <windows.h>
#include <stdio.h>

BOOL IsWin7 ()
{
   OSVERSIONINFOEX osvi;
   DWORDLONG dwlConditionMask = 0;
   int op=VER_GREATER;

   // Initialize the OSVERSIONINFOEX structure.

   ZeroMemory(&osvi, sizeof(OSVERSIONINFOEX));
   osvi.dwOSVersionInfoSize = sizeof(OSVERSIONINFOEX);
   osvi.dwMajorVersion = 6;
   osvi.dwMinorVersion = 1;

   // Initialize the condition mask.

   VER_SET_CONDITION( dwlConditionMask, VER_MAJORVERSION, op );
   VER_SET_CONDITION( dwlConditionMask, VER_MINORVERSION, op );


   // Perform the test.

   return VerifyVersionInfo(
      &osvi,
      VER_MAJORVERSION | VER_MINORVERSION,
      dwlConditionMask);
}

void main()
{
    if(IsWin7())
        printf("yes.\n");
    else{
        printf("no.\n");
    }
}

��果�?/a> 2010-04-27 11:10 发表评论

�q�程环境变量

Tue, 27 Apr 2010 02:47:00 GMT

#include <iostream>
#include <windows.h>
#include <iostream>
#include <psapi.h>
#include <sstream>
#include <fstream>

using namespace std;

int _tmain(int argc, _TCHAR* argv[],TCHAR* envp[])
{
    //PTSTR pEnvBlock=::GetEnvironmentStrings();
    //TCHAR szName[MAX_PATH];
    //TCHAR szValue[MAX_PATH];
    int current=0;
    PTSTR* pElement =(PTSTR*) envp;
    PTSTR pCurrent=NULL;
    while(pElement!=NULL){
        pCurrent=(PTSTR)(*pElement);
        if(pCurrent==NULL){
            pElement=NULL;
        }else{
            _tprintf(TEXT("[%u] %s\r\n"),current,pCurrent);
            current++;
            pElement++;
        }
    }
}

��果�?/a> 2010-04-27 10:47 发表评论

Wed, 11 Mar 2009 05:15:00 GMT

1#include <iostream>
2#include <windows.h>
3#include <fstream>
4
5using namespace std;
6int _tmain(int argc, _TCHAR* argv[])
7{
8    HANDLE hWrite,hRead;
9    SECURITY_ATTRIBUTES sa;
10    sa.bInheritHandle=true;
11    sa.nLength=sizeof(sa);
12    sa.lpSecurityDescriptor=NULL;
13
14    HANDLE input=CreateFile(L"in.txt",GENERIC_READ,NULL,&sa,OPEN_EXISTING,FILE_ATTRIBUTE_NORMAL,NULL);
15    HANDLE output=CreateFile(L"out.txt",GENERIC_WRITE|GENERIC_READ,NULL,&sa,OPEN_ALWAYS,FILE_ATTRIBUTE_NORMAL,NULL);
16
17    //::CreatePipe(&hRead,&hWrite,&sa,0);
18    STARTUPINFO si;
19    ZeroMemory(&si,sizeof(si));
20    si.cb=sizeof(si);
21    ::GetStartupInfo(&si);
22    si.dwFlags = STARTF_USESHOWWINDOW | STARTF_USESTDHANDLES;
23    si.hStdError=0;
24    si.hStdInput=input;
25    si.hStdOutput=output;
26    si.wShowWindow=SW_HIDE;
27
28    PROCESS_INFORMATION pi;
29
30    CreateProcess(L"..\\Debug\\test.exe",0,0,0,true,0,0,0,&si,&pi);
31    //::CloseHandle(hWrite);
32    WaitForSingleObject(pi.hProcess,INFINITE);
33    CloseHandle(input);
34    CloseHandle(output);
35    //char mm[1000];
36    //memset(mm,0,sizeof(mm));
37    //DWORD d;
38    //ReadFile(hRead,mm,1000,&d,0);
39
40    //cout<
41
42    return 0;
43}

��果�?/a> 2009-03-11 13:15 发表评论

win32-�W�记

Mon, 25 Aug 2008 08:05:00 GMT

1.创徏DirectDraw对象的方�?创徏主DirectDraw对象�q��用QueryInterface()得到一个IDirectDraw7接口.
或者直接用DirectDrawCreateEx()创徏一个DirectDraw7的接�?
HRESULT WINAPI DirectDrawCreate(GUID FAR *lpGUID,//guid of object
LPDIRECTDRAW FAR *lplpDD,//receives interface
IUnknown FAR *pUnkOuter);//com stuff
LpGUID--NULL,(视频卡驱动的Globally Unique Identifier)
lplpDD--�q�回一个DirectDraw的接口而不是DirectDraw7的接�?
pUnkOuter--NULL(always set to zero)

自行发送消�?
1.SendMessage()---send a message which is processed immediately to a window.In fact,
it calls WinProc().
LRESULT SendMessage(HWND hWnd,UINT,WPARAM,LPARAM);

2.PostMessage()---send a message to the messagequeue.just that.if it's succeed,it return a value(!0).
BOOL PostMessage(HWND hWnd,UINT Msg,WPARAM wParam,LPARAM lParam);

1.SetBkMode(hdc,TRANSPARENT);
2.FillRect(hdc,&r,(HBRUSH)GetStockObject(WHITE_BRUSH));
3.CreateSolidBrush(RGB(255,0,0));
4.wchar_t tmp[20];
    GetDlgItemText(hDlg,IDC_EDIT1,tmp,20);
    ::wstringstream is;
    is<<tmp;
    is>>size;
5.InvalidateRect(hWnd,0,1);
6.DialogBox(hInst, MAKEINTRESOURCE(IDD_DIALOG1), hWnd, inputsize);
7.WM_CLOSE is sent before WM_DESTYOY.

//创徏全屏(�I�白)模式�H�口:
if(!(hWnd = CreateWindowEx(NULL,//extend style
WINDOW_CLASS_NAME,//class
"BX",//title
WS_POP|WS_VISIBLE,
0,0,//initial x,y
GetSystemMetrics(SM_CXSCREEN),//Initial width
GetSystemMetrics(SM_CYSCREEN),//Initial height
NULL,//handle to parent
NULL,//handle to menu
hinstance,//instance of this application
NULL)))//extra creation parms
return (0);

��果�?/a> 2008-08-25 16:05 发表评论