非类成员形式的operator new的伪代码：

void * operator new(size_t size)        // operator new还可能有其它参数
{                                      

  if (size == 0)                      // 处理0字节请求时，
  {

        size = 1;                            // 把它当作1个字节请求来处理

  }                                    
  while (1)

{
    分配size字节内存;

      if (分配成功)
           return (指向内存的指针);

    // 分配不成功，找出当前出错处理函数
      new_handler globalhandler = set_new_handler(0);
     set_new_handler(globalhandler);

      if (globalhandler) (*globalhandler)();
      else throw std::bad_alloc();
  }
}

为特定类写的new往往没有考虑该类被继承的情况，使用sizeof(父类)获得大小，但是如果发生子类调用父类的new时，往往

会出错，子类的size往往大于父类的size。最好父类的new应该这么写：

void * base::operator new(size_t size)
{
  if (size != sizeof(base))                  // 如果数量“错误”，让标准operator new，精华部分。
    return ::operator new(size);        // 去处理这个请求
                                                         //

  ...                                                    // 否则处理这个请求
}

对于operator delete(以及它的伙伴operator delete[])，情况更简单。所要记住的只是，c++保证删除空指针永远是安全的，所以你要充分地应用这一保证。

下面是非类成员形式的operator delete的伪代码：
void operator delete(void *rawmemory)
{
  if (rawmemory == 0) return;   //如果指针为空，返回
                                 //

  释放rawmemory指向的内存;

  return;
}

这个函数的类成员版本也简单，只是还必须检查被删除的对象的大小。假设类的operator new将“错误”大小的分配请求转给::operator new，那么也必须将“错误”大小的删除请求转给::operator delete：

void base::operator delete(void *rawmemory, size_t size)
{
  if (rawmemory == 0) return;          // 检查空指针

  if (size != sizeof(base))                 // 如果size"错误"，

{    
    ::operator delete(rawmemory);  // 让标准operator来处理请求
    return;                       
  }

  释放指向rawmemory的内存;

  return;
}

有关operator new和operator delete(以及他们的数组形式)的规定不是那么麻烦，重要的是必须遵守它。只要内存分配程序支持new-handler函数并正确地处理了零内存请求，就差不多了；如果内存释放程序又处理了空指针，那就没其他什么要做的了。至于在类成员版本的函数里增加继承支持，那将很快就可以完成。

例子程序
这是一个前辈写的，非常详细
//main.cpp
int a = 0; 全局初始化区
char *p1; 全局未初始化区
main()
{
int b; 栈
char s[] = "abc"; 栈
char *p2; 栈
char *p3 = "123456"; 123456\0在常量区，p3在栈上。
static int c =0； 全局（静态）初始化区
p1 = (char *)malloc(10);
p2 = (char *)malloc(20);
分配得来得10和20字节的区域就在堆区。
strcpy(p1, "123456"); 123456\0放在常量区，编译器可能会将它与p3所指向的"123456"优化成一个地方。
}


二、堆和栈的理论知识

2.1申请方式
stack:
由系统自动分配。 例如，声明在函数中一个局部变量 int b; 系统自动在栈中为b开辟空间
heap:
需要程序员自己申请，并指明大小，在c中malloc函数
如p1 = (char *)malloc(10);
在C++中用new运算符
如p2 = (char *)malloc(10);
但是注意p1、p2本身是在栈中的。

2.2申请后系统的响应
栈：只要栈的剩余空间大于所申请空间，系统将为程序提供内存，否则将报异常提示栈溢出。
堆：首先应该知道操作系统有一个记录空闲内存地址的链表，当系统收到程序的申请时，
会遍历该链表，寻找第一个空间大于所申请空间的堆结点，然后将该结点从空闲结点链表中删除，并将该结点的空间分配给程序，另外，对于大多数系统，会在这块内存空间中的首地址处记录本次分配的大小，这样，代码中的delete语句才能正确的释放本内存空间。另外，由于找到的堆结点的大小不一定正好等于申请的大小，系统会自动的将多余的那部分重新放入空闲链表中。

2.3申请大小的限制
栈：在Windows下,栈是向低地址扩展的数据结构，是一块连续的内存的区域。这句话的意思是栈顶的地址和栈的最大容量是系统预先规定好的，在WINDOWS下，栈的大小是2M（也有的说是1M，总之是一个编译时就确定的常数），如果申请的空间超过栈的剩余空间时，将提示overflow。因此，能从栈获得的空间较小。
堆：堆是向高地址扩展的数据结构，是不连续的内存区域。这是由于系统是用链表来存储的空闲内存地址的，自然是不连续的，而链表的遍历方向是由低地址向高地址。堆的大小受限于计算机系统中有效的虚拟内存。由此可见，堆获得的空间比较灵活，也比较大。


2.4申请效率的比较
栈由系统自动分配，速度较快。但程序员是无法控制的。
堆是由new分配的内存，一般速度比较慢，而且容易产生内存碎片,不过用起来最方便.
另外，在WINDOWS下，最好的方式是用VirtualAlloc分配内存，他不是在堆，也不是在栈是直接在进程的地址空间中保留一快内存，虽然用起来最不方便。但是速度快，也最灵活。

2.5堆和栈中的存储内容
栈： 在函数调用时，第一个进栈的是主函数中后的下一条指令（函数调用语句的下一条可执行语句）的地址，然后是函数的各个参数，在大多数的C编译器中，参数是由右往左入栈的，然后是函数中的局部变量。注意静态变量是不入栈的。
当本次函数调用结束后，局部变量先出栈，然后是参数，最后栈顶指针指向最开始存的地址，也就是主函数中的下一条指令，程序由该点继续运行。
堆：一般是在堆的头部用一个字节存放堆的大小。堆中的具体内容有程序员安排。

2.6存取效率的比较
char s1[] = "aaaaaaaaaaaaaaa";
char *s2 = "bbbbbbbbbbbbbbbbb";
aaaaaaaaaaa是在运行时刻赋值的；
而bbbbbbbbbbb是在编译时就确定的；
但是，在以后的存取中，在栈上的数组比指针所指向的字符串(例如堆)快。
比如：
＃i nclude
void main()
{
char a = 1;
char c[] = "1234567890";
char *p ="1234567890";
a = c[1];
a = p[1];
return;
}
对应的汇编代码
10: a = c[1];
00401067 8A 4D F1 mov cl,byte ptr [ebp-0Fh]
0040106A 88 4D FC mov byte ptr [ebp-4],cl
11: a = p[1];
0040106D 8B 55 EC mov edx,dword ptr [ebp-14h]
00401070 8A 42 01 mov al,byte ptr [edx+1]
00401073 88 45 FC mov byte ptr [ebp-4],al
第一种在读取时直接就把字符串中的元素读到寄存器cl中，而第二种则要先把指针值读到edx中，在根据edx读取字符，显然慢了。

2.7小结
堆和栈的区别可以用如下的比喻来看出：
使用栈就象我们去饭馆里吃饭，只管点菜（发出申请）、付钱、和吃（使用），吃饱了就走，不必理会切菜、洗菜等准备工作和洗碗、刷锅等扫尾工作，他的好处是快捷，但是自由度小。
使用堆就象是自己动手做喜欢吃的菜肴，比较麻烦，但是比较符合自己的口味，而且自由度大。



windows进程中的内存结构


在阅读本文之前，如果你连堆栈是什么多不知道的话，请先阅读文章后面的基础知识。

接触过编程的人都知道，高级语言都能通过变量名来访问内存中的数据。那么这些变量在内存中是如何存放的呢？程序又是如何使用这些变量的呢？下面就会对此进行深入的讨论。下文中的C语言代码如没有特别声明，默认都使用VC编译的release版。

首先，来了解一下 C 语言的变量是如何在内存分部的。C 语言有全局变量(Global)、本地变量(Local)，静态变量(Static)、寄存器变量(Regeister)。每种变量都有不同的分配方式。先来看下面这段代码：

＃i nclude <stdio.h>

int g1=0, g2=0, g3=0;

int main()
{
static int s1=0, s2=0, s3=0;
int v1=0, v2=0, v3=0;

//打印出各个变量的内存地址

printf("0x%08x\n",&v1); //打印各本地变量的内存地址
printf("0x%08x\n",&v2);
printf("0x%08x\n\n",&v3);
printf("0x%08x\n",&g1); //打印各全局变量的内存地址
printf("0x%08x\n",&g2);
printf("0x%08x\n\n",&g3);
printf("0x%08x\n",&s1); //打印各静态变量的内存地址
printf("0x%08x\n",&s2);
printf("0x%08x\n\n",&s3);
return 0;
}

编译后的执行结果是：

0x0012ff78
0x0012ff7c
0x0012ff80

0x004068d0
0x004068d4
0x004068d8

0x004068dc
0x004068e0
0x004068e4

输出的结果就是变量的内存地址。其中v1,v2,v3是本地变量，g1,g2,g3是全局变量，s1,s2,s3是静态变量。你可以看到这些变量在内存是连续分布的，但是本地变量和全局变量分配的内存地址差了十万八千里，而全局变量和静态变量分配的内存是连续的。这是因为本地变量和全局/静态变量是分配在不同类型的内存区域中的结果。对于一个进程的内存空间而言，可以在逻辑上分成3个部份：代码区，静态数据区和动态数据区。动态数据区一般就是“堆栈”。“栈(stack)”和“堆(heap)”是两种不同的动态数据区，栈是一种线性结构，堆是一种链式结构。进程的每个线程都有私有的“栈”，所以每个线程虽然代码一样，但本地变量的数据都是互不干扰。一个堆栈可以通过“基地址”和“栈顶”地址来描述。全局变量和静态变量分配在静态数据区，本地变量分配在动态数据区，即堆栈中。程序通过堆栈的基地址和偏移量来访问本地变量。


├———————┤低端内存区域
│ …… │
├———————┤
│ 动态数据区 │
├———————┤
│ …… │
├———————┤
│ 代码区 │
├———————┤
│ 静态数据区 │
├———————┤
│ …… │
├———————┤高端内存区域


堆栈是一个先进后出的数据结构，栈顶地址总是小于等于栈的基地址。我们可以先了解一下函数调用的过程，以便对堆栈在程序中的作用有更深入的了解。不同的语言有不同的函数调用规定，这些因素有参数的压入规则和堆栈的平衡。windows API的调用规则和ANSI C的函数调用规则是不一样的，前者由被调函数调整堆栈，后者由调用者调整堆栈。两者通过“__stdcall”和“__cdecl”前缀区分。先看下面这段代码：

＃i nclude <stdio.h>

void __stdcall func(int param1,int param2,int param3)
{
int var1=param1;
int var2=param2;
int var3=param3;
printf("0x%08x\n",?m1); //打印出各个变量的内存地址
printf("0x%08x\n",?m2);
printf("0x%08x\n\n",?m3);
printf("0x%08x\n",&var1);
printf("0x%08x\n",&var2);
printf("0x%08x\n\n",&var3);
return;
}

int main()
{
func(1,2,3);
return 0;
}

编译后的执行结果是：

0x0012ff78
0x0012ff7c
0x0012ff80

0x0012ff68
0x0012ff6c
0x0012ff70


├———————┤<—函数执行时的栈顶（ESP）、低端内存区域
│ …… │
├———————┤
│ var 1 │
├———————┤
│ var 2 │
├———————┤
│ var 3 │
├———————┤
│ RET │
├———————┤<—“__cdecl”函数返回后的栈顶（ESP）
│ parameter 1 │
├———————┤
│ parameter 2 │
├———————┤
│ parameter 3 │
├———————┤<—“__stdcall”函数返回后的栈顶（ESP）
│ …… │
├———————┤<—栈底（基地址 EBP）、高端内存区域


上图就是函数调用过程中堆栈的样子了。首先，三个参数以从又到左的次序压入堆栈，先压“param3”，再压“param2”，最后压入“param1”；然后压入函数的返回地址(RET)，接着跳转到函数地址接着执行（这里要补充一点，介绍UNIX下的缓冲溢出原理的文章中都提到在压入RET后，继续压入当前EBP，然后用当前ESP代替EBP。然而，有一篇介绍windows下函数调用的文章中说，在windows下的函数调用也有这一步骤，但根据我的实际调试，并未发现这一步，这还可以从param3和var1之间只有4字节的间隙这点看出来）；第三步，将栈顶(ESP)减去一个数，为本地变量分配内存空间，上例中是减去12字节(ESP=ESP-3*4，每个int变量占用4个字节)；接着就初始化本地变量的内存空间。由于“__stdcall”调用由被调函数调整堆栈，所以在函数返回前要恢复堆栈，先回收本地变量占用的内存(ESP=ESP+3*4)，然后取出返回地址，填入EIP寄存器，回收先前压入参数占用的内存(ESP=ESP+3*4)，继续执行调用者的代码。参见下列汇编代码：

;--------------func 函数的汇编代码-------------------

:00401000 83EC0C sub esp, 0000000C //创建本地变量的内存空间
:00401003 8B442410 mov eax, dword ptr [esp+10]
:00401007 8B4C2414 mov ecx, dword ptr [esp+14]
:0040100B 8B542418 mov edx, dword ptr [esp+18]
:0040100F 89442400 mov dword ptr [esp], eax
:00401013 8D442410 lea eax, dword ptr [esp+10]
:00401017 894C2404 mov dword ptr [esp+04], ecx

……………………（省略若干代码）

:00401075 83C43C add esp, 0000003C ;恢复堆栈，回收本地变量的内存空间
:00401078 C3 ret 000C ;函数返回，恢复参数占用的内存空间
;如果是“__cdecl”的话，这里是“ret”，堆栈将由调用者恢复

;-------------------函数结束-------------------------


;--------------主程序调用func函数的代码--------------

:00401080 6A03 push 00000003 //压入参数param3
:00401082 6A02 push 00000002 //压入参数param2
:00401084 6A01 push 00000001 //压入参数param1
:00401086 E875FFFFFF call 00401000 //调用func函数
;如果是“__cdecl”的话，将在这里恢复堆栈，“add esp, 0000000C”

聪明的读者看到这里，差不多就明白缓冲溢出的原理了。先来看下面的代码：

＃i nclude <stdio.h>
＃i nclude <string.h>

void __stdcall func()
{
char lpBuff[8]="\0";
strcat(lpBuff,"AAAAAAAAAAA");
return;
}

int main()
{
func();
return 0;
}

编译后执行一下回怎么样？哈，“"0x00414141"指令引用的"0x00000000"内存。该内存不能为"read"。”，“非法操作”喽！"41"就是"A"的16进制的ASCII码了，那明显就是strcat这句出的问题了。"lpBuff"的大小只有8字节，算进结尾的\0，那strcat最多只能写入7个"A"，但程序实际写入了11个"A"外加1个\0。再来看看上面那幅图，多出来的4个字节正好覆盖了RET的所在的内存空间，导致函数返回到一个错误的内存地址，执行了错误的指令。如果能精心构造这个字符串，使它分成三部分，前一部份仅仅是填充的无意义数据以达到溢出的目的，接着是一个覆盖RET的数据，紧接着是一段shellcode，那只要着个RET地址能指向这段shellcode的第一个指令，那函数返回时就能执行shellcode了。但是软件的不同版本和不同的运行环境都可能影响这段shellcode在内存中的位置，那么要构造这个RET是十分困难的。一般都在RET和shellcode之间填充大量的NOP指令，使得exploit有更强的通用性。


├———————┤<—低端内存区域
│ …… │
├———————┤<—由exploit填入数据的开始
│ │
│ buffer │<—填入无用的数据
│ │
├———————┤
│ RET │<—指向shellcode，或NOP指令的范围
├———————┤
│ NOP │
│ …… │<—填入的NOP指令，是RET可指向的范围
│ NOP │
├———————┤
│ │
│ shellcode │
│ │
├———————┤<—由exploit填入数据的结束
│ …… │
├———————┤<—高端内存区域


windows下的动态数据除了可存放在栈中，还可以存放在堆中。了解C++的朋友都知道，C++可以使用new关键字来动态分配内存。来看下面的C++代码：

＃i nclude <stdio.h>
＃i nclude <iostream.h>
＃i nclude <windows.h>

void func()
{
char *buffer=new char[128];
char bufflocal[128];
static char buffstatic[128];
printf("0x%08x\n",buffer); //打印堆中变量的内存地址
printf("0x%08x\n",bufflocal); //打印本地变量的内存地址
printf("0x%08x\n",buffstatic); //打印静态变量的内存地址
}

void main()
{
func();
return;
}

程序执行结果为：

0x004107d0
0x0012ff04
0x004068c0

可以发现用new关键字分配的内存即不在栈中，也不在静态数据区。VC编译器是通过windows下的“堆(heap)”来实现new关键字的内存动态分配。在讲“堆”之前，先来了解一下和“堆”有关的几个API函数：

HeapAlloc 在堆中申请内存空间
HeapCreate 创建一个新的堆对象
HeapDestroy 销毁一个堆对象
HeapFree 释放申请的内存
HeapWalk 枚举堆对象的所有内存块
GetProcessHeap 取得进程的默认堆对象
GetProcessHeaps 取得进程所有的堆对象
LocalAlloc
GlobalAlloc

当进程初始化时，系统会自动为进程创建一个默认堆，这个堆默认所占内存的大小为1M。堆对象由系统进行管理，它在内存中以链式结构存在。通过下面的代码可以通过堆动态申请内存空间：

HANDLE hHeap=GetProcessHeap();
char *buff=HeapAlloc(hHeap,0,8);

其中hHeap是堆对象的句柄，buff是指向申请的内存空间的地址。那这个hHeap究竟是什么呢？它的值有什么意义吗？看看下面这段代码吧：

#pragma comment(linker,"/entry:main") //定义程序的入口
＃i nclude <windows.h>

_CRTIMP int (__cdecl *printf)(const char *, ...); //定义STL函数printf
/*---------------------------------------------------------------------------
写到这里，我们顺便来复习一下前面所讲的知识：
(*注)printf函数是C语言的标准函数库中函数，VC的标准函数库由msvcrt.dll模块实现。
由函数定义可见，printf的参数个数是可变的，函数内部无法预先知道调用者压入的参数个数，函数只能通过分析第一个参数字符串的格式来获得压入参数的信息，由于这里参数的个数是动态的，所以必须由调用者来平衡堆栈，这里便使用了__cdecl调用规则。BTW，Windows系统的API函数基本上是__stdcall调用形式，只有一个API例外，那就是wsprintf，它使用__cdecl调用规则，同printf函数一样，这是由于它的参数个数是可变的缘故。
---------------------------------------------------------------------------*/
void main()
{
HANDLE hHeap=GetProcessHeap();
char *buff=HeapAlloc(hHeap,0,0x10);
char *buff2=HeapAlloc(hHeap,0,0x10);
HMODULE hMsvcrt=LoadLibrary("msvcrt.dll");
printf=(void *)GetProcAddress(hMsvcrt,"printf");
printf("0x%08x\n",hHeap);
printf("0x%08x\n",buff);
printf("0x%08x\n\n",buff2);
}

执行结果为：

0x00130000
0x00133100
0x00133118

hHeap的值怎么和那个buff的值那么接近呢？其实hHeap这个句柄就是指向HEAP首部的地址。在进程的用户区存着一个叫PEB(进程环境块)的结构，这个结构中存放着一些有关进程的重要信息，其中在PEB首地址偏移0x18处存放的ProcessHeap就是进程默认堆的地址，而偏移0x90处存放了指向进程所有堆的地址列表的指针。windows有很多API都使用进程的默认堆来存放动态数据，如windows 2000下的所有ANSI版本的函数都是在默认堆中申请内存来转换ANSI字符串到Unicode字符串的。对一个堆的访问是顺序进行的，同一时刻只能有一个线程访问堆中的数据，当多个线程同时有访问要求时，只能排队等待，这样便造成程序执行效率下降。

最后来说说内存中的数据对齐。所位数据对齐，是指数据所在的内存地址必须是该数据长度的整数倍，DWORD数据的内存起始地址能被4除尽，WORD数据的内存起始地址能被2除尽，x86 CPU能直接访问对齐的数据，当他试图访问一个未对齐的数据时，会在内部进行一系列的调整，这些调整对于程序来说是透明的，但是会降低运行速度，所以编译器在编译程序时会尽量保证数据对齐。同样一段代码，我们来看看用VC、Dev-C++和lcc三个不同编译器编译出来的程序的执行结果：

＃i nclude <stdio.h>

int main()
{
int a;
char b;
int c;
printf("0x%08x\n",&a);
printf("0x%08x\n",&b);
printf("0x%08x\n",&c);
return 0;
}

这是用VC编译后的执行结果：
0x0012ff7c
0x0012ff7b
0x0012ff80
变量在内存中的顺序：b(1字节)-a(4字节)-c(4字节)。

这是用Dev-C++编译后的执行结果：
0x0022ff7c
0x0022ff7b
0x0022ff74
变量在内存中的顺序：c(4字节)-中间相隔3字节-b(占1字节)-a(4字节)。

这是用lcc编译后的执行结果：
0x0012ff6c
0x0012ff6b
0x0012ff64
变量在内存中的顺序：同上。

三个编译器都做到了数据对齐，但是后两个编译器显然没VC“聪明”，让一个char占了4字节，浪费内存哦。


基础知识：
堆栈是一种简单的数据结构，是一种只允许在其一端进行插入或删除的线性表。允许插入或删除操作的一端称为栈顶，另一端称为栈底，对堆栈的插入和删除操作被称为入栈和出栈。有一组CPU指令可以实现对进程的内存实现堆栈访问。其中，POP指令实现出栈操作，PUSH指令实现入栈操作。CPU的ESP寄存器存放当前线程的栈顶指针，EBP寄存器中保存当前线程的栈底指针。CPU的EIP寄存器存放下一个CPU指令存放的内存地址，当CPU执行完当前的指令后，从EIP寄存器中读取下一条指令的内存地址，然后继续执行。

 <br>

堆（Heap）栈（Stack）

1、内存分配方面：

    堆：一般由程序员分配释放， 若程序员不释放，程序结束时可能由OS回收 。注意它与数据结构中的堆是两回事，分配方式是类似于链表。可能用到的关键字如下：new、malloc、delete、free等等。

    栈：由编译器(Compiler)自动分配释放，存放函数的参数值，局部变量的值等。其操作方式类似于数据结构中的栈。

2、申请方式方面：

    堆：需要程序员自己申请，并指明大小。在c中malloc函数如p1 = (char *)malloc(10)；在C++中用new运算符，但是注意p1、p2本身是在栈中的。因为他们还是可以认为是局部变量。

    栈：由系统自动分配。 例如，声明在函数中一个局部变量 int b；系统自动在栈中为b开辟空间。

3、系统响应方面：

    堆：操作系统有一个记录空闲内存地址的链表，当系统收到程序的申请时，会遍历该链表，寻找第一个空间大于所申请空间的堆结点，然后将该结点从空闲结点链表中删除，并将该结点的空间分配给程序，另外，对于大多数系统，会在这块内存空间中的首地址处记录本次分配的大小，这样代码中的delete语句才能正确的释放本内存空间。另外由于找到的堆结点的大小不一定正好等于申请的大小，系统会自动的将多余的那部分重新放入空闲链表中。

    栈：只要栈的剩余空间大于所申请空间，系统将为程序提供内存，否则将报异常提示栈溢出。

4、大小限制方面：

    堆：是向高地址扩展的数据结构，是不连续的内存区域。这是由于系统是用链表来存储的空闲内存地址的，自然是不连续的，而链表的遍历方向是由低地址向高地址。堆的大小受限于计算机系统中有效的虚拟内存。由此可见，堆获得的空间比较灵活，也比较大。

    栈：在Windows下, 栈是向低地址扩展的数据结构，是一块连续的内存的区域。这句话的意思是栈顶的地址和栈的最大容量是系统预先规定好的，在WINDOWS下，栈的大小是固定的（是一个编译时就确定的常数），如果申请的空间超过栈的剩余空间时，将提示overflow。因此，能从栈获得的空间较小。

5、效率方面：

    堆：是由new分配的内存，一般速度比较慢，而且容易产生内存碎片，不过用起来最方便，另外，在WINDOWS下，最好的方式是用VirtualAlloc分配内存，他不是在堆，也不是在栈是直接在进程的地址空间中保留一快内存，虽然用起来最不方便。但是速度快，也最灵活。

    栈：由系统自动分配，速度较快。但程序员是无法控制的。

6、存放内容方面：

    堆：一般是在堆的头部用一个字节存放堆的大小。堆中的具体内容有程序员安排。

    栈：在函数调用时第一个进栈的是主函数中后的下一条指令（函数调用语句的下一条可执行语句）的地址然后是函数的各个参数，在大多数的C编译器中，参数是由右往左入栈，然后是函数中的局部变量。 注意: 静态变量是不入栈的。当本次函数调用结束后，局部变量先出栈，然后是参数，最后栈顶指针指向最开始存的地址，也就是主函数中的下一条指令，程序由该点继续运行。

7、存取效率方面：

    堆：char *s1 = "Hellow Word"；是在编译时就确定的；

    栈：char s1[] = "Hellow Word"； 是在运行时赋值的；用数组比用指针速度要快一些，因为指针在底层汇编中需要用edx寄存器中转一下，而数组在栈上直接读取。

Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=1925576

#include "drm_korea_def.h"

#ifdef __KDRM_FSTRACE

#define LOG_BUFFER_SIZE 512
#define LOG_LINE_NUM  16

#ifdef WIN32
#define LOG_FILE     FILE *
#define LOG_OPEN(s, m)   fopen(s, m)
#define LOG_CLOSE(hLog)   fclose(hLog)
#define LOG_READ (hLog, p, x)  fread (p, x, 1, hLog)
#define LOG_WRITE(hLog, p, x) fwrite(p, x, 1, hLog)
#define LOG_PUTC(hLog, c)  fputc(c, hLog)
#define LOG_PUTS(hLog, s)  fputs(s, hLog)
#else
#define LOG_FILE     int32_t
#define LOG_OPEN(s, m)   Fopen((uint8_t *)s, (uint8_t *)m)
#define LOG_CLOSE(hLog)   Fclose(hLog)
#define LOG_READ (hLog, p, x)  Fread (hLog,  p, x)
#define LOG_WRITE(hLog, p, x) Fwrite(hLog, p, x)
#define LOG_PUTC(hLog, c)  Fputc(hLog, c)
#define LOG_PUTS(hLog, s)  Fputs(hLog, (uint8_t *)s)
#endif

static LOG_FILE fpLogfile;
static char logBuffer[LOG_BUFFER_SIZE];

void log_Init(char *logName)
{
 fpLogfile = LOG_OPEN(logName, "w+");

 if(fpLogfile > 0)
 {
  log_Print("\r\n====> Starting ... :%s %s\r\n", __TIME__, __FILE__);
 }
}

void log_Print(char *logFormat, ...)
{
 if(fpLogfile > 0)
 {
  va_list va;
  int len;

  va_start(va, logFormat);
  len = vsprintf(logBuffer, logFormat, va);
  va_end(va);

  logBuffer[len+1] = 0;

  LOG_PUTS(fpLogfile, logBuffer);
 }
}

char Hex2Dec(unsigned char bHex)
{
 bHex &= 0x0F;
 bHex += bHex<10? '0': 'A' - 10;

 return bHex;
}

void log_Dump(const unsigned char  *pCache, int u32Size, bool bBinary)
{
 int i, stride;
 unsigned char *p = (unsigned char  *)pCache;
 char cTmp;

 if(fpLogfile < 0)
  return;

 if(bBinary)
 {
  for(; p<pCache+u32Size; p+=LOG_BUFFER_SIZE)
  {
   stride = (p+LOG_BUFFER_SIZE <= pCache+u32Size)? LOG_BUFFER_SIZE: u32Size%LOG_BUFFER_SIZE;
   LOG_WRITE(fpLogfile, p, stride);
  }
 }
 else
 {
  for(; p<pCache+u32Size; p+=LOG_LINE_NUM)
  {
   stride = (p+LOG_LINE_NUM <= pCache+u32Size)? LOG_LINE_NUM:u32Size%LOG_LINE_NUM;

   for(i=0; i<stride; i++)
   {
    cTmp = Hex2Dec((p[i]&0xF0) >> 4);
    LOG_PUTC(fpLogfile, cTmp);
    cTmp = Hex2Dec(p[i]&0x0F);
    LOG_PUTC(fpLogfile, cTmp);
    LOG_PUTC(fpLogfile, ' ');
    if(i== (LOG_LINE_NUM/2 - 1))
    {
     LOG_PUTC(fpLogfile, '-');
     LOG_PUTC(fpLogfile, ' ');
    }
   }

   LOG_PUTC(fpLogfile, '\n');
  }
 }
}

void log_Terminate(void)
{
 if(fpLogfile > 0)
 {
  log_Print("<==== Stopping ... :%s\r\n", __TIME__);
  LOG_CLOSE(fpLogfile);
 }
}

#endif //__KDRM_FSTRACE

最近学习状态不佳，感觉什么都想做却什么也做不下去，浮躁之极。大的库一下子研究不下来，索性找一下小库来看看。
游戏里面一般都涉及到文本、压缩、图像、脚本的概念，为了将来有机会研究游戏所以先下手这些小库，不求甚解只求用好。

先从字体着手，FreeType字体作为一种字体文件编程开发包，广泛易用在游戏里面。网上汉语资料比较少，只能看它的faq。翻译了部分如下：

FreeType 2 Library

FAQ

（当前下载地址： http://sourceforge.net/project/showfiles.php?group_id=3157 版本 2.2.1 ）

1、  FreeType2 是什么？

它是一个为各种应用程序提供通用的字体文件访问的软件包。尤其值得注意的以下特性：

l         提供统一的字体文件访问接口。支持位图和向量格式，包括 TrueType 、 OpenType 、 Typel 、 CID 、 CFF 、 Windows FON/FNT 、 X11 PCF 。

l         提供高效反走样的基于 256 灰度级的位图字形的生产。

l         模块清晰，每种字体格式对于一个模块。类库的构建可以按照你需要支持的格式进行裁减以减小代码尺寸。（最小的反走样 FreeType 库 <30Kb ）

2、  FreeType2 能做什么？

FT2 已经易用于许多领域。例如：

l         图形子系统和文本显示库

l         文本排版（布局、分页、渲染）

l         字体识别和转换工具

一般来说，该库使得你能轻松的操纵字体文件。

3、  FreeType2 不能做什么？

FT2 并不包含大量丰富的高级特性，它只定位于出色的字体服务。也就是说下面的一些特性 FT2 类库并不直接提供支持，然而你可以以它为基础在上层进行实现：

l         任意表面的文字渲染

FT2 不是图形库所以它仅支持两种象素格式的文本渲染： 1-bit 的单色位图和 8-bit 的灰度象素。

如果你需要绘制其它格式的表面（例如 24-bit RGB 象素），你就得选择其它你喜爱的图形库来做。

注意：为了渲染向量轮廓文本而不是放走样的象素，应用程序可以提供自己的渲染回调以绘制或者直接组合反走样文本到任意目标表面。

l         文本缓存

每次从字体中请求文本图象， FT2 都要解析字体文件 / 流相关部分，通过它的字体格式进行解释。对于某些特殊格式可能会很慢包括像 TrueType （或者 Type1 ）这样的向量字体。

注意：自从 2.0.1 版本开始 FT2 提供了一个 beta 版本的缓存子系统。当然你还是可以写自己的缓存来满足某种特殊需求。

l         文本布局

不支持文本布局操作。高级操作例如文本替换、字距调整、两端调整等都不属于字体服务本身职责。

4、  FreeType2 可移植性？

FT2 源码可移植性很好由于以下原因：

l         代码书写遵循 ANSI C 标准

l         对于各种编译警告我们都谨慎的避免。当前代码在很多编译器上编译通过且没有产生一条警告。

l         库没有使用任何硬编码，是嵌入式系统开发的一个好的选择。（例如它能够直接在 ROM 中运行）

同时，我们尽最大努力确保库的高效、紧凑和友好性。

5、  FreeType2 与 FreeType1.x 的区别？

最大的区别就是：

l         FT1 仅支持 TrueType 格式，而 FT2 支持很多格式。

l         FT2 APIs 比 FT1 APIs 简单且强大。

l         FT1 包括 OpenType 文本布局处理扩展，而 FT2 中则不包括而是移到独立的工程里面―― FreeType Layout 。（ FT 布局目前无法获取）

6、  FreeType2 是否兼容 FreeType 1.x ？

FreeType2 不直接兼容 FreeType 1.x ，但是我们可以提供一个二进制兼容层使得应用程序重链接到新版本。我们最终放弃了这种想法因为两个版本可以共存在一个系统中。（没有命名冲突）

FT2 API 比 1.x 简单且强大，所以我们鼓励你采用新版本，这样可以使你减少很多不必要的工作。

7、  是否可以使用 FreeType2 编辑字体或者创建新字体？

答案是明确的：不可以。因为该库设计明确，用较少代码和内存读取字体文件。所以我们不打算以任何方式在字体引擎里面支持编辑或者创建功能，因为这样将导致整个代码重写。这并不意味我们将来不会引入字体编辑 / 创建功能库，这取决于需求（或者说有多少人愿意为此买单）。

在我们正式发布前不要在这方面进行揣测，对我们而言这个项目存在其他一些更重要的部分需要解决（像文字布局、文本缓存）。

编译 & 配置

1、  如何编译 FreeType2 库？

可以采取多种编译方式，在 freetype2/docs/build 下有详细说明文档。

这里介绍最简单的基于 VS IDE 的编译方式。 freetype\builds\win32\visualc 下有 VC6 和 VC7.1 的工作区文件。 VC6 打开后直接编译，有几个警告。



光看或许无法到感性认识，于是来两个demo。网上比较少，我是参考nehe教程写的。总体来说会简单使用了，如果想深入了解怕是非看他的document不可。
简单使用示例

FT_Library    pFTLib         =  NULL;
    FT_Face        pFTFace         =  NULL;
    FT_Error    error         =   0 ;
     //  Init FreeType Lib to manage memory
    error  =  FT_Init_FreeType( & pFTLib);
     if (error)
     {
        pFTLib  =   0 ;
        printf( " There is some error when Init Library " );
         return   - 1 ;
    }

     //  create font face from font file
    error  =  FT_New_Face(pFTLib,  " C:\\WINDOWS\\Fonts\\arial.ttf " ,  0 ,  & pFTFace);
     if ( ! error)
     {
        FT_Set_Char_Size(pFTFace,  16 << 6 ,  16 << 6 ,  300 ,  300 );
        FT_Glyph    glyph;
         //  load glyph 'C'
        FT_Load_Glyph(pFTFace, FT_Get_Char_Index(pFTFace,  67 ), FT_LOAD_DEFAULT);
        error  =  FT_Get_Glyph(pFTFace -> glyph,  & glyph);
         if ( ! error)
         {
             //  convert glyph to bitmap with 256 gray
            FT_Glyph_To_Bitmap( & glyph, ft_render_mode_normal,  0 ,  1 );
            FT_BitmapGlyph    bitmap_glyph  =  (FT_BitmapGlyph)glyph;
            FT_Bitmap &     bitmap  =  bitmap_glyph -> bitmap;
             for ( int  i = 0 ; i < bitmap.rows;  ++ i)
             {
                 for ( int  j = 0 ; j < bitmap.width;  ++ j)
                 {
                     //  if it has gray>0 we set show it as 1, o otherwise
                    printf( " %d " , bitmap.buffer[i * bitmap.width + j] ? 1 : 0 );
                }
                printf( " \n " );
            }
             //  free glyph
            FT_Done_Glyph(glyph);
            glyph  =  NULL;
        }
         //  free face
        FT_Done_Face(pFTFace);
        pFTFace  =  NULL;
    }

     //  free FreeType Lib
    FT_Done_FreeType(pFTLib);
    pFTLib  =  NULL;

2. 软件测试，发现了20个Bug。

3. 程序员修改了10个Bug，并告诉测试组另外10个不是Bug。

4. 测试组发现其中5个改动根本无法工作，同时又发现了15个新Bug。

5. 重复3次步骤3和步骤4。

6. 鉴于市场方面的压力，为了配合当初制定的过分乐观的发布时间表，产品终于上市了。

7. 用户发现了137个新Bug。

8. 已经领了项目奖金的程序员不知跑到哪里去了。

9. 新组建的项目组修正了差不多全部137个Bug，但又发现了456个新Bug。

10. 最初那个程序员从斐济给饱受拖欠工资之苦的测试组寄来了一张明信片。整个测试组集体辞职.

11. 公司被竞争对手恶意收购。收购时，软件的最终版本包含783个Bug。

12. 新CEO走马上任。公司雇了一名新程序员重写该软件。

13. 程序员写出自认为没有Bug的代码。

　　要我说，如果真有这样的公司，不倒闭对不起人民。

　这个笑话从程序员开始，到程序员结束，从头到尾都在说程序员的不是。但是我要说的是，这完全是管理者的失败，从整个过程中，看不到任何管理工作。这种管理者不但无知无能，还很无耻——将自己的失败责任推给程序员。

　1、程序员凭什么证明他的代码没有BUG？有Test case吗？有Code review吗？这个环节管理缺失。

　2、测试发现BUG有进行BUG管理吗？有跟踪吗？这个环节管理缺失。
　3、凭什么证明程序员已经把那10个BUG修改好了？另10个又为什么不是BUG？BUG的评价标准难道是程序员说了算？这个环节管理缺失。

　4、5个不能工作的BUG修改问题有没有追究责任？增加新BUG是修改过程中不可避免的事情，但是如果有有效的单元测试机制，可以大大减少这种情况。这个环节管理缺失。

　5、迭代是正常的，但是问题处理于发散而不是收敛发展，可见没有有效的管理调控。这个环节管理缺失。

　6、过于乐观的时间表和不可能达到的最后期限，都表现出管理者的无知和无能。而在这样的情况下强行推出产品，那就是无知者无畏了。

　7、这是对用户的不负责任，管理者要负最大的责任。

　8、这样的情况还能发项目奖金，只能说管理者不是一般的愚蠢。

　9、管理工作没有任何的改进，问题仍然处于发散迭代状态。管理工作依然没有到位。

　10、拖欠测试部门工资体现出管理者对质量管理工作的忽视以及对人力资源管理方面一无所知。

　11、送被收购者两个字：活该。送收购者两个字：瞎眼。

　12、可见新管理者与原管理者半斤八两，都没有认识到问题的根本所在。不过也只有这样的管理者才会作出收购这种公司的决策。

　13、历史的重演是必然的。

　一个正常的企业或是项目，其运作必须应该是循环向上进行的。而保障这种运行的工作就是管理。而管理工作的主要内容就是控制，包括控制循环的节奏——不能太快也不能太慢，控制发展的方向——只能向上不能向下，控制运作的稳定——不能大起大落或时聚时散等。
　而这一切，在这个例子中都看不到。

　在这个笑话的例子中，一切都是以开发工作在驱动，这首先就是一个方向性错误，产品是为用户服务的，当然应该是以用户和市场作为驱动，并且结合自身的能力最终 确定工作的重点。这一错误折射出管理者对被管理的内容很不了解，只好任由比较了解的程序员摆布——事实上他们除了技术，并不会了解更多。

　一个管理者如果对自己所管理的内容不了解，他就不可能管理得好。

　这是一件毫无疑问的事，可是国内的软件业似乎总是不相信这一点。中国软件业中流毒最深的谎言之一就是：

　管理者只要懂管理就可以，不需要懂技术。

其实这不过是那些无知无能无耻的管理者为了骗钱而编出来的，相信这句话的人必将付出金钱的代价。

　其次是质量管理。基本的质量管理常识告诉我们，每次循环结束前，最重的工作就是总结改进。只有这样才能保证循环运作是向上发展，而不是失去控制地向下发展。 也只有有效的质量管理，才能保证迭代过程是收敛发展，并最终达到目标。但在这个例子中，这个部分显然是缺失的——其中虽然有测试部门，但是他们的作用仅仅 是质量管理中的质量检测环节，管理部分还是缺失的。

　然后是人力资源管理。软件开发是一项劳动密集型的工作，虽然这是脑力劳动，但同样意味着人在因素在其中占有决定性的地位。而例子中未改完BUG的程 序员拿到项目奖金，而同样辛苦工作的测试人员却被拖欠薪资，除了表现出管理者对他们的工作内容的不了解，以及对质量管理工作的不重视以外，还表现出管理者 完全不会管人，这是一种谋杀团队的行为——谋杀一个团队远比建设要容易得多。

　最后，这个失败的管理者把他的经历编成这个笑话，让大家看到他被程序员们害得多惨，把程序员妖魔化为一群骗子。但只要稍懂管理的人简单分析一下就可以看出来，只不过是这个人的无知和无能造成了他现在的结果，而把责任推给别人的行为更是表现出他的无耻。

　作为身居高位的管理者，如果连应该承担的责任都要推卸，他们还能胜任什么事情呢?

 while (*eos)
     ++eos;

 return eos-wcs;
}

int strcmpW(const wchar_t *pwc1, const wchar_t *pwc2)
{
 int ret = 0;

 while ( !(ret = *pwc1 - *pwc2) && *pwc2)
  ++pwc1, ++pwc2;
 return ret;
}