恩恩，這個小玩具（龍之谷加點模擬器）一個月前就開始做了，因為對GTK不熟悉，所以中間拖了很久，現在基本功能已經實現，界面如下，有不少按鈕以及全部菜單都是假的，無所謂，基本的功能已經OK了，下一步應該會加上視頻演示吧。。恩，自我感覺良好。（今天真開心。。啦啦啦）

今天在把linux下做的ipmsg移植到windows過程中，因為包含了一個開源庫SimpleSocket，而這個庫又引用了winsock2，沒太注意就寫下了下面的makefile：


結果報出了N多丑陋的undefined reference..之后嘗試將-lws2_32和-lclsocketd交換位置后，編譯通過。

上網查了下，發現gcc編譯時依賴庫的順序是很重要的。比如說，liba.a依賴于libb.a，則必須寫成-la -lb，似乎感覺這種順序很奇怪。另外參考網上http://m.shnenglu.com/findingworld/archive/2008/11/09/66408.html的內容，在庫比較多依賴關系比較復雜或者相互依賴或者自己不清楚的情況下，可以采取下面2種辦法：

1、-la -lb -la，丑陋，但是有效。
2、gcc有這樣的選項，-Xlinker，寫成如下格式可以強制gcc重復查找依賴庫：


這樣在括號中的庫的依賴關系就不需要你操心啦，雖然會延長鏈接時間。不過本人在實際使用過程中，g++認不出"-)"，不加也可以鏈接成功。

為了方便調試，需要在VS中為GUI程序添加console窗口。

項目 -> 屬性 -> 配置屬性 -> 生成事件 -> 生成后事件 -> 命令行：


ipmsg.exe改為可執行代碼的文件名。

SDL里將所有stdout和stderr重定向到了stdout.txt和stderr.txt文件中，在學習SDL的過程中，每次要打開一個文本文件看日志很麻煩。之前也遇到這個問題，沒有解決，這次特意上網找了下，終于得以解決。

參考解決方案地址：http://www.gamedev.net/community/forums/topic.asp?topic_id=371770

下面說下解決辦法。
SDL源碼src\main\win32目錄下有個SDL_win32_main.c這個文件，里面處理了輸出流的重定向。有這么幾句：

可以看到NO_STDIO_REDIRECT這么一個條件，因為這是在編譯過程中選擇的，而SDL代碼里并沒有關于NO_STDIO_REDIRECT的定義，如果直接通過lib鏈接的話，肯定是會redirect的。所以我們的做法就是在compile時加入define選項重新編譯這段源碼，以后如果想要重定向時，去掉define選項即可。參考上面網站的做法（有所不同，他的辦法我沒有成功）：
1、將SDL_win32_main.c加入項目中；
2、去掉鏈接庫選項-lSDLmain；
3、在編譯SDL_win32_main.o的時候加入-DNO_STDIO_REDIRECT選項(或者在SDL_win32_main.c中加入#define NO_STDIO_REDIRECT一句)。

這樣就一切OK了，看吧。

GVIM用的是UTF-8，cmd為GB2312，中文輸出的時候就會亂碼；

將GVIM中的中文轉成GB2312時輸出正常；

SQLITE open時用的是UTF-8，insert時因為直接取的文件中的內容，輸出cmd正常，所以是用的GB2312；
這時候在select中文的時候在GVIM輸入中文字，即使用UTF-8，則無法找到GB2312的數據；

在insert時將數據全部轉成UTF-8后，直接select UTF-8就能夠找到，但輸出cmd為亂碼；

這樣就全部解釋清楚了。
現在要做的就是在insert時轉為UTF-8，至于cmd那垃圾輸出就算了，我可沒興趣為了輸出個東西看還要轉成GB2312，再次噴下微軟。。

     摘要: 摘要：動態鏈接庫技術實現和設計程序常用的技術，在Windows和Linux系統中都有動態庫的概念，采用動態庫可以有效的減少程序大小，節省空間，提高效率，增加程序的可擴展性，便于模塊化管理。

但不同操作系統的動態庫由于格式 不同，在需要不同操作系統調用時需要進行動態庫程序移植。本文分析和比較了兩種操作系統動態庫技術，并給出了將Visual C++編制的動態庫移植到Linux上的方法和經驗。

1、引言

動態庫（Dynamic Link Library abbr，DLL）技術是程序設計中經常采用的技術。其目的減少程序的大小，節省空間，提高效率，具有很高的靈活性。

采用動態庫技術對于升級軟件版本更加容易。與靜態庫（Static Link Library）不同，動態庫里面的函數不是執行程序本身的一部分，而是根據執行需要按需載入，其執行代碼可以同時在多個程序中共享。

在Windows和Linux操作系統中，都可采用這種方式進行軟件設計，但他們的調用方式以及程序編制方式不盡相同。本文首先分析了在這兩種  閱讀全文

環境的搭建不說了，網上很多。我本人是用GCC，沒有用VC完全是因為不熟悉微軟的東西，以及不想太過依賴微軟（就算依賴至少也得知道到底依賴了他哪些東西）。

其中看到的OpenGL的函數，
以gl開頭的函數都是OpenGL的標準函數；
以glu開頭的函數都是GLU實用庫所提供的函數；
以glut開頭的函數都是GLUT工具包所提供的函數；
函數庫的內容詳見OpenGL開發庫的詳細介紹。 

1、添加CMD在這里。
regedit -> \HKEY_CLASSES_ROOT\Folder\shell -> 新建CMD here項 -> 新建Command項 -> 鍵值cmd /K cd /d %L

2、添加右鍵以xx程序打開該文件。
regedit -> \HKEY_CLASSES_ROOT\*\shell -> 新建Edit with VimMate項 -> 新建Command項 -> 鍵值"D:\Program Files\VimMate\vim72\gvim.exe" -p --remote-tab-silent "%1"。其中Edit with VimMate為右鍵菜單顯示的文字，鍵值為執行的程序，至于-p --remote-tab-silent參數，則是GVIM默認以標簽形式打開（不重開新GVIM窗口）。

加了一些技術群，經常會看到一些奇怪的現象。一個新手在群里提了個問題，結果半天沒人回答，倒是會跳出四五個衛道士模樣的人，指手畫腳，指責新手編碼風格不好，習慣不好，種種。看上去句句在理，實際上全部放屁。本來編碼風格之類的東西就是溫飽以后考慮的問題，現在人家連飯還沒吃飽，你要他考慮這種奢侈品，那你要么是吃飽了撐的，要么就是純粹去饞人家。不管回答者水平如何，避而不談問題本身，去扯那些暫時對新人沒有用的東西，那就是方向性的誤導。最終的結果，新人完全搞不明白你在說什么，本來簡單的問題，弄了半天沒搞懂。這是一種嚴重的不負責任，作為技術上的前輩，你可以不回答，但你絕對不要去誤導。

回正題（-。-）。原來從公司拷來的redhat已經被我搞的很亂了，于是萌發了將平臺移植到新的虛擬機里，因為對ubuntu相對比較熟悉，所以今天重裝了ubuntu的虛擬機。重裝途中，困難重重，結果到半夜才勉強搞定。記錄一下遇到的問題，以及解決的辦法，還有一些東西已備以后查看。

1、取消ubuntu默認的點陣字體

2、ubuntu初始安裝是沒有ftp/telnet的

其中需要設置：/etc/vsftpd.conf文件中將以下一行注釋去掉:local_enable=YES，目的是可以使用linux用戶登錄ftp（否則只能匿名登錄）。
另外還有個問題，在FTP的put時，似乎由于權限問題會put失敗，嘗試root登錄也失敗，暫時沒有找到原因，以后研究了補上。

3、su - root
ubuntu第一次安裝好后默認無法登錄root，這時候可以通過下面命令修改root口令，就可以su - root了。

4、新增字體
將字體文件拷入/home/.fonts目錄下，執行下列命令刷新字體緩存。然后就可以使用新加的字體了。

sudo不sudo無所謂。另外建議將字體的權限改成755，以便其他用戶read。


5、最后一個，也是本文的標題，同樣也是困擾我一晚上的問題。在SecureCRT登錄的時候發現中文有亂碼的問題，嘗試了網上的一些辦法，把編碼改UTF-8 GBK都是有問題，最后發現了原來字體的字符集也是有關系的，現在把我改的東西整理如下。

（1）/var/lib/locales/supported.d/local文件中添加一行：zh_CN.UTF-8 UTF-8，執行sudo locale-gen下載文件
（2）在/etc/environment中增加兩行分別為：LANG="zh_CN.UTF-8"和LC_ALL="zh_CN.UTF-8"
（3）~/.profile中增加兩行分別為：export LANG="zh_CN.UTF-8"和export LC_ALL="zh_CN.UTF-8"，執行.profile
（4）SecureCRT中選擇終端類型為Linux，選擇編碼為UTF-8，最重要的是選擇一個支持GB2312字符集的字體。因為我常用的Monaco字體不支持，于是我不得不忍痛放棄，在網上找到一個“YaHei Mono”是可以正常顯示的，雖然看上去不如Monaco，不過用著慢慢也習慣了吧（記得大學里做畢業設計的時候用netbeans里一個Yahei console字體和這個很相似），具體詳見這里。

到此SecureCRT終于可以正常顯示漢字了，因為很困了所以只是羅列了一下修改內容，沒有寫太多的理由。在此我不禁要噴一噴微軟，你說你好好的UTF-8不用，都WIN7了還用這么個GB2312，你不是害人嗎。

睡了，有修改內容以后補充。




 

今天看到同事寫的代碼：

因為以前沒見過這樣的寫法，心想retcode本身就是指向字符數組的指針，再加個&不是變成指向指向字符數組指針的指針了嗎？結果他告訴我，這樣寫是可以的，而且可以防止retcode改變類型造成的coredump的情況。

帶著懷疑的想法去查了下《C與指針》，還真發現了這種用法。根據書中描述我才知道，這個retcode一般情況下表示的是指向char的常量指針，只有兩種情況，數組名所表示的不是指針常量：
   1、當數組名作為sizeof操作符的操作數時。這時sizeof返回的是整個數組的長度，而不是指向數組的指針的長度；
   2、當數組名作為單目操作符&的操作數時。取一個數組名的地址產生的是一個指向數組的指針（和使用數組名效果相同），而不是指向某個指針常量值的指針。

這么一句memset把兩種情況都用上了。

------------------------------------------------------------------------------
2010.04.26

今天遇到一個問題，在調zlib的compress的函數的時候總是報Z_STREAM_ERROR，半天都沒找到原因，最后發現，我寫了下面的代碼：
因為自從知道上面的數組memset的寫法以后，就一直習慣在前面加個&。然而，這一次，栽了。。
仔細看，這只是個unsigned char指針，加上了&就完全不知道指哪兒去了。。。

所以，這個寫法，只能用在數組前，千萬別用在指針前。。。另外，這里的sizeof(alObuf)也只是4而已，指針的sizeof。。。數組和指針，別搞混了。

需要用到對informix的兩個庫的操作，一個是本地庫一個是遠程庫，因為要有交叉操作，所以如果不停的開關會影響效率。

用時指定當前的連接：

需要寫一個卸數的工具，有一個SELECT MAX的操作：


目的是取出滿足WHERE條件的index的最大值。但是得出的結果卻是-21474836478，十六進制為0x00000080，非常奇怪。嘗試了很多次還是這種結果，后來在網上找到了一篇文章（http://www.tek-tips.com/viewthread.cfm?qid=1501792&page=3），大致意思是當滿足WHERE條件的條數為0時，這條語句會有問題。仔細檢查才發現我其中的y值取錯了，造成符合條件的記錄數為0，造成以上的問題，至于index為什么會有那個值原因未知。

結論是：在使用SELECT MAX之前，需要首先確定滿足WHERE條件的COUNT(*)>0，否則會造成未知錯誤。

PS：至于剛才網址中作者所說的空表時會報-201錯我沒有碰到，我在空表時和沒找到記錄時現象相同。

研究了一下浮點型在內存中的表示方法，終于明白fortify果然不是吃素的，原來double型數字真的有可能超過200位的。。

一、浮點型在內存中的表示
單精度float型:  1位符號位,  8位階碼(固定偏移  7F), 尾數23, 固定隱含位有
雙精度double型: 1位符號位, 11位階碼(固定偏移 3FF), 尾數52, 固定隱含位有
long double型: 1位符號位, 15位階碼(固定偏移3FFF), 尾數64, 固定隱含位無
某些編譯器中把long double作double處理

其中，
符號位s：0表示正，1表示負；
階碼e：表示指數，需要減去固定偏移de；
尾數x：表示純小數位，固定隱含位z是指整數位的1或者0。
表示成十進制就是(-1)^s * 2^(e-de) * (z+x)
對于32位系統，float占32位，double占64位

舉例來說，在BIG ENDIAN中二進制表示為01000001 00100000 00000000 00000000的浮點數，根據上面的規則，可以寫成：
0,10000010,0100000   000000000   0000000
符號位s=0，階碼e=10000010b=130，固定偏移de=0x7F=127，尾數x=0.01000000000000000000000b=0.25，固定隱含位有，z=1
根據公式可以算出這個數的十進制表示為：(-1)^0 * 2^(130-127) * (1+0.25) = 10.0

二、一些特殊的浮點數
0,00000000,0000000   00000000   00000000和1,00000000,0000000   00000000   00000000均表示0（階碼和尾數都是0）
*,11111111,*******   ********   ********   表示非法數字（階碼是255時）
最大的float數：0,11111110,1111111   11111111   11111111   用10進制表示約為   +3.4e38   
最小的float數：1,11111110,1111111   11111111   11111111   用10進制表示約為   -3.4e38  
絕對值最小的float數：0,00000000,0000000   00000000   00000001和1,00000000,0000000   00000000   00000001  

三、浮點數的精度
單精度數的尾數用23位存儲，加上默認的小數點前的1位1，2^(23+1) = 16777216。因為 10^7 < 16777216 < 10^8，所以說單精度浮點數的有效位數是7位。
雙精度的尾數用52位存儲，2^(52+1) = 9007199254740992，10^16 < 9007199254740992 < 10^17，所以雙精度的有效位數是16位。
如果你在浮點數的有效位后增加數字的話，結果是不會變化的。

四、浮點數的取值范圍
float取值范圍：
負數取值范圍為 -3.4028235E+38 到 -1.401298E-45，正數取值范圍為 1.401298E-45 到 3.4028235E+38。
double取值范圍：
負值取值范圍-1.79769313486231570E+308 到 -4.94065645841246544E-324，正值取值范圍為 4.94065645841246544E-324 到 1.79769313486231570E+308。
所以說，double型在sprintf的時候，要么想辦法回避Buffer Overflow的問題，要么就...給字符數組分配308以上的空間...

 

今天在fortify代碼掃描的時候檢測出一個HOT，漏洞類型是Buffer Overflow，元兇是sprintf。

其中aTmp是20位字符數組，TransAmt為double型金額字段，值不確定。

理論上來說，是TransAmt按照格式16.2f寫進aTmp的時候，有可能產生越界的錯誤。我一開始考慮將aTmp長度放長后，double應該可以順利拷進aTmp，嘗試將aTmp的長度分配到50，100，200，還是消除不掉這個HOT，因為不明白是double所表示的浮點數的長度有可能超過200位還是fortify認死理，而銀行又強制規定代碼掃描不能有HOT（-。-），所以將sprintf替換成snprintf。

需要注意的一點是，第二個參數的值。網上有人提到寫成snprintf(buf, 10, "%10s", p)其實是不對的，因為這里的長度，是包括結束符0x00的，也就是說，既然需要按照%10s格式化，那么這里的第二個參數必須寫成11而不是10。

相似的，strcpy等不帶長度的字符串操作函數，如果不注意寫法，往往會有Buffer Overflow的隱患。這時候，一般來說以strncpy等類似的帶長度參數的函數替換就可以避免漏洞的產生。

另外，在網上查這個問題的時候，看到一個關于sprintf和snprintf的自拷貝的問題。


因為我自己有時候也會有這種寫法，但也是不太確定會不會有問題。既然網上已經有明確的研究了，那我就直接拿結論。

關于這兩個函數的自拷貝問題，在不同的編譯器上，結果不同。編譯器可以有不同的策略，有的簡單的把原先的值抹去，有的會保留。因此，一般來說，我們應該盡量避免這種寫法。

 

今天準備手動make原來用CODE BLOCKS寫的代碼的時候報了這么個錯誤：

大概意思是WinMain未定義。WinMain是windows程序的入口函數，一般來說沒有main函數或者main函數名拼寫錯誤的話會在編譯的時候報這個錯。我檢查以后，發現main應該是正確的。

google一下后發現有不少人也遇到這個問題。仔細檢查了下Makefile，發現在連接庫的時候-lmingw32寫在了SDL庫的后面，將-lmingw32放在最前面后，問題解決。