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

今天在把linux下做的ipmsg移植到windows過程中，因?yàn)榘艘粋€(gè)開源庫(kù)SimpleSocket，而這個(gè)庫(kù)又引用了winsock2，沒太注意就寫下了下面的makefile：


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

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

1、-la -lb -la，丑陋，但是有效。
2、gcc有這樣的選項(xiàng)，-Xlinker，寫成如下格式可以強(qiáng)制gcc重復(fù)查找依賴庫(kù)：


這樣在括號(hào)中的庫(kù)的依賴關(guān)系就不需要你操心啦，雖然會(huì)延長(zhǎng)鏈接時(shí)間。不過本人在實(shí)際使用過程中，g++認(rèn)不出"-)"，不加也可以鏈接成功。

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

項(xiàng)目 -> 屬性 -> 配置屬性 -> 生成事件 -> 生成后事件 -> 命令行：


ipmsg.exe改為可執(zhí)行代碼的文件名。

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

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

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

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

這樣就一切OK了，看吧。

GVIM用的是UTF-8，cmd為GB2312，中文輸出的時(shí)候就會(huì)亂碼；

將GVIM中的中文轉(zhuǎn)成GB2312時(shí)輸出正常；

SQLITE open時(shí)用的是UTF-8，insert時(shí)因?yàn)橹苯尤〉奈募械膬?nèi)容，輸出cmd正常，所以是用的GB2312；
這時(shí)候在select中文的時(shí)候在GVIM輸入中文字，即使用UTF-8，則無法找到GB2312的數(shù)據(jù)；

在insert時(shí)將數(shù)據(jù)全部轉(zhuǎn)成UTF-8后，直接select UTF-8就能夠找到，但輸出cmd為亂碼；

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

     摘要: 摘要：動(dòng)態(tài)鏈接庫(kù)技術(shù)實(shí)現(xiàn)和設(shè)計(jì)程序常用的技術(shù)，在Windows和Linux系統(tǒng)中都有動(dòng)態(tài)庫(kù)的概念，采用動(dòng)態(tài)庫(kù)可以有效的減少程序大小，節(jié)省空間，提高效率，增加程序的可擴(kuò)展性，便于模塊化管理。

但不同操作系統(tǒng)的動(dòng)態(tài)庫(kù)由于格式 不同，在需要不同操作系統(tǒng)調(diào)用時(shí)需要進(jìn)行動(dòng)態(tài)庫(kù)程序移植。本文分析和比較了兩種操作系統(tǒng)動(dòng)態(tài)庫(kù)技術(shù)，并給出了將Visual C++編制的動(dòng)態(tài)庫(kù)移植到Linux上的方法和經(jīng)驗(yàn)。

1、引言

動(dòng)態(tài)庫(kù)（Dynamic Link Library abbr，DLL）技術(shù)是程序設(shè)計(jì)中經(jīng)常采用的技術(shù)。其目的減少程序的大小，節(jié)省空間，提高效率，具有很高的靈活性。

采用動(dòng)態(tài)庫(kù)技術(shù)對(duì)于升級(jí)軟件版本更加容易。與靜態(tài)庫(kù)（Static Link Library）不同，動(dòng)態(tài)庫(kù)里面的函數(shù)不是執(zhí)行程序本身的一部分，而是根據(jù)執(zhí)行需要按需載入，其執(zhí)行代碼可以同時(shí)在多個(gè)程序中共享。

在Windows和Linux操作系統(tǒng)中，都可采用這種方式進(jìn)行軟件設(shè)計(jì)，但他們的調(diào)用方式以及程序編制方式不盡相同。本文首先分析了在這兩種  閱讀全文

環(huán)境的搭建不說了，網(wǎng)上很多。我本人是用GCC，沒有用VC完全是因?yàn)椴皇煜の④浀臇|西，以及不想太過依賴微軟（就算依賴至少也得知道到底依賴了他哪些東西）。

其中看到的OpenGL的函數(shù)，
以gl開頭的函數(shù)都是OpenGL的標(biāo)準(zhǔn)函數(shù)；
以glu開頭的函數(shù)都是GLU實(shí)用庫(kù)所提供的函數(shù)；
以glut開頭的函數(shù)都是GLUT工具包所提供的函數(shù)；
函數(shù)庫(kù)的內(nèi)容詳見OpenGL開發(fā)庫(kù)的詳細(xì)介紹。 

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

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

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

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

1、取消ubuntu默認(rèn)的點(diǎn)陣字體

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

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

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

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

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


5、最后一個(gè)，也是本文的標(biāo)題，同樣也是困擾我一晚上的問題。在SecureCRT登錄的時(shí)候發(fā)現(xiàn)中文有亂碼的問題，嘗試了網(wǎng)上的一些辦法，把編碼改UTF-8 GBK都是有問題，最后發(fā)現(xiàn)了原來字體的字符集也是有關(guān)系的，現(xiàn)在把我改的東西整理如下。

（1）/var/lib/locales/supported.d/local文件中添加一行：zh_CN.UTF-8 UTF-8，執(zhí)行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"，執(zhí)行.profile
（4）SecureCRT中選擇終端類型為L(zhǎng)inux，選擇編碼為UTF-8，最重要的是選擇一個(gè)支持GB2312字符集的字體。因?yàn)槲页Ｓ玫腗onaco字體不支持，于是我不得不忍痛放棄，在網(wǎng)上找到一個(gè)“YaHei Mono”是可以正常顯示的，雖然看上去不如Monaco，不過用著慢慢也習(xí)慣了吧（記得大學(xué)里做畢業(yè)設(shè)計(jì)的時(shí)候用netbeans里一個(gè)Yahei console字體和這個(gè)很相似），具體詳見這里。

到此SecureCRT終于可以正常顯示漢字了，因?yàn)楹芾Я怂灾皇橇_列了一下修改內(nèi)容，沒有寫太多的理由。在此我不禁要噴一噴微軟，你說你好好的UTF-8不用，都WIN7了還用這么個(gè)GB2312，你不是害人嗎。

睡了，有修改內(nèi)容以后補(bǔ)充。




 

今天看到同事寫的代碼：

因?yàn)橐郧皼]見過這樣的寫法，心想retcode本身就是指向字符數(shù)組的指針，再加個(gè)&不是變成指向指向字符數(shù)組指針的指針了嗎？結(jié)果他告訴我，這樣寫是可以的，而且可以防止retcode改變類型造成的coredump的情況。

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

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

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

今天遇到一個(gè)問題，在調(diào)zlib的compress的函數(shù)的時(shí)候總是報(bào)Z_STREAM_ERROR，半天都沒找到原因，最后發(fā)現(xiàn)，我寫了下面的代碼：
因?yàn)樽詮闹郎厦娴臄?shù)組memset的寫法以后，就一直習(xí)慣在前面加個(gè)&。然而，這一次，栽了。。
仔細(xì)看，這只是個(gè)unsigned char指針，加上了&就完全不知道指哪兒去了。。。

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

需要用到對(duì)informix的兩個(gè)庫(kù)的操作，一個(gè)是本地庫(kù)一個(gè)是遠(yuǎn)程庫(kù)，因?yàn)橐薪徊娌僮鳎匀绻煌５拈_關(guān)會(huì)影響效率。

用時(shí)指定當(dāng)前的連接：

需要寫一個(gè)卸數(shù)的工具，有一個(gè)SELECT MAX的操作：


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

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

PS：至于剛才網(wǎng)址中作者所說的空表時(shí)會(huì)報(bào)-201錯(cuò)我沒有碰到，我在空表時(shí)和沒找到記錄時(shí)現(xiàn)象相同。

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

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

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

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

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

三、浮點(diǎn)數(shù)的精度
單精度數(shù)的尾數(shù)用23位存儲(chǔ)，加上默認(rèn)的小數(shù)點(diǎn)前的1位1，2^(23+1) = 16777216。因?yàn)?10^7 < 16777216 < 10^8，所以說單精度浮點(diǎn)數(shù)的有效位數(shù)是7位。
雙精度的尾數(shù)用52位存儲(chǔ)，2^(52+1) = 9007199254740992，10^16 < 9007199254740992 < 10^17，所以雙精度的有效位數(shù)是16位。
如果你在浮點(diǎn)數(shù)的有效位后增加數(shù)字的話，結(jié)果是不會(huì)變化的。

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

 

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

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

理論上來說，是TransAmt按照格式16.2f寫進(jìn)aTmp的時(shí)候，有可能產(chǎn)生越界的錯(cuò)誤。我一開始考慮將aTmp長(zhǎng)度放長(zhǎng)后，double應(yīng)該可以順利拷進(jìn)aTmp，嘗試將aTmp的長(zhǎng)度分配到50，100，200，還是消除不掉這個(gè)HOT，因?yàn)椴幻靼资莇ouble所表示的浮點(diǎn)數(shù)的長(zhǎng)度有可能超過200位還是fortify認(rèn)死理，而銀行又強(qiáng)制規(guī)定代碼掃描不能有HOT（-。-），所以將sprintf替換成snprintf。

需要注意的一點(diǎn)是，第二個(gè)參數(shù)的值。網(wǎng)上有人提到寫成snprintf(buf, 10, "%10s", p)其實(shí)是不對(duì)的，因?yàn)檫@里的長(zhǎng)度，是包括結(jié)束符0x00的，也就是說，既然需要按照%10s格式化，那么這里的第二個(gè)參數(shù)必須寫成11而不是10。

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

另外，在網(wǎng)上查這個(gè)問題的時(shí)候，看到一個(gè)關(guān)于sprintf和snprintf的自拷貝的問題。


因?yàn)槲易约河袝r(shí)候也會(huì)有這種寫法，但也是不太確定會(huì)不會(huì)有問題。既然網(wǎng)上已經(jīng)有明確的研究了，那我就直接拿結(jié)論。

關(guān)于這兩個(gè)函數(shù)的自拷貝問題，在不同的編譯器上，結(jié)果不同。編譯器可以有不同的策略，有的簡(jiǎn)單的把原先的值抹去，有的會(huì)保留。因此，一般來說，我們應(yīng)該盡量避免這種寫法。

 

今天準(zhǔn)備手動(dòng)make原來用CODE BLOCKS寫的代碼的時(shí)候報(bào)了這么個(gè)錯(cuò)誤：

大概意思是WinMain未定義。WinMain是windows程序的入口函數(shù)，一般來說沒有main函數(shù)或者main函數(shù)名拼寫錯(cuò)誤的話會(huì)在編譯的時(shí)候報(bào)這個(gè)錯(cuò)。我檢查以后，發(fā)現(xiàn)main應(yīng)該是正確的。

google一下后發(fā)現(xiàn)有不少人也遇到這個(gè)問題。仔細(xì)檢查了下Makefile，發(fā)現(xiàn)在連接庫(kù)的時(shí)候-lmingw32寫在了SDL庫(kù)的后面，將-lmingw32放在最前面后，問題解決。