1、字符串
Unicode 字符串有一个结构体定义如下：
typedef struct _UNICODE_STRING {
USHORT Length; // 字符串的长度（字节数）
USHORT MaximumLength; // 字符串缓冲区的长度（字节数）
PWSTR Buffer; // 字符串缓冲区
} UNICODE_STRING, *PUNICODE_STRING;
需要注意的是，当我们定义了一个UNICODE_STRING 变量之后，它的Buffer 域还没有分配空间，因此我们不能直接赋值，好的做法是使用微软提供的Rtl 系列函数。
UNICODE_STRING str;
RtlInitUnicodeString(&str, L"my first string!");
或者如下所示：
#include <ntdef.h>
UNICODE_STRING str = RTL_CONSTANT_STRING(L"my first string!");
与ring3 不同，我们的UNICODE 字符串并不是以“\0”来表示字符串结束的，而是依靠UNICODE_STRING 的Length 域来确定。
1）字符串的很多操作都有相应的函数，例如字符串的复制可以使用RtlCopyUnicodeString函数，字符串的比较可以使用RtlCompareUnicodeString 函数，字符串转换成大写可以使用RtlUpcaseUnicodeString 函数（没有转换成小写的），字符串与整数数字互相转换分别可以使用RtlUnicodeStringToInteger 和RtlIntegerToUnicodeString 函数。
比如在输出日志记录的时候，我们往往同时涉及数字、字符等信息，在C语言中我们可以使用sprintf 和swprintf 函数来完成任务，这两个函数在驱动中仍然可以使用，但很不安全，因为有许多C 语言的运行时函数都是基于Win32 API 的，在驱动中绝对不能使用，如果我们不清楚哪些可以使用哪些不能使用，就都不要使用，而使用微软推荐的Rtl 系列函数。对应sprintf 的功能函数是RtlStringCbPrintfW，它需要包含头文件“ntstrsafe.h”和静态连接库“ntsafestr.lib”。
http://msdn.microsoft.com/en-us/library/ff561817%28VS.85%29.aspx
WCHAR buf[512] = { 0 };
UNICODE_STRING dst;
NTSTATUS status;
……
// 字符串初始化为空串。缓冲区长度为512*sizeof (WCHAR)
RtlInitEmptyString(dst,dst_buf,512*sizeof(WCHAR));
// 调用RtlStringCbPrintfW 来进行打印
status = RtlStringCbPrintfW(
dst->Buffer,L”file path = %wZ file size = %d \r\n”，
&file_path,file_size);
//这里调用wcslen 没问题，这是因为RtlStringCbPrintfW打印的字符串是以空结束的。
dst->Length = wcslen(dst->Buffer) * sizeof (WCHAR);
RtlStringCbPrintfW在目标缓冲区内存不足的时候依然可以打印，但是多余的部分被截
去了。返回的status值为STATUS_BUFFER_OVERFLOW。调用这个函数之前很难知道究竟需要多长的缓冲区。一般都采取倍增尝试。每次都传入一个为前次尝试长度为2 倍长度的新缓冲区，直到这个函数返回STATUS_SUCCESS为止。
值得注意的是UNICODE_STRING 类型的指针，通常用%wZ可以打印出字符串。在不
能保证字符串为空结束的时候，必须避免使用%ws或者%s。其他的打印格式字符串与传统
C 语言中的printf函数完全相同。可以尽情使用。
2）内核模式下各种开头函数的区别
函数开头含义
| Cc |
Cache manager |
| Cm |
Configuration manager |
| Ex |
Executive support routines |
| FsRtl |
File system driver run-time library |
| Hal |
Hardware abstraction layer |
| Io |
I/O manager |
| Ke |
Kernel |
| Lpc |
Local Procedure Call |
| Lsa |
Local security authentication |
| Mm |
Memory manager |
| Nt |
Windows 2000 system services (most of which are exported as Win32 functions)，例如NtCreateFile 往往导出为CreateFile |
| Ob |
Object manager |
| Po |
Power manager |
| Pp |
PnP manager |
| Ps |
Process support |
| Rtl |
Run-time library |
| Se |
Security |
| Wmi |
Windows Management Instrumentation |
| Zw |
Mirror entry point for system services (beginning with Nt) that sets previous access mode to kernel, which eliminates parametervalidation, since Nt system services validate parameters only if previous access mode is user see Inside Microsoft Windows 2000 |
3）大部分的Win32 API 都是通过Native API 实现的，Native API 函数一般都是Win32 API函数前面加上Nt 两个字符，例如CreateFile 函数对应着NtCreateFile 函数，这些Nt 函数都是在“ntdll.dll”实现的，而多数Win32 API 都是在“kernel.dll”导出的，也有少部分GDI或窗口相关的函数是在“gdi32.dll”和“user32.dll”导出的。
Native API 从用户模式穿越进入到内核模式调用系统服务，这个穿越过程是通过软中断的方式进入的。这个软中断的实现方法在不同版本的Windows 实现方式略有不同，在Win 2K下是通过“int 2eh”实现的，在Win XP 是通过“sysenter”指令完成的。
软中断会将Native API 的参数和系统服务号的参数一起传进内核模式，不同的NativeAPI 会对应不同的系统服务号，这个过程是由SSDT 辅助完成的。
系统服务函数一般和Native API 具有相同的名字，例如都是NtCreateFile，但它们的实现不同，系统服务调用是在“ntoskrnl.exe”导出的。
4）创建文件
代码
2
3 CreateFileTest( IN PUNICODE_STRING FileName )
4
5 {
6
7 HANDLE hFile = NULL;
8
9 NTSTATUS status;
10
11 IO_STATUS_BLOCK Io_Status_Block;
12
13 // 初始化文件路径
14
15 OBJECT_ATTRIBUTES obj_attrib;
16
17 InitializeObjectAttributes( & obj_attrib,
18
19 FileName,
20
21 OBJ_CASE_INSENSITIVE | OBJ_KERNEL_HANDLE,
22
23 NULL,
24
25 NULL );
26
27 // 创建文件
28
29 status = ZwCreateFile( & hFile,
30
31 GENERIC_ALL,
32
33 & obj_attrib,
34
35 & Io_Status_Block,
36
37 NULL,
38
39 FILE_ATTRIBUTE_NORMAL,
40
41 FILE_SHARE_READ,
42
43 FILE_CREATE,
44
45 FILE_NON_DIRECTORY_FILE | FILE_SYNCHRONOUS_IO_NONALERT,
46
47 NULL,
48
49 0 );
50
51 if (NT_SUCCESS(status))
52
53 {
54
55 status = STATUS_SUCCESS;
56
57 }
58
59 else
60
61 {
62
63 status = Io_Status_Block.Status;
64
65 }
66
67 KdPrint(( " hFile = %08X " , hFile));
68
69 // 关闭句柄
70
71 if (hFile)
72
73 {
74
75 ZwClose(hFile);
76
77 }
78
79 return status;
80
81 }
５）长长整形：
typedef __int64 LONGLONG;
typedef union _LARGE_INTEGER {
struct {
ULONG LowPart;
LONG HighPart;
};
struct {
ULONG LowPart;
LONG HighPart;
} u;
LONGLONG QuadPart;
} LARGE_INTEGER;
这个共用体的方便之处在于，既可以很方便的得到高32位，低32位，也可以方便的得到整个64位。进行运算和比较的时候，使用QuadPart即可。
2、链表
1）内存的分配与释放
传统的C 语言中，分配内存常常使用的函数是malloc，但在驱动开发过程中这个函数不再有效。驱动中分配内存，最常用的是调用ExAllocatePoolWithTag 或ExAllocatePool。
// 定义一个内存分配标记
#define MEM_TAG ‘MyTt’
// 目标字符串，接下来它需要分配空间。
UNICODE_STRING dst = { 0 };
// 分配空间给目标字符串。根据源字符串的长度。
dst.Buffer = (PWCHAR)ExAllocatePoolWithTag(NonpagedPool,src->Length,M EM_TAG);
if(dst.Buffer == NULL)
{
// 错误处理
status = STATUS_INSUFFICIENT_RESOUCRES;
……
}
dst.Length = dst.MaximumLength = src->Length;
ExAllocatePoolWithTag 的第一个参数NonpagedPool 表明分配的内存是非分页内存，这样它们可以永远存在于物理内存，而不会被分页交换到硬盘上去；第二个参数是长度；第三个参数是一个所谓的“内存分配标记”。
内存分配标记用于检测内存泄漏。一般每个驱动程序定义一个自己的内存标记，也可以在每个模块中定义单独的内存标记。内存标记是随意的32位数字，即使冲突也不会有什么问题。此外也可以分配可分页内存，使用PagedPool标识第一个参数即可。ExAllocatePoolWithTag分配的内存可以使用 ExFreePool来释放。
ExFreePool 只需要提供需要释放的指针即可。举例如下：
ExFreePool(dst.Buffer);
dst.Buffer = NULL;
dst.Length = dst.MaximumLength = 0;
注意，ExFreePool不能用来释放一个栈空间的指针，否则系统立刻崩溃。诸如下面的代码将会招致立刻蓝屏的灾难：
UNICODE_STRING src = RTL_CONST_STRING(L”My source string!”);
ExFreePool(src.Buffer);
请务必保持ExAllocatePoolWithTag 或ExAllocatePool 和ExFreePool 的成对关系。Windows内核提供了一个双向链表结构LIST_ENTRY，此外还有一些其他的结构，比如SINGLE_LIST_ENTRY（单向链表）。
LIST_ENTRY 是一个双向链表结构，通常的做法是我们自定义一个结构体，将LIST_ENTRY作为该结构体的一个子域，将LIST_ENTRY作为结构体的第一个子域是最简单的做法。如下所示：
typedef struct _MYDATASTRUCT{
LIST_ENTRY ListEntry;
ULONG number;
} MYDATASTRUCT, *PMYDATASTRUCT;
如果把它放在后面，这时候，如果我们想获取节点的地址，需要有一个计算偏移的过程，DDK 里面提供了一个宏CONTAINING_RECORD 可以在指定结构中找到节点地址的指针。
http://msdn.microsoft.com/en-us/library/ff554296%28VS.85%29.aspx
如：
for(p = my_list_head.Flink; p != &my_list_head.Flink; p = p->Flink)
{
PMY_FILE_INFOR elem =
CONTAINING_RECORD(p,MY_FILE_INFOR, list_entry);
// 在这里做需要做的事…
}
其中的CONTAINING_RECORD是一个WDK中已经定义的宏，作用是通过一个LIST_ENTRY结构的指针，找到这个结构所在的节点的指针。定义如下：
#define CONTAINING_RECORD(address, type, field) ((type *)( \
(PCHAR)(address) - \
(ULONG_PTR)(&((type *)0)->field)))
从上面的代码中可以总结如下的信息：
LIST_ENTRY中的数据成员Flink指向下一个LIST_ENTRY。整个链表中的最后一个LIST_ENTRY的Flink不是空。而是指向头节点。得到LIST_ENTRY之后，要用CONTAINING_RECORD来得到链表节点中的数据。
2）使用自旋锁
代码
2
3 KIRQL irql;
4
5 // 初始化
6
7 KeInitializeSpinLock( & my_spin_lock);
8
9 KeAcquireSpinLock( & my_spin_lock, & irql);
10
11 // do something …
12
13 KeReleaseSpinLock( & my_spin_lock,irql);
14
15 一个例子程序：
16
17 VOID
18
19 LinkListTest()
20
21 {
22
23 LIST_ENTRY linkListHead; // 链表
24
25 PMYDATASTRUCT pData; // 节点数据
26
27 ULONG i = 0 ; // 计数
28
29 KSPIN_LOCK spin_lock; // 自旋锁
30
31 KIRQL irql; // 中断级别
32
33 // 初始化
34
35 InitializeListHead( & linkListHead);
36
37 KeInitializeSpinLock( & spin_lock);
38
39 // 向链表中插入10 个元素
40
41 KdPrint(( " [Test] Begin insert to link list " ));
42
43 // 锁定，注意这里的irql 是个指针
44
45 KeAcquireSpinLock( & spin_lock, & irql);
46
47 for (i = 0 ; i < 10 ; i ++ )
48
49 {
50
51 pData = (PMYDATASTRUCT)ExAllocatePool(PagedPool, sizeof (MYDATASTRUCT));
52
53 pData -> number = i;
54
55 InsertHeadList( & linkListHead, & pData -> ListEntry);
56
57 }
58
59 // 解锁，注意这里的irql 不是指针
60
61 KeReleaseSpinLock( & spin_lock, irql);
62
63 // 从链表中取出所有数据并显示
64
65 KdPrint(( " [Test] Begin remove from link list\n " ));
66
67 // 锁定
68
69 KeAcquireSpinLock( & spin_lock, & irql);
70
71 while ( ! IsListEmpty( & linkListHead))
72
73 {
74
75 PLIST_ENTRY pEntry = RemoveTailList( & linkListHead);
76
77 // 获取节点地址
78
79 pData = CONTAINING_RECORD(pEntry, MYDATASTRUCT, ListEntry);
80
81 // 读取节点数据
82
83 KdPrint(( " [Test] %d\n " ,pData -> number));
84
85 ExFreePool(pData);
86
87 }
88
89 // 解锁
90
91 KeReleaseSpinLock( & spin_lock, irql);
92
93 }
需要注意的是，像上述代码中在函数中定义一个锁的做法是没有实际意义的，因为它是一个局部变量，被定义在栈中，每当有线程调用该函数时，都会重新初始化一个锁，因此它就失去了本来的作用。
在实际的编程中，我们应该把锁定义为一个全局变量、静态（static ）变量或者将其定义在堆中。不过在驱动中应该尽量避免使用全局变量，良好的做法是将需要全局访问的变量
定义为设备扩展结构体DEVICE_EXTENSION 的一个子域。另外，我们还可以为每个链表都定义并初始化一个锁，在需要向该链表插入或移除节点时不使用前面介绍的普通函数，而是使用如下方法：
ExInterlockedInsertHeadList(&linkListHead, &pData->ListEntry, &spin_lock);
pData = (PMYDATASTRUCT)ExInterlockedRemoveHeadList(&linkListHead, &spin_lock);
此时在向链表中插入或移除节点时会自动调用关联的锁进行加锁操作，可以有效地保证多线程安全性，加裁驱动除了使用DriverStudio外，还可以使用KmdManager等工具。
NT式驱动的安装是基于服务的，可以通过修改注册表进行，也可以直接通过服务函数如CreateService 进行安装；但WDM 式驱动不同，它安装的时候需要通过编写一个inf 文件进行控制。除此之外，它们所使用的头文件也不大相同，例如NT 式驱动往往需要导入一个名为“ntddk.h”的头文件，而WDM 式驱动需要的却是“wdm.h”头文件。我们在学习的过程中所编写的大多属于NT 式驱动，除非我们需要自己的设备支持即插即用，才需要考虑编写WDM 式驱动程序。
