1、Logger

每个Logger对象都有一个Name。这些Logger对象全部维护在一个Map中，我们可以通过LogManager.GetLogger(string name)来获取一个Logger对象。GetLogger方法内部会查找这个Map，如果找到名字相同的就返回，否则使用LoggerFactory创建一个新的Logger对象，并注册在Map中。当获得Logger对象之后，我们就可以使用ILog接口中的方法记录日志了：

public interface ILog : ILoggerWrapper
{
  void Debug(...);
  void Error(...);
  void Fatal(...);
  void Info(...);
  void Warn(...);
}

ILog接口里面只是默认实现了五个Level的日志，如果你觉得不够，还可以通过获取ILog上的ILogger对象实现更加丰富的控制。

Logger对象有个Level参数。如果给Logger对象设置了Level属性，则只有日志级别大于或等于该级别时，日志才会被记录下来，否则Log方法是直接返回的，就好像调用了一个空函数一样。这样给我们带来的好处就是，我们可以尽情的在代码中记录一些Debug日志，当部署时将Level级别设置为Info或更高就可以了，完全不必担心这些代码消耗性能，也不用使用#ifdef #endif 这类代码了。

log4net中的日志Level使用一个整数来表示级别，因此理论上可以设置int.MinValue~int.MaxValue任何一个级别。不过log4net已经默认为我们定义了十几种日志级别（详见log4net.Core.Logger的静态实例），而且ILogger对象中也默认只使用Debug、Info、Warn、Error、Fatal五种。除了这五种之外，还有两个常用的Level：Off（int.MaxValue）和All（int.MinValue）。如果将Logger对象的Level设置为Off，则表示关闭任何级别的日志（严格来讲是关闭任何级别小于int.MaxValue的日志）；如果设置为All，则表示所有级别的日志都会被记录。

对于这些常用的日志级别来讲，他们的级别顺序是：OFF > FATAL > ERROR > WARN > INFO > DEBUG > ALL。

在log4net中，Logger是可以继承的，比如我们定义了三个Logger：A、A.B、A.B.C。则A.B.C被视为A.B的子Logger对象，A.B又被视为A的子对象。同时隐含的，A是Root的对象，因为在log4net中将所有的Logger对象都视为一个名字为“Root”的Logger。子Logger继承父Logger的Appender列表，这一点是需要注意的。如果我们在Root中设置日志写入到Console、数据库，在A中设置日志写入到FileAppender，则实际使用A时，日志将同时被写入Console、数据库和文件。

2、Appender

Appender用来描述将日志写道哪里去。log4net默认提供了许多Appender对象，可以写入到文件、到控制台、到邮件服务器等。当然我们也可以实现自己的Appender，按照我们自己的逻辑记录日志。

具体的Appender这里就不再列举，各位可以参考log4net帮助文档中的例子，或者查看sdk。

3、Layout

Layout用来描述怎样格式化日志文本。常用的是PatternLayout，具体用法同样参考帮助文档中的例子，或者查看sdk。

除了使用默认提供的Layout，我们也可以实现自定义Layout。

PatternLayout在序列化%message时，会将MessageObject转换为字符串。该类会判断MessageObject的类型，如果是哈希表，就序列化成{key=value,key=value}这种形式，同样的，PatternLayout会自动处理数组。

log4net通过注册PatternConverter类，将“message”与“MessagePatternConverter”类绑定在一起，这样当PatternLayout遇到%message时，就会创建一个MessagePatternConverter类，利用这个类将MessageObject转换为字符串。同理，PatternLayout中的类似%n、%l等参数，都是这样通过实现的。

因此，假设我们要实现自己的Layout更改%message的格式化方式，则只需要创建一个自己的PatternLayout类，并在构造方法中调用AddConverter方法，将message重新注册为我们自己的“MyMessagePatternConverter”就可以了。

4、ObjectRender

除了通过Layout控制日志文本的格式化方式，我们还可以通过注册对象的Render方式，让log4net在遇到指定类型的对象时，自动使用对应的ObjectRender来格式化日志。

比如：如果我们觉得log4net输出的异常信息不够详细。我们更想使用类似微软企业类库中的异常格式化方式。那么我们可以自定义一个ExceptionRender，在这个类里面使用企业类库中的类将异常格式化为文本，然后注册ExceptionRender：

   ExceptionRender exceptionRender = new ExceptionRender();
   foreach(ILoggerRepository i in LogManager.GetAllRepositories())
   {
    i.RendererMap.Put(typeof(Exception), exceptionRender);
   }

5、配置文件实例：

下面是一个配置文件实例。

 1）、注册ConfigSection

使用log4net配置文件时，必须告诉应用程序配置文件中的<log4net>*</log4net>节点需要使用那个配置节解析类去处理。因此，必须在配置文件的configSections节添加注册。

2）、Logger设置

本实例中只设置了一个Logger，即名字为Root的Logger，其日志级别为All（即记录所有的日志），并关联了三个Appender。

3）、RollingFileAppender设置

本例中使用RollingFileAppender将日志以非独占的方式写入到了滚动文件中，文件的滚动方式为按日期滚动，文件名格式为“Log/yyyy-MM-dd.log”注意DatePattern中的&quot;.log&quot;部分：如果不用&quot;将“.log”括起来，最终的文件名可能变成乱码。使用&quot;将yyyy-MM-dd这样的日期格式之外的部分括起来可以避免文件名出错。

在使用FileAppender时，默认是独占日志文件的，即程序运行时会一直打开文件并禁止其他用户读文件。这样对于查阅日志是不便的。可以通过指定FileAppender的LockingModel为MinimalLock即可，比如文件中的第27行。

4）、Filter

在该配置文件的第45行，为AlertAppender设置了一个Filter，指定只有日志级别大于或等于Error时，该Appender才会生效。

5）、给对象设置属性

在上面的例子中，有很多param节点等。log4net在读取配置节时，会使用反射的方式去查看对象是否有一个同名的属性，如果有就会将指定的值绑定到对象的属性中去。如果是简单属性，使用param节就可以了；否则就要像第16行一样，添加一个同名的节点并且设置type属性。

不过，上述过程在最新的操作系统上不同，因为这些新的操作系统认得托管程序的标志（也就是说知道根据PE文件中的标志去判断是否是托管程序），因此在加载时就会直接调用_CorExeMain，JMP指令直接被跳过的。

刚才说了托管程序在启动时的一些特殊处理：系统在进入入口函数前会首先调用MSCorEE.dll中的代码来启动CLR并做一些初始工作，然后再进入入口函数。但还有个问题没提到：那就是刚才我们有说到托管程序的编译结果是IL代码，这个IL代码是在运行时被CLR实时编译的。那么，这个实时编译的过程又是怎样的呢？

实际上，IL中的方法并不是每次被调用时都会被重新编译一次，而是就像我们平时采用的“LazyLoad”一样，他只有在第一次被调用的时候才会被编译。即时编译器保存有一个映射表。当调用一个方法时，即时编译器如果发现在这个映射表中没有标记这个方法，就会将这个方法的IL代码编译成CPU指令，然后分配在一个内存空间上，然后在这个映射表中记录下这个方法名和方法入口对应的内存地址，然后通过JMP指令跳转到函数中去。当下次再产生对这个方法的调用时，即时编译器因为已经知道了这个方法对应的内存地址，因此就会直接通过JMP指令跳转，而不会再次编译这段代码。

因此可以看出，只要程序所有的代码都被执行过一次了，那么整个程序就都会被编译成CPU指令保存在内存中。在此之后托管程序跟非托管程序的执行效率就基本上没什么区别了——当然，托管程序需要从那个映射表中取函数地址，而非托管程序中方法的地址是已知的。

因此，理论上在某些情况下（比如win service、iis等长期循环执行的程序），托管程序的性能并不会比非托管程序的性能差多少。而且，非托管程序因为要考虑兼容性必须兼容标准指令，而非托管程序因为是运行时编译的，非常清楚操作系统环境，因此可以做针对性的优化。

不过，因为即时编译的结果是保存在内存中的，因此对于那些会频繁启动的程序来讲，其启动过程是会比较慢的——因为每次启动都需要加载CLR并做一次即时编译。

至此，在了解到了托管程序与非托管程序在加载、执行时的区别，我们就可以更加清楚怎样才能充分利用非托管程序的优点、避免其缺点，从而发挥他的最大价值、避免使用时走入误区。

//WINNT.H
typedef struct _IMAGE_DOS_HEADER { // DOS的.EXE头部
USHORT e_magic; // 魔术数字
USHORT e_cblp; // 文件最后页的字节数
USHORT e_cp; // 文件页数
USHORT e_crlc; // 重定义元素个数
USHORT e_cparhdr; // 头部尺寸，以段落为单位
USHORT e_minalloc; // 所需的最小附加段
USHORT e_maxalloc; // 所需的最大附加段
USHORT e_ss; // 初始的SS值（相对偏移量）
USHORT e_sp; // 初始的SP值
USHORT e_csum; // 校验和
USHORT e_ip; // 初始的IP值
USHORT e_cs; // 初始的CS值（相对偏移量）
USHORT e_lfarlc; // 重分配表文件地址
USHORT e_ovno; // 覆盖号
USHORT e_res[4]; // 保留字
USHORT e_oemid; // OEM标识符（相对e_oeminfo）
USHORT e_oeminfo; // OEM信息
USHORT e_res2[10]; // 保留字
LONG e_lfanew; // 新exe头部的文件地址
} IMAGE_DOS_HEADER, *PIMAGE_DOS_HEADER;

//PEFILE.H
#define NTSIGNATURE(a) ((LPVOID)((BYTE *)a + \
((PIMAGE_DOS_HEADER)a)->e_lfanew))

//PEFILE.C
DWORD WINAPI ImageFileType (LPVOID lpFile)
{
/* 首先出现的是DOS文件标志 */
if (*(USHORT *)lpFile == IMAGE_DOS_SIGNATURE)
{
/* 由DOS头部决定PE文件头部的位置 */
if (LOWORD (*(DWORD *)NTSIGNATURE (lpFile)) ==
IMAGE_OS2_SIGNATURE ||
LOWORD (*(DWORD *)NTSIGNATURE (lpFile)) ==
IMAGE_OS2_SIGNATURE_LE)
return (DWORD)LOWORD(*(DWORD *)NTSIGNATURE (lpFile));
else if (*(DWORD *)NTSIGNATURE (lpFile) ==
IMAGE_NT_SIGNATURE)
return IMAGE_NT_SIGNATURE;
else
return IMAGE_DOS_SIGNATURE;
}
else
/* 不明文件种类 */
return 0;
}

//WINNT.H
#define IMAGE_DOS_SIGNATURE 0x5A4D // MZ
#define IMAGE_OS2_SIGNATURE 0x454E // NE
#define IMAGE_OS2_SIGNATURE_LE 0x454C // LE
#define IMAGE_NT_SIGNATURE 0x00004550 // PE00
　　

//PEFILE.C
#define PEFHDROFFSET(a) ((LPVOID)((BYTE *)a + \
((PIMAGE_DOS_HEADER)a)->e_lfanew + \
SIZE_OF_NT_SIGNATURE))
　　

PIMAGE_FILE_HEADER pfh;
pfh = (PIMAGE_FILE_HEADER)PEFHDROFFSET(lpFile);

//WINNT.H
typedef struct _IMAGE_FILE_HEADER {
USHORT Machine;
USHORT NumberOfSections;
ULONG TimeDateStamp;
ULONG PointerToSymbolTable;
ULONG NumberOfSymbols;
USHORT SizeOfOptionalHeader;
USHORT Characteristics;
} IMAGE_FILE_HEADER, *PIMAGE_FILE_HEADER;
#define IMAGE_SIZEOF_FILE_HEADER 20

PEFILE.C
int WINAPI NumOfSections(LPVOID lpFile)
{
/* 文件头部中所表示出的段数目 */
return (int)((PIMAGE_FILE_HEADER)
PEFHDROFFSET (lpFile))->NumberOfSections);
}

//PEFILE.H
#define OPTHDROFFSET(a) ((LPVOID)((BYTE *)a + \
((PIMAGE_DOS_HEADER)a)->e_lfanew + \
SIZE_OF_NT_SIGNATURE + \
sizeof(IMAGE_FILE_HEADER)))
　　

//WINNT.H
typedef struct _IMAGE_OPTIONAL_HEADER {
//
// 标准域
//
USHORT Magic;
UCHAR MajorLinkerVersion;
UCHAR MinorLinkerVersion;
ULONG SizeOfCode;
ULONG SizeOfInitializedData;
ULONG SizeOfUninitializedData;
ULONG AddressOfEntryPoint;
ULONG BaseOfCode;
ULONG BaseOfData;
//
// NT附加域
//
ULONG ImageBase;
ULONG SectionAlignment;
ULONG FileAlignment;
USHORT MajorOperatingSystemVersion;
USHORT MinorOperatingSystemVersion;
USHORT MajorImageVersion;
USHORT MinorImageVersion;
USHORT MajorSubsystemVersion;
USHORT MinorSubsystemVersion;
ULONG Reserved1;
ULONG SizeOfImage;
ULONG SizeOfHeaders;
ULONG CheckSum;
USHORT Subsystem;
USHORT DllCharacteristics;
ULONG SizeOfStackReserve;
ULONG SizeOfStackCommit;
ULONG SizeOfHeapReserve;
ULONG SizeOfHeapCommit;
ULONG LoaderFlags;
ULONG NumberOfRvaAndSizes;
IMAGE_DATA_DIRECTORY DataDirectory[IMAGE_NUMBEROF_DIRECTORY_ENTRIES];
} IMAGE_OPTIONAL_HEADER, *PIMAGE_OPTIONAL_HEADER;

//PEFILE.C
LPVOID WINAPI GetModuleEntryPoint(LPVOID lpFile)
{
PIMAGE_OPTIONAL_HEADER poh;
poh = (PIMAGE_OPTIONAL_HEADER)OPTHDROFFSET(lpFile);
if (poh != NULL)
return (LPVOID)poh->AddressOfEntryPoint;
else
return NULL;
}

//WINNT.H
// 目录入口
// 导出目录
#define IMAGE_DIRECTORY_ENTRY_EXPORT 0
// 导入目录
#define IMAGE_DIRECTORY_ENTRY_IMPORT 1
// 资源目录
#define IMAGE_DIRECTORY_ENTRY_RESOURCE 2
// 异常目录
#define IMAGE_DIRECTORY_ENTRY_EXCEPTION 3
// 安全目录
#define IMAGE_DIRECTORY_ENTRY_SECURITY 4
// 重定位基本表
#define IMAGE_DIRECTORY_ENTRY_BASERELOC 5
// 调试目录
#define IMAGE_DIRECTORY_ENTRY_DEBUG 6
// 描述字串
#define IMAGE_DIRECTORY_ENTRY_COPYRIGHT 7
// 机器值（MIPS GP）
#define IMAGE_DIRECTORY_ENTRY_GLOBALPTR 8
// TLS目录
#define IMAGE_DIRECTORY_ENTRY_TLS 9
// 载入配置目录
#define IMAGE_DIRECTORY_ENTRY_LOAD_CONFIG 10
　　

//WINNT.H
typedef struct _IMAGE_DATA_DIRECTORY {
ULONG VirtualAddress;
ULONG Size;
} IMAGE_DATA_DIRECTORY, *PIMAGE_DATA_DIRECTORY;

//WINNT.H
#define IMAGE_SIZEOF_SHORT_NAME 8
typedef struct _IMAGE_SECTION_HEADER {
UCHAR Name[IMAGE_SIZEOF_SHORT_NAME];
union {
ULONG PhysicalAddress;
ULONG VirtualSize;
} Misc;
ULONG VirtualAddress;
ULONG SizeOfRawData;
ULONG PointerToRawData;
ULONG PointerToRelocations;
ULONG PointerToLinenumbers;
USHORT NumberOfRelocations;
USHORT NumberOfLinenumbers;
ULONG Characteristics;
} IMAGE_SECTION_HEADER, *PIMAGE_SECTION_HEADER;
　　

//PEFILE.C
BOOL WINAPI GetSectionHdrByName(LPVOID lpFile, IMAGE_SECTION_HEADER *sh, char *szSection)
{
PIMAGE_SECTION_HEADER psh;
int nSections = NumOfSections (lpFile);
int i;
if ((psh = (PIMAGE_SECTION_HEADER)SECHDROFFSET(lpFile))
!= NULL)
{
/* 由名称查找段 */
for (i = 0; i < nSections; i++)
{
if (!strcmp(psh->Name, szSection))
{
/* 向头部复制数据 */
CopyMemory((LPVOID)sh, (LPVOID)psh,
sizeof(IMAGE_SECTION_HEADER));
return TRUE;
}
else
psh++;
}
}
return FALSE;
}

// PEFILE.C
LPVOID WINAPI ImageDirectoryOffset(LPVOID lpFile,
DWORD dwIMAGE_DIRECTORY)
{
PIMAGE_OPTIONAL_HEADER poh;
PIMAGE_SECTION_HEADER psh;
int nSections = NumOfSections(lpFile);
int i = 0;
LPVOID VAImageDir;
/* 必须为0到(NumberOfRvaAndSizes-1)之间 */
if (dwIMAGE_DIRECTORY >= poh->NumberOfRvaAndSizes)
return NULL;
/* 获得可选头部和段头部的偏移量 */
poh = (PIMAGE_OPTIONAL_HEADER)OPTHDROFFSET(lpFile);
psh = (PIMAGE_SECTION_HEADER)SECHDROFFSET(lpFile);
/* 定位映像目录的相对虚拟地址 */
VAImageDir = (LPVOID)poh->DataDirectory
[dwIMAGE_DIRECTORY].VirtualAddress;
/* 定位包含映像目录的段 */
while (i++ < nSections)
{
if (psh->VirtualAddress <= (DWORD)VAImageDir &&
psh->VirtualAddress +
psh->SizeOfRawData > (DWORD)VAImageDir)
break;
psh++;
}
if (i > nSections)
return NULL;
/* 返回映像导入目录的偏移量 */
return (LPVOID)(((int)lpFile +
(int)VAImageDir. psh->VirtualAddress) +
(int)psh->PointerToRawData);
}
　　

//WINNT.H
typedef struct _IMAGE_RESOURCE_DIRECTORY {
ULONG Characteristics;
ULONG TimeDateStamp;
USHORT MajorVersion;
USHORT MinorVersion;
USHORT NumberOfNamedEntries;
USHORT NumberOfIdEntries;
} IMAGE_RESOURCE_DIRECTORY, *PIMAGE_RESOURCE_DIRECTORY;
　　

// WINNT.H
typedef struct _IMAGE_RESOURCE_DIRECTORY_ENTRY {
ULONG Name;
ULONG OffsetToData;
} IMAGE_RESOURCE_DIRECTORY_ENTRY, *PIMAGE_RESOURCE_DIRECTORY_ENTRY;

// WINNT.H
typedef struct _IMAGE_RESOURCE_DATA_ENTRY {
ULONG OffsetToData;
ULONG Size;
ULONG CodePage;
ULONG Reserved;
} IMAGE_RESOURCE_DATA_ENTRY, *PIMAGE_RESOURCE_DATA_ENTRY;

//WINUSER.H
/*
* 预定义的资源种类
*/
#define RT_CURSOR MAKEINTRESOURCE(1)
#define RT_BITMAP MAKEINTRESOURCE(2)
#define RT_ICON MAKEINTRESOURCE(3)
#define RT_MENU MAKEINTRESOURCE(4)
#define RT_DIALOG MAKEINTRESOURCE(5)
#define RT_STRING MAKEINTRESOURCE(6)
#define RT_FONTDIR MAKEINTRESOURCE(7)
#define RT_FONT MAKEINTRESOURCE(8)
#define RT_ACCELERATOR MAKEINTRESOURCE(9)
#define RT_RCDATA MAKEINTRESOURCE(10)
#define RT_MESSAGETABLE MAKEINTRESOURCE(11)
　　

// WINNT.H
typedef struct _IMAGE_RESOURCE_DIR_STRING_U {
USHORT Length;
WCHAR NameString[1];
} IMAGE_RESOURCE_DIR_STRING_U, *PIMAGE_RESOURCE_DIR_STRING_U;
　　

// PEFILE.C
int WINAPI GetListOfResourceTypes(LPVOID lpFile, HANDLE hHeap, char **pszResTypes)
{
PIMAGE_RESOURCE_DIRECTORY prdRoot;
PIMAGE_RESOURCE_DIRECTORY_ENTRY prde;
char *pMem;
int nCnt, i;
/* 获得资源树的根目录 */
if ((prdRoot = (PIMAGE_RESOURCE_DIRECTORY)ImageDirectoryOffset
(lpFile, IMAGE_DIRECTORY_ENTRY_RESOURCE)) == NULL)
return 0;
/* 在堆上分配足够的空间来包括所有类型 */
nCnt = prdRoot->NumberOfIdEntries * (MAXRESOURCENAME + 1);
*pszResTypes = (char *)HeapAlloc(hHeap, HEAP_ZERO_MEMORY,
nCnt);
if ((pMem = *pszResTypes) == NULL)
return 0;
/* 将指针指向第一个资源种类的入口 */
prde = (PIMAGE_RESOURCE_DIRECTORY_ENTRY)((DWORD)prdRoot +
sizeof (IMAGE_RESOURCE_DIRECTORY));
/* 在所有的资源目录入口类型中循环 */
for (i = 0; i < prdRoot->NumberOfIdEntries; i++)
{
if (LoadString(hDll, prde->Name, pMem, MAXRESOURCENAME))
pMem += strlen(pMem) + 1;
prde++;
}
return nCnt;
}
　　

// WINNT.H
typedef struct _IMAGE_EXPORT_DIRECTORY {
ULONG Characteristics;
ULONG TimeDateStamp;
USHORT MajorVersion;
USHORT MinorVersion;
ULONG Name;
ULONG Base;
ULONG NumberOfFunctions;
ULONG NumberOfNames;
PULONG *AddressOfFunctions;
PULONG *AddressOfNames;
PUSHORT *AddressOfNameOrdinals;
} IMAGE_EXPORT_DIRECTORY, *PIMAGE_EXPORT_DIRECTORY;
　　

// PEFILE.C
int WINAPI GetExportFunctionNames(LPVOID lpFile, HANDLE hHeap, char **pszFunctions)
{
IMAGE_SECTION_HEADER sh;
PIMAGE_EXPORT_DIRECTORY ped;
char *pNames, *pCnt;
int i, nCnt;
/* 获得.edata域中的段头部和指向数据目录的指针 */
if ((ped = (PIMAGE_EXPORT_DIRECTORY)ImageDirectoryOffset
(lpFile, IMAGE_DIRECTORY_ENTRY_EXPORT)) == NULL)
return 0;
GetSectionHdrByName (lpFile, &sh, ".edata");
/* 决定导出函数名称的偏移量 */
pNames = (char *)(*(int *)((int)ped->AddressOfNames -
(int)sh.VirtualAddress + (int)sh.PointerToRawData +
(int)lpFile) - (int)sh.VirtualAddress +
(int)sh.PointerToRawData + (int)lpFile);
/* 计算出要为所有的字符串分配多少内存 */
pCnt = pNames;
for (i = 0; i < (int)ped->NumberOfNames; i++)
while (*pCnt++);
nCnt = (int)(pCnt.pNames);
/* 在堆上为函数名称分配内存 */
*pszFunctions = HeapAlloc (hHeap, HEAP_ZERO_MEMORY, nCnt);
/* 将所有字符串复制到缓冲区 */
CopyMemory((LPVOID)*pszFunctions, (LPVOID)pNames, nCnt);
return nCnt;
}

// PEFILE.H
typedef struct tagImportDirectory
{
DWORD dwRVAFunctionNameList;
DWORD dwUseless1;
DWORD dwUseless2;
DWORD dwRVAModuleName;
DWORD dwRVAFunctionAddressList;
} IMAGE_IMPORT_MODULE_DIRECTORY, *PIMAGE_IMPORT_MODULE_DIRECTORY;

//PEFILE.C
int WINAPI GetImportModuleNames(LPVOID lpFile, HANDLE hHeap, char **pszModules)
{
PIMAGE_IMPORT_MODULE_DIRECTORY pid;
IMAGE_SECTION_HEADER idsh;
BYTE *pData;
int nCnt = 0, nSize = 0, i;
char *pModule[1024];
char *psz;
pid = (PIMAGE_IMPORT_MODULE_DIRECTORY)ImageDirectoryOffset
(lpFile, IMAGE_DIRECTORY_ENTRY_IMPORT);
pData = (BYTE *)pid;
/* 定位.idata段头部 */
if (!GetSectionHdrByName(lpFile, &idsh, ".idata"))
return 0;
/* 提取所有导入模块 */
while (pid->dwRVAModuleName)
{
/* 为绝对字符串偏移量分配缓冲区 */
pModule[nCnt] = (char *)(pData +
(pid->dwRVAModuleName-idsh.VirtualAddress));
nSize += strlen(pModule[nCnt]) + 1;
/* 增至下一个导入目录入口 */
pid++;
nCnt++;
}
/* 将所有字符串赋值到一大块的堆内存中 */
*pszModules = HeapAlloc(hHeap, HEAP_ZERO_MEMORY, nSize);
psz = *pszModules;
for (i = 0; i < nCnt; i++)
{
strcpy(psz, pModule[i]);
psz += strlen (psz) + 1;
}
return nCnt;
}

E6A7 0000 F6A7 0000 08A8 0000 1AA8 0000 ................
28A8 0000 3CA8 0000 4CA8 0000 0000 0000 (...<...L.......
0000 4765 744F 7065 6E46 696C 654E 616D ..GetOpenFileNam
6541 0000 636F 6D64 6C67 3332 2E64 6C6C eA..comdlg32.dll
0000 2500 4372 6561 7465 466F 6E74 496E ..%.CreateFontIn
6469 7265 6374 4100 4744 4933 322E 646C directA.GDI32.dl
6C00 A000 4765 7444 6576 6963 6543 6170 l...GetDeviceCap
7300 C600 4765 7453 746F 636B 4F62 6A65 s...GetStockObje
6374 0000 D500 4765 7454 6578 744D 6574 ct....GetTextMet
7269 6373 4100 1001 5365 6C65 6374 4F62 ricsA...SelectOb
6A65 6374 0000 1601 5365 7442 6B43 6F6C ject....SetBkCol
6F72 0000 3501 5365 7454 6578 7443 6F6C or..5.SetTextCol
6F72 0000 4501 5465 7874 4F75 7441 0000 or..E.TextOutA..

// PEFILE.C
int WINAPI GetImportFunctionNamesByModule(LPVOID lpFile, HANDLE hHeap,
char *pszModule, char **pszFunctions)
{
PIMAGE_IMPORT_MODULE_DIRECTORY pid;
IMAGE_SECTION_HEADER idsh;
DWORD dwBase;
int nCnt = 0, nSize = 0;
DWORD dwFunction;
char *psz;
/* 定位.idata段的头部 */
if (!GetSectionHdrByName(lpFile, &idsh, ".idata"))
return 0;
pid = (PIMAGE_IMPORT_MODULE_DIRECTORY)ImageDirectoryOffset
(lpFile, IMAGE_DIRECTORY_ENTRY_IMPORT);
dwBase = ((DWORD)pid. idsh.VirtualAddress);
/* 查找模块的pid */
while (pid->dwRVAModuleName && strcmp (pszModule,
(char *)(pid->dwRVAModuleName+dwBase)))
pid++;
/* 如果模块未找到，就退出 */
if (!pid->dwRVAModuleName)
return 0;
/* 函数的总数和字符串长度 */
dwFunction = pid->dwRVAFunctionNameList;
while (dwFunction && *(DWORD *)(dwFunction + dwBase) &&
*(char *)((*(DWORD *)(dwFunction + dwBase)) + dwBase+2))
{
nSize += strlen ((char *)((*(DWORD *)(dwFunction +
dwBase)) + dwBase+2)) + 1;
dwFunction += 4;
nCnt++;
}
/* 在堆上分配函数名称的空间 */
*pszFunctions = HeapAlloc (hHeap, HEAP_ZERO_MEMORY, nSize);
psz = *pszFunctions;
/* 向内存指针复制函数名称 */
dwFunction = pid->dwRVAFunctionNameList;
while (dwFunction && *(DWORD *)(dwFunction + dwBase) &&
*((char *)((*(DWORD *)(dwFunction + dwBase)) + dwBase+2)))
{
strcpy (psz, (char *)((*(DWORD *)(dwFunction + dwBase)) +
dwBase+2));
psz += strlen((char *)((*(DWORD *)(dwFunction + dwBase))+
dwBase+2)) + 1;
dwFunction += 4;
}
return nCnt;
}
　　

// WINNT.H
typedef struct _IMAGE_DEBUG_DIRECTORY {
ULONG Characteristics;
ULONG TimeDateStamp;
USHORT MajorVersion;
USHORT MinorVersion;
ULONG Type;
ULONG SizeOfData;
ULONG AddressOfRawData;
ULONG PointerToRawData;
} IMAGE_DEBUG_DIRECTORY, *PIMAGE_DEBUG_DIRECTORY;

// WINNT.H
#define IMAGE_DEBUG_TYPE_UNKNOWN 0
#define IMAGE_DEBUG_TYPE_COFF 1
#define IMAGE_DEBUG_TYPE_CODEVIEW 2
#define IMAGE_DEBUG_TYPE_FPO 3
#define IMAGE_DEBUG_TYPE_MISC 4
　　

//PEFILE.C
int WINAPI RetrieveModuleName(LPVOID lpFile, HANDLE hHeap, char **pszModule)
{
PIMAGE_DEBUG_DIRECTORY pdd;
PIMAGE_DEBUG_MISC pdm = NULL;
int nCnt;
if (!(pdd = (PIMAGE_DEBUG_DIRECTORY)ImageDirectoryOffset(lpFile,
IMAGE_DIRECTORY_ENTRY_DEBUG)))
return 0;
while (pdd->SizeOfData)
{
if (pdd->Type == IMAGE_DEBUG_TYPE_MISC)
{
pdm = (PIMAGE_DEBUG_MISC)((DWORD)pdd->PointerToRawData + (DWORD)lpFile);
nCnt = lstrlen(pdm->Data) * (pdm->Unicode ? 2 : 1);
*pszModule = (char *)HeapAlloc(hHeap, HEAP_ZERO_MEMORY, nCnt+1);
CopyMemory(*pszModule, pdm->Data, nCnt);
break;
}
pdd ++;
}
if (pdm != NULL)
return nCnt;
else
return 0;
}

// PEFILE.H
/* 获得指向MS-DOS MZ头部的指针 */
BOOL WINAPI GetDosHeader(LPVOID, PIMAGE_DOS_HEADER);
/* 决定.EXE文件的类型 */
DWORD WINAPI ImageFileType(LPVOID);
/* 获得指向PE文件头部的指针 */
BOOL WINAPI GetPEFileHeader(LPVOID, PIMAGE_FILE_HEADER);
/* 获得指向PE可选头部的指针 */
BOOL WINAPI GetPEOptionalHeader(LPVOID, PIMAGE_OPTIONAL_HEADER);
/* 返回模块入口点的地址 */
LPVOID WINAPI GetModuleEntryPoint(LPVOID);
/* 返回文件中段的总数 */
int WINAPI NumOfSections(LPVOID);
/* 返回当可执行文件被装载入进程地址空间时的首选基地址 */
LPVOID WINAPI GetImageBase(LPVOID);
/* 决定文件中一个特定的映像数据目录的位置 */
LPVOID WINAPI ImageDirectoryOffset(LPVOID, DWORD);
/* 获得文件中所有段的名称 */
int WINAPI GetSectionNames(LPVOID, HANDLE, char **);
/* 复制一个特定段的头部信息 */
BOOL WINAPI GetSectionHdrByName(LPVOID, PIMAGE_SECTION_HEADER, char *);
/* 获得由空字符分隔的导入模块名称列表 */
int WINAPI GetImportModuleNames(LPVOID, HANDLE, char **);
/* 获得一个模块由空字符分隔的导入函数列表 */
int WINAPI GetImportFunctionNamesByModule(LPVOID, HANDLE, char *, char **);
/* 获得由空字符分隔的导出函数列表 */
int WINAPI GetExportFunctionNames(LPVOID, HANDLE, char **);
/* 获得导出函数总数 */
int WINAPI GetNumberOfExportedFunctions(LPVOID);
/* 获得导出函数的虚拟地址入口点列表 */
LPVOID WINAPI GetExportFunctionEntryPoints(LPVOID);
/* 获得导出函数顺序值列表 */
LPVOID WINAPI GetExportFunctionOrdinals(LPVOID);
/* 决定资源对象的种类 */
int WINAPI GetNumberOfResources (LPVOID);
/* 返回文件中所使用的所有资源对象的种类 */
int WINAPI GetListOfResourceTypes(LPVOID, HANDLE, char **);
/* 决定调试信息是否已从文件中分离 */
BOOL WINAPI IsDebugInfoStripped(LPVOID);
/* 获得映像文件名称 */
int WINAPI RetrieveModuleName(LPVOID, HANDLE, char **);
/* 决定文件是否是一个有效的调试文件 */
BOOL WINAPI IsDebugFile(LPVOID);
/* 从调试文件中返回调试头部 */
BOOL WINAPI GetSeparateDebugHeader(LPVOID, PIMAGE_SEPARATE_DEBUG_HEADER);
　　除了以上所列的函数之外，本文中早先提到的宏也定义在了PEFILE.H中，完整的列表如下：
/* PE文件标志的偏移量 */
#define NTSIGNATURE(a) ((LPVOID)((BYTE *)a + \
((PIMAGE_DOS_HEADER)a)->e_lfanew))
/* MS操作系统头部标识了双字的NT PE文件标志；PE文件头部就紧跟在这个双字之后 */
#define PEFHDROFFSET(a) ((LPVOID)((BYTE *)a + \
((PIMAGE_DOS_HEADER)a)->e_lfanew + \
SIZE_OF_NT_SIGNATURE))
/* PE可选头部紧跟在PE文件头部之后 */
#define OPTHDROFFSET(a) ((LPVOID)((BYTE *)a + \
((PIMAGE_DOS_HEADER)a)->e_lfanew + \
SIZE_OF_NT_SIGNATURE + \
sizeof(IMAGE_FILE_HEADER)))
/* 段头部紧跟在PE可选头部之后 */
#define SECHDROFFSET(a) ((LPVOID)((BYTE *)a + \
((PIMAGE_DOS_HEADER)a)->e_lfanew + \
SIZE_OF_NT_SIGNATURE + \
sizeof(IMAGE_FILE_HEADER) + \
sizeof(IMAGE_OPTIONAL_HEADER)))
　　

我们先回顾一下操作系统原理。
操作系统中，CPU竞争有很多种策略。Unix系统使用的是时间片算法，而Windows则属于抢占式的。

在时间片算法中，所有的进程排成一个队列。操作系统按照他们的顺序，给每个进程分配一段时间，即该进程允许运行的时间。如果在 时间片结束时进程还在运行，则CPU将被剥夺并分配给另一个进程。如果进程在时间片结束前阻塞或结束，则CPU当即进行切换。调度程 序所要做的就是维护一张就绪进程列表，，当进程用完它的时间片后，它被移到队列的末尾。

所谓抢占式操作系统，就是说如果一个进程得到了 CPU 时间，除非它自己放弃使用 CPU ，否则将完全霸占 CPU 。因此可以看出，在抢 占式操作系统中，操作系统假设所有的进程都是“人品很好”的，会主动退出 CPU 。

在抢占式操作系统中，假设有若干进程，操作系统会根据他们的优先级、饥饿时间（已经多长时间没有使用过 CPU 了），给他们算出一 个总的优先级来。操作系统就会把 CPU 交给总优先级最高的这个进程。当进程执行完毕或者自己主动挂起后，操作系统就会重新计算一 次所有进程的总优先级，然后再挑一个优先级最高的把 CPU 控制权交给他。

我们用分蛋糕的场景来描述这两种算法。假设有源源不断的蛋糕（源源不断的时间），一副刀叉（一个CPU），10个等待吃蛋糕的人（10 个进程）。

如果是 Unix操作系统来负责分蛋糕，那么他会这样定规矩：每个人上来吃 1 分钟，时间到了换下一个。最后一个人吃完了就再从头开始。于是，不管这10个人是不是优先级不同、饥饿程度不同、饭量不同，每个人上来的时候都可以吃 1 分钟。当然，如果有人本来不太饿，或者饭量小，吃了30秒钟之后就吃饱了，那么他可以跟操作系统说：我已经吃饱了（挂起）。于是操作系统就会让下一个人接着来。

如果是 Windows 操作系统来负责分蛋糕的，那么场面就很有意思了。他会这样定规矩：我会根据你们的优先级、饥饿程度去给你们每个人计算一个优先级。优先级最高的那个人，可以上来吃蛋糕——吃到你不想吃为止。等这个人吃完了，我再重新根据优先级、饥饿程度来计算每个人的优先级，然后再分给优先级最高的那个人。
这样看来，这个场面就有意思了——可能有些人是PPMM，因此具有高优先级，于是她就可以经常来吃蛋糕。可能另外一个人是个丑男，而去很ws，所以优先级特别低，于是好半天了才轮到他一次（因为随着时间的推移，他会越来越饥饿，因此算出来的总优先级就会越来越高，因此总有一天会轮到他的）。而且，如果一不小心让一个大胖子得到了刀叉，因为他饭量大，可能他会霸占着蛋糕连续吃很久很久，导致旁边的人在那里咽口水。。。
而且，还可能会有这种情况出现：操作系统现在计算出来的结果，5号PPMM总优先级最高，而且高出别人一大截。因此就叫5号来吃蛋糕。5号吃了一小会儿，觉得没那么饿了，于是说“我不吃了”（挂起）。因此操作系统就会重新计算所有人的优先级。因为5号刚刚吃过，因此她的饥饿程度变小了，于是总优先级变小了；而其他人因为多等了一会儿，饥饿程度都变大了，所以总优先级也变大了。不过这时候仍然有可能5号的优先级比别的都高，只不过现在只比其他的高一点点——但她仍然是总优先级最高的啊。因此操作系统就会说：5号mm上来吃蛋糕……（5号mm心里郁闷，这不刚吃过嘛……人家要减肥……谁叫你长那么漂亮，获得了那么高的优先级）。

那么，Thread.Sleep 函数是干吗的呢？还用刚才的分蛋糕的场景来描述。上面的场景里面，5号MM在吃了一次蛋糕之后，觉得已经有8分饱了，她觉得在未来的半个小时之内都不想再来吃蛋糕了，那么她就会跟操作系统说：在未来的半个小时之内不要再叫我上来吃蛋糕了。这样，操作系统在随后的半个小时里面重新计算所有人总优先级的时候，就会忽略5号mm。Sleep函数就是干这事的，他告诉操作系统“在未来的多少毫秒内我不参与CPU竞争”。

看完了 Thread.Sleep 的作用，我们再来想想文章开头的两个问题。

对于第一个问题，答案是：不一定。因为你只是告诉操作系统：在未来的1000毫秒内我不想再参与到CPU竞争。那么1000毫秒过去之后，这时候也许另外一个线程正在使用CPU，那么这时候操作系统是不会重新分配CPU的，直到那个线程挂起或结束；况且，即使这个时候恰巧轮到操作系统进行CPU 分配，那么当前线程也不一定就是总优先级最高的那个，CPU还是可能被其他线程抢占去。

与此相似的，Thread有个Resume函数，是用来唤醒挂起的线程的。好像上面所说的一样，这个函数只是“告诉操作系统我从现在起开始参与CPU竞争了”，这个函数的调用并不能马上使得这个线程获得CPU控制权。

对于第二个问题，答案是：有，而且区别很明显。假设我们刚才的分蛋糕场景里面，有另外一个PPMM 7号，她的优先级也非常非常高（因为非常非常漂亮），所以操作系统总是会叫道她来吃蛋糕。而且，7号也非常喜欢吃蛋糕，而且饭量也很大。不过，7号人品很好，她很善良，她没吃几口就会想：如果现在有别人比我更需要吃蛋糕，那么我就让给他。因此，她可以每吃几口就跟操作系统说：我们来重新计算一下所有人的总优先级吧。不过，操作系统不接受这个建议——因为操作系统不提供这个接口。于是7号mm就换了个说法：“在未来的0毫秒之内不要再叫我上来吃蛋糕了”。这个指令操作系统是接受的，于是此时操作系统就会重新计算大家的总优先级——注意这个时候是连7号一起计算的，因为“0毫秒已经过去了”嘛。因此如果没有比7号更需要吃蛋糕的人出现，那么下一次7号还是会被叫上来吃蛋糕。

因此，Thread.Sleep(0)的作用，就是“触发操作系统立刻重新进行一次CPU竞争”。竞争的结果也许是当前线程仍然获得CPU控制权，也许会换成别的线程获得CPU控制权。这也是我们在大循环里面经常会写一句Thread.Sleep(0) ，因为这样就给了其他线程比如Paint线程获得CPU控制权的权力，这样界面就不会假死在那里。

末了说明一下，虽然上面提到说“除非它自己放弃使用 CPU ，否则将完全霸占 CPU”，但这个行为仍然是受到制约的——操作系统会监控你霸占CPU的情况，如果发现某个线程长时间霸占CPU，会强制使这个线程挂起，因此在实际上不会出现“一个线程一直霸占着 CPU 不放”的情况。至于我们的大循环造成程序假死，并不是因为这个线程一直在霸占着CPU。实际上在这段时间操作系统已经进行过多次CPU竞争了，只不过其他线程在获得CPU控制权之后很短时间内马上就退出了，于是就又轮到了这个线程继续执行循环，于是就又用了很久才被操作系统强制挂起。。。因此反应到界面上，看起来就好像这个线程一直在霸占着CPU一样。

末了再说明一下，文中线程、进程有点混乱，其实在Windows原理层面，CPU竞争都是线程级的，本文中把这里的进程、线程看成同一个东西就好了。

1、设计过度和设计不足同样不可取

所谓的过度设计，顾名思议就是代码的灵活性、复杂性超出所需。这个问题在一些没有项目责任心的人身上是不会发生的，因为他不会去为了让项目更灵活、功能更强大而去仔细的设计这个系统，反而在一些有心将项目设计好的人身上经常发生。产生这种问题的原因，其实还是对于模式这个东西的真正意义没有理解。模式是用来将系统变简单的，而不是用来将系统变复杂的。

设计一个灵活的、能够满足未来需求变化的系统这个出发点是很好的，但是必须正视现实：如果对未来的需求预计不正确，预期中的需求根本不会变成现实，那么按此编写的代码又怎样呢？毕竟我们都无法未卜先知。

如果我们遇见某个模块将来可能会发生需求变化，我们需要根据这个可能性的概率、要投入的成本以及将带来的收益去衡量一下。

一般的系统，生命周期达到3年而不做大重构的，已经非常不容易了。那么，我们在做一般软件的时候，就完全没有必要考虑到5年、10年以后的问题。距离现在越远，需求的可测量性就越小，自己对需求的猜测正确性就越低，现在的设计还能满足需求的概率就越小。

况且，我们可以先做一些小的工作，使得将来一旦需求变化，我们只需要重构模块内部而不会对周围模块产生大的影响，就可以了。

事实上，设计模式并没有标准的模型，每种模式在不同的场景下实现的途径都可能会不同，怎样实现模式与实际环境密不可分。因此，有意义的模式都是通过重构产生的，而重构往往会产生模式。

这，也就是“演进式设计”。

就好像我们要改造一个房子，我们要把一堵墙全部换成隔音砖。那，我们是一小块一小块区域的换呢，还是一下子把一堵墙拆了重新砌墙呢？呵呵，小心房子倒掉哦～～^_^

2、设计欠账

假设你去请求开发经理给你一些时间以重构现有代码以“改善其设计”，他会有何反应呢？可能是斩钉截铁的说不：应付没完没了的需求和bug就已经够难了，哪里还有时间让你“一段时间啥功能都没完成”。

使用重构的语言和大多数管理人员沟通，效果往往都不好。不过，我们可以用设计欠账来隐喻。

人类无法一次性就写出完美的代码。我们会自然而然的累积设计欠账。所以问题就变成“应该什么时候偿还设计欠账”？

用金融术语来说，如果不偿还债务，就会产生滞纳金。如果不偿还滞纳金，滞纳金就会越来越多，而去是按照复利计算的。随着时间的转移，债务就像滚雪球或者我们所说的驴打滚一样，越来越多。设计欠账也是如此。

因此，定期的清理设计欠账，是必要的。

3、模式的真正价值只是一种思想，而不是一个框图。

对设计模式过于痴迷的人往往会走向另外一个极端。如果一个简单的HelloWorld程序，有人用了Factory、Command、Observer、Templete Method来实现，你看了会如何呢？说到这里，使我想起了微软的PetShop网站。这个网站，用了大量的设计模式——实际上这个网站就是微软设计模式系列在线培训的例程。之前面试的很多人，都提到说看过PetShop。但问及里面的模式是用来解决什么问题的，就一问三不知了。甚至有人说，仿造PetShop做过系统——这个有用么？数据库教材里面有提到第二范式第三范式甚至第N范式，我们在设计数据库的时候也要遵循第N范式么？那样设计出来的，不是系统，而是花瓶。

实际上，PetShop只是用来演示“模式能够达到什么目的”的，而不是用来演示“模式应该在什么时候用”的。

之前面试时很多人在问到设计模式的时候，就会把设计模式教程上那些框图说出来。事实上，设计模式只是一个思想，他只是一些最佳实践，真正的价值在于告诉你“遇到某种情景，可以怎样解决”，而不是告诉你“遇到某种情景，应该怎样解决”。真正优秀的系统设计，往往是跟教程上那些框图对应不起来的。

4、模式是否会使得代码更加复杂

本书的作者提到了一个现实中我们经常遇到的相同的问题，呵呵。

某人A使用设计模式很好的改造了一个模块。在作者看来，这个改造使得这个模块变得灵活、可扩展、清晰简单。而另外一个不了解设计模式的B看到这个重构后，大叫“现在的代码太复杂了！我更喜欢原来的代码！”。而在作者教B学习和掌握了这个模式后，B勉强同意代码没有他原来以为的那么复杂，但仍然表示重构后的代码并不比原先的更好。

是啊。作者对于设计模式的熟悉，使得在作者的眼里这个重构是优秀的。这件事说明，人们对于模式的熟悉程度决对于他们如何看待基于模式的重构将起到决定性的作用。因此，开发小组需要进一步学习这些模式，另一方面，某些模式的实现确实会使得代码过分复杂，如果出现这种情况，返回或者进一步重构就非常有必要。