久久免费香蕉视频,一本久久知道综合久久,久久久久国产一区二区三区

Relocate SVN

shaker(太子) — Wed, 28 Dec 2011 05:59:00 GMT

自己搞点��东西用的到�?br />在工�E�的根目录里��Z��个svn目录�Q�然后在svn目录里创��Z��个版本库�Q�用svn��Z��下�?br />�q�样�q�个工程��可以被svn��理了�?br />但是如果整个工程被移动过了，那么svn��׃��出错�Q�于是写了个��程序来重定位，从此可以把工�E�放在u盘带着到处跑了�?br />

1 #include "stdafx.h"
  2
  3 using namespace std;
  4
  5 void AlertError(DWORD err)
  6 {
  7     LPVOID lpMsgBuf;
  8     LPVOID lpDisplayBuf;
  9
10     FormatMessage(
11         FORMAT_MESSAGE_ALLOCATE_BUFFER |
12         FORMAT_MESSAGE_FROM_SYSTEM |
13         FORMAT_MESSAGE_IGNORE_INSERTS,
14         NULL,
15         err,
16         MAKELANGID(LANG_NEUTRAL, SUBLANG_DEFAULT),
17         (LPTSTR) &lpMsgBuf,
18         0, NULL );
19
20     lpDisplayBuf = (LPVOID)LocalAlloc(LMEM_ZEROINIT,
21         strlen((char*)lpMsgBuf) + 40);
22     sprintf((char*)lpDisplayBuf,"错误�? %d\n信　�? %s", err,lpMsgBuf);
23     MessageBox(NULL, (LPCTSTR)lpDisplayBuf, "错误", MB_OK|MB_ICONERROR);
24
25     LocalFree(lpMsgBuf);
26     LocalFree(lpDisplayBuf);
27 }
28
29 void GetCommandOutput(char* CmdLine, string& strOutput, bool IncludeErr=false)
30 {
31     strOutput="";
32     SECURITY_ATTRIBUTES  sa;
33     HANDLE hRead, hWrite;
34     memset(&sa,0,sizeof(sa));
35     sa.nLength=sizeof(sa);
36     sa.bInheritHandle=TRUE;
37     sa.lpSecurityDescriptor=NULL;
38     if(CreatePipe(&hRead,&hWrite,&sa,0))
39     {
40         STARTUPINFO si;
41         memset(&si,0,sizeof(si));
42         si.cb=sizeof(si);
43         si.hStdOutput=hWrite;
44         si.hStdInput=GetStdHandle(STD_INPUT_HANDLE);
45         si.hStdError=(IncludeErr?hWrite:GetStdHandle(STD_ERROR_HANDLE));
46         si.dwFlags=STARTF_USESTDHANDLES|STARTF_USESHOWWINDOW;
47         si.wShowWindow=SW_HIDE;
48
49         PROCESS_INFORMATION pi;
50         if(CreateProcess(NULL,CmdLine,&sa,&sa,TRUE,CREATE_NO_WINDOW|NORMAL_PRIORITY_CLASS,
51             NULL,NULL,&si,&pi))
52         {
53             char szBuf[512];
54             DWORD dwReaded;
55             if(WaitForSingleObject(pi.hProcess,INFINITE)!=WAIT_TIMEOUT)
56             {
57                 CloseHandle(hWrite);
58                 while(ReadFile(hRead,szBuf,511,&dwReaded,NULL))
59                 {
60                     szBuf[dwReaded]='\0';
61                     strOutput+=szBuf;
62                 }
63             }
64             else
65             {
66                 cout<<"WaitForSingleObject错误;"< 67                 CloseHandle(hWrite);
68                 AlertError(GetLastError());
69             }
70             CloseHandle(pi.hThread);
71             CloseHandle(pi.hProcess);
72         }
73         else
74         {
75             cout<<"建立�q�程错误;"< 76             AlertError(GetLastError());
77         }
78         CloseHandle(hRead);
79     }
80     else
81     {
82         cout<<"建立��道错误;"< 83         AlertError(GetLastError());
84     }
85 }
86
87 int APIENTRY WinMain(HINSTANCE hInstance,
88                      HINSTANCE hPrevInstance,
89                      LPSTR     lpCmdLine,
90                      int       nCmdShow)
91 {
92     char szBuf[MAX_PATH+20];
93     wchar_t wcBuf[MAX_PATH];
94     int i, j;
95     string msg;
96
97     GetCommandOutput("svn info --xml",msg);
98     TiXmlDocument *doc = new TiXmlDocument();
99     doc->Parse(msg.c_str());
100     TiXmlNode *node;
101     node=doc->FirstChild("info");
102     if(node==NULL)
103     {
104         MessageBox(NULL,"当前目录没有被SVN","�l�果",MB_OK|MB_ICONINFORMATION);
105         return 0;
106     }
107     node=node->FirstChild("entry");
108     if(node==NULL)
109     {
110         MessageBox(NULL,"当前目录没有被SVN","�l�果",MB_OK|MB_ICONINFORMATION);
111         return 0;
112     }
113     node=node->FirstChild("wc-info");
114     if(node==NULL)
115     {
116         MessageBox(NULL,"当前目录没有被SVN","�l�果",MB_OK|MB_ICONINFORMATION);
117         return 0;
118     }
119     node=node->FirstChild("wcroot-abspath");
120     if(node==NULL)
121     {
122         MessageBox(NULL,"当前目录没有被SVN","�l�果",MB_OK|MB_ICONINFORMATION);
123         return 0;
124     }
125     strcpy(szBuf,node->ToElement()->GetText());
126     delete node;
127     delete doc;
128
129     j=strlen(szBuf);
130     i=MultiByteToWideChar(CP_UTF8,0,szBuf,j,wcBuf,MAX_PATH);
131     wcBuf[i]=static_cast(0);
132     strcpy(szBuf,"svn relocate file:///");
133     j=strlen(szBuf);
134     i=WideCharToMultiByte(CP_ACP,0,wcBuf,i,&szBuf[j],MAX_PATH,NULL,NULL);
135     szBuf[i+j]=static_cast<char>(0);
136     SetCurrentDirectory(&szBuf[j]);
137
138     i+=j;
139     if((szBuf[i-1]=='\\')||(szBuf[i-1]=='/'))
140         strcat(szBuf,"svn/");
141     else
142         strcat(szBuf,"/svn/");
143     for(i=0,j=strlen(szBuf);i 144     {
145         if(szBuf[i]=='\\')
146             szBuf[i]='/';
147     }
148
149     GetCommandOutput(szBuf,msg,true);
150     MessageBox(NULL,msg.c_str(),"�l�果",MB_OK);
151
152     return 0;
153 }

shaker(太子) 2011-12-28 13:59 发表评论

又是一个APIHOOK

shaker(太子) — Sun, 31 Jul 2011 07:21:00 GMT

摘要: API Hook 阅读全文

shaker(太子) 2011-07-31 15:21 发表评论

[zt] Windows APC机制

shaker(太子) — Thu, 05 May 2011 04:09:00 GMT

异步�q�程调用(APCs) 是NT异步处理体系�l�构中的一个基��部分�Q�理解了它，对于了解NT怎样操作和执行几个核心的�pȝ��操作很有帮助�?/p>

1) APCs允许用户�E�序和系�l�元件在一个进�E�的地址�I�间内某个线�E�的上下文中执行代码�?br>2) I/O��理器��用APCs来完成一个线�E�发��L��异步的I/O操作。例如：当一个设备驱动调用IoCompleteRequest来通知I/O��理器，它已�l�结束处理一个异步I/O��h��Ӟ��I/O��理器排队一个apc到发赯��求的�U�程。然后线�E�在一个较低IRQL�U�别�Q�来执行APC. APC的作用是从系�l�空间拷贝I/O操作�l�果和状态信息到�U�程虚拟内存�I�间的一个缓冲中�?br>3) 使用APC可以得到或者设�|�一个线�E�的上下文和挂�v�U�程的执行�?/p>

上面是网上找来的�Q�下面是MSDN上的说明�Q?/p>

An asynchronous procedure call (APC) is a function that executes asynchronously in the context of a particular thread. When an APC is queued to a thread, the system issues a software interrupt. The next time the thread is scheduled, it will run the APC function. An APC generated by the system is called a kernel-mode APC. An APC generated by an application is called a user-mode APC. A thread must be in an alertable state to run a user-mode APC.

Each thread has its own APC queue. An application queues an APC to a thread by calling the QueueUserAPC function. The calling thread specifies the address of an APC function in the call to QueueUserAPC. The queuing of an APC is a request for the thread to call the APC function.

�q�先看一下那些重要结构：

kd> dt KTHREAD
nt!KTHREAD
+0x000 Header : _DISPATCHER_HEADER
+0x010 MutantListHead : _LIST_ENTRY
+0x018 InitialStack : Ptr32 Void
+0x01c StackLimit : Ptr32 Void
+0x020 KernelStack : Ptr32 Void
+0x024 ThreadLock : Uint4B
+0x028 ApcState : _KAPC_STATE
+0x028 ApcStateFill : [23] UChar
+0x03f ApcQueueable : UChar
+0x040 NextProcessor : UChar
+0x041 DeferredProcessor : UChar
+0x042 AdjustReason : UChar
+0x043 AdjustIncrement : Char
+0x044 ApcQueueLock : Uint4B
+0x048 ContextSwitches : Uint4B
+0x04c State : UChar
+0x04d NpxState : UChar
+0x04e WaitIrql : UChar
+0x04f WaitMode : Char
+0x050 WaitStatus : Int4B
+0x054 WaitBlockList : Ptr32 _KWAIT_BLOCK
+0x054 GateObject : Ptr32 _KGATE
+0x058 Alertable : UChar
+0x059 WaitNext : UChar
+0x05a WaitReason : UChar
+0x05b Priority : Char
+0x05c EnableStackSwap : UChar
+0x05d SwapBusy : UChar
+0x05e Alerted : [2] UChar
+0x060 WaitListEntry : _LIST_ENTRY
+0x060 SwapListEntry : _SINGLE_LIST_ENTRY
+0x068 Queue : Ptr32 _KQUEUE
+0x06c WaitTime : Uint4B
+0x070 KernelApcDisable : Int2B
+0x072 SpecialApcDisable : Int2B
+0x070 CombinedApcDisable : Uint4B
+0x074 Teb : Ptr32 Void
+0x078 Timer : _KTIMER
+0x078 TimerFill : [40] UChar
+0x0a0 AutoAlignment : Pos 0, 1 Bit
+0x0a0 DisableBoost : Pos 1, 1 Bit
+0x0a0 ReservedFlags : Pos 2, 30 Bits
+0x0a0 ThreadFlags : Int4B
+0x0a8 WaitBlock : [4] _KWAIT_BLOCK
+0x0a8 WaitBlockFill0 : [23] UChar
+0x0bf SystemAffinityActive : UChar
+0x0a8 WaitBlockFill1 : [47] UChar
+0x0d7 PreviousMode : Char
+0x0a8 WaitBlockFill2 : [71] UChar
+0x0ef ResourceIndex : UChar
+0x0a8 WaitBlockFill3 : [95] UChar
+0x107 LargeStack : UChar
+0x108 QueueListEntry : _LIST_ENTRY
+0x110 TrapFrame : Ptr32 _KTRAP_FRAME
+0x114 CallbackStack : Ptr32 Void
+0x118 ServiceTable : Ptr32 Void
+0x11c ApcStateIndex : UChar
+0x11d IdealProcessor : UChar
+0x11e Preempted : UChar
+0x11f ProcessReadyQueue : UChar
+0x120 KernelStackResident : UChar
+0x121 BasePriority : Char
+0x122 PriorityDecrement : Char
+0x123 Saturation : Char
+0x124 UserAffinity : Uint4B
+0x128 Process : Ptr32 _KPROCESS
+0x12c Affinity : Uint4B
+0x130 ApcStatePointer : [2] Ptr32 _KAPC_STATE
+0x138 SavedApcState : _KAPC_STATE
+0x138 SavedApcStateFill : [23] UChar
+0x14f FreezeCount : Char
+0x150 SuspendCount : Char
+0x151 UserIdealProcessor : UChar
+0x152 CalloutActive : UChar
+0x153 Iopl : UChar
+0x154 Win32Thread : Ptr32 Void
+0x158 StackBase : Ptr32 Void
+0x15c SuspendApc : _KAPC
+0x15c SuspendApcFill0 : [1] UChar
…………

…………

上面�U�色部分是APC机制用到的几个字�D�！�Q?/p>

kd> dt _KAPC_STATE
nt!_KAPC_STATE
+0x000 ApcListHead : [2] _LIST_ENTRY�Q�每个指针指向_KAPC�l�构
+0x010 Process : Ptr32 _KPROCESS
+0x014 KernelApcInProgress : UChar
+0x015 KernelApcPending : UChar
+0x016 UserApcPending : UChar

昄��Q�这里的 ApcListHead ��是 APC 队列头。不�q�这是个大小�?2 的数�l�，说明实际
�?每个�U�程)有两�?APC 队列。这是因�?APC 函数分�ؓ用户 APC 和内�?APC 两种�Q�各�?br>各的队列。所谓用�?APC�Q�是指相应的 APC 函数位于用户�I�间、在用户�I�间执行�Q�而内�?br>APC�Q�则相应�?APC 函数为内核函数�?/p>

SavedApcState也是个_KAPC_STATE�l�构�Q�当当前�E�暂�?#8220;挂靠(Attach)”到另一个进�E�的地址�I�间的时侯，ApcState��拷贝到SavedApcState暂时存放�Q?/p>

当然�Q�还要有状态信息说明本�U�程当前是处�?#8220;原始环境”�q�是“挂靠环境”�Q�这��是 ApcStateIndex 的作用，代码中�ؓ ApcStateIndex的值定义了一�U�枚丄��型：

typedef enum _KAPC_ENVIRONMENT {
OriginalApcEnvironment,
AttachedApcEnvironment,
CurrentApcEnvironment,
InsertApcEnvironment
} KAPC_ENVIRONMENT;

实际可用�?ApcStateIndex 的只�?OriginalApcEnvironment�?AttachedApcEnvironment�?/p>

KAPC_STATE 指针数组 ApcStatePointer[2]�Q�就用ApcStateIndex 的当前��g��Z��标，而数�l�中的指针则�Ҏ��情况可以分别指向两个APC_STATE 数据�l�构中的一个�?/p>

kd> dt _KAPC ;APC对象
nt!_KAPC
+0x000 Type : UChar
+0x001 SpareByte0 : UChar
+0x002 Size : UChar
+0x003 SpareByte1 : UChar
+0x004 SpareLong0 : Uint4B
+0x008 Thread : Ptr32 _KTHREAD
+0x00c ApcListEntry : _LIST_ENTRY
+0x014 KernelRoutine : Ptr32 void
+0x018 RundownRoutine : Ptr32 void
+0x01c NormalRoutine : Ptr32 void
+0x020 NormalContext : Ptr32 Void
+0x024 SystemArgument1 : Ptr32 Void
+0x028 SystemArgument2 : Ptr32 Void
+0x02c ApcStateIndex : Char
+0x02d ApcMode : Char
+0x02e Inserted : UChar

KernelRoutine、RundownRoutine、NormalRoutine。其中只�?NormalRoutine才指�?执行)APC 函数的请求者所提供的函敎ͼ�其余两个都是辅助性的�Q?/p>

NTKERNELAPI
VOID
KeInitializeApc (
__out PRKAPC Apc,
__in PRKTHREAD Thread,
__in KAPC_ENVIRONMENT Environment,
__in PKKERNEL_ROUTINE KernelRoutine,
__in_opt PKRUNDOWN_ROUTINE RundownRoutine,
__in_opt PKNORMAL_ROUTINE NormalRoutine,
__in_opt KPROCESSOR_MODE ProcessorMode,
__in_opt PVOID NormalContext
);

�q�个函数主要用来初始化Apc�Q�_KAPC�Q�这个结构的�Q�如果Environment==CurrentApcEnvironment,Apc->ApcStateIndex��q��KTHREAD中的ApcStateIndex军_��Q�但Environment不能大于KTHREAD中的ApcStateIndex�Q?/p>

最后，APC ��h��的模式ProcessorMode�Q�但是有个例外，那就是：如果指针NormalRoutine �?0�Q�那么实际的模式变成�?KernelMode。这是因为在�q�种情况下没有用��L��间APC函数可以执行�Q?唯一��得到执行的是KernelRoutine�Q?/p>

最后，KeInitializeApc 讄��Inserted域�ؓFALSE。然而初始化APC对象�Q��ƈ没有把它存放到相应的APC队列中�?/p>

NTKERNELAPI
BOOLEAN
KeInsertQueueApc (
__inout PRKAPC Apc,
__in_opt PVOID SystemArgument1,
__in_opt PVOID SystemArgument2,
__in KPRIORITY Increment
);

据APC��h��的具体情况，有时候要插在队列的前��_��一般则挂在队列的尾部�?/p>

_KiServiceExit:

cli ; disable interrupts
DISPATCH_USER_APC ebp, ReturnCurrentEax

;
; Exit from SystemService
;

EXIT_ALL NoRestoreSegs, NoRestoreVolatile ;�q�个宏以后再�?/p>

DISPATCH_USER_APC macro TFrame, ReturnCurrentEax
local a, b, c
c:
.errnz (EFLAGS_V86_MASK AND 0FF00FFFFh)

test byte ptr [TFrame]+TsEflags+2, EFLAGS_V86_MASK/010000h ; is previous mode v86?
jnz short b ; if nz, yes, go check for APC
test byte ptr [TFrame]+TsSegCs,MODE_MASK ; is previous mode user mode?
jz a ; No, previousmode=Kernel, jump out
b: mov ebx, PCR[PcPrcbData+PbCurrentThread]; get addr of current thread
mov byte ptr [ebx]+ThAlerted, 0 ; clear kernel mode alerted
cmp byte ptr [ebx]+ThApcState.AsUserApcPending, 0
je a ; if eq, no user APC pending

mov ebx, TFrame
ifnb ;条�g宏汇�~�，如果ReturnCurrentEax参数不�ؓ�I�，则编译！

;DISPATCH_USER_APC ebp, ReturnCurrentEax�Q�显然这里是�~�译的！
mov [ebx].TsEax, eax ; Store return code in trap frame
mov dword ptr [ebx]+TsSegFs, KGDT_R3_TEB OR RPL_MASK
mov dword ptr [ebx]+TsSegDs, KGDT_R3_DATA OR RPL_MASK
mov dword ptr [ebx]+TsSegEs, KGDT_R3_DATA OR RPL_MASK
mov dword ptr [ebx]+TsSegGs, 0
endif

;
; Save previous IRQL and set new priority level
;
RaiseIrql APC_LEVEL
push eax ; Save OldIrql

sti ; Allow higher priority ints

;
; call the APC delivery routine.
;
; ebx - Trap frame
; 0 - Null exception frame
; 1 - Previous mode
;
; call APC deliver routine
;

stdCall _KiDeliverApc, <1, 0, ebx> ;1��是UserMode

pop ecx ; (ecx) = OldIrql
LowerIrql ecx

ifnb ;同上分析
mov eax, [ebx].TsEax ; Restore eax, just in case
endif

cli
jmp b ; 注意�q�个循环�Q�！

ALIGN 4
a:
endm

�q�段代码主要��查：

卛_��q�回的是否用��L��间�?br>是否有用户APC��h��正在�{�待执行

条�g�W�合才用KiDeliverApc真正投递APC。注意代码jmp b�Q�好像在�q�回用户�I�间前KiDeliverApc会被循环调用直到没有user APC�Q�其实不是的�Q�KiDeliverApc每处理完一个User APC��把UserApcPending清零�Q�所以User APCs在返回用��L��间时�q�是只能投递一�ơ！KiDeliverApc中用while处理完所有Kernel Mode APCs�Q�但User Mode APC却只处理一个！事实上User APC的投递是很特�D�的�Q�以后会讲到�Q�而且每次只能投递一�ơ！

前面讲过�Q�KTHREAD 中有两个 KAPC_STATE 数据�l�构�Q�一个是 ApcState�Q�另一个是SavedApcState�Q�二者都有APC 队列�Q�但是要投递的只是ApcState 中的队列�?/p>

KiDeliverApc (
IN KPROCESSOR_MODE PreviousMode,//写成DeliverMode不是更好
IN PKEXCEPTION_FRAME ExceptionFrame,//�q�个参数几乎��是0
IN PKTRAP_FRAME TrapFrame
)

�q�个函数里面�q�比较复杂，代码不帖了�?/p>

参数PreviousMode表示需�?#8220;投�?#8221;哪一�U?APC�Q�可以是UserMode�Q�也可以是KernelMode。不�q�，KernelMode ��实表示只要求执行内�?APC�Q�而UserMode 却表�C�在执行内核 APC 之外再执行用户APC�?/p>

The Windows operating system uses three kinds of APCs:

User APCs run strictly in user mode and only when the current thread is in an alertable wait state. The operating system uses user APCs to implement mechanisms such as overlapped I/O and the QueueUserApc Win32 routine. �Q�run IRQL = PASSIVE_LEVEL�Q?br>Normal kernel APCs run in kernel mode at IRQL = PASSIVE_LEVEL. A normal kernel APC preempts all user-mode code, including user APCs. Normal kernel APCs are generally used by file systems and file-system filter drivers.
Special kernel APCs run in kernel mode at IRQL = APC_LEVEL. A special kernel APC preempts user-mode code and kernel-mode code that executes at IRQL = PASSIVE_LEVEL, including both user APCs and normal kernel APCs. The operating system uses special kernel APCs to handle operations such as I/O request completion.
从代码的角度看是�q�样的：

User APCs
_KAPC.ApcMode==UserMode,_KAPC.KernelRoutine!=NULL,_KAPC.NormolRoutine!=NULL

Normal kernel APCs

_KAPC.ApcMode==KernelMode,_KAPC.KernelRoutine!=NULL,_KAPC.NormolRoutine!=NULL

Special kernel APCs

_KAPC.ApcMode==KernelMode,_KAPC.KernelRoutine!=NULL,_KAPC.NormolRoutine==NULL

有一点它们的_KAPC.KernelRoutine肯定不�ؓ�I�。�ƈ且，如果NormolRoutine也不为空�Q�那么KernelRoutine都在NormolRoutine被调用前被调用！�Q?/p>

上文中讲到投递User Mode APCs是很�Ҏ��的，道理很简单，因�ؓUser Mode APC是ring3下的回调函数�Q�显然ring0中的KiDeliverAPC�Q�）不能像Kernel Mode APC那样直接call�Q�必��要先回到ring3环境下。当然不能像普通情况那栯��回（否则��回到ring3�pȝ��调用的地方了�Q�，只有一个办法，那就是修改TrapFrame �Q�欺骗系�l�返�?#8220;APC回调函数”�Q�KiInitializeUserApc��是�q�么做的�Q?/p>

该函数首先把TrapFrame转化为ContextFrame�Q�然后移动用��h��ESP指针�Q�分配大�U�sizeof�Q�CONTEXT�Q?sizeof�Q�KAPC_RECORD�Q�个字节:

UserStack-> ……

KAPC_RECORD

……

CONTEXT

TopOfStack-> ……

KAPC_RECORD��是KiInitializeUserApc的最后四个参�?/p>

nt!_KAPC_RECORD

+0x000 NormalRoutine : Ptr32 void

+0x004 NormalContext : Ptr32 Void

+0x008 SystemArgument1 : Ptr32 Void

+0x00c SystemArgument2 : Ptr32 Void

CONTEXT�l�构主要来存放被修改前的TrapFrame�Q�之所以用CONTEXT�l�构是跟APC函数�q�回有关�Q?/p>

TrapFrame->HardwareEsp = UserStack;

TrapFrame->Eip = (ULONG)KeUserApcDispatcher;

TrapFrame->ErrCode = 0;

从上面的代码看到��实修改了TrapFrame�Q��ƈ且返回到的是ring3下的KeUserApcDispatcher�Q�刚才说的_KAPC_RECORD其实也是它的参数�Q�真正我们的User APC回调函数是由KeUserApcDispatcher调用的！

.func KiUserApcDispatcher@16

.globl _KiUserApcDispatcher@16

_KiUserApcDispatcher@16:

/* Setup SEH stack */

lea eax, [esp+CONTEXT_ALIGNED_SIZE+16]

mov ecx, fs:[TEB_EXCEPTION_LIST]

mov edx, offset _KiUserApcExceptionHandler

mov [eax], ecx

mov [eax+4], edx

/* Enable SEH */

mov fs:[TEB_EXCEPTION_LIST], eax

/* Put the Context in EDI */

pop eax

lea edi, [esp+12]

/* Call the APC Routine */

call eax

/* Restore exception list */

mov ecx, [edi+CONTEXT_ALIGNED_SIZE]

mov fs:[TEB_EXCEPTION_LIST], ecx

/* Switch back to the context */

push 1 ; TestAlert

push edi ;edi->CONTEXT�l�构

call _ZwContinue@8

;;不会�q�回到这里的

上面的代码�ƈ不难理解�Q�我们的User APC回调函数�q�回后，立即调用了ZwContinue�Q�这是个ntdll中的导出函数�Q�这个函数又通过�pȝ��调用�q�入kernel中的NtContinue�Q?/p>

NTSTATUS

; NtContinue (

; IN PCONTEXT ContextRecord,

; IN BOOLEAN TestAlert

; )

;

; Routine Description:

;

; This routine is called as a system service to continue execution after

; an exception has occurred. Its function is to transfer information from

; the specified context record into the trap frame that was built when the

; system service was executed, and then exit the system as if an exception

; had occurred.

;

; WARNING - Do not call this routine directly, always call it as

; ZwContinue!!! This is required because it needs the

; trapframe built by KiSystemService.

;

; Arguments:

;

; KTrapFrame (ebp+0: after setup) -> base of KTrapFrame

;

; ContextRecord (ebp+8: after setup) = Supplies a pointer to a context rec.

;

; TestAlert (esp+12: after setup) = Supplies a boolean value that specifies

; whether alert should be tested for the previous processor mode.

;

; Return Value:

;

; Normally there is no return from this routine. However, if the specified

; context record is misaligned or is not accessible, then the appropriate

; status code is returned.

;

;--

NcTrapFrame equ [ebp + 0]

NcContextRecord equ [ebp + 8]

NcTestAlert equ [ebp + 12]

align dword

cPublicProc _NtContinue ,2

push ebp ;ebp->TrapFrame

;

; Restore old trap frame address since this service exits directly rather

; than returning.

;

mov ebx, PCR[PcPrcbData+PbCurrentThread] ; get current thread address

mov edx, [ebp].TsEdx ; restore old trap frame address

mov [ebx].ThTrapFrame, edx ;

;

; Call KiContinue to load ContextRecord into TrapFrame. On x86 TrapFrame

; is an atomic entity, so we don't need to allocate any other space here.

;

; KiContinue(NcContextRecord, 0, NcTrapFrame)

;

mov ebp,esp

mov eax, NcTrapFrame

mov ecx, NcContextRecord

stdCall _KiContinue,

or eax,eax ; return value 0?

jnz short Nc20 ; KiContinue failed, go report error

;

; Check to determine if alert should be tested for the previous processor mode.

;

cmp byte ptr NcTestAlert,0 ; Check test alert flag

je short Nc10 ; if z, don't test alert, go Nc10

mov al,byte ptr [ebx]+ThPreviousMode ; No need to xor eax, eax.

stdCall _KeTestAlertThread, ; test alert for current thread

;如果User APCs不�ؓ�I�，它会讄��UserApcPending,

;跟Alertable无关

Nc10: pop ebp ; (ebp) -> TrapFrame

mov esp,ebp ; (esp) = (ebp) -> trapframe

jmp _KiServiceExit2 ; common exit

Nc20: pop ebp ; (ebp) -> TrapFrame

mov esp,ebp ; (esp) = (ebp) -> trapframe

jmp _KiServiceExit ; common exit

stdENDP _NtContinue

NtContinue把CONTEXT�l�构转化成TrapFrame�Q�回复原来的陷阱帧）�Q�然后就从KiServiceExit2处退出系�l�调用！

;++

;

; _KiServiceExit2 - same as _KiServiceExit BUT the full trap_frame

; context is restored

;

;--

public _KiServiceExit2

_KiServiceExit2:

cli ; disable interrupts

DISPATCH_USER_APC ebp

;

; Exit from SystemService

;

EXIT_ALL ; RestoreAll

KiServiceExit2跟KiServiceExit差不多，只是宏参数的不同!同样如果�q�有User APC又会�q�入上文描述的情形，直到没有User APC�Q�至此才会返回真正发起原始系�l�调用的地方�Q?/p>

本文来自CSDN博客�Q��{载请标明出处�Q?a >http://blog.csdn.net/better0332/archive/2009/06/29/4306683.aspx

shaker(太子) 2011-05-05 12:09 发表评论

shaker(太子) — Thu, 05 May 2011 03:46:00 GMT

异步�q�程调用(APCs) 是NT异步处理体系�l�构中的一个基��部分�Q�理解了它，对于了解NT怎样操作和执行几个核心的�pȝ��操作很有帮助�?br style="PADDING-BOTTOM: 0px; MARGIN: 0px; PADDING-LEFT: 0px; PADDING-RIGHT: 0px; PADDING-TOP: 0px">
1) APCs允许用户�E�序和系�l�元件在一个进�E�的地址�I�间内某个线�E�的上下文中执行代码�?br style="PADDING-BOTTOM: 0px; MARGIN: 0px; PADDING-LEFT: 0px; PADDING-RIGHT: 0px; PADDING-TOP: 0px">2) I/O��理器��用APCs来完成一个线�E�发��L��异步的I/O操作。例如：当一个设备驱动调用IoCompleteRequest来通知I/O��理器，它已�l�结束处理一个异步I/O��h��Ӟ��I/O��理器排队一个apc到发赯��求的�U�程。然后线�E�在一个较低IRQL�U�别�Q�来执行APC. APC的作用是从系�l�空间拷贝I/O操作�l�果和状态信息到�U�程虚拟内存�I�间的一个缓冲中�?br style="PADDING-BOTTOM: 0px; MARGIN: 0px; PADDING-LEFT: 0px; PADDING-RIGHT: 0px; PADDING-TOP: 0px">3) 使用APC可以得到或者设�|�一个线�E�的上下文和挂�v�U�程的执行�?br style="PADDING-BOTTOM: 0px; MARGIN: 0px; PADDING-LEFT: 0px; PADDING-RIGHT: 0px; PADDING-TOP: 0px">
��管APCs在nt体系�l�构下被�q�泛使用�Q�但是关于怎样使用它的文��却非常的�~�Z��。本��我们详�l�介�l�下nt�pȝ��是怎样处理APCs的，�q�且记录导出的nt函数�Q�方便设备驱动开发者在他们的程序中使用APCs。我也会展示一个非常可靠的NT的APC调度子程序KiDeliverApc的实玎ͼ�来帮助你更好的掌握APC调度的内�q��?br style="PADDING-BOTTOM: 0px; MARGIN: 0px; PADDING-LEFT: 0px; PADDING-RIGHT: 0px; PADDING-TOP: 0px">
APC对象

在NT中，有两�U�类型的APCs�Q�用��h��式和内核模式。用户APCs�q�行在用��h��式下目标�U�程当前上下文中�Q��ƈ且需要从目标�U�程得到许可来运行。特别是�Q�用��h��式的APCs需要目标线�E�处在alertable�{�待状态才能被成功的调度执行。通过调用下面��L��一个函敎ͼ�都可以让�U�程�q�入�q�种状态。这些函数是�Q�KeWaitForSingleObject, KeWaitForMultipleObjects, KeWaitForMutexObject, KeDelayExecutionThread�?br style="PADDING-BOTTOM: 0px; MARGIN: 0px; PADDING-LEFT: 0px; PADDING-RIGHT: 0px; PADDING-TOP: 0px">对于用户模式下，可以调用函数SleepEx, SignalObjectAndWait, WaitForSingleObjectEx, WaitForMultipleObjectsEx,MsgWaitForMultipleObjectsEx 都可以��目标�U�程处于alertable�{�待状态，从而让用户模式APCs执行,原因是这些函数最�l�都是调用了内核中的KeWaitForSingleObject, KeWaitForMultipleObjects, KeWaitForMutexObject, KeDelayExecutionThread�{�函数。另外通过调用一个未公开的alert-test服务KeTestAlertThread�Q�用��L��E�可以��用户模式APCs执行�?br style="PADDING-BOTTOM: 0px; MARGIN: 0px; PADDING-LEFT: 0px; PADDING-RIGHT: 0px; PADDING-TOP: 0px">
当一个用��h��式APC被投递到一个线�E�，调用上面的等待函敎ͼ�如果�q�回�{�待状态STATUS_USER_APC�Q�在�q�回用户模式�Ӟ��内核转去控制APC例程�Q�当APC例程完成后，再��l�线�E�的执行.

和用��h��式APCs比较�Q�内核模式APCs执行在内核模式下。可以被划分为常规的和特�D�的两类。当APCs被投递到一个特�D�的�U�程�Q�特�D�的内核模式APCs不需要从�U�程得到许可来运行。然而，常规的内核模式APCs在他们成功执行前�Q�需要有特定的环境。此外，�Ҏ��的内核APC被尽可能快地执行�Q�既只要APC_LEVEL�U�上有可调度的活动。在很多情况下，�Ҏ��的内核APC甚至能唤醒阻塞的�U�程。普通的内核APC仅在所有特�D�APC都被执行完，�q�且目标�U�程仍在�q�行�Q�同时该�U�程中也没有其它内核模式APC正执行时才执行。用��h��式APC在所有内核模式APC执行完后才执行，�q�且仅在目标�U�程有alertable属性时才执行�?br style="PADDING-BOTTOM: 0px; MARGIN: 0px; PADDING-LEFT: 0px; PADDING-RIGHT: 0px; PADDING-TOP: 0px">
每一个等待执行的APC都存在于一个线�E�执行体�Q�由内核��理的队列中。系�l�中的每一个线�E�都包含两个APC队列�Q�一个是为用��h��式APCs,另一个是为内核模式APCs的�?br style="PADDING-BOTTOM: 0px; MARGIN: 0px; PADDING-LEFT: 0px; PADDING-RIGHT: 0px; PADDING-TOP: 0px">NT通过一个成为KAPC的内核控制对象来描述一个Ａ�Q��E�Q�尽��Ｄ�Q��O中没有明��的文��化Ａ�Q��Eｓ，但是在NTDDK.H中却非常清楚的定义了�Q�Ｐ�Q�对象。从下面的KAPC对象的定义看�Q�有些是不需要说明的。像Type和Size。Type表示了这是一个APC内核对象。在nt中，每一个内核对象或者执行体对象都有Type和Size�q�两个域。由此处理函数可以确定当前处理的对象。Size表示一个字寚w��的结构体的大��。也��是指明了对象占的内存空间大��。Spare0看�v来有些晦涩难懂，但是它是没用什么�Q何深�q�的意义�Q�仅仅是��Z��内存补齐。其他的域将在下面的��幅中介�l��?br style="PADDING-BOTTOM: 0px; MARGIN: 0px; PADDING-LEFT: 0px; PADDING-RIGHT: 0px; PADDING-TOP: 0px">
//-------------------------------------------------------------------------------------------------------

几个函数声明和结构定义：

typedef struct _KAPC {
CSHORT Type;
CSHORT Size;
ULONG Spare0;
struct _KTHREAD *Thread;
LIST_ENTRY ApcListEntry;
PKKERNEL_ROUTINE KernelRoutine;
PKRUNDOWN_ROUTINE RundownRoutine;
PKNORMAL_ROUTINE NormalRoutine;
PVOID NormalContext;
//
// N.B. The following two members MUST be together.
//
PVOID SystemArgument1;
PVOID SystemArgument2;
CCHAR ApcStateIndex;
KPROCESSOR_MODE ApcMode;
BOOLEAN Inserted;
} KAPC, *PKAPC, *RESTRICTED_POINTER PRKAPC;
//------

APC环境

一个线�E�在它执行的��L��时刻�Q�假讑ֽ�前的IRQL是在Passive�U�，它可能需要��时在其他的进�E�上下文中执行代码，��Z��完成�q�个操作�Q�线�E�调用系�l�功能函数KeAttachProcess�Q�在从这个调用返回时�Q�线�E�执行在另一个进�E�的地址�I�间。先前所有在�U�程自己的进�E�上下文中等待执行的APCs,�׃��q�时其所属进�E�的地址�I�间不是当前可用的，因此他们不能被投递执行。然而，新的插入到这个线�E�的APCs可以执行在这个新的进�E�空间。甚臛_��U�程最后从新的�q�程中分��L��Q�新的插入到�q�个�U�程的APCs�q�可以在�q�个�U�程所属的�q�程上下文中执行�?br style="PADDING-BOTTOM: 0px; MARGIN: 0px; PADDING-LEFT: 0px; PADDING-RIGHT: 0px; PADDING-TOP: 0px">��Z��辑ֈ�控制APC传送的�q�个�E�度�Q�NT中每个线�E�维护了两个APC环境或者说是状态。每一个APC环境包含了用��h��式的APC队列和内核模式的APC队列�Q�一个指向当前进�E�对象的指针和三个控制变量，用于指出�Q�是否有未决的内核模式APCs(KernelApcPending),是否有常规内核模式APC在进行中(KernelApcInProgress)�Q�是否有未决的用��h��式的APC(UserApcPending). �q�些APC的环境保存在�U�程对象的ApcStatePointer域中。这个域是由2个元素组成的数组。即�Q?0x138 ApcStatePointer : [2] Ptr32 _KAPC_STATE

typedef struct _KAPC_STATE {
LIST_ENTRY ApcListHead[MaximumMode];
struct _KPROCESS *Process;
BOOLEAN KernelApcInProgress;
BOOLEAN KernelApcPending;
BOOLEAN UserApcPending;
} KAPC_STATE, *PKAPC_STATE, *PRKAPC_STATE;

lkd> dt _kthread
ntdll!_KTHREAD
+0x000 Header : _DISPATCHER_HEADER
+0x010 MutantListHead : _LIST_ENTRY
+0x018 InitialStack : Ptr32 Void
+0x01c StackLimit : Ptr32 Void
+0x020 Teb : Ptr32 Void
+0x024 TlsArray : Ptr32 Void
+0x028 KernelStack : Ptr32 Void
+0x02c DebugActive : UChar
+0x02d State : UChar
+0x02e Alerted : [2] UChar
+0x030 Iopl : UChar
+0x031 NpxState : UChar
+0x032 Saturation : Char
+0x033 Priority : Char
+0x034 ApcState : _KAPC_STATE
+0x04c ContextSwitches : Uint4B
+0x050 IdleSwapBlock : UChar
+0x051 Spare0 : [3] UChar
+0x054 WaitStatus : Int4B
+0x058 WaitIrql : UChar
+0x059 WaitMode : Char
+0x05a WaitNext : UChar
+0x05b WaitReason : UChar
+0x05c WaitBlockList : Ptr32 _KWAIT_BLOCK
+0x060 WaitListEntry : _LIST_ENTRY
+0x060 SwapListEntry : _SINGLE_LIST_ENTRY
+0x068 WaitTime : Uint4B
+0x06c BasePriority : Char
+0x06d DecrementCount : UChar
+0x06e PriorityDecrement : Char
+0x06f Quantum : Char
+0x070 WaitBlock : [4] _KWAIT_BLOCK
+0x0d0 LegoData : Ptr32 Void
+0x0d4 KernelApcDisable : Uint4B
+0x0d8 UserAffinity : Uint4B
+0x0dc SystemAffinityActive : UChar
+0x0dd PowerState : UChar
+0x0de NpxIrql : UChar
+0x0df InitialNode : UChar
+0x0e0 ServiceTable : Ptr32 Void
+0x0e4 Queue : Ptr32 _KQUEUE
+0x0e8 ApcQueueLock : Uint4B
+0x0f0 Timer : _KTIMER
+0x118 QueueListEntry : _LIST_ENTRY
+0x120 SoftAffinity : Uint4B
+0x124 Affinity : Uint4B
+0x128 Preempted : UChar
+0x129 ProcessReadyQueue : UChar
+0x12a KernelStackResident : UChar
+0x12b NextProcessor : UChar
+0x12c CallbackStack : Ptr32 Void
+0x130 Win32Thread : Ptr32 Void
+0x134 TrapFrame : Ptr32 _KTRAP_FRAME
+0x138 ApcStatePointer : [2] Ptr32 _KAPC_STATE
+0x140 PreviousMode : Char
+0x141 EnableStackSwap : UChar
+0x142 LargeStack : UChar
+0x143 ResourceIndex : UChar
+0x144 KernelTime : Uint4B
+0x148 UserTime : Uint4B
+0x14c SavedApcState : _KAPC_STATE
+0x164 Alertable : UChar
+0x165 ApcStateIndex : UChar
+0x166 ApcQueueable : UChar
+0x167 AutoAlignment : UChar
+0x168 StackBase : Ptr32 Void
+0x16c SuspendApc : _KAPC
+0x19c SuspendSemaphore : _KSEMAPHORE
+0x1b0 ThreadListEntry : _LIST_ENTRY
+0x1b8 FreezeCount : Char
+0x1b9 SuspendCount : Char
+0x1ba IdealProcessor : UChar
+0x1bb DisableBoost : UChar

主APC环境是位于线�E�对象的ApcState 域，卻I��
+0x034 ApcState : _KAPC_STATE

�U�程中等待在当前�q�程上下文中执行的APC保存在ApcState的队列中。无��Z��Ӟ��NT的APC�z�֏��?dispatcher)和其他系�l�元件查询一个线�E�未决的APCs�? 他们都会��查主APC环境�Q�如果这里有��M��未决的APCs,��׃��马上被投递，或者修改它的控制变量稍后投递�?br style="PADDING-BOTTOM: 0px; MARGIN: 0px; PADDING-LEFT: 0px; PADDING-RIGHT: 0px; PADDING-TOP: 0px">
�W�二个APC环境是位于线�E�对象的SavedApcState域，当线�E��时挂接到其他�q�程�Ӟ��它是用来备䆾主APC环境的�?br style="PADDING-BOTTOM: 0px; MARGIN: 0px; PADDING-LEFT: 0px; PADDING-RIGHT: 0px; PADDING-TOP: 0px">
当一个线�E�调用KeAttachProcess�Q�在另外的进�E�上下文中执行后�l�的代码�Ӟ��ApcState域的内容��p��拯��到SavedApcState域。然后ApcState域被清空�Q�它的APC队列重新初始化，控制变量讄��?�Q�当前进�E�域讄��为新的进�E�。这些步骤成功的��保先前在线�E�所属的�q�程上下文地址�I�间中等待的APCs�Q�当�U�程�q�行在其它不同的�q�程上下文时�Q�这些APCs不被传送执行。随后，ApcStatePointer域数�l�内容被更新来反映新的状态，数组中第一个元素指向SavedApcState域，�W�二个元素指向ApcState域，表明�U�程所属进�E�上下文的APC环境位于SavedApcState域。线�E�的新的�q�程上下文的APC环境位于ApcState域。最后，当前�q�程上下文切换到新的�q�程上下文�?br style="PADDING-BOTTOM: 0px; MARGIN: 0px; PADDING-LEFT: 0px; PADDING-RIGHT: 0px; PADDING-TOP: 0px">
对于一个APC对象�Q�决定当前APC环境的是ApcStateIndex域。ApcStateIndex域的��g��为ApcStatePointer域数�l�的索引来得到目标APC环境指针。随后，目标APC环境指针用来在相应的队列中存放apc对象.

当线�E�从新的�q�程中脱��L��(KeDetachProcess), ��M��在新的进�E�地址�I�间中等待执行的未决的内核APCs被派发执行。随后SavedApcState 域的内容被拷贝回ApcState域。SavedApcState 域的内容被清�I�，�U�程的ApcStateIndex域被设�ؓOriginalApcEnvironment�Q�ApcStatePointer域更斎ͼ�当前�q�程上下文切换到�U�程所属进�E��?br style="PADDING-BOTTOM: 0px; MARGIN: 0px; PADDING-LEFT: 0px; PADDING-RIGHT: 0px; PADDING-TOP: 0px">
使用APCs

讑֤�驱动�E�序使用两个主要函数来利用APCs, �W�一个是KeInitializeApc�Q�用来初始化APC对象。这个函数接受一个驱动分配的APC对象�Q�一个目标线�E�对象指针，APC环境索引�Q�指出APC对象存放于哪个APC环境�Q�，APC的kernel,rundown和normal例程指针�Q�APC�c�d��Q�用��h��式或者内核模式）和一个上下文参数�?函数声明如下�Q?br style="PADDING-BOTTOM: 0px; MARGIN: 0px; PADDING-LEFT: 0px; PADDING-RIGHT: 0px; PADDING-TOP: 0px">
NTKERNELAPI
VOID
KeInitializeApc (
IN PRKAPC Apc,
IN PKTHREAD Thread,
IN KAPC_ENVIRONMENT Environment,
IN PKKERNEL_ROUTINE KernelRoutine,
IN PKRUNDOWN_ROUTINE RundownRoutine OPTIONAL,
IN PKNORMAL_ROUTINE NormalRoutine OPTIONAL,
IN KPROCESSOR_MODE ApcMode,
IN PVOID NormalContext
);

typedef enum _KAPC_ENVIRONMENT {
OriginalApcEnvironment,
AttachedApcEnvironment,
CurrentApcEnvironment
} KAPC_ENVIRONMENT;

KeInitializeApc 首先讄��APC对象的Type和Size域一个适当的��|��然后��查参数Environment的��|��如果是CurrentApcEnvironment�Q�那么ApcStateIndex域设�|��ؓ目标�U�程的ApcStateIndex域。否则，ApcStateIndex域设�|��ؓ参数Environment的倹{��随后，函数直接用参数设�|�APC对象Thread�Q�RundownRoutine�Q�KernelRoutine域的倹{��ؓ了正��地��定APC的类型，KeInitializeApc ��查参数NormalRoutine的��|��如果是NULL�Q�ApcMode域的��D��|��ؓKernelMode�Q�NormalContext域设�|��ؓNULL。如果NormalRoutine的��g��是NULL�Q�这时候它一定指向一个有效的例程�Q�就用相应的参数来设�|�ApcMode域和NormalContext域。最后，KeInitializeApc 讄��Inserted域�ؓFALSE.然而初始化APC对象�Q��ƈ没有把它存放到相应的APC队列中�?br style="PADDING-BOTTOM: 0px; MARGIN: 0px; PADDING-LEFT: 0px; PADDING-RIGHT: 0px; PADDING-TOP: 0px">
从这个解释看�Q�你可以了解到APCs对象如果�~�少有效的NormalRoutine�Q�就会被当作内核模式APCs.��其是它们会被认为是�Ҏ��的内核模式APCs.
实际上，I/O��理器就是用�q�类的APC来完成异步I/O操作。相反地�Q�APC对象定义了有效的NormalRoutine�Q��ƈ且ApcMode域是KernelMode�Q�就会被当作常规的内核模式APCs,否则��׃��被当作是用户模式APCs. NTDDK.H中KernelRoutine, RundownRoutine, and NormalRoutine 的定义如下：
typedef
VOID
(*PKKERNEL_ROUTINE) (
IN struct _KAPC *Apc,
IN OUT PKNORMAL_ROUTINE *NormalRoutine,
IN OUT PVOID *NormalContext,
IN OUT PVOID *SystemArgument1,
IN OUT PVOID *SystemArgument2
);

typedef
VOID
(*PKRUNDOWN_ROUTINE) (
IN struct _KAPC *Apc
);

typedef
VOID
(*PKNORMAL_ROUTINE) (
IN PVOID NormalContext,
IN PVOID SystemArgument1,
IN PVOID SystemArgument2
);
//------------------

通常�Q�无论是什么类型，每个APC对象必须要包含一个有效的KernelRoutine 函数指针。当�q�个APC被NT的APC dispatcher传送执行时�Q�这个例�E�首先被执行。用��h��式的APCs必须包含一个有效的NormalRoutine 函数指针�Q�这个函数必��d��用户内存区域。同��L��Q�常规内核模式APCs也必��d��含一个有效的NormalRoutine�Q�但是它��像KernelRoutine一栯��行在内核模式。作为可选择的，��L��c�d��的APC都可以定义一个有效的RundownRoutine�Q�这个例�E�必��d��内核内存区域�Q��ƈ且仅仅当�pȝ��需要释放APC队列的内�Ҏ��Q�才被调用。例如线�E�退出时�Q�在�q�种情况下，KernelRoutine和NormalRoutine都不执行�Q�只有RundownRoutine执行。没有这个例�E�的APC对象会被删除�?br style="PADDING-BOTTOM: 0px; MARGIN: 0px; PADDING-LEFT: 0px; PADDING-RIGHT: 0px; PADDING-TOP: 0px">
��C��Q�投递APCs��C��个线�E�的动作�Q�仅仅是操作�pȝ��调用KiDeliverApc完成的。执行APC实际上就是调用APC内的例程�?br style="PADDING-BOTTOM: 0px; MARGIN: 0px; PADDING-LEFT: 0px; PADDING-RIGHT: 0px; PADDING-TOP: 0px">
一旦APC对象完成初始化后�Q�设备驱动调用KeInsertQueueApc来将APC对象存放到目标线�E�的相应的APC队列中。这个函数接受一个由KeInitializeApc完成初始化的APC对象指针�Q�两个系�l�参数和一个优先��增量。跟传递给KeInitializeApc函数的参数context 一��P��q�两个系�l�参数只是在APC的例�E�执行时�Q�简单的传递给APC的例�E��?br style="PADDING-BOTTOM: 0px; MARGIN: 0px; PADDING-LEFT: 0px; PADDING-RIGHT: 0px; PADDING-TOP: 0px">
NTKERNELAPI
BOOLEAN
KeInsertQueueApc (
IN PRKAPC Apc,
IN PVOID SystemArgument1,
IN PVOID SystemArgument2,
IN KPRIORITY Increment
);
//-----------------
在KeInsertQueueApc ��APC对象存放到目标线�E�相应的APC队列之前�Q�它首先��查目标线�E�是否是APC queueable。如果不是，函数立即�q�回FALSE.如果是，函数直接用参数设�|�SystemArgument1域和SystemArgument2 域，随后�Q�函数调用KiInsertQueueApc来将APC对象存放到相应的APC队列�?br style="PADDING-BOTTOM: 0px; MARGIN: 0px; PADDING-LEFT: 0px; PADDING-RIGHT: 0px; PADDING-TOP: 0px">
KiInsertQueueApc 仅仅接受一个APC对象和一个优先��增量。这个函数首先得到线�E�APC队列的spinlock�q�且持有它，防止其他�U�程修改当前�U�程的APC�l�构。随后，��查APC对象的Inserted 域。如果是TRUE,表明�q�个APC对象已经存放到APC队列中了�Q�函数立卌��回FALSE.如果APC对象的Inserted 域是FALSE.函数通过ApcStateIndex域来��定目标APC环境�Q�然后把APC对象存放到相应的APC队列中，卛_��APC对象中的ApcListEntry 域链入到APC环境的ApcListHead域中。链入的位置由APC的类型决定。常规的内核模式APC,用户模式APC都是存放到相应的APC队列的末端。相反的�Q�如果队列中已经存放了一些APC对象�Q�特�D�的内核模式APC存放到队列中�W�一个常规内核模式APC对象的前面。如果是内核定义的一个当�U�程退出时使用的用户APC,它也会被攑֜�相应的队列的前面。然后，�U�程的主APC环境中的UserApcPending域杯讄��为TRUE。这时KiInsertQueueApc 讄��APC对象的Inserted 域�ؓTRUE�Q�表明这个APC对象已经存放到APC队列中了。接下来�Q�检查这个APC对象是否被排队到�U�程的当前进�E�上下文APC环境中，如果不是�Q�函数立卌��回TRUE。如果这是一个内核模式APC�Q�线�E�主APC环境中的KernelApcPending域设�|��ؓTRUE�?br style="PADDING-BOTTOM: 0px; MARGIN: 0px; PADDING-LEFT: 0px; PADDING-RIGHT: 0px; PADDING-TOP: 0px">
在WIN32 SDK文��中是�q�样描述APCs的：当一个APC被成功的存放到它的队列后�Q�发��Z��个��Y中断�Q�APC��会在线�E�被调度�q�行的下一个时间片执行。然而这不是完全正确的。这样一个��Y中断�Q�仅仅是当一个内核模式的APC�Q�无论是常规的内核模式APC�q�是�Ҏ��的内核模式APC�Q�针对于调用�U�程�Ӟ��才会发出。随后函数返回TRUE�?br style="PADDING-BOTTOM: 0px; MARGIN: 0px; PADDING-LEFT: 0px; PADDING-RIGHT: 0px; PADDING-TOP: 0px">
1�Q�如果APC不是针对于调用线�E�，目标�U�程在Passive权限�{��处在�{�待状态；
2�Q�这是一个常规内核模式APC
3�Q�这个线�E�不再��界区
4�Q�没有其他的常规内核模式APC仍然在进行中
那么�q�个�U�程被唤醒，�q�回状态是STATUS_KERNEL_APC。但是等待状态没有aborted�?如果�q�是一个用��h��式APC�Q�KiInsertQueueApc��查判断目标线�E�是否是alertable�{�待状态，�q�且WaitMode域等于UserMode。如果是�Q�主APC环境的UserApcPending 域设�|��ؓTRUE。等待状态返回STATUS_USER_APC�Q�最后，函数释放spinlock�Q�返回TRUE�Q�表�C�APC对象已经被成功放入队列�?br style="PADDING-BOTTOM: 0px; MARGIN: 0px; PADDING-LEFT: 0px; PADDING-RIGHT: 0px; PADDING-TOP: 0px">早期作�ؓAPC��理函数的补充，讑֤�驱动开发者可以��用未公开的系�l�服务NtQueueApcThread来直接将一个用��h��式的APC投递到某个�U�程�?br style="PADDING-BOTTOM: 0px; MARGIN: 0px; PADDING-LEFT: 0px; PADDING-RIGHT: 0px; PADDING-TOP: 0px">�q�个函数内部实际上是调用了KeInitializeApc 和KeInsertQueueApc 来完成这个�Q务�?br style="PADDING-BOTTOM: 0px; MARGIN: 0px; PADDING-LEFT: 0px; PADDING-RIGHT: 0px; PADDING-TOP: 0px">
NTSYSAPI
NTSTATUS
NTAPI
NtQueueApcThread (
IN HANDLE Thread,
IN PKNORMAL_ROUTINE NormalRoutine,
IN PVOID NormalContext,
IN PVOID SystemArgument1,
IN PVOID SystemArgument2
);

NT的APC�z�֏��?br style="PADDING-BOTTOM: 0px; MARGIN: 0px; PADDING-LEFT: 0px; PADDING-RIGHT: 0px; PADDING-TOP: 0px">
NT��查是否线�E�有未决的APCs. 然后APC�z�֏�器子�E�序KiDeliverApc在这个线�E�上下文执行来开始将未决的APC执行。注意，�q�个行�ؓ中断了线�E�的正常执行��程�Q�首先将控制权给APC�z�֏�器，随后当KiDeliverApc完成后，�l�箋�U�程的执行�?br style="PADDING-BOTTOM: 0px; MARGIN: 0px; PADDING-LEFT: 0px; PADDING-RIGHT: 0px; PADDING-TOP: 0px">例如�Q�当一个线�E�被调度�q�行�Ӟ��最后一步，上下文切换函�?SwapContext 用来��查是否新的线�E�有未决的内核APCs.如果是，SwapContext要么�Q?�Q�请求一个APC�U�别的��Y中断来开始APC执行�Q�由于新�U�程�q�行在低的IRQL�Q�Passive�U�别�?br style="PADDING-BOTTOM: 0px; MARGIN: 0px; PADDING-LEFT: 0px; PADDING-RIGHT: 0px; PADDING-TOP: 0px">或者（2�Q�返回TRUE�Q�表�C�新的线�E�有未决的内核APCs�?br style="PADDING-BOTTOM: 0px; MARGIN: 0px; PADDING-LEFT: 0px; PADDING-RIGHT: 0px; PADDING-TOP: 0px">
�I�竟是执�?1)�q�是(2)取决于新�U�程所处的IRQL�U�别. 如果它的权限�U�别高于Passive�U?SwapContext 执行(1),如果它是在Passive�U?则选择执行(2).
SwapContext的返回��g��仅是特定�pȝ��函数可用�?�q�些�pȝ��函数调用SwapContext来强制切换线�E�上下文到另一个线�E? 然后,当这些系�l�函数经�q�一�D�|��间再�l�箋�?他们通常��查SwapContext 的返回�?如果是TRUE,他们��׃��调用APC�z�֏�器来投递内核APCs到当前的�U�程. 例如:
�pȝ��函数KiSwapThread被等待服务用来放弃处理器�Q�直到等待结束。这个函数内部调用SwapContext。当�{�待�l�束�Q��l�从调用SwapContext处执行时�Q�就会检查SwapContext的返回倹{��如果是TRUE�Q�KiSwapThread会降低IRQL�U�别到APC�U�，然后调用KiDeliverApc来在当前�U�程执行内核APCs.
对于用户APCs, 内核调用APC�z�֏�器仅仅是当线�E�回到用��h��式，�q�且�U�程的主APC环境的UserApcPending域�ؓTRUE时。例如：当系�l�服务派发器KiSystemService完成一个系�l�服务请求正打算回到用户模式�Ӟ��它会��查是否有未决的用户APCs。在执行上，KiDeliverApc调用用户APC的KernelRoutine. 随后�Q�KiInitializeUserApc函数被调用，用来讄��U�程的陷阱��。所以从内核模式退出时�Q�线�E�开始在用户模式下执�?br style="PADDING-BOTTOM: 0px; MARGIN: 0px; PADDING-LEFT: 0px; PADDING-RIGHT: 0px; PADDING-TOP: 0px">。KiInitializeUserApc的函数的作用是拷贝当前线�E�先前的执行状态（当进入内核模式时�Q�这个状态保存在�U�程内核栈创建的陷阱帧里�Q�，从内核栈到线�E�的用户模式栈，初始化用��h��式APC。APC�z�֏�器子�E�序KiUserApcDispatcher在Ntdll.dll内。最后，加蝲陷阱帧的EIP寄存器和Ntdll.dll中KiUserApcDispatcher的地址。当陷阱帧最后释放时�Q�内核将控制转交�l�KiUserApcDispatcher�Q�这个函数调用APC的NormalRoutine例程�Q�NormalRoutine函数地址以及参数都在栈中�Q�当例程完成�Ӟ��它调用NtContinue来让�U�程利用在栈中先前的上下文��l�执行，仿佛什么事情也没有发生�q��?br style="PADDING-BOTTOM: 0px; MARGIN: 0px; PADDING-LEFT: 0px; PADDING-RIGHT: 0px; PADDING-TOP: 0px">

当内核调用KiDeliverApc来执行一个用��h��式APC�Ӟ��U�程中的PreviousMode域被设�ؓUserMode. TrapFrame域指向线�E�的陷阱帧。当内核调用KiDeliverApc来执行内核APCs�Ӟ��U�程中的PreviousMode域被设�ؓKernelMode. TrapFrame域指向NULL�?br style="PADDING-BOTTOM: 0px; MARGIN: 0px; PADDING-LEFT: 0px; PADDING-RIGHT: 0px; PADDING-TOP: 0px">注意�Q�无��Z��时只要KernelRoutine被调用，传递给它的指针是一个局部的APC属性的副本�Q�由于APC对象已经��q��了队列，所以可以安全的在KernelRoutine中释放APC内存。此外，�q�个例程在它的参数被传递给其他例程之前�Q�有一个最后的��Z��来修改这些参数�?br style="PADDING-BOTTOM: 0px; MARGIN: 0px; PADDING-LEFT: 0px; PADDING-RIGHT: 0px; PADDING-TOP: 0px">
�l�论�Q?br style="PADDING-BOTTOM: 0px; MARGIN: 0px; PADDING-LEFT: 0px; PADDING-RIGHT: 0px; PADDING-TOP: 0px">APC提供了一个非常有用的机制�Q�允许在特定的线�E�上下文中异步的执行代码。作��Z��个设备驱动开发者，你可以依赖APCs在某个特定的�U�程上下文中执行一个例�E�，而不需要线�E�的许可和干涉。对于用户应用程序，用户模式APCs可以用来有效地实��C��些回调通知机制�?/span>

shaker(太子) 2011-05-05 11:46 发表评论

NtProtectVirtualMemory

shaker(太子) — Wed, 23 Mar 2011 02:01:00 GMT

  1 NTSTATUS
  2 NTAPI
  3 NtProtectVirtualMemory(IN HANDLE ProcessHandle,
  4                        IN OUT PVOID *UnsafeBaseAddress,
  5                        IN OUT SIZE_T *UnsafeNumberOfBytesToProtect,
  6                        IN ULONG NewAccessProtection,
  7                        OUT PULONG UnsafeOldAccessProtection)
  8 {
  9     PEPROCESS Process;
10     ULONG OldAccessProtection;
11     ULONG Protection;
12     PEPROCESS CurrentProcess = PsGetCurrentProcess();
13     PVOID BaseAddress = NULL;
14     SIZE_T NumberOfBytesToProtect = 0;
15     KPROCESSOR_MODE PreviousMode = ExGetPreviousMode();
16     NTSTATUS Status;
17     BOOLEAN Attached = FALSE;
18     KAPC_STATE ApcState;
19     PAGED_CODE();
20
21     //
22     // Check for valid protection flags
23     //
24     Protection = NewAccessProtection & ~(PAGE_GUARD|PAGE_NOCACHE);
25     if (Protection != PAGE_NOACCESS &&
26         Protection != PAGE_READONLY &&
27         Protection != PAGE_READWRITE &&
28         Protection != PAGE_WRITECOPY &&
29         Protection != PAGE_EXECUTE &&
30         Protection != PAGE_EXECUTE_READ &&
31         Protection != PAGE_EXECUTE_READWRITE &&
32         Protection != PAGE_EXECUTE_WRITECOPY)
33     {
34         //
35         // Fail
36         //
37         return STATUS_INVALID_PAGE_PROTECTION;
38     }
39
40     //
41     // Check if we came from user mode
42     //
43     if (PreviousMode != KernelMode)
44     {
45         //
46         // Enter SEH for probing
47         //
48         _SEH2_TRY
49         {
50             //
51             // Validate all outputs
52             //
53             ProbeForWritePointer(UnsafeBaseAddress);
54             ProbeForWriteSize_t(UnsafeNumberOfBytesToProtect);
55             ProbeForWriteUlong(UnsafeOldAccessProtection);
56
57             //
58             // Capture them
59             //
60             BaseAddress = *UnsafeBaseAddress;
61             NumberOfBytesToProtect = *UnsafeNumberOfBytesToProtect;
62         }
63         _SEH2_EXCEPT(EXCEPTION_EXECUTE_HANDLER)
64         {
65             //
66             // Get exception code
67             //
68             _SEH2_YIELD(return _SEH2_GetExceptionCode());
69         }
70         _SEH2_END;
71     }
72     else
73     {
74         //
75         // Capture directly
76         //
77         BaseAddress = *UnsafeBaseAddress;
78         NumberOfBytesToProtect = *UnsafeNumberOfBytesToProtect;
79     }
80
81     //
82     // Catch illegal base address
83     //
84     if (BaseAddress > MM_HIGHEST_USER_ADDRESS) return STATUS_INVALID_PARAMETER_2;
85
86     //
87     // Catch illegal region size
88     //
89     if ((MmUserProbeAddress - (ULONG_PTR)BaseAddress) < NumberOfBytesToProtect)
90     {
91         //
92         // Fail
93         //
94         return STATUS_INVALID_PARAMETER_3;
95     }
96
97     //
98     // 0 is also illegal
99     //
100     if (!NumberOfBytesToProtect) return STATUS_INVALID_PARAMETER_3;
101
102     //
103     // Get a reference to the process
104     //
105     Status = ObReferenceObjectByHandle(ProcessHandle,
106                                        PROCESS_VM_OPERATION,
107                                        PsProcessType,
108                                        PreviousMode,
109                                        (PVOID*)(&Process),
110                                        NULL);
111     if (!NT_SUCCESS(Status)) return Status;
112
113     //
114     // Check if we should attach
115     //
116     if (CurrentProcess != Process)
117     {
118         //
119         // Do it
120         //
121         KeStackAttachProcess(&Process->Pcb, &ApcState);
122         Attached = TRUE;
123     }
124
125     //
126     // Do the actual work
127     //
128     Status = MiProtectVirtualMemory(Process,
129                                     &BaseAddress,
130                                     &NumberOfBytesToProtect,
131                                     NewAccessProtection,
132                                     &OldAccessProtection);
133
134     //
135     // Detach if needed
136     //
137     if (Attached) KeUnstackDetachProcess(&ApcState);
138
139     //
140     // Release reference
141     //
142     ObDereferenceObject(Process);
143
144     //
145     // Enter SEH to return data
146     //
147     _SEH2_TRY
148     {
149         //
150         // Return data to user
151         //
152         *UnsafeOldAccessProtection = OldAccessProtection;
153         *UnsafeBaseAddress = BaseAddress;
154         *UnsafeNumberOfBytesToProtect = NumberOfBytesToProtect;
155     }
156     _SEH2_EXCEPT(EXCEPTION_EXECUTE_HANDLER)
157     {
158     }
159     _SEH2_END;
160
161     //
162     // Return status
163     //
164     return Status;
165 }

shaker(太子) 2011-03-23 10:01 发表评论

【�{帖】Windows�|�络体系�l�构�ȝ��

shaker(太子) — Tue, 22 Feb 2011 06:48:00 GMT

�?�? Windows�|�络体系�l�构�ȝ��
�?�? jbwang
�?�? 2009-11-23,11:22:25
�?�? http://bbs.pediy.com/showthread.php?t=101794

做了一些东西自�׃��看了一些书�Q�最�q��ȝ��了一下，想给大家分��n一下，高手可以飞过了。如果有什么问题可以给��弟指正一下，多谢�Q?img alt="" src="http://www.shnenglu.com/images/cppblog_com/shaker/022211_0647_Windows1.gif">

在介�l�Windows�|�络体系架构之前�Q�我首先介绍一下Windows中的两个重要�~�程规范——TDI�Q�NDIS.�Q�然后再介绍�|�络体系的架构�?br>TDI�Q�Transport Driver Interface�Q�传输驱动程序接口。\Windows\System32\Drivers\Tdi.sys
在实现网�l�API驱动�E�序�Ӟ��׃��牉|��到很多不同协议，会用��C��同协议驱动提供的接口�Q��得开发的工作复杂化。所以Microsoft在网�l�API驱动�E�序和协议驱动之间又增加了一层TDI。TDI接口只是一�U?��网�l�请求格式化成IRP�Q�以及申��L��l�地址和数据通信"的做法规范化。遵从TDI标准的传输协议向他们的客��P��如Socket emulator�Q�Netbios emulator�{�）导出了TDI接口�Q�有利于上下层之间的通信�Q?br>�?nbsp; 一斚w��Q�对于TDI上层的网�l�API驱动�E�序��׃��需要��用所有协议驱动程序所提供的接口，直接使用TDI提供的统一接口�?br>�?nbsp; 另一斚w��Q�对于下层协议驱动程序（也称为TDI Transport Provider传输器）直接由TDI接口来调用，发出��h��?br>

在Windows VISTA版本之后�Q�TDI��׃��再��用了�Q�取而代之的是Windows filter platform和Winsock kernel�?br>
NDIS�Q�Network Driver Interface Specification�Q�网�l�驱动程序接口规范，在操作系�l�中的位�|?br>\Windows\System32\Drivers\NDIS.sys
当一个协议驱动程序想要按照其协议的格式解析网上读写的数据�Ӟ��而这些数据必��通过�|�络适配器才能取得，期望协议驱动�E�序能够理解市场上的每一�Ƅ��l�适配器的�l�微区别是不可能的。所以在1989�q�_��由Microsoft�?Com联合开发的了NDIS�Q��得协议驱动程序可以以一�U�与讑֤�无关的方式来跟网�l�适配器驱动程序进行通信。遵从NDIS的网�l�适配器驱动程序称为NDIS minport driver�?/span>

NDIS规范实现了与TDI标准�c�M��的功能，都是��复杂的下层调用规范化、标准化�Q�大大提高了Windows操作�pȝ��的可扩展性和兼容性。也表现在两个方面：
�?nbsp; 对于下层�Q�让�|�络适配器制造商很easy的开发自��q��讑֤�驱动�E�序�Q�也��是Ndis miniport driver。这些miniport driver直接利用NDIS提供的接口发送指令，NDIS对这些格式化的指令进行解析，做进一步处理。（�q�些处理��到了HAL了）
�?nbsp; 对于上层�Q�多个协议驱动程序与下层minport driver之间的通信�Q�也都是通过�l�一的NDIS接口�Q�NidsAllocatePacket�Q�NdisSend�{�函数来收发数据�?br>
废话两句�Q�TDI和NDIS两大接口规范�Q�有力的提升了Windows操作�pȝ��对不同设备厂商的支持�Q�降低了讑֤�厂商对设备驱动程序开发的隑ֺ��Q�也增加了对于不同网�l�协议的支持�Q�给用户更强大的�|�络功能支持。这�U�设计我们也可以在Windows存储��理中看刎ͼ�从中我们��g��可以了解��C��些，Windows操作�pȝ��在商业上取得成功的原因。Linux操作�pȝ��中没有这��L��驱动层次�l�构�?br>
讑֤�刉��商开发的Ndis miniport driver直接调用NDIS库中的接口函敎ͼ�因此不需要考虑重入的问题，��是一个请求尚未结束的时候，新的��h��又进来了。NDIS库对��h��q�行了序列化�Q�但是这�U�序列化也妨��了多处理器的扩展性。所以NDIS5中提供了非序列化的操作项。下面，我来介绍一下，Deserialized和Serialized minport driver的区别：
Deserialized NDIS miniport driver自己序列化对MinportXxx函数的操作，排队和管理多个�ƈ发请求的��d��都由驱动�E�序自己来完成。而Serialized NDIS miniport driver以上的工作都是依赖于NDIS库来完成的。从性能角度看，Deserialized NDIS miniport driver的性能是Serialized NDIS miniport driver性能�?倍多�Q�所以到NDIS6.0之后的所有Miniport driver都是deserialize的�?br>

以上是我参考MSDN以及自己的一些理解画出来的windows�|�络架构图，下面我就从上��C��来简单介�l�一下其中的各个层�?/span>

1.  �|�络应用�E�，Network applicantion�Q�用��h��的应用�E�序调用Windows操作�pȝ��提供的网�l�API�Q�网�l�API包括�Q?br>a)  Windows套接字（winsock�Q?br>b)  �q�程�q�程调用RPC
c)  Web讉K��API
d)  命名��道和邮件槽
e)  其他�|�络API
�q�些API既可以在用户模式下实玎ͼ�也可以同时在用户模式和内核模式下实现。从本质上说�q�些API是下层提供接口的另一层封装而已�?br>2.  TDI Clients�Q�传输驱动程序接口客��P��是内核模式的讑֤�驱动�E�序�Q�用于实现网�l�API的内栔R��分。将�|�络API的请求�{换成IRP�Q�通过TDI标准格式化后�Q�发送给下层的协议驱动（也就是TDI传输器）。从sockets emulator的架构图看到�Q�TDI Clients的实现可以有用户态的部分�Q�也有内核态的部分。AFD辅助功能驱动�E�序通过向协议驱动程序发送TDI IRP来执行网�l�套接字操作�Q�比如发送和接受消息。AFD没有不是��定使用哪一个协议驱动，而是上层通知其要使用的协议名�U�ͼ�然后AFD��L��开相应协议的设备对象�?/span>

3.  TDI Transport Providers、TDI传输器、NDIS协议驱动�E�序、协议驱动程序，所有这些其实就是指的同一个东西，我在后面��q��其�ؓ协议驱动�E�序。这个部分就是我们对某个协议的具体实现部分。做�q�网�l�协议开发的朋友一定知道，协议其实��是双发协商好的一套通信的规则。以IP协议��Z��Q�实际上��是对网�l�数据的一�U�处理方式，�Ҏ��|�络数据包的解析�l�构�Q�做出相应的处理。Windows的tcpip.sys��实��C��多个协议�Q�ip、tcp、udp、arp、icmp、igmp�Q�它��Z��层的TDI Clients提供�?个设备对象，用于讉K��使用�q�些协议�Q�TDI Clients打开�q�些讑֤�对象�Q�向其发送IRP��h��来实现自��q��操作。通过DDK的DeviceTree我们可以得到�q�些讑֤�对象
a)  \Device\Rawip
b)  \Device\Tcp
c)  \Device\Udp
d)  \Device\IPMULTICAST
e)  \Device\Ip
协议驱动�E�序处理的数据是通过NDIS库中提供的接口来获取的，不需要发送IRP来取得。在DDK XP中提供了一个协议驱动程序了源程序Ndisuio�Q�DDK XP后的版本提供的是Ndisport。在DriverEntry中我们可以看刎ͼ�驱动�E�序一开始就注册了一个NDIS_PROTOCOL_CHARACTERISTICS�Q�这个结构体中是一堆NdisXxxx函数。NDIS规范在这里就开始发挥它的作用了�?br>协议驱动�E�序的另一个作用就是监听网�l�数据，自己开发一个网�l�协议通过Ndis API获得所有的�|�络数据�Q�但是不能够拦截�|�络数据�Q�因为其他协议驱动也可以通过Nids API获取数据。一个典型的应用��是Winpcap了，使用NPF.SYS来捕��L��l�数据，�q�且做好充分�~�冲处理�Q�防止大数据量到来时出现数据包丢��q��情况。详情情节winpcap的开源代码�?br>具体的协议驱动开发过�E�，我就不细�q�C��Q�大家可以参看Ndisuio和DDK doc�Q�我推荐boywhp的一��文��《NDIS协议驱动开发》给大家�?br>4.  NDIS�Q�Network Driver Interface Specification�Q�网�l�协议接口标准。从图中我们可以看到包裹在其中的两个驱动�E�序�Q�一个是NDIS intermediate driver�Q�NDIS中间层驱动程序，另一个是NDIS minport driver�Q�小端口驱动�E�序。下面简单介�l�一下这两个驱动�E�序�Q?br>a)  Ndis intermediate driver�Q�NDIS中间层驱动程序，对于上层的protocol driver它充当minport driver的作用，对于下层的minport driver它充当一个protocol driver的作用，所以在驱动�E�序DriverEntry中就注册NDIS_PROTOCOL_CHARACTERISTICS和NDIS_MINIPORT_CHARACTERISTICS�Q��用protocol characteristics中NDIS API从miniport driver那里取得数据包，再用miniport characteristics的NDIS API向上层的protocol driver发送数据包。Nids intermediate driver最大的优势��是所有miniport driver的数据包都要通过它这里倒手�l�protocol driver�Q�所以网�l�防火墙��q��上了�q�块风水宝地。现在很多网�l�防火墙都��用NDIS intermediate driver做数据包的过滤和拦截工作�Q�过滤的规则讄��到MPSendPackets�Q�PTReceive�Q�PTReceiveRacket�q�三个函数。具体开发过�E�请大家参考DDK提供的PassThru源代码，www.ndis.com�Q?nbsp;�|�上有很多相关的资料�?br>NDIS 6.0之后�Q�filter driver��取代了Ndis intermediate driver�Q�WDK中提供源码�?br>b)  Ndis miniport driver一般是��p��备厂商提供的�Q�在DDK中也提供了miniport driver的一个例子e100bex�Q�支持Intel EtherExpressTM PRO/100+ Ethernet PCI adapter 和Intel EtherExpressTM PRO/100B PCI adapter两款�|�络适配器�?br>5.  最后介�l�一下�ȝ��Q�计��机�ȝ��有好几种�Q�USB�ȝ��、ISA�ȝ��、PCI�ȝ��、虚拟�ȝ��{�，一般都是以PCI�ȝ��作�ؓ�Ҏ�ȝ��Q�在Windows�pȝ��中其他的�ȝ��可以理解为PCI�ȝ��上的一个设备。PCI�ȝ��作�ؓ�Ҏ�ȝ��Q�其传输速度较高�Q�可以达�?33MB/S�Q�显卡和�|�卡很多都是用PCI插槽�?br>PCI-ISA桥设备，也称为南桥，实现了ISA�ȝ��与PCI�ȝ��的桥接，南桥�q�包括终端、IDE、USB、DMA�{�控制器讑֤�。其中USB-HOST讑֤�实现了USB�ȝ��和PCI�ȝ��的桥接。HOST/PCI桥称为北桥，是主处理器中心啊到基��PCI局部�ȝ��。南桥和北桥�l�成了主板的芯片�l�，通过芯片的扩展实��C��多种�ȝ��与基��PCI局部�ȝ��的桥接�?br>�ȝ��驱动�E�序和PNP��理器实��C��x��即用的功能，物理讑֤�对象PDO��是由�ȝ��驱动�E�序产生的�?/span>

shaker(太子) 2011-02-22 14:48 发表评论

Pro OGRE 3D Programming 中文��译版本0.2.0

shaker(太子) — Wed, 18 Aug 2010 09:04:00 GMT

shaker(太子) 2010-08-18 17:04 发表评论

Boost的状态机库教�E?补充

shaker(太子) — Mon, 16 Aug 2010 06:55:00 GMT

来自:http://www.shnenglu.com/shanoa/archive/2009/05/30/86143.html
接触了boost的状态机�Q�发��C��是想象中的那么好用，在一些地方还得用上mpl库里的东西，�׃��Ҏ��板元�~�程不是很熟�l�，搞了好些天才��弄明白�q�该�ȝ��mpl::list的原理和用法�?br>boost的状态机是属于静态链接的状态机�Q�也��是��_��它的囄��构是�~�译期间��q��定了的，在运行时不可以动态配�|�。所以，它的用途是有一定局限性的�Q�但在一般情况下�Q�它不仅很通用�Q�而且在你会用�q�熟�l�地情况下，�q�会很好用，用�v来很舒服�Q�逻辑也很合理。下面就是一�D�代码，当然也是借鉴了别人的东西�Q�自�׃��改了一下，在MainState中添加了一个Transition做了��试�Q�因为此前我�q�不知道一个状态如何包含多个Transition�Q�呵呵，原来是用mpl::list来做。至于这个状态机的入门教�E�，�|�上随处可见的三部曲�Q�《boost 状态机入门教程》说得很清楚�?br>

  1 #include <iostream>
  2 #include <ctime>
  3
  4 #include <boost/statechart/transition.hpp>
  5 #include <boost/statechart/event.hpp>
  6 #include <boost/statechart/state_machine.hpp>
  7 #include <boost/statechart/simple_state.hpp>
  8
  9 namespace sc = boost::statechart;
10
11
12
13 class EvtStartStop : public sc::event<EvtStartStop>{};
14 class EvtReset : public sc::event<EvtReset>{};
15 class EvtGo : public sc::event<EvtGo>{};
16
17
18 class MainState;
19 class StopState;
20 class RunState;
21 class TwoState;
22
23 class Machine : public sc::state_machine<Machine, MainState>
24 {};
25
26
27
28
29
30
31 class MainState : public sc::simple_state<MainState, Machine, StopState>
32 {
33 public:
34     typedef sc::transition<EvtReset, MainState> reactReset;
35     typedef sc::transition<EvtGo, TwoState> reactGo;
36     typedef boost::mpl::list<reactReset, reactGo> reactions;
37
38     MainState(void){
39         std::cout<<"�q�入MainState"<<std::endl;
40         mTime = 0;
41     }
42
43     ~MainState(void){
44         std::cout<<"退出MainState"<<std::endl;
45     }
46
47     double mTime;
48 };
49
50
51 // 该状态属于无用状态，用于��试mpl::list的多transition用法
52 class TwoState : public sc::simple_state<TwoState, Machine>
53 {
54 public:
55     typedef sc::transition<EvtGo, MainState> reactions;
56
57     TwoState(void){
58         std::cout<<"�q�入TwoState"<<std::endl;
59     }
60
61     ~TwoState(void){
62         std::cout<<"退出TwoState"<<std::endl;
63     }
64 };
65
66
67 class StopState : public sc::simple_state<StopState, MainState>
68 {
69 public:
70     typedef sc::transition<EvtStartStop, RunState> reactions;
71     StopState(void){
72         std::cout<<"�q�入StopState"<<std::endl;
73     }
74
75     ~StopState(void){
76         std::cout<<"退出StopState"<<std::endl;
77     }
78 };
79
80 class RunState : public sc::simple_state<RunState, MainState>
81 {
82 public:
83     typedef sc::transition<EvtStartStop, StopState> reactions;
84     RunState(void){
85         std::cout<<"�q�入RunState"<<std::endl;
86         mStartTime = 0;
87     }
88
89     ~RunState(void){
90         std::cout<<"退出RunState"<<std::endl;
91         context<MainState>().mTime += std::difftime(std::time(0), mStartTime);
92     }
93
94     std::time_t mStartTime;
95 };
96
97
98 int _tmain(int argc, _TCHAR* argv[])
99 {
100     Machine mc;
101     mc.initiate();
102
103     mc.process_event(EvtStartStop());
104     mc.process_event(EvtStartStop());
105     mc.process_event(EvtReset());
106     mc.process_event(EvtGo());
107     mc.process_event(EvtGo());
108
109     return 0;
110 }

shaker(太子) 2010-08-16 14:55 发表评论

Boost的状态机库教�E?3)

shaker(太子) — Mon, 16 Aug 2010 06:53:00 GMT

1.2 增加动作

此时我们��只用一�U�动作：transitions�Q�我们在下面的代码中插入了黑体的部分�?/span>

1#include <boost/statechart/transition.hpp>
2
3//
4
5struct  Stopped;
6struct  Active : sc::simple_state< Active, StopWatch, Stopped >
7{
8   typedef  sc::transition< EvReset, Active > reactions;
9};
10
11struct  Running : sc::simple_state< Running, Active >
12{
13   typedef  sc::transition< EvStartStop, Stopped > reactions;
14};
15
16struct  Stopped : sc::simple_state< Stopped, Active >
17{
18   typedef  sc::transition< EvStartStop, Running > reactions;
19};
20
21//一个状态可以定义�Q意数量的动作。这��是��Z��么当多于一个时�Q?br>22//我们不得不将它们攑ֈ�一个mpl::list<> 里�?/span>
23
24int  main()
25{
26  StopWatch myWatch;
27  myWatch.initiate();
28  myWatch.process_event( EvStartStop() );
29  myWatch.process_event( EvStartStop() );
30  myWatch.process_event( EvStartStop() );
31  myWatch.process_event( EvReset() );
32   return  0;
33}
34

现在我们有了所有的状态，�q�在适当的位�|�增加了所有的�q�移动作�Q�同时我们也向StopWatch发送了一些事件。这个状态机会尽职尽责的按我们的希望�q�行状态迁�U�，但依然现在还没有其它的动作�?/span>

1.3 State-local存储

下一步我们将让这个Stop watch真正的记录时间了。根据stop watch所处不同的状态，我们需要不同的变量�?/span>

l Stopped状态：需要一个保存逝去旉��的变量�?/span>

l Running状态：需要一个保存逝去旉��的变量，�q�需要一个保存上一�ơ启动的旉��点的变量�?/span>

无论状态机在什么状态下�Q�我们都必须观察逝去旉��q�个变量。此外，当我们向状态机发送EvReSet事�g�Ӟ��q�个变量应该被置�?。其它的变量只是状态机在Running状态时需要。无��Z��时我们进入Running状态时�Q�它应该被置为系�l�时钟的当前旉��。当我们退出Running状态时�Q�我们仅仅从�pȝ��旉��的当前时间减��d��始时��_��q�入时记录的旉��Q�，��结果加到逝去旉��里就可以了�?/span>

1#include <ctime>
2
3//
4
5struct  Stopped;
6struct  Active : sc::simple_state< Active, StopWatch, Stopped >
7{
8   public :
9     typedef  sc::transition< EvReset, Active > reactions;
10
11    Active() : elapsedTime_( 0.0 ) {}
12    double  ElapsedTime()  const  {  return  elapsedTime_; }
13    double  & ElapsedTime() {  return  elapsedTime_; }
14   private :
15     double  elapsedTime_ ;
16};
17
18struct  Running : sc::simple_state< Running, Active >
19{
20   public :
21     typedef  sc::transition< EvStartStop, Stopped > reactions;
22
23    Running() : startTime_( std::time( 0 ) ) {}
24    ~Running()
25    {
26       // 与派生类可以讉K��它的基类�怼��Q?br>27       //context<>() 用来获得一个状态的直接或间接的上下文的讉K��权�?br>28       // �q�可以是直接或间接的外层状态或状态机本��n
29       // (例如�Q�像�q�样: context< StopWatch >()).
30      context< Active >().ElapsedTime() +=
31        std::difftime( std::time( 0 ), startTime_ );
32    }
33   private :
34    std:: time_t  startTime_;
35};

�q�个状态机现在可以��量旉��了，但是我们�q�不能看到结果�?/span>

在这里，State-local storage的优势还没有完成昄��出来。在FAQ��目“State-local storage酷在哪里�Q?#8221;中，会通过与一个没有用State-local storage的Stop Watch的比较来说明�?/span>

1.4 在状态机外得到状态信�?/span>

��Z��取得��量的时��_��我们需要一个从状态机外得到状态信息的机制。按我们现在的状态机设计�Q�可以有两种�Ҏ��。�ؓ��单�v见，我们在这里用一个低效的方式�Q�state_cast<>()(在StopWatch2.cpp中我们会用一个稍复杂一点的替代�Ҏ��)�Q?span style="COLOR: #000080">译者注�Q�在StopWatch2.cpp中是向状态机发送一个取得逝去旉��的事�Ӟ��从事件成员量中将逝去旉��带回�?/span> �Q�，从字面意思就可以看出�Q�它在语义上与dynamic_cast有点�怼�。例如，当我们调用myWatch.state_cast()�Ӟ��当状态机在Stopped状态时�Q�我们会得到一个Stopped状态类的引用。否则，会抛出std::bad_cast异常。我们可以利用这个功能来实现一个StopWatch的成员函敎ͼ�让它的结果返回逝去的时间。然而，我们不是先问一下状态机在什么状态，然后再去用不同的�Ҏ��计算逝去旉��Q�而是��计��放到Stopped和Running状态中�Q�用一个接口来获得逝去逝去旉��?/span>

#include   
    
// ... 
    
struct  IElapsedTime  
    
{  
    
   virtual   double  ElapsedTime()  const  = 0;  
    
};  
    
struct  Active; 
    
struct  StopWatch : sc::state_machine< StopWatch, Active > 
    
{ 
    
   double  ElapsedTime()  const   
    
  {  
    
     return  state_cast<  const  IElapsedTime & >().ElapsedTime();  
    
  }  
    
}; 
    
// ... 
    
struct  Running : IElapsedTime,  
    
  sc::simple_state< Running, Active > 
    
{ 
    
   public : 
    
     typedef  sc::transition< EvStartStop, Stopped > reactions; 
    
    Running() : startTime_( std::time( 0 ) ) {} 
    
    ~Running() 
    
    { 
    
      context< Active >().ElapsedTime() = ElapsedTime();  
    
    }
    
     virtual   double  ElapsedTime()  const   
    
        {  
    
           return  context< Active >().ElapsedTime() +  
    
            std::difftime( std::time( 0 ), startTime_ );  
    
        }  
    
       private :  
    
        std:: time_t  startTime_;  
    
    };  
    
     struct  Stopped : IElapsedTime,  
    
      sc::simple_state< Stopped, Active > 
    
    { 
    
       typedef  sc::transition< EvStartStop, Running > reactions; 
    
       virtual   double  ElapsedTime()  const   
    
      {  
    
         return  context< Active >().ElapsedTime();  
    
      }  
    
    }; 
    
     int  main() 
    
    { 
    
      StopWatch myWatch; 
    
      myWatch.initiate(); 
    
      std::cout << myWatch.ElapsedTime() <<  "\n" ;  
    
      myWatch.process_event( EvStartStop() ); 
    
      std::cout << myWatch.ElapsedTime() <<  "\n" ;  
    
      myWatch.process_event( EvStartStop() ); 
    
      std::cout << myWatch.ElapsedTime() <<  "\n" ;  
    
      myWatch.process_event( EvStartStop() ); 
    
      std::cout << myWatch.ElapsedTime() <<  "\n" ;  
    
      myWatch.process_event( EvReset() ); 
    
      std::cout << myWatch.ElapsedTime() <<  "\n" ;  
    
       return  0; 
    
    }

��Z��实看到被测量的旉��Q�你应该惛_��法在main()中单步执行。StopWatch例子��这个程序扩展�ؓ一个交互式的终端程序了�?/span>

shaker(太子) 2010-08-16 14:53 发表评论

Boost的状态机库教�E?2)

shaker(太子) — Mon, 16 Aug 2010 06:45:00 GMT

1 基础主题�Q�秒�?/strong>
    下面我们要�ؓ一个机械秒表徏模一个状态机。这样一个秒表通常会有两个按钮�?br>     * Start/Stop
     * Reset
     同时有两�U�状态：
     * Stoped: 表针停留在上�ơ停止时的位�|�：
        o 按下Reset按钮�Q�表针回退�?的位�|�。秒表保持在Stoped状态不变�?br>        o 按下Start/Stop按钮�Q�秒表�{到Running状态�?br>     * Running: 表针在移动，�q�持�l�显�C��ȝ��旉��Q?/span>
        o 按下Reset按钮�Q�表针回退�?的位�|�，�U�表转到停止状态�?br>        o 按下Start/Stop按钮�Q��{到Stoped状态�?br>    下面是其UML图：

1.1 定义状态和事�g
两个按钮可以建模��Z��个事件。进而，定义出必要的状态和初始状态。我们从下面的代码开始，以前的代码片�D�会陆箋加入其中�Q?/span>

#include <boost/statechart/event.hpp>
#include <boost/statechart/state_machine.hpp>
#include <boost/statechart/simple_state.hpp>

namespace sc = boost::statechart;

struct EvStartStop : sc::event< EvStartStop > {};
struct EvReset : sc::event< EvReset > {};

struct Active;
struct StopWatch : sc::state_machine< StopWatch, Active > {};

struct Stopped;

// �q�里的simple_state�c�L��板可以接�?个参敎ͼ�
// - �W?个参数指定内部的初始状态，如果有一个这��L��状态的话�?br>//   在这里，Active有一个内部状态（Stoped�Q�，所以将�q�个内部
//   初始状态传�l�它的基�c�R�?br>// - �W?个参数指定是否保留和保留什么类型历�?br>
// Active是最外层的状态，因此要把它所属的状态机�c�M��l�它
struct Active : sc::simple_state<
  Active, StopWatch, Stopped > {};

// Stopped �?nbsp;Running 都把Active作�ؓ它们的上下文�Q�这使他们嵌入到了Active状态中�?/span>
struct Running : sc::simple_state< Running, Active > {};
struct Stopped : sc::simple_state< Stopped, Active > {};

// 因�ؓ状态的上下文必��L��一个完整的�c�d��Q�不能单单是声明�Q�，
// 所以状态机必须要在“外层状�?#8221;之间先定义�?br>// 也就是说�Q�我们需要从状态机开始，然后是最外层的状态，然后是其内部的状态，如此反复�?br>// 我们可以用广度或深度方式�Q�再或是以两都�؜合的方式来进行定义�?/span>

int main()
{
  StopWatch myWatch;
  myWatch.initiate();
  return 0;
}

�q�个代码已经可以�~�译了，但不会发生�Q何可察觉的事件�?br>

shaker(太子) 2010-08-16 14:45 发表评论

Boost的状态机库教�E?1)

shaker(太子) — Mon, 16 Aug 2010 06:42:00 GMT
介绍
    Boost状态机库一个应用程序框�Ӟ��你可以用它将UML状态图快速的转换为可执行的c++代码�Q�而不需要�Q何的代码生成器。它支持几乎所有的UML特征�Q�可以直接了当的转换�Q��ƈ且�{换后的c++代码��像对状态机�q�行一�ơ文本描�q�C��样具体可��L��?br>
如何阅读�q�个教程
�q�个教程是以�U�性阅�ȝ��方式�q�行的章节设计。如果你是第一�ơ看�q�个教程的话�Q�你可以从头开始读�Q�到你觉得了解的东西对你手头的�Q务来说已�l��够时��停止。具体可以这��P��
* 如果你的��d��是要实现一个小的、简单的�Q��ƈ且有很少几个状态的状态机�Q�那么下面的“初��主题�Q�秒�?#8221;里所讲的��差不多够你用的了�?br> * 如果你要做一个有很多状态的大型状态机�Q�你可以看一�?#8220;中��主题�Q�数码相�?#8221;�Q�那里的讲解可能对你有帮助�?br>    * 最后，如果你是一个要创徏异常复杂状态机的用��P��或者是一个想要评��C��个Boost状态机的设计师的话�Q�你��p��看一�?#8220;高��主题”部分。�ƈ且，我还强烈��你看一下Rationle里的Limitions部分�?br>
Hello World!
    我们��要从一个最��单程序开始我们的�W�一步，状态图如下�Q?br>
对于�q�个状态图�Q�我们的实现代码如下�Q?

1#include <boost/statechart/state_machine.hpp>
2#include <boost/statechart/simple_state.hpp>
3#include <iostream>
4
5namespace  sc = boost::statechart;
6
7// ��Z��避免写public�Q�下面声明的�c�d��全部为struct�?br> 8// 如果你不在乎的话可以把它们都�Ҏ��class�?br> 9
10// 我们需要先声明一下初始状态，�q�是因�ؓ我们要在定义状态机时��用它
11// 但又不得不在状态机�q�后定义它�?/span>
12
13struct  Greeting;
14
15// Boost.Statechart大量应用模板模式�?br>16// �z��c�d��d��自己做�ؓ基类模板的第一个参数�?br>17//
18// 状态机必须要知道当其初始化后进行的�W�一个状态�?br>19// �q�就是�ؓ什么Greeting要做为每二个模板参数�?br>20// �Q�译者注�Q�也��是说Greeting状态是Machine状态机初始化后�q�入的第一个状态）
21struct  Machine : sc::state_machine< Machine, Greeting > {};
22
23// 对于每一个状态，我们需要�ؓ其指明：它属于哪一个状态机�Q�它位于状态图的哪个位�|��?br>24// 我们用simple_state<>的上下文参数��可以完成这些指定了�?br>25// 对于我们目前的这个简单的状态机来说�Q�上下文��是状态机�Q�Machine)
26// 所以，Machine必须要做为simple_state的第二个模块参数�?br>27// �Q�关于上下文参数的详�l�解释在下一个例子中有）
28struct  Greeting : sc::simple_state< Greeting, Machine >
29{
30  // 一旦状态机�q�行一个状态的时候，它就要创��Z��个相应状态类的对象（�c�d��例）
31  // 只要状态机保持在这个状态下�Q�这个对象就会一直存在�?br>32  // 最后，当状态机��d��q�个状态时�Q�对象被销毁�?br>33  // 所以，一个状态的�q�入动作��是�q�个状态类的构造器�Q�而它的退出动作则是它的析构类�?nbsp;  Greeting() { std::cout <<  "Hello World!\n" ; }  // �q�入
34  ~Greeting() { std::cout <<  "Bye Bye World!\n" ; }  // 退�?/span>
35};
36
37int  main()
38{
39  Machine myMachine;
40  // 构造完状态机后，它�ƈ未开始运行。我们要通过调用它的initiate()来启动它�?br>41  // 同时�Q�它也将触发它的初始状态（Greeting�Q�的构造�?/span>
42  myMachine.initiate();
43  // 当我们离开main()函数�Ӟ��myMachine��被销毁，�q�将��D��它销毁它内部的所有活动的状态类�?br>44  // �Q�译者注�Q��ؓ什么会说所有？�q�是因�ؓ一个状态机可以同时保持在多个状态中�Q�可以参�?#8220;高��主题”部分�Q?/span>
45  return  0;
46}
�q�个�E�序会显�C?#8220;Hello World!”�?#8220; Bye Bye World! ”�Q�然后退出�?/span>

shaker(太子) 2010-08-16 14:42 发表评论

[转]RGB与YUV转换

shaker(太子) — Fri, 26 Mar 2010 12:27:00 GMT

1 前言

        自然界的颜色千变万化�Q��ؓ了给颜色一个量化的衡量标准�Q�就需要徏立色彩空间模型来描述各种各样的颜�Ԍ��׃��人对色彩的感知是一个复杂的生理和心理联合作�?的过�E�，所以在不同的应用领域中��Z��更好更准��的满��各自的需求，��出��C��各种各样的色彩空间模型来量化的描�q�颜艌Ӏ�我们比较常接触到的��包�?RGB / CMYK / YIQ / YUV / HSI�{�等�?/p>
        对于数字电子多媒体领域来��_��我们�l�常接触到的色彩�I�间的概念，主要是RGB , YUV�q�两�U�（实际上，�q�两�U�体�p�d��含了许多�U�具体的颜色表达方式和模型，如sRGB, Adobe RGB, YUV422, YUV420 …�Q? RGB是按三基色加光系�l�的原理来描�q�颜�Ԍ��而YUV则是按照亮度�Q�色差的原理来描�q�颜艌Ӏ?/p>
        即��只是RGB YUV�q�两大类色彩�I�间�Q�所涉及到的知识也是十分丰富复杂的，自知不具备��够的相关专业知识�Q�所以本文主要针对工�E�领域的应用及算法进行讨论�?/p>
2 YUV相关色彩�I�间模型

2.1 YUV �?YIQ YcrCb

        对于YUV模型�Q�实际上很多时候，我们是把它和YIQ / YCrCb模型混�ؓ一谈的�?/p>
        实际�?YUV模型用于PAL制式的电视系�l�，Y表示亮度�Q�UV�q��M��单词的羃写�?/p>
        YIQ模型与YUV模型�c�M��Q�用于NTSC制式的电视系�l�。YIQ颜色�I�间中的I和Q分量相当于将YUV�I�间中的UV分量做了一�?3度的旋�{�?/p>
        YCbCr颜色�I�间是由YUV颜色�I�间�z��的一�U�颜色空��_��主要用于数字电视�pȝ��中。从RGB到YCbCr的�{换中�Q�输入、输出都�?位二�q�制格式�?/p>
        三者与RGB的�{换方�E�如下：

        RGB -> YUV�Q?/p>

        实际上也��是�Q?/p>
Y=0.30R+0.59G+0.11B �Q?U=0.493(B�Q�Y) �Q?V=0.877(R�Q�Y)

        RGB -> YIQ�Q?/p>

        RGB -> YCrCb�Q?/p>

        从公式中�Q�我们关键要理解的一�Ҏ��Q�UV / CbCr信号实际上就是蓝色差信号和红色差信号�Q�进而言之，实际上一定程度上间接的代表了蓝色和红色的强度�Q�理解这一点对于我们理解各�U�颜色变换处理的�q�程会有很大的帮助�?/p>
        我们在数字电子多媒体领域所谈到的YUV格式�Q�实际上准确的说�Q�是以YcrCb色彩�I�间模型为基��的具有多�U�存储格式的一�c�颜色模型的家族�Q�包�?YUV444 / YUV422 / YUV420 / YUV420P�{�等�Q�。�ƈ不是传统意义上用于PAL制模拟电视的YUV模型。这些YUV模型的区别主要在于UV数据的采��h��式和存储方式�Q�这里就不详�q��?/p>
        而在Camera Sensor中，最常用的YUV模型�?YUV422格式�Q�因为它采用4个字节描�q�C��个像素，能和RGB565模型比较好的兼容。有利于Camera Sensor和Camera controller的��Y��g接口设计�?/p>
3 YUV2RGB快速算法分�?/p>
        �q�里指的YUV实际是YcrCb�?8 ) YUV2RGB的�{换公式本�w�是很简单的�Q�但是牵涉到��点�q�算�Q�所以，如果要实现快速算法，��法�l�构本��n没什么好研究的了�Q�主要是采用整型�q�算或者查表来加快计算速度�?br>首先可以推导得到转换公式为：

        R = Y + 1.4075 *�Q�V-128�Q?br>        G = Y – 0.3455 *�Q�U –128�Q?– 0.7169 *�Q�V –128�Q?br>        B = Y + 1.779 *�Q�U – 128�Q?/p>
3.1 整型��法

       要用整型�q�算代替��点�q�算�Q�当然是要用�U�M��的办法了�Q�我们可以很�Ҏ��得到下列��法�Q?/p>
        u = YUVdata[UPOS] - 128;
        v = YUVdata[VPOS] - 128;

        rdif = v + ((v * 103) >> 8);
        invgdif = ((u * 88) >> 8) +((v * 183) >> 8);
        bdif = u +( (u*198) >> 8);

        r = YUVdata[YPOS] + rdif;
        g = YUVdata[YPOS] - invgdif;
        b = YUVdata[YPOS] + bdif;

��Z��防止出现溢出�Q�还需要判错计��的�l�果是否�?-255范围内，做类��g��面的判断�?/p>
        if (r>255)
            r=255;
        if (r<0)
            r=0;

        要从RGB24转换成RGB565数据�q�要做移位和或运��：

        RGBdata[1] =( (r & 0xF8) | ( g >> 5) );
        RGBdata[0] =( ((g & 0x1C) << 3) | ( b >> 3) );

3.2 部分查表�?/p>
        查表法首先可以想到的��是用查表替代上�q�整型算法中的乘法运��?/p>
        rdif = fac_1_4075[u];
        invgdif = fac_m_0_3455[u] + fac_m_0_7169[v];
        bdif = fac_1_779[u];

        �q�里一共需�?�?�l�数�l�，下标�?开始到255�Q�表格共占用�U?K的内存空间。uv可以不需要做�?28的操作了。在事先计算对应的数�l�元素的值的时候计��在内就好了�?/p>
        对于每个像素�Q�部分查表法用查表替代了2�ơ减法运��和4�ơ乘法运��，4�ơ移位运��。但是，依然需要多�ơ加法运��和6�ơ比较运��和可能存在的赋值操作，相对�W�一�U�方法运��速度提高�q�不明显�?/p>
3.3 完全查表�?/p>
        那么是否可以由YUV直接查表得到对应的RGB值呢�Q�乍一看似乎不太可能，以最复杂的G的运��ؓ例，因�ؓG与YUV三者都相关�Q�所以类�?G=YUV2G[Y][U][V]�q�样的算法，一个三�l�下标尺寔R��?56的数�l�就需要占�?�?4�ơ方�U?6兆空��_��l�对是没法接受的。所以目前多数都是采用部分查表法�?/p>
        但是�Q�如果我们仔�l�分析就可以发现�Q�对于G我们实际上完全没有必要采用三�l�数�l�，因�ؓY只与UV�q�算的结果相养I��与UV的个体无养I��所以我们可以采用二�ơ查表的�Ҏ��G的运��简化�ؓ对两个二�l�数�l�的查表操作�Q�如下：

        G = yig2g_table[ y ][ uv2ig_table[ u ][ v ] ]�Q?/p>
        而RB本��n��只和YU或YV相关�Q�所以这��h��们一共需�?�?*8的二�l�表��|��需要占�?�?�?6�ơ方�?56K内存。基本可以接受。但是对于手��L��嵌入式运用来��_��q�是略有些大了�?/p>
        �q�一步分析，我们可以看到�Q�因为在手机�{�嵌入式�q�用上我们最�l�是要把数据转换成RGB565格式送到LCD屏上昄��的，所以，对于RGB三分量来��_��我们 �Ҏ��不需�?bit�q�么高的�_�ֺ��Q��ؓ了简单和�q�算的统一赯��Q�对每个分量我们其实只需要高6bit的数据就��_��了，所以我们可以进一步把表格改�ؓ4�?6*6的二�l�表��|��q�样一共只需要占�?6K内存�Q�在计算表格元素值的时候还可以把最�l�的溢出判断也事先做完。最后的��法如下�Q?/p>
        y = (YUVdata[Y1POS] >> 2);
        u = (YUVdata[UPOS] >> 2);
        v = (YUVdata[VPOS] >> 2);

        r = yv2r_table[ y ][ v ];
        g = yig2g_table[ y ][ uv2ig_table[ u ][ v ] ];
        b = yu2b_table[ y ][ u ];

        RGBdata[1] =( (r & 0xF8) | ( g >> 5) );
        RGBdata[0] =( ((g & 0x1C) << 3) | ( b >> 3) );

        �q�样相对部分查表法，我们增加�?�ơ移位运��，而进一步减��了4�ơ加法运��和6�ơ比较赋值操作�?/p>
        在计��表格元素数值的时候，要考虑舍入和偏�Uȝ��因数使得计算的中间结果满��x��l�下标非负的要求�Q�需要一定的技巧�?/p>
        采用完全查表法，相对于第一�U�算法，最�l�运��速度可以有比较明昄��提高�Q�具体性能能提高多��，要看所在��^台的CPU�q�算速度和内存存取速度的相�Ҏ��例。内存存取速度��快�Q�用查表法带来的性能改善��明显。在我的PC上测试的�l�果性能大约能提�?5%。而在某ARM�q�_��上测试只提高了约15%�?/p>
3.4 �q�一步的思�?/p>
        实际上，上述��法�Q?/p>
        RGBdata[1] =( (r & 0xF8) | ( g >> 5) );
        RGBdata[0] =( ((g & 0x1C) << 3) | ( b >> 3) );

        中的 (r & 0xF8) �?( b >> 3) �{�运��也完全可以在表��g��事先计算出来。另外，YU / YV的取值实际上不可能覆盖满6*6的范��_��中间有些�Ҏ��永远取不到的无输入，RB的运��也可以考虑�?*5的表根{��这些都可能�q�一步提高运��的速度�Q�减 ��表格的��寸�?/p>
        另外�Q�在嵌入式运用中�Q�如果可能尽量将表格攑֜�高速内存如SRAM中应该比攑֜�SDRAM中更加能发挥查表法的优势�?/p>
4 RGB2YUV ?

        目前觉得�q�个是没法将3�l�表格的查表�q�算化简�?�l�表格的查表�q�算了。只能用部分查表法替代其中的乘法�q�算�?/p>
        另外�Q�多数情况下�Q�我们需要的�q�是YUV2RGB的�{换，因�ؓ从Sensor得到的数据通常我们会用YUV数据�Q�此外JPG和MPEG实际上也是基于YUV格式�~�码的，所以要昄��解码后的数据需要的也是YUV2RGB的运��?8 �Q�运气运气�?/p>

本文来自CSDN博客�Q��{载请标明出处�Q?a >http://blog.csdn.net/ALENTAM/archive/2008/03/13/2178020.aspx

shaker(太子) 2010-03-26 20:27 发表评论

一个简易的采集�pȝ��

shaker(太子) — Sun, 08 Nov 2009 15:14:00 GMT
     摘要: �l�手之作,��Z��实现一些自��q��x��,见笑见笑!~
  阅读全文

shaker(太子) 2009-11-08 23:14 发表评论

shaker(太子) — Mon, 04 May 2009 09:29:00 GMT
     摘要:   阅读全文

shaker(太子) 2009-05-04 17:29 发表评论

shaker(太子) — Fri, 01 Aug 2008 10:19:00 GMT
     摘要: PolicyScope  阅读全文

shaker(太子) 2008-08-01 18:19 发表评论

BCGSoft announces that BCGControlBar Pro for MFC version 10.0 is available!

shaker(太子) — Mon, 09 Jun 2008 04:45:00 GMT
     摘要: BCGSoft is proud to announce that the next generation of BCGControlBar Pro - version 10.0 is available now!   阅读全文

shaker(太子) 2008-06-09 12:45 发表评论

BCGControlBar Library Professional Edition v9.56

shaker(太子) — Wed, 13 Feb 2008 03:15:00 GMT
     摘要: BCGControlBar ("Business Components Gallery ControlBar") is an MFC extension library that allows you to create Microsoft�] Office 2000/XP/2003/2007 and Microsoft�] Visual Studio-like applications with full customization options (ribbons, customizable toolbars, menus, keyboard and more).   阅读全文

shaker(太子) 2008-02-13 11:15 发表评论

[ZT]C++ Boost Thread �~�程指南

shaker(太子) — Fri, 05 Oct 2007 16:05:00 GMT
     摘要: C++ Boost Thread �~�程指南   阅读全文

shaker(太子) 2007-10-06 00:05 发表评论

C++Builder2007 安装办法

shaker(太子) — Fri, 05 Oct 2007 15:06:00 GMT
     摘要: 转自:http://www.ccrun.com/article.asp?i=1022&d=j0q784  阅读全文

shaker(太子) 2007-10-05 23:06 发表评论

shaker(太子) — Thu, 27 Sep 2007 05:08:00 GMT
     摘要: PDF文�g  阅读全文

shaker(太子) 2007-09-27 13:08 发表评论

shaker(太子) — Tue, 28 Aug 2007 15:59:00 GMT
     摘要: �q�时的游�?反正攑֜��盘里面烂掉不如发出�?看看有没人需�?nbsp; 阅读全文

shaker(太子) 2007-08-28 23:59 发表评论

shaker(太子) — Tue, 28 Aug 2007 15:40:00 GMT
使用boost::signals�q�接�c�L��员函�?参照boost的手�?a >http://www.boost.org/doc/html/signals/tutorial.html#id1627926 的写法似乎在VS2005中编译不�q?不知道是新的版本更新了还是手册的bug
应该使用�c�M��以下的方�?

    m_Game.sig_HpChange.connect(boost::bind(&CMainFrame::OnHpChange,boost::ref(*this),_1,_2));

shaker(太子) 2007-08-28 23:40 发表评论

write a simple os with asm&c

shaker(太子) — Sat, 19 May 2007 16:26:00 GMT
     摘要: 太simple�?  阅读全文

shaker(太子) 2007-05-20 00:26 发表评论

shaker(太子) — Mon, 23 Apr 2007 15:44:00 GMT
     摘要: CStreamPacket: 为无固定�l�构的网�l�数据包传送设计的.  阅读全文

shaker(太子) 2007-04-23 23:44 发表评论

用boost::regex来做词法分析

shaker(太子) — Wed, 11 Apr 2007 07:20:00 GMT
     摘要: boost:regex的小��应�?nbsp; 阅读全文

shaker(太子) 2007-04-11 15:20 发表评论

MSDN的Bug!

shaker(太子) — Wed, 28 Feb 2007 14:59:00 GMT
msdn原文

CListCtrl::SortItems

This method sorts list view items using an application-defined comparison function. The index of each item changes to reflect the new sequence.

BOOL SortItems( PFNLVCOMPARE pfnCompare, DWORD dwData);
Parameters
pfnCompare
Specifies the address of the application-defined comparison function. The comparison function is called during the sort operation each time the relative order of two list items needs to be compared. The comparison function must be either a static member of a class or a standalone function that is not a member of any class.
dwData
Specifies the application-defined value that is passed to the comparison function.
Return Value

Nonzero if it is successful; otherwise, it is zero. Remarks
The comparison function has the following form:
int CALLBACK CompareFunc(LPARAM lParam1, LPARAM lParam2,   LPARAM lParamSort);

The comparison function must return a negative value if the first item should precede the second, a positive value if the first item should follow the second, or zero if the two items are equivalent.
The lParam1 and lParam2 parameters specify the item data for the two items being compared. The lParamSort parameter is the same as the dwData value.

Example

// Sort the item in reverse alphabetical order.
static int CALLBACK
MyCompareProc(LPARAM lParam1, LPARAM lParam2, LPARAM lParamSort)
{
   // lParamSort contains a pointer to the list view control.
   CListCtrl* pListCtrl = (CListCtrl*) lParamSort;
   CString    strItem1 = pListCtrl->GetItemText(lParam1, 0);
   CString    strItem2 = pListCtrl->GetItemText(lParam2, 0);

   return strcmp(strItem2, strItem1);
}

void snip_CListCtrl_SortItems()
{
   // The pointer to my list view control.
   extern CListCtrl* pmyListCtrl;

   // Sort the list view items using my callback procedure.
   pmyListCtrl->SortItems(MyCompareProc, (LPARAM) pmyListCtrl);
}

例子中的代码是不能按照预想的工作�? 因�ؓ回调函数接收�?个参数是�?strong>SetItemData传入的�?而不是Item的Index!

shaker(太子) 2007-02-28 22:59 发表评论