HUUYUU

Freetype學習筆記

posted @ 2008-07-10 22:22 HUYU 閱讀(1347) | 評論 (1) | 編輯 收藏

寫operator new和operator delete時要遵循常規

posted @ 2008-01-22 09:42 HUYU 閱讀(408) | 評論 (0) | 編輯 收藏

堆和棧的區別

一、預備知識—程序的內存分配
    一個由c/C++編譯的程序占用的內存分為以下幾個部分
    1、棧區（stack）— 由編譯器自動分配釋放 ，存放函數的參數值，局部變量的值等。其操作方式類似于數據結構中的棧。
    2、堆區（heap） — 一般由程序員分配釋放， 若程序員不釋放，程序結束時可能由OS回收 。注意它與數據結構中的堆是兩回事，分配方式倒是類似于鏈表，呵呵。
    3、全局區（靜態區）（static）—，全局變量和靜態變量的存儲是放在一塊的，初始化的全局變量和靜態變量在一塊區域， 未初始化的全局變量和未初始化的靜態變量在相鄰的另一塊區域。 - 程序結束后有系統釋放
    4、文字常量區—常量字符串就是放在這里的。 程序結束后由系統釋放
    5、程序代碼區—存放函數體的二進制代碼。

例子程序
這是一個前輩寫的，非常詳細
//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

posted @ 2008-01-10 13:22 HUYU 閱讀(444) | 評論 (0) | 編輯 收藏

Variable Parameters Print Example

#include <stdio.h>
#include <string.h>
#include <stdarg.h>

#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

posted @ 2007-01-19 17:55 HUYU 閱讀(339) | 評論 (0) | 編輯 收藏

FreeType2研究

FreeType2研究

最近學習狀態不佳，感覺什么都想做卻什么也做不下去，浮躁之極。大的庫一下子研究不下來，索性找一下小庫來看看。
游戲里面一般都涉及到文本、壓縮、圖像、腳本的概念，為了將來有機會研究游戲所以先下手這些小庫，不求甚解只求用好。

先從字體著手，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;

posted @ 2006-11-10 23:00 HUYU 閱讀(2174) | 評論 (5) | 編輯 收藏

從笑話中悟出C++開發管理之"道"

1. 程序員寫出自認為沒有Bug的代碼。

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的程 序員拿到項目獎金，而同樣辛苦工作的測試人員卻被拖欠薪資，除了表現出管理者對他們的工作內容的不了解，以及對質量管理工作的不重視以外，還表現出管理者 完全不會管人，這是一種謀殺團隊的行為——謀殺一個團隊遠比建設要容易得多。

　最后，這個失敗的管理者把他的經歷編成這個笑話，讓大家看到他被程序員們害得多慘，把程序員妖魔化為一群騙子。但只要稍懂管理的人簡單分析一下就可以看出來，只不過是這個人的無知和無能造成了他現在的結果，而把責任推給別人的行為更是表現出他的無恥。

　作為身居高位的管理者，如果連應該承擔的責任都要推卸，他們還能勝任什么事情呢?

posted @ 2006-10-30 08:49 HUYU 閱讀(281) | 評論 (0) | 編輯 收藏

關注對TinyXML的應用

posted @ 2006-10-13 13:56 HUYU 閱讀(406) | 評論 (0) | 編輯 收藏

strlen & strcmp

unsigned int strlenW(const wchar_t *wcs)
{
?const wchar_t *eos = wcs;

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

posted @ 2006-10-04 00:02 HUYU 閱讀(376) | 評論 (0) | 編輯 收藏

如何識別字符串的編碼？

posted @ 2006-10-04 00:01 HUYU 閱讀(1102) | 評論 (0) | 編輯 收藏

c++中的string用法(三)

posted @ 2006-09-04 18:49 HUYU 閱讀(8405) | 評論 (0) | 編輯 收藏