C++博客-To Be C++

Neocs

shaker(太子) — Tue, 08 Apr 2014 15:13:00 GMT

摘要:
阅读全文

shaker(太子) 2014-04-08 23:13 发表评论

Relocate SVN

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

自己搞点小东西用的到。
在工程的根目录里建一个svn目录，然后在svn目录里创建一个版本库，用svn检出一下。
这样这个工程就可以被svn管理了。
但是如果整个工程被移动过了，那么svn就会出错，于是写了个小程序来重定位，从此可以把工程放在u盘带着到处跑了。

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<<"建立进程错误;"< 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","结果",MB_OK|MB_ICONINFORMATION);
105         return 0;
106     }
107     node=node->FirstChild("entry");
108     if(node==NULL)
109     {
110         MessageBox(NULL,"当前目录没有被SVN","结果",MB_OK|MB_ICONINFORMATION);
111         return 0;
112     }
113     node=node->FirstChild("wc-info");
114     if(node==NULL)
115     {
116         MessageBox(NULL,"当前目录没有被SVN","结果",MB_OK|MB_ICONINFORMATION);
117         return 0;
118     }
119     node=node->FirstChild("wcroot-abspath");
120     if(node==NULL)
121     {
122         MessageBox(NULL,"当前目录没有被SVN","结果",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(),"结果",MB_OK);
151
152     return 0;
153 }

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

LISTVIEW_LButtonDown

shaker(太子) — Thu, 15 Sep 2011 13:45:00 GMT

摘要: 阅读全文

shaker(太子) 2011-09-15 21:45 发表评论

又是一个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

异步过程调用(APCs) 是NT异步处理体系结构中的一个基础部分，理解了它，对于了解NT怎样操作和执行几个核心的系统操作很有帮助。

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

上面是网上找来的，下面是MSDN上的说明：

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.

还先看一下那些重要结构：

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
…………

…………

上面红色部分是APC机制用到的几个字段！！

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

显然，这里的 ApcListHead 就是 APC 队列头。不过这是个大小为 2 的数组，说明实际
上(每个线程)有两个 APC 队列。这是因为 APC 函数分为用户 APC 和内核 APC 两种，各有
各的队列。所谓用户 APC，是指相应的 APC 函数位于用户空间、在用户空间执行；而内核
APC，则相应的 APC 函数为内核函数。

SavedApcState也是个_KAPC_STATE结构，当当前程暂时“挂靠(Attach)”到另一个进程的地址空间的时侯，ApcState就拷贝到SavedApcState暂时存放！

当然，还要有状态信息说明本线程当前是处于“原始环境”还是“挂靠环境”，这就是 ApcStateIndex 的作用，代码中为 ApcStateIndex的值定义了一种枚举类型：

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

实际可用于 ApcStateIndex 的只是 OriginalApcEnvironment和 AttachedApcEnvironment。

KAPC_STATE 指针数组 ApcStatePointer[2]，就用ApcStateIndex 的当前值作为下标，而数组中的指针则根据情况可以分别指向两个APC_STATE 数据结构中的一个。

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 函数的请求者所提供的函数，其余两个都是辅助性的！

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
);

这个函数主要用来初始化Apc（_KAPC）这个结构的，如果Environment==CurrentApcEnvironment,Apc->ApcStateIndex就由KTHREAD中的ApcStateIndex决定，但Environment不能大于KTHREAD中的ApcStateIndex！

最后，APC 请求的模式ProcessorMode，但是有个例外，那就是：如果指针NormalRoutine 为 0，那么实际的模式变成了 KernelMode。这是因为在这种情况下没有用户空间APC函数可以执行，唯一将得到执行的是KernelRoutine！

最后，KeInitializeApc 设置Inserted域为FALSE。然而初始化APC对象，并没有把它存放到相应的APC队列中。

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

据APC请求的具体情况，有时候要插在队列的前头，一般则挂在队列的尾部。

_KiServiceExit:

cli ; disable interrupts
DISPATCH_USER_APC ebp, ReturnCurrentEax

;
; Exit from SystemService
;

EXIT_ALL NoRestoreSegs, NoRestoreVolatile ;这个宏以后再讲

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 ;条件宏汇编，如果ReturnCurrentEax参数不为空，则编译！

;DISPATCH_USER_APC ebp, ReturnCurrentEax，显然这里是编译的！
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 ; 注意这个循环！！

ALIGN 4
a:
endm

这段代码主要检查：

即将返回的是否用户空间。
是否有用户APC请求正在等待执行

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

前面讲过，KTHREAD 中有两个 KAPC_STATE 数据结构，一个是 ApcState，另一个是SavedApcState，二者都有APC 队列，但是要投递的只是ApcState 中的队列。

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

这个函数里面还比较复杂，代码不帖了。

参数PreviousMode表示需要“投递”哪一种 APC，可以是UserMode，也可以是KernelMode。不过，KernelMode 确实表示只要求执行内核 APC，而UserMode 却表示在执行内核 APC 之外再执行用户APC。

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. （run IRQL = PASSIVE_LEVEL）
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.
从代码的角度看是这样的：

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肯定不为空。并且，如果NormolRoutine也不为空，那么KernelRoutine都在NormolRoutine被调用前被调用！！

上文中讲到投递User Mode APCs是很特殊的，道理很简单，因为User Mode APC是ring3下的回调函数，显然ring0中的KiDeliverAPC（）不能像Kernel Mode APC那样直接call，必须要先回到ring3环境下。当然不能像普通情况那样返回（否则就回到ring3系统调用的地方了），只有一个办法，那就是修改TrapFrame ，欺骗系统返回“APC回调函数”！KiInitializeUserApc就是这么做的！

该函数首先把TrapFrame转化为ContextFrame，然后移动用户态ESP指针，分配大约sizeof（CONTEXT）+sizeof（KAPC_RECORD）个字节:

UserStack-> ……

KAPC_RECORD

……

CONTEXT

TopOfStack-> ……

KAPC_RECORD就是KiInitializeUserApc的最后四个参数

nt!_KAPC_RECORD

+0x000 NormalRoutine : Ptr32 void

+0x004 NormalContext : Ptr32 Void

+0x008 SystemArgument1 : Ptr32 Void

+0x00c SystemArgument2 : Ptr32 Void

CONTEXT结构主要来存放被修改前的TrapFrame，之所以用CONTEXT结构是跟APC函数返回有关！

TrapFrame->HardwareEsp = UserStack;

TrapFrame->Eip = (ULONG)KeUserApcDispatcher;

TrapFrame->ErrCode = 0;

从上面的代码看到确实修改了TrapFrame，并且返回到的是ring3下的KeUserApcDispatcher，刚才说的_KAPC_RECORD其实也是它的参数！真正我们的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结构

call _ZwContinue@8

;;不会返回到这里的

上面的代码并不难理解，我们的User APC回调函数返回后，立即调用了ZwContinue，这是个ntdll中的导出函数，这个函数又通过系统调用进入kernel中的NtContinue！

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不为空，它会设置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结构转化成TrapFrame（回复原来的陷阱帧），然后就从KiServiceExit2处退出系统调用！

;++

;

; _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差不多，只是宏参数的不同!同样如果还有User APC又会进入上文描述的情形，直到没有User APC，至此才会返回真正发起原始系统调用的地方！

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/better0332/archive/2009/06/29/4306683.aspx

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

[zt]谈谈对APC的一点理解

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

异步过程调用(APCs) 是NT异步处理体系结构中的一个基础部分，理解了它，对于了解NT怎样操作和执行几个核心的系统操作很有帮助。

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

尽管APCs在nt体系结构下被广泛使用，但是关于怎样使用它的文档却非常的缺乏。本篇我们详细介绍下nt系统是怎样处理APCs的，并且记录导出的nt函数，方便设备驱动开发者在他们的程序中使用APCs。我也会展示一个非常可靠的NT的APC调度子程序KiDeliverApc的实现，来帮助你更好的掌握APC调度的内幕。

APC对象

在NT中，有两种类型的APCs：用户模式和内核模式。用户APCs运行在用户模式下目标线程当前上下文中，并且需要从目标线程得到许可来运行。特别是，用户模式的APCs需要目标线程处在alertable等待状态才能被成功的调度执行。通过调用下面任意一个函数，都可以让线程进入这种状态。这些函数是：KeWaitForSingleObject, KeWaitForMultipleObjects, KeWaitForMutexObject, KeDelayExecutionThread。
对于用户模式下，可以调用函数SleepEx, SignalObjectAndWait, WaitForSingleObjectEx, WaitForMultipleObjectsEx,MsgWaitForMultipleObjectsEx 都可以使目标线程处于alertable等待状态，从而让用户模式APCs执行,原因是这些函数最终都是调用了内核中的KeWaitForSingleObject, KeWaitForMultipleObjects, KeWaitForMutexObject, KeDelayExecutionThread等函数。另外通过调用一个未公开的alert-test服务KeTestAlertThread，用户线程可以使用户模式APCs执行。

当一个用户模式APC被投递到一个线程，调用上面的等待函数，如果返回等待状态STATUS_USER_APC，在返回用户模式时，内核转去控制APC例程，当APC例程完成后，再继续线程的执行.

和用户模式APCs比较，内核模式APCs执行在内核模式下。可以被划分为常规的和特殊的两类。当APCs被投递到一个特殊的线程，特殊的内核模式APCs不需要从线程得到许可来运行。然而，常规的内核模式APCs在他们成功执行前，需要有特定的环境。此外，特殊的内核APC被尽可能快地执行，既只要APC_LEVEL级上有可调度的活动。在很多情况下，特殊的内核APC甚至能唤醒阻塞的线程。普通的内核APC仅在所有特殊APC都被执行完，并且目标线程仍在运行，同时该线程中也没有其它内核模式APC正执行时才执行。用户模式APC在所有内核模式APC执行完后才执行，并且仅在目标线程有alertable属性时才执行。

每一个等待执行的APC都存在于一个线程执行体，由内核管理的队列中。系统中的每一个线程都包含两个APC队列，一个是为用户模式APCs,另一个是为内核模式APCs的。
NT通过一个成为KAPC的内核控制对象来描述一个ＡＰＣ．尽管ＤＤＫ中没有明确的文档化ＡＰＣｓ，但是在NTDDK.H中却非常清楚的定义了ＡＰＣ对象。从下面的KAPC对象的定义看，有些是不需要说明的。像Type和Size。Type表示了这是一个APC内核对象。在nt中，每一个内核对象或者执行体对象都有Type和Size这两个域。由此处理函数可以确定当前处理的对象。Size表示一个字对齐的结构体的大小。也就是指明了对象占的内存空间大小。Spare0看起来有些晦涩难懂，但是它是没用什么任何深远的意义，仅仅是为了内存补齐。其他的域将在下面的篇幅中介绍。

//-------------------------------------------------------------------------------------------------------

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

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环境

一个线程在它执行的任意时刻，假设当前的IRQL是在Passive级，它可能需要临时在其他的进程上下文中执行代码，为了完成这个操作，线程调用系统功能函数KeAttachProcess，在从这个调用返回时，线程执行在另一个进程的地址空间。先前所有在线程自己的进程上下文中等待执行的APCs,由于这时其所属进程的地址空间不是当前可用的，因此他们不能被投递执行。然而，新的插入到这个线程的APCs可以执行在这个新的进程空间。甚至当线程最后从新的进程中分离时，新的插入到这个线程的APCs还可以在这个线程所属的进程上下文中执行。
为了达到控制APC传送的这个程度，NT中每个线程维护了两个APC环境或者说是状态。每一个APC环境包含了用户模式的APC队列和内核模式的APC队列，一个指向当前进程对象的指针和三个控制变量，用于指出：是否有未决的内核模式APCs(KernelApcPending),是否有常规内核模式APC在进行中(KernelApcInProgress)，是否有未决的用户模式的APC(UserApcPending). 这些APC的环境保存在线程对象的ApcStatePointer域中。这个域是由2个元素组成的数组。即：+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环境是位于线程对象的ApcState 域，即：
+0x034 ApcState : _KAPC_STATE

线程中等待在当前进程上下文中执行的APC保存在ApcState的队列中。无论何时，NT的APC派发器(dispatcher)和其他系统元件查询一个线程未决的APCs时, 他们都会检查主APC环境，如果这里有任何未决的APCs,就会马上被投递，或者修改它的控制变量稍后投递。

第二个APC环境是位于线程对象的SavedApcState域，当线程临时挂接到其他进程时，它是用来备份主APC环境的。

当一个线程调用KeAttachProcess，在另外的进程上下文中执行后续的代码时，ApcState域的内容就被拷贝到SavedApcState域。然后ApcState域被清空，它的APC队列重新初始化，控制变量设置为0，当前进程域设置为新的进程。这些步骤成功的确保先前在线程所属的进程上下文地址空间中等待的APCs，当线程运行在其它不同的进程上下文时，这些APCs不被传送执行。随后，ApcStatePointer域数组内容被更新来反映新的状态，数组中第一个元素指向SavedApcState域，第二个元素指向ApcState域，表明线程所属进程上下文的APC环境位于SavedApcState域。线程的新的进程上下文的APC环境位于ApcState域。最后，当前进程上下文切换到新的进程上下文。

对于一个APC对象，决定当前APC环境的是ApcStateIndex域。ApcStateIndex域的值作为ApcStatePointer域数组的索引来得到目标APC环境指针。随后，目标APC环境指针用来在相应的队列中存放apc对象.

当线程从新的进程中脱离时(KeDetachProcess), 任何在新的进程地址空间中等待执行的未决的内核APCs被派发执行。随后SavedApcState 域的内容被拷贝回ApcState域。SavedApcState 域的内容被清空，线程的ApcStateIndex域被设为OriginalApcEnvironment，ApcStatePointer域更新，当前进程上下文切换到线程所属进程。

使用APCs

设备驱动程序使用两个主要函数来利用APCs, 第一个是KeInitializeApc，用来初始化APC对象。这个函数接受一个驱动分配的APC对象，一个目标线程对象指针，APC环境索引（指出APC对象存放于哪个APC环境），APC的kernel,rundown和normal例程指针，APC类型（用户模式或者内核模式）和一个上下文参数。函数声明如下：

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，那么ApcStateIndex域设置为目标线程的ApcStateIndex域。否则，ApcStateIndex域设置为参数Environment的值。随后，函数直接用参数设置APC对象Thread，RundownRoutine，KernelRoutine域的值。为了正确地确定APC的类型，KeInitializeApc 检查参数NormalRoutine的值，如果是NULL，ApcMode域的值设置为KernelMode，NormalContext域设置为NULL。如果NormalRoutine的值不是NULL，这时候它一定指向一个有效的例程，就用相应的参数来设置ApcMode域和NormalContext域。最后，KeInitializeApc 设置Inserted域为FALSE.然而初始化APC对象，并没有把它存放到相应的APC队列中。

从这个解释看，你可以了解到APCs对象如果缺少有效的NormalRoutine，就会被当作内核模式APCs.尤其是它们会被认为是特殊的内核模式APCs.
实际上，I/O管理器就是用这类的APC来完成异步I/O操作。相反地，APC对象定义了有效的NormalRoutine，并且ApcMode域是KernelMode，就会被当作常规的内核模式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
);
//------------------

通常，无论是什么类型，每个APC对象必须要包含一个有效的KernelRoutine 函数指针。当这个APC被NT的APC dispatcher传送执行时，这个例程首先被执行。用户模式的APCs必须包含一个有效的NormalRoutine 函数指针，这个函数必须在用户内存区域。同样的，常规内核模式APCs也必须包含一个有效的NormalRoutine，但是它就像KernelRoutine一样运行在内核模式。作为可选择的，任意类型的APC都可以定义一个有效的RundownRoutine，这个例程必须在内核内存区域，并且仅仅当系统需要释放APC队列的内容时，才被调用。例如线程退出时，在这种情况下，KernelRoutine和NormalRoutine都不执行，只有RundownRoutine执行。没有这个例程的APC对象会被删除。

记住，投递APCs到一个线程的动作，仅仅是操作系统调用KiDeliverApc完成的。执行APC实际上就是调用APC内的例程。

一旦APC对象完成初始化后，设备驱动调用KeInsertQueueApc来将APC对象存放到目标线程的相应的APC队列中。这个函数接受一个由KeInitializeApc完成初始化的APC对象指针，两个系统参数和一个优先级增量。跟传递给KeInitializeApc函数的参数context 一样，这两个系统参数只是在APC的例程执行时，简单的传递给APC的例程。

NTKERNELAPI
BOOLEAN
KeInsertQueueApc (
IN PRKAPC Apc,
IN PVOID SystemArgument1,
IN PVOID SystemArgument2,
IN KPRIORITY Increment
);
//-----------------
在KeInsertQueueApc 将APC对象存放到目标线程相应的APC队列之前，它首先检查目标线程是否是APC queueable。如果不是，函数立即返回FALSE.如果是，函数直接用参数设置SystemArgument1域和SystemArgument2 域，随后，函数调用KiInsertQueueApc来将APC对象存放到相应的APC队列。

KiInsertQueueApc 仅仅接受一个APC对象和一个优先级增量。这个函数首先得到线程APC队列的spinlock并且持有它，防止其他线程修改当前线程的APC结构。随后，检查APC对象的Inserted 域。如果是TRUE,表明这个APC对象已经存放到APC队列中了，函数立即返回FALSE.如果APC对象的Inserted 域是FALSE.函数通过ApcStateIndex域来确定目标APC环境，然后把APC对象存放到相应的APC队列中，即将APC对象中的ApcListEntry 域链入到APC环境的ApcListHead域中。链入的位置由APC的类型决定。常规的内核模式APC,用户模式APC都是存放到相应的APC队列的末端。相反的，如果队列中已经存放了一些APC对象，特殊的内核模式APC存放到队列中第一个常规内核模式APC对象的前面。如果是内核定义的一个当线程退出时使用的用户APC,它也会被放在相应的队列的前面。然后，线程的主APC环境中的UserApcPending域杯设置为TRUE。这时KiInsertQueueApc 设置APC对象的Inserted 域为TRUE，表明这个APC对象已经存放到APC队列中了。接下来，检查这个APC对象是否被排队到线程的当前进程上下文APC环境中，如果不是，函数立即返回TRUE。如果这是一个内核模式APC，线程主APC环境中的KernelApcPending域设置为TRUE。

在WIN32 SDK文档中是这样描述APCs的：当一个APC被成功的存放到它的队列后，发出一个软中断，APC将会在线程被调度运行的下一个时间片执行。然而这不是完全正确的。这样一个软中断，仅仅是当一个内核模式的APC（无论是常规的内核模式APC还是特殊的内核模式APC）针对于调用线程时，才会发出。随后函数返回TRUE。

1）如果APC不是针对于调用线程，目标线程在Passive权限等级处在等待状态；
2）这是一个常规内核模式APC
3）这个线程不再临界区
4）没有其他的常规内核模式APC仍然在进行中
那么这个线程被唤醒，返回状态是STATUS_KERNEL_APC。但是等待状态没有aborted。如果这是一个用户模式APC，KiInsertQueueApc检查判断目标线程是否是alertable等待状态，并且WaitMode域等于UserMode。如果是，主APC环境的UserApcPending 域设置为TRUE。等待状态返回STATUS_USER_APC，最后，函数释放spinlock，返回TRUE，表示APC对象已经被成功放入队列。
早期作为APC管理函数的补充，设备驱动开发者可以使用未公开的系统服务NtQueueApcThread来直接将一个用户模式的APC投递到某个线程。
这个函数内部实际上是调用了KeInitializeApc 和KeInsertQueueApc 来完成这个任务。

NTSYSAPI
NTSTATUS
NTAPI
NtQueueApcThread (
IN HANDLE Thread,
IN PKNORMAL_ROUTINE NormalRoutine,
IN PVOID NormalContext,
IN PVOID SystemArgument1,
IN PVOID SystemArgument2
);

NT的APC派发器

NT检查是否线程有未决的APCs. 然后APC派发器子程序KiDeliverApc在这个线程上下文执行来开始将未决的APC执行。注意，这个行为中断了线程的正常执行流程，首先将控制权给APC派发器，随后当KiDeliverApc完成后，继续线程的执行。
例如：当一个线程被调度运行时，最后一步，上下文切换函数 SwapContext 用来检查是否新的线程有未决的内核APCs.如果是，SwapContext要么（1）请求一个APC级别的软中断来开始APC执行，由于新线程运行在低的IRQL（Passive级别。
或者（2）返回TRUE，表示新的线程有未决的内核APCs。

究竟是执行(1)还是(2)取决于新线程所处的IRQL级别. 如果它的权限级别高于Passive级,SwapContext 执行(1),如果它是在Passive级,则选择执行(2).
SwapContext的返回值仅仅是特定系统函数可用的,这些系统函数调用SwapContext来强制切换线程上下文到另一个线程. 然后,当这些系统函数经过一段时间再继续时,他们通常检查SwapContext 的返回值,如果是TRUE,他们就会调用APC派发器来投递内核APCs到当前的线程. 例如:
系统函数KiSwapThread被等待服务用来放弃处理器，直到等待结束。这个函数内部调用SwapContext。当等待结束，继续从调用SwapContext处执行时，就会检查SwapContext的返回值。如果是TRUE，KiSwapThread会降低IRQL级别到APC级，然后调用KiDeliverApc来在当前线程执行内核APCs.
对于用户APCs, 内核调用APC派发器仅仅是当线程回到用户模式，并且线程的主APC环境的UserApcPending域为TRUE时。例如：当系统服务派发器KiSystemService完成一个系统服务请求正打算回到用户模式时，它会检查是否有未决的用户APCs。在执行上，KiDeliverApc调用用户APC的KernelRoutine. 随后，KiInitializeUserApc函数被调用，用来设置线程的陷阱帧。所以从内核模式退出时，线程开始在用户模式下执行
。KiInitializeUserApc的函数的作用是拷贝当前线程先前的执行状态（当进入内核模式时，这个状态保存在线程内核栈创建的陷阱帧里），从内核栈到线程的用户模式栈，初始化用户模式APC。APC派发器子程序KiUserApcDispatcher在Ntdll.dll内。最后，加载陷阱帧的EIP寄存器和Ntdll.dll中KiUserApcDispatcher的地址。当陷阱帧最后释放时，内核将控制转交给KiUserApcDispatcher，这个函数调用APC的NormalRoutine例程，NormalRoutine函数地址以及参数都在栈中，当例程完成时，它调用NtContinue来让线程利用在栈中先前的上下文继续执行，仿佛什么事情也没有发生过。

当内核调用KiDeliverApc来执行一个用户模式APC时，线程中的PreviousMode域被设为UserMode. TrapFrame域指向线程的陷阱帧。当内核调用KiDeliverApc来执行内核APCs时，线程中的PreviousMode域被设为KernelMode. TrapFrame域指向NULL。
注意，无论何时只要KernelRoutine被调用，传递给它的指针是一个局部的APC属性的副本，由于APC对象已经脱离了队列，所以可以安全的在KernelRoutine中释放APC内存。此外，这个例程在它的参数被传递给其他例程之前，有一个最后的机会来修改这些参数。

结论：
APC提供了一个非常有用的机制，允许在特定的线程上下文中异步的执行代码。作为一个设备驱动开发者，你可以依赖APCs在某个特定的线程上下文中执行一个例程，而不需要线程的许可和干涉。对于用户应用程序，用户模式APCs可以用来有效地实现一些回调通知机制。

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网络体系结构总结

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

标题: Windows网络体系结构总结
作者: jbwang
时间: 2009-11-23,11:22:25
链接: http://bbs.pediy.com/showthread.php?t=101794

做了一些东西自己也看了一些书，最近总结了一下，想给大家分享一下，高手可以飞过了。如果有什么问题可以给小弟指正一下，多谢！

在介绍Windows网络体系架构之前，我首先介绍一下Windows中的两个重要编程规范——TDI，NDIS.，然后再介绍网络体系的架构。
TDI，Transport Driver Interface，传输驱动程序接口。\Windows\System32\Drivers\Tdi.sys
在实现网络API驱动程序时，由于牵涉到很多不同协议，会用到不同协议驱动提供的接口，使得开发的工作复杂化。所以Microsoft在网络API驱动程序和协议驱动之间又增加了一层TDI。TDI接口只是一种"将网络请求格式化成IRP，以及申请网络地址和数据通信"的做法规范化。遵从TDI标准的传输协议向他们的客户（如Socket emulator，Netbios emulator等）导出了TDI接口，有利于上下层之间的通信：
 一方面，对于TDI上层的网络API驱动程序就不需要使用所有协议驱动程序所提供的接口，直接使用TDI提供的统一接口。
 另一方面，对于下层协议驱动程序（也称为TDI Transport Provider传输器）直接由TDI接口来调用，发出请求。

在Windows VISTA版本之后，TDI就不再使用了，取而代之的是Windows filter platform和Winsock kernel。

NDIS，Network Driver Interface Specification，网络驱动程序接口规范，在操作系统中的位置
\Windows\System32\Drivers\NDIS.sys
当一个协议驱动程序想要按照其协议的格式解析网上读写的数据时，而这些数据必须通过网络适配器才能取得，期望协议驱动程序能够理解市场上的每一款网络适配器的细微区别是不可能的。所以在1989年，由Microsoft和3Com联合开发的了NDIS，使得协议驱动程序可以以一种与设备无关的方式来跟网络适配器驱动程序进行通信。遵从NDIS的网络适配器驱动程序称为NDIS minport driver。

NDIS规范实现了与TDI标准类似的功能，都是将复杂的下层调用规范化、标准化，大大提高了Windows操作系统的可扩展性和兼容性。也表现在两个方面：
 对于下层，让网络适配器制造商很easy的开发自己的设备驱动程序，也就是Ndis miniport driver。这些miniport driver直接利用NDIS提供的接口发送指令，NDIS对这些格式化的指令进行解析，做进一步处理。（这些处理就到了HAL了）
 对于上层，多个协议驱动程序与下层minport driver之间的通信，也都是通过统一的NDIS接口，NidsAllocatePacket，NdisSend等函数来收发数据。

废话两句：TDI和NDIS两大接口规范，有力的提升了Windows操作系统对不同设备厂商的支持，降低了设备厂商对设备驱动程序开发的难度；也增加了对于不同网络协议的支持，给用户更强大的网络功能支持。这种设计我们也可以在Windows存储管理中看到，从中我们似乎可以了解到一些，Windows操作系统在商业上取得成功的原因。Linux操作系统中没有这样的驱动层次结构。

设备制造商开发的Ndis miniport driver直接调用NDIS库中的接口函数，因此不需要考虑重入的问题，就是一个请求尚未结束的时候，新的请求又进来了。NDIS库对请求进行了序列化，但是这种序列化也妨碍了多处理器的扩展性。所以NDIS5中提供了非序列化的操作项。下面，我来介绍一下，Deserialized和Serialized minport driver的区别：
Deserialized NDIS miniport driver自己序列化对MinportXxx函数的操作，排队和管理多个并发请求的任务都由驱动程序自己来完成。而Serialized NDIS miniport driver以上的工作都是依赖于NDIS库来完成的。从性能角度看，Deserialized NDIS miniport driver的性能是Serialized NDIS miniport driver性能的2倍多，所以到NDIS6.0之后的所有Miniport driver都是deserialize的。

以上是我参考MSDN以及自己的一些理解画出来的windows网络架构图，下面我就从上到下来简单介绍一下其中的各个层。

1.  网络应用程，Network applicantion，用户态的应用程序调用Windows操作系统提供的网络API，网络API包括：
a)  Windows套接字（winsock）
b)  远程过程调用RPC
c)  Web访问API
d)  命名管道和邮件槽
e)  其他网络API
这些API既可以在用户模式下实现，也可以同时在用户模式和内核模式下实现。从本质上说这些API是下层提供接口的另一层封装而已。
2.  TDI Clients，传输驱动程序接口客户，是内核模式的设备驱动程序，用于实现网络API的内核部分。将网络API的请求转换成IRP，通过TDI标准格式化后，发送给下层的协议驱动（也就是TDI传输器）。从sockets emulator的架构图看到，TDI Clients的实现可以有用户态的部分，也有内核态的部分。AFD辅助功能驱动程序通过向协议驱动程序发送TDI IRP来执行网络套接字操作，比如发送和接受消息。AFD没有不是确定使用哪一个协议驱动，而是上层通知其要使用的协议名称，然后AFD去打开相应协议的设备对象。

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

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

Windows内核情景分析(前五章)

shaker(太子) — Fri, 18 Feb 2011 14:57:00 GMT

摘要: Linux内核情景分析作者毛德操的又一巨著
阅读全文

shaker(太子) 2011-02-18 22:57 发表评论

Delphi对象创建和释放过程

shaker(太子) — Sun, 06 Feb 2011 03:36:00 GMT

一个类实例的生成需要经过对象内存分配、内存初始化、设置对象执行框架三个步骤。

编译器首先调用System._ClassCreate进行对象内存分配、内存初始化的工作。而System._ClassCreate调用TObject类的虚方法NewInstance建立对象的实例空间，继承类通常不需要重载TObject.NewInstance，除非你使用自己的内存管理器，因此缺省是调用TObject.NewInstance。TObject.NewInstance方法将根据编译器在类信息数据中初始化的对象实例尺寸（TObject.InstanceSize），调用系统缺省的MemoryManager.GetMem过程为该对象在堆（Heap）中分配内存，然后调用TObject.InitInstance方法将分配的空间初始化。InitInstance方法首先将对象空间的头4个字节初始化为指向对象类的VMT的指针，然后将其余的空间清零。如果类中还设计了接口，它还要初始化接口表格（Interface Table）。

当对象实例在内存中分配且初始化后，开始设置执行框架。所谓设置执行框架就是执行你在Create方法里真正写的代码。设置执行框架的规矩是先设置基类的框架，然后再设置继承类的，通常用Inherited关键字来实现。

上述工作都做完后，编译器还要调用System._AfterConstruction让你有最后一次机会进行一些事务的处理工作。System._AfterConstruction是调用虚方法AfterConstruction实现的。在TObject中AfterConstruction中只是个Place Holder，你很少需要重载这个方法，重载这个方法通常只是为了与C++ Builder对象模型兼容。

最后，编译器返回对象实例数据的地址指针。

对象释放服务其实就是对象创建服务的逆过程，可以认为对象释放服务就是回收对象在创建过程中分配的资源。

当编译器遇到destructor关键字通常会这样编码：首先调用System._BeforeDestruction，而System._BeforeDestruction继而调用虚方法BeforeDestruction，在TObject中BeforeDestruction中只是个Place Holder，你很少需要重载这个方法，重载这个方法通常只是为了与C++ Builder对象模型兼容。

这之后，编译器调用你在Destroy中真正写的代码，如果当前你在撰写的类是继承链上的一员，不要忘记通过inherited调用父类的析构函数以释放父类分配的资源，但规矩是，先释放当前类的资源，然后再调用父类的，这和对象创建服务中设置对象执行框架的顺序恰好相反。

当前类及继承链中所有类中分配的资源全部释放后，最后执行的就是释放掉对象本身及一些特别数据类型占用的内存空间。编译器调用System._ClassDestroy来完成这件工作。System._ClassDestroy继而调用虚方法FreeInstance，继承类通常不需要重载TObject.FreeInstance，除非你使用自己的内存管理器，因此缺省是调用TObject.FreeInstance。TObject.FreeInstance继而调用TObject.CleanupInstance完成对于字符串数组、宽字符串数组、Variant、未定义类型数组、记录、接口和动态数组这些特别数据类型占用资源的释放[4]，最后TObject.FreeInstance调用MemoryManager.FreeMem释放对象本身占用的内存空间。

很有意思的是，对象释放服务与对象创建服务所用方法、函数是一一对应的，是不是有一种很整齐的感觉？

对象创建服务

对象释放服务

System._ClassCreate

System._ClassDestroy

System._AfterConstruction

System._BeforeDestruction

TObject.AfterConstruction(virtual)

TObject.BeforeDestruction(virtual)

TObject.NewInstance(virtual)

TObject.FreeInstance(virtual)

TObject.InitInstance

TObject.CleanupInstance

MemoryManager.GetMem

MemoryManager.FreeMem

还有一点要注意，通常我们不会直接调用 Destroy 来释放对象，而是调用 TObject.Free，它会在释放对象之前检查对象引用是否为 nil。

shaker(太子) 2011-02-06 11:36 发表评论

自己开发Delphi的VCL

shaker(太子) — Wed, 12 Jan 2011 01:12:00 GMT

自己开发Delphi的VCL

Delphi为何成为广大程序员爱好的开发工具，其中一个原因就是它有大量的共享的VCL库，打打扩展了Delphi的功能。但是在实际的开发过程中，有时候根据项目的需要要开发自己的VCL控件，我就有过不少这样的需求，因此自己也开发了多个VCL控件，由于水平有限，功能也不是很强大，下面将自己的一些经验介绍一下。
1、选择File | New，在对话框中选择Component。在Ancestor Type中选择你的控件是从那个类继承下来的，然后在 "Class Name"输入你的类的名称，在Palette Page 中选择要把你的控件放到哪一个页面中。输入完毕后点击OK，生成pas文件。
2、在控件中添加属性：
首先，控件的属性要存储在一个类变量中，比如一个类型为string的变量，就可以存储在一个可以存储string的类变量，比如一个string，TStringList等。因此首先要在类的private区域声明一个私有的类变量，为了防止名字重复，一般在私有的类变量前加一个"F"。如
private
  Fname:String
我们假设这个属性的名字叫 FieldName，那我们就需要在published区域加上如下语句：
property FieldName:String read Fname write Fname;
这样的属性你可以访问，但是不在 "Object Inspector"中出现，如果想如此，应这样写：
property FieldName:String read Fname write Fname stored true;
这样的方法只实用于一些基本的数据类型，如integer, double ,String等等，对一些类，如Tstringlist，就不适合，对这些类应该怎么办呢？首先，还是要声明一个私有的变量存储该属性，以 Tstringlist为例子：
private Fnames:Tstringlist;
同时要写两个方法来对此类变量进行存取：
protected
  Function getNames:Tstringlist;
  Procedure setNames(value:Tstringlist);
在getName的函数体中，应这样写：
begin
result:=Fname;
end;
在setNames的方法中，应这样写：
begin
Fname.assign(value);
end;
在published中写：
property Names:Tstringlist read getNames write setNames;
同样如果想要这个属性在 "Object Inspector"中出现，要在后面加 stored true.
当然，你也可以通过其他类型的类对这个属性进行存取，比如通过Tlistbox来存取Tstringlist，因为类Tlistbox也包含有一个Tstringlist类。
3、在控件中添加方法
添加方法比较简单，在published中声明方法，然后写方法体就可以。
4、在控件中添加事件
添加事件之前，首先要声明一个事件类，如TnotifyEvent
private
  MyEvent:TnotifyEvent;
声明事件
published
  property OnMyEvent:TnotifyEvent read MyEvent write MyEvent stored true;
然后在特定的条件下调用这个事件：
OnMyEvent(owner);
5、写数据敏感的控件：
数据敏感的控件和普通控件基本相同，只是有一个类Tdatalink，Tdatalink有一个onDatachange事件，你可以声明一个事件，然后将事件指向Tdatalink的onDatachange事件，然后在事件中写下程序就可以实现数据敏感了。
  FDataLink.OnDataChange := DataChange;
然后在Datachange中写程序。
6、重载构造器和构析器。在public或published中写：
构造器：
constructor Create(Aowner:Tcomponent); override;
构析器：
destructor Destory; override;
在构造时对一些类变量进行初始化，有的需要调用类变量的类构造方法进行构造，如
  Fnames:=Tstirnglist.create;
在构析时对类变量进行释放
  Fnames.Free;
7、对于一些界面有关的控件，如果有特殊的界面需要，需要重载onpaint事件，在重画时对自己的canvas进行操作，当然，也可以对别的类的canvas进行操作，比如写一个控件，在重画时对它的容器用一个画进行平铺处理。
8、对于从哪些类继承，根据自己的需要选择，尽可能选择功能接近，已经实现部分功能的类，这样写比较方便。
以上是自己的一些心得，还望多多指正。

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

[ZT]正则表达式30分钟入门教程

shaker(太子) — Tue, 31 Aug 2010 14:19:00 GMT

摘要: 阅读全文

shaker(太子) 2010-08-31 22:19 发表评论

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

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

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

Boost的状态机库教程补充

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

来自:http://www.cppblog.com/shanoa/archive/2009/05/30/86143.html
接触了boost的状态机，发现不是想象中的那么好用，在一些地方还得用上mpl库里的东西，由于对模板元编程不是很熟练，搞了好些天才算弄明白这该死的mpl::list的原理和用法。
boost的状态机是属于静态链接的状态机，也就是说，它的图结构是编译期间就确定了的，在运行时不可以动态配置。所以，它的用途是有一定局限性的，但在一般情况下，它不仅很通用，而且在你会用并熟练地情况下，还会很好用，用起来很舒服，逻辑也很合理。下面就是一段代码，当然也是借鉴了别人的东西，自己修改了一下，在MainState中添加了一个Transition做了测试，因为此前我还不知道一个状态如何包含多个Transition，呵呵，原来是用mpl::list来做。至于这个状态机的入门教程，网上随处可见的三部曲：《boost 状态机入门教程》说得很清楚。

  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<<"进入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<<"进入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<<"进入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<<"进入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的状态机库教程(3)

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

1.2 增加动作

此时我们将只用一种动作：transitions，我们在下面的代码中插入了黑体的部分。

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//一个状态可以定义任意数量的动作。这就是为什么当多于一个时，
22//我们不得不将它们放到一个mpl::list<> 里。
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

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

1.3 State-local存储

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

l Stopped状态：需要一个保存逝去时间的变量。

l Running状态：需要一个保存逝去时间的变量，还需要一个保存上一次启动的时间点的变量。

无论状态机在什么状态下，我们都必须观察逝去时间这个变量。此外，当我们向状态机发送EvReSet事件时，这个变量应该被置为0。其它的变量只是状态机在Running状态时需要。无论何时我们进入Running状态时，它应该被置为系统时钟的当前时间。当我们退出Running状态时，我们仅仅从系统时钟的当前时间减去开始时间（进入时记录的时间），将结果加到逝去时间里就可以了。

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       // 与派生类可以访问它的基类相似，
27       //context<>() 用来获得一个状态的直接或间接的上下文的访问权。
28       // 这可以是直接或间接的外层状态或状态机本身
29       // (例如，像这样: context< StopWatch >()).
30      context< Active >().ElapsedTime() +=
31        std::difftime( std::time( 0 ), startTime_ );
32    }
33   private :
34    std:: time_t  startTime_;
35};

这个状态机现在可以测量时间了，但是我们还不能看到结果。

在这里，State-local storage的优势还没有完成显现出来。在FAQ项目“State-local storage酷在哪里？”中，会通过与一个没有用State-local storage的Stop Watch的比较来说明。

1.4 在状态机外得到状态信息

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

#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; 
    
    }

为了确实看到被测量的时间，你应该想办法在main()中单步执行。StopWatch例子将这个程序扩展为一个交互式的终端程序了。

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

Boost的状态机库教程(2)

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

1 基础主题：秒表
    下面我们要为一个机械秒表建模一个状态机。这样一个秒表通常会有两个按钮。
     * Start/Stop
     * Reset
     同时有两种状态：
     * Stoped: 表针停留在上次停止时的位置：
        o 按下Reset按钮，表针回退到0的位置。秒表保持在Stoped状态不变。
        o 按下Start/Stop按钮，秒表转到Running状态。
     * Running: 表针在移动，并持续显示过去的时间：
        o 按下Reset按钮，表针回退到0的位置，秒表转到停止状态。
        o 按下Start/Stop按钮，转到Stoped状态。
    下面是其UML图：

1.1 定义状态和事件
两个按钮可以建模为两个事件。进而，定义出必要的状态和初始状态。我们从下面的代码开始，以前的代码片段会陆续加入其中：

#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;

// 这里的simple_state类模板可以接受4个参数：
// - 第3个参数指定内部的初始状态，如果有一个这样的状态的话。
//   在这里，Active有一个内部状态（Stoped），所以将这个内部
//   初始状态传给它的基类。
// - 第4个参数指定是否保留和保留什么类型历史

// Active是最外层的状态，因此要把它所属的状态机类传给它
struct Active : sc::simple_state<
  Active, StopWatch, Stopped > {};

// Stopped 和 Running 都把Active作为它们的上下文，这使他们嵌入到了Active状态中。
struct Running : sc::simple_state< Running, Active > {};
struct Stopped : sc::simple_state< Stopped, Active > {};

// 因为状态的上下文必须是一个完整的类型（不能单单是声明），
// 所以状态机必须要在“外层状态”之间先定义。
// 也就是说，我们需要从状态机开始，然后是最外层的状态，然后是其内部的状态，如此反复。
// 我们可以用广度或深度方式，再或是以两都混合的方式来进行定义。

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

这个代码已经可以编译了，但不会发生任何可察觉的事件。

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

Boost的状态机库教程(1)

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

介绍
    Boost状态机库一个应用程序框架，你可以用它将UML状态图快速的转换为可执行的c++代码，而不需要任何的代码生成器。它支持几乎所有的UML特征，可以直接了当的转换，并且转换后的c++代码就像对状态机进行一次文本描述一样具体可读性。

如何阅读这个教程
这个教程是以线性阅读的方式进行的章节设计。如果你是第一次看这个教程的话，你可以从头开始读，到你觉得了解的东西对你手头的任务来说已经足够时就停止。具体可以这样：
* 如果你的任务是要实现一个小的、简单的，并且有很少几个状态的状态机，那么下面的“初级主题：秒表”里所讲的就差不多够你用的了。
* 如果你要做一个有很多状态的大型状态机，你可以看一下“中级主题：数码相机”，那里的讲解可能对你有帮助。
    * 最后，如果你是一个要创建异常复杂状态机的用户，或者是一个想要评估一个Boost状态机的设计师的话，你就要看一下“高级主题”部分。并且，我还强烈建议你看一下Rationle里的Limitions部分。

Hello World!
    我们将要从一个最简单程序开始我们的第一步，状态图如下：

对于这个状态图，我们的实现代码如下：

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

这个程序会显示“Hello World!”和“ Bye Bye World! ”，然后退出。

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

[转]RGB与YUV转换

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

1 前言

自然界的颜色千变万化，为了给颜色一个量化的衡量标准，就需要建立色彩空间模型来描述各种各样的颜色，由于人对色彩的感知是一个复杂的生理和心理联合作用的过程，所以在不同的应用领域中为了更好更准确的满足各自的需求，就出现了各种各样的色彩空间模型来量化的描述颜色。我们比较常接触到的就包括 RGB / CMYK / YIQ / YUV / HSI等等。

对于数字电子多媒体领域来说，我们经常接触到的色彩空间的概念，主要是RGB , YUV这两种（实际上，这两种体系包含了许多种具体的颜色表达方式和模型，如sRGB, Adobe RGB, YUV422, YUV420 …）, RGB是按三基色加光系统的原理来描述颜色，而YUV则是按照亮度，色差的原理来描述颜色。

即使只是RGB YUV这两大类色彩空间，所涉及到的知识也是十分丰富复杂的，自知不具备足够的相关专业知识，所以本文主要针对工程领域的应用及算法进行讨论。

2 YUV相关色彩空间模型

2.1 YUV 与 YIQ YcrCb

对于YUV模型，实际上很多时候，我们是把它和YIQ / YCrCb模型混为一谈的。

实际上,YUV模型用于PAL制式的电视系统，Y表示亮度，UV并非任何单词的缩写。

YIQ模型与YUV模型类似，用于NTSC制式的电视系统。YIQ颜色空间中的I和Q分量相当于将YUV空间中的UV分量做了一个33度的旋转。

YCbCr颜色空间是由YUV颜色空间派生的一种颜色空间，主要用于数字电视系统中。从RGB到YCbCr的转换中，输入、输出都是8位二进制格式。

三者与RGB的转换方程如下：

RGB -> YUV：

实际上也就是：

Y=0.30R+0.59G+0.11B ， U=0.493(B－Y) ， V=0.877(R－Y)

RGB -> YIQ：

RGB -> YCrCb：

从公式中，我们关键要理解的一点是，UV / CbCr信号实际上就是蓝色差信号和红色差信号，进而言之，实际上一定程度上间接的代表了蓝色和红色的强度，理解这一点对于我们理解各种颜色变换处理的过程会有很大的帮助。

我们在数字电子多媒体领域所谈到的YUV格式，实际上准确的说，是以YcrCb色彩空间模型为基础的具有多种存储格式的一类颜色模型的家族（包括 YUV444 / YUV422 / YUV420 / YUV420P等等）。并不是传统意义上用于PAL制模拟电视的YUV模型。这些YUV模型的区别主要在于UV数据的采样方式和存储方式，这里就不详述。

而在Camera Sensor中，最常用的YUV模型是 YUV422格式，因为它采用4个字节描述两个像素，能和RGB565模型比较好的兼容。有利于Camera Sensor和Camera controller的软硬件接口设计。

3 YUV2RGB快速算法分析

这里指的YUV实际是YcrCb了 8 ) YUV2RGB的转换公式本身是很简单的，但是牵涉到浮点运算，所以，如果要实现快速算法，算法结构本身没什么好研究的了，主要是采用整型运算或者查表来加快计算速度。
首先可以推导得到转换公式为：

        R = Y + 1.4075 *（V-128）
        G = Y – 0.3455 *（U –128） – 0.7169 *（V –128）
        B = Y + 1.779 *（U – 128）

3.1 整型算法

要用整型运算代替浮点运算，当然是要用移位的办法了，我们可以很容易得到下列算法：

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;

为了防止出现溢出，还需要判错计算的结果是否在0-255范围内，做类似下面的判断。

        if (r>255)
            r=255;
        if (r<0)
            r=0;

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

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

3.2 部分查表法

查表法首先可以想到的就是用查表替代上述整型算法中的乘法运算。

        rdif = fac_1_4075[u];
        invgdif = fac_m_0_3455[u] + fac_m_0_7169[v];
        bdif = fac_1_779[u];

这里一共需要4个1维数组，下标从0开始到255，表格共占用约1K的内存空间。uv可以不需要做减128的操作了。在事先计算对应的数组元素的值的时候计算在内就好了。

对于每个像素，部分查表法用查表替代了2次减法运算和4次乘法运算，4次移位运算。但是，依然需要多次加法运算和6次比较运算和可能存在的赋值操作，相对第一种方法运算速度提高并不明显。

3.3 完全查表法

那么是否可以由YUV直接查表得到对应的RGB值呢？乍一看似乎不太可能，以最复杂的G的运算为例，因为G与YUV三者都相关，所以类似 G=YUV2G[Y][U][V]这样的算法，一个三维下标尺寸都为256的数组就需要占用2的24次方约16兆空间，绝对是没法接受的。所以目前多数都是采用部分查表法。

但是，如果我们仔细分析就可以发现，对于G我们实际上完全没有必要采用三维数组，因为Y只与UV运算的结果相关，与UV的个体无关，所以我们可以采用二次查表的方法将G的运算简化为对两个二维数组的查表操作，如下：

G = yig2g_table[ y ][ uv2ig_table[ u ][ v ] ]；

而RB本身就只和YU或YV相关，所以这样我们一共需要4个8*8的二维表格，需要占用4乘2的16次方共256K内存。基本可以接受。但是对于手机这样的嵌入式运用来说，还是略有些大了。

进一步分析，我们可以看到，因为在手机等嵌入式运用上我们最终是要把数据转换成RGB565格式送到LCD屏上显示的，所以，对于RGB三分量来说，我们根本不需要8bit这么高的精度，为了简单和运算的统一起见，对每个分量我们其实只需要高6bit的数据就足够了，所以我们可以进一步把表格改为4个 6*6的二维表格，这样一共只需要占用16K内存！在计算表格元素值的时候还可以把最终的溢出判断也事先做完。最后的算法如下：

        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) );

这样相对部分查表法，我们增加了3次移位运算，而进一步减少了4次加法运算和6次比较赋值操作。

在计算表格元素数值的时候，要考虑舍入和偏移等因数使得计算的中间结果满足数组下标非负的要求，需要一定的技巧。

采用完全查表法，相对于第一种算法，最终运算速度可以有比较明显的提高，具体性能能提高多少，要看所在平台的CPU运算速度和内存存取速度的相对比例。内存存取速度越快，用查表法带来的性能改善越明显。在我的PC上测试的结果性能大约能提高35%。而在某ARM平台上测试只提高了约15%。

3.4 进一步的思考

实际上，上述算法：

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

中的 (r & 0xF8) 和 ( b >> 3) 等运算也完全可以在表格中事先计算出来。另外，YU / YV的取值实际上不可能覆盖满6*6的范围，中间有些点是永远取不到的无输入，RB的运算也可以考虑用5*5的表格。这些都可能进一步提高运算的速度，减小表格的尺寸。

另外，在嵌入式运用中，如果可能尽量将表格放在高速内存如SRAM中应该比放在SDRAM中更加能发挥查表法的优势。

4 RGB2YUV ?

目前觉得这个是没法将3维表格的查表运算化简为2维表格的查表运算了。只能用部分查表法替代其中的乘法运算。

另外，多数情况下，我们需要的还是YUV2RGB的转换，因为从Sensor得到的数据通常我们会用YUV数据，此外JPG和MPEG实际上也是基于YUV格式编码的，所以要显示解码后的数据需要的也是YUV2RGB的运算 8 ）运气运气。

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/ALENTAM/archive/2008/03/13/2178020.aspx

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

一个简易的采集系统

shaker(太子) — Sun, 08 Nov 2009 15:14:00 GMT

摘要: 练手之作,顺便实现一些自己的想法,见笑见笑!~
阅读全文

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

使用wget加速Ubuntu更新

shaker(太子) — Thu, 18 Jun 2009 10:43:00 GMT

在白天Ubuntu的更新管理器或apt-get更新总是慢吞吞的，我用的是官方源，但直接用Firefox去“http://archive.ubuntu.com/ubuntu/”下载却很快，用扩展DTA都能接近满速，看来更新管理器或apt-get不是多线程，速度是慢点，干脆用Firefox去下载好了。

获得更新deb地址列表：
首先要获得deb包的下载地址，有个笨点的方法就是使用更新管理器，然后在下载窗口点击取消，然后就在出错窗口复制获得下载列表，还要修改一下。用命令更快捷，结果折腾一番，运行下面的命令即把需要更新的deb包的列表输出

sudo apt-get -y --print-uris dist-upgrade | grep http | awk '{print $1}' | sed 's/'\''//g'

每次都要打这么长的命令是很恼人的，添加一个alias到“~/.bashrc”里去

alias sgdl="sudo apt-get -y --print-uris dist-upgrade | grep http | awk '{print \$1}' | sed 's/'\''//g'"

有点变态的别名，主要是单引号转义，以后每次运行

sgdl > deblist

输出到文件deblist中去。“sgdl”助记“sudo get deb list”。

下载deb文件：
获得列表然后就是下载啦，用Firefox打开deblist，然后Ctrl+A全选，用Flashgot选择“使用Flashgot下载所选连接”，当前调用的下载管理器为DTA，在DTA里选择下载所有连接，设置好下载目录，然后开足火力猛拖。又或者使用wget，更简单

wget -i deblist

如果按了Ctrl+C中断，下次加上“-c”选项续传

wget -c -i deblist

链接包并更新：
下载好后，到apt-get的缓存目录建立deb的链接

sudo ln -s ~/debfiles/*.deb /var/cache/apt/archives/

这里debfiles为下载deb的文件夹。最后就是运行一下更新命令啦。

sudo apt-get upgrade

作者：雾之大陆
出处：http://muzuiget.blog.ubuntu.org.cn/

shaker(太子) 2009-06-18 18:43 发表评论