Google Protocol Buffer是一種用來描述網絡協議很高效的開發工具。這篇文章寫得通俗易懂，簡單明了。很適合初次接觸的人。以后找機會在項目中嘗試一下這種工具，在這里先做個標記。
http://www.ibm.com/developerworks/cn/linux/l-cn-gpb/index.html?ca=drs-

在寫一個包含多個Project的程序時，采取分布編譯生成OBJ文件，然后主程序組裝，結果調試信息丟失。
warning LNK4099: PDB 'vc90.pdb' was not found with 'E:\Projects\XXXXX\Lib\log4cplusSD.lib' or at 'E:\Projects\XXXXX\Debug\vc90.pdb';
為解決這個問題搜索了下MSDN中關于PDB文件生成的一些解釋匯集在這里。
1）http://msdn.microsoft.com/zh-cn/library/yd4f8bd1(v=vs.80).aspx
程序數據庫 (PDB) 文件保存著調試和項目狀態信息，使用這些信息可以對程序的調試配置進行增量鏈接。當以 /ZI 或 /Zi（用于 C/C++）生成時，將創建一個 PDB 文件。

在 Visual C++ 中，/Fd 選項用于命名由編譯器創建的 PDB 文件。當使用向導在 Visual Studio 中創建項目時，/Fd 選項被設置為創建一個名為 project.PDB 的 PDB。

如果使用生成文件創建 C/C++ 應用程序，并指定 /ZI 或 /Zi 而不指定 /Fd 時，則最終將生成兩個 PDB 文件：

• VC80.PDB   （更籠統地說就是 VCx0.PDB，其中 x 表示 Visual C++ 的版本。）該文件存儲各個 OBJ 文件的所有調試信息并與項目生成文件駐留在同一個目錄中。

• project.PDB   該文件存儲 .exe 文件的所有調試信息。對于 C/C++，它駐留在 \debug 子目錄中。

每當創建 OBJ 文件時，C/C++ 編譯器都將調試信息合并到 VCx0.PDB 中。插入的信息包括類型信息，但不包括函數定義等符號信息。因此，即使每個源文件都包含公共頭文件（如 <windows.h>），這些頭文件中的 typedef 也只存儲一次，而不是在每個 OBJ 文件中都存在。

鏈接器將創建 project.PDB，它包含項目的 EXE 文件的調試信息。project.PDB 文件包含完整的調試信息（包括函數原型），而不僅僅是在 VCx0.PDB 中找到的類型信息。這兩個 PDB 文件都允許增量更新。鏈接器還在其創建的 .exe 或 .dll 文件中嵌入 .pdb 文件的路徑。

Visual Studio 調試器使用 EXE 或 DLL 文件中的 PDB 路徑查找 project.PDB 文件。如果調試器在該位置無法找到 PDB 文件或者如果路徑無效（例如，如果項目被移動到了另一臺計算機上），調試器將搜索包含 EXE 的路徑，即在“選項”對話框（“調試”文件夾，“符號”節點）中指定的符號路徑。調試器不會加載與所調試的二進制不匹配的 PDB。

2）http://msdn.microsoft.com/zh-cn/library/958x11bc(v=vs.80).aspx

下表描述了這些選項。

無

不產生任何調試信息，因此編譯較快。

/Z7

生成包含用于調試器的完整符號調試信息的 .obj 文件。符號調試信息包括變量的名稱和類型以及函數和行號。不會生成任何 .pdb 文件。

對于第三方庫的發布者，不生成 .pdb 文件是一個優點。但是，在鏈接和調試期間，用于預編譯頭的 .obj 文件是必需的。如果 .pch 對象文件中只有類型信息（沒有代碼），則還必須使用 /Yl（為調試庫插入 PCH 引用） 進行編譯。

/Zi

產生包含用于調試器的類型信息和符號調試信息的程序數據庫 (PDB)。符號調試信息包括變量的名稱和類型以及函數和行號。

/Zi 不影響優化。但是，/Zi 的確暗示了 /debug；有關更多信息，請參見 /DEBUG（生成調試信息）。

類型信息放置在 .pdb 文件而不是 .obj 文件中。

可以將 /Gm（啟用最小重新生成） 和 /Zi 結合使用，但使用 /Z7 編譯時不能使用 /Gm。

使用 /Zi 和 /clr 編譯時，DebuggableAttribute 屬性將不會被放入程序集元數據中；如果要使用該屬性，則必須在源代碼中指定它。該屬性可影響應用程序的運行時性能。有關 Debuggable 屬性如何影響性能以及如何減輕性能影響的更多信息，請參見令映像更易于調試。

/ZI

以支持“編輯并繼續”功能的格式產生如上所述的程序數據庫。如果想使用“編輯并繼續”調試，則必須使用此選項。因為大多數優化與“編輯并繼續”不兼容，所以使用 /ZI 會禁用代碼中的所有 #pragma optimize 語句。

/ZI 會導致在編譯中使用 /Gy（啟用函數級鏈接）。

/ZI 與 /clr（公共語言運行庫編譯） 不兼容。

注意
/ZI 只可用于面向 x86 的編譯器中；此編譯器選項不可用于面向 x64 或 Itanium 處理器系列 (IPF) 的編譯器中。

編譯器將程序數據庫命名為 project.pdb。如果編譯沒有項目的文件，則編譯器將創建名為 VCx0.pdb. 的數據庫，其中 x 是正在使用的 Visual C++ 的主版本。編譯器將 PDB 的名稱嵌入每個使用此選項創建的 .obj 文件中，從而使調試器了解符號和行號信息的位置。當使用此選項時，.obj 文件將較小，因為調試信息存儲在 .pdb 文件中而不是 .obj 文件中。

如果從使用此選項編譯的對象創建庫，則在將庫鏈接到程序時，關聯 .pdb 文件必須可用。因此，如果發布此庫，就必須發布 PDB。

若要不使用 .pdb 文件創建包含調試信息的庫，必須選擇編譯器的 C 7.0 兼容 (/Z7) 選項。如果使用預編譯頭選項，則預編譯頭和其他源代碼的調試信息都放在 PDB 中。指定了“程序數據庫”選項時將忽略 /Yd 選項。

3）http://msdn.microsoft.com/zh-cn/library/dd998269.aspx

/PDBALTPATH（使用備用 PDB 路徑）

 

很簡單的一款兒童學習數學的軟件，長期使用時需要注冊碼，下面簡單分析一下注冊算法。
注冊碼必須是25位，形如AAAAa-BBBBb-CCCCc-DDDDd-EEEEe.真正有用的只是AAAABBBBCCCCDDDD16位，其他位置可以隨便填寫。
004015B1                 call    ds:_mbscmp處是比較注冊碼是否正確。
正確的注冊碼需要用硬盤的id號計算，比如我的虛擬機8位硬盤id:18e9de99
1）先進行變形在2,4,6,8,10,12,14,16位分別插入1,2,3,4,5,6,7,8.多次變形后生成24位長字符串11128324e5369748d5e69798。
2）按照6個字符一段分成4組，按照3）4）5）計算生成4個4位共16位字符串
3）每一組的后三字符逐位與種子數組【0a,13,09,0c,0b,0a,08】相乘后求和，并轉換為字符串。
4）計算3）中生成字符串的第3位與第4位差的絕對值，存入m。
5）對3）生成的字符串進行變形，先把第1位加上m；然后前4位每位各加上0x11，生成4位字符串
按照1）-5）步驟重復兩次，第一次生成JBCJHBHCEGHJHCJE，第二次生成ICDJCDCCCHBBCIFF。
ICDJCDCCCHBBCIFF就是對應上面的AAAABBBBCCCCDDDD16位注冊碼了。
所以我的虛擬機的注冊碼就是ICDJ1-CDCC2-CHBB3-CIFF4-00000。注冊成功后你的注冊碼保存在dat\diary.dat文件中。

對于socket編程一直有一種誤解：socket的阻塞連接下應該調用send/recv來發送和接收數據，而無阻塞連接下應該用WSASend/WSARecv函數來發送和接收數據。其實socket工作模式與調用哪個收發函數沒有任何關系，自己寫段簡單的代碼測試下就知道了。無阻塞模式下，send/recv都是立即返回的。并不會等待發送或接收完成才返回。測試還發現選擇模式下無阻塞連接，調用connect函數會立即返回，隨后調用select，在連接建立時會設置fdWrite。 很多問題要想深入理解最好的方法就是寫一段短的測試程序驗證一下，既不要想當然也不要道聽途說。

http://anaturb.net/C/ccc.htm

stanza是ipod/iphone上的免費讀書軟件，功能非常實用。最近由于我的ipod系統出現問題，想導出stanza下載的電子書后重裝系統，結果折騰了好久。

在stanza官網上搜索了下，發現很多人都有和我一樣的需求，作者也適時推出了Stanza Book Restore Tool,我立馬下載回來。這個工具是從ipod備份（通過itune備份）中導出stanza電子書。但是我一運行這個工具就提示我RE:java.lang.IllegalArgumentException: Cannot find backup folder錯誤。
會不會是這個工具不支持中文目錄呢？我把itunes備份目錄copy到c:根目錄下。結果還是一樣的錯誤提示，這下沒轍了。重新回到stanza官網搜索，發現了這篇文章http://www.lexcycle.com/node/1864。摘錄如下

RE:java.lang.IllegalArgumentException: Cannot find backup folder

這個解決辦法是要修改stanzabookrestore.jar中的StanzaBookRestore.java文件，將StanzaBookRestore.run()函數中的所有backupFolder.length() == 0條件檢查去掉。據說是Windows下才有這個問題。
以前我可沒有編譯過java。只好下載了java jdk以及XJad反編譯工具。先用XJad反編譯stanzabookrestore.jar，然后安裝jdk，修改StanzaBookRestore.java并重新編譯為jar。要說明的一點是，stanzabookrestore.jar中已經帶有所有java源文件了。XJad反編譯后的java文件編譯時有點小問題，我是直接從作者的源文件替換、修改后重新編譯的。
說說java的編譯過程。
1.執行javac ????.java生成 ????.class
2.建一個manifest.mf 文件用來申明main函數所在類，這里可以直接用作者原來的manifest.mf
3.用jar 打包class文件。
先將所有class文件copy到classes文件夾，然后在上一級目錄下建一個myjar.bat文件，內容如下：
set JAVA_HOME=C:\Program Files\Java\jdk1.6.0_21
set PATH=%JAVA_HOME%\bin
set CLASSPATH=%JAVA_HOME%\lib\tools.jar;
jar cvfm stanzabookrestore.jar MANIFEST.MF -C classes/ .
運行myjar.bat就重新生成了stanzabookrestore.jar.
沒想到搞個stanza電子書的備份居然要學習java的編譯。不過也許以后還用得著，先記在這里吧。
重新編譯后的在這里http://www.shnenglu.com/Files/huyutian/stanzabookrestore.zip

最近將編程環境升級到VS2008，結果很多原來正常編譯的projects都出現了編譯告警和錯誤。花了一周多時間熟悉下VS2008.，總體來看vs2008在64位編程、多核/多處理器編譯、函數的安全性、c++模板的支持方面都有很多改進。但是在升遷到新的環境之前也有很多問題需要重新考慮了。
1。time_t在vs2003中默認是32位__time32_t，現在默認為__time_64_t了，如果要繼續兼任原有代碼必須在頭文件的開始處增加如下語句
#ifndef _USE_32BIT_TIME_T
#define _USE_32BIT_TIME_T//use __time32_t
#endif
2.sprintf，memcpy之類的函數都會提示告警，要繼續使用這些函數必須在定義宏
#define _CRT_SECURE_NO_DEPRECATE
#define _CRT_SECURE_NO_WARNINGS
3.編譯時出現：無法打開vc90.pdb的錯誤。在MSDN上搜索了一下，解決辦法是http://msdn.microsoft.com/en-us/library/hk8k8k4h(VS.80).aspx
原文貼在這里，主要是因為vs2008支持一在個solutions下多個不相互依賴的project的并行編譯，當然前提是你的cpu是多核的或者有多個cpu。如果多個projects的output目錄相同就會碰到同時寫入vc90.pdb的問題。知道了原因就很好解決了。
Title: You may receive a "PRJ0008" or "C2471" or "C1083" or "D8022" or "LNK1103" or similar error message when you try to build a solution in Visual C++

Symptoms:

• D8022 : Cannot open 'RSP00000215921192.rsp'
• PRJ0008 : Could not delete file 'vc90.idb'.
• C1083 : Cannot open program database file 'vc90.pdb'
• C2471 : Cannot update program database 'vc90.pdb'
• LNK1103 : debugging information corrupt.

Cause:

This problem occurs when all of the following conditions are true:

1. You have a solution with more than one project in it.
2. Two or more of the projects are not dependent on each other.
3. You have parallel builds enabled. (Tools -> Options: Projects and Solutions, Build and Run: "maximum number of parallel project builds" is set to a value greater than 1)
4. You are building on a system with multiple CPUs (cores).
5. Two or more of the non-dependent projects are configured to use the same Intermediate and/or Output directory.
6. A specific race condition in mspdbsrv.exe remains uncorrected.

Resolution:

To resolve the problem do one or more of the following:

• Reconfigure the non-dependent projects to specify an Intermediate and Output directory that is different from one another, e.g. Output Directory = "$(SolutionDir)$(ProjectName)\$(ConfigurationName)", Intermediate Directory = "$(OutDir)".
• Adjust your solution's project dependencies (Project -> Project Dependencies...) so that each is dependent on another.
• Disable parallel builds.
• Add the "/onecpu" boot option to your boot.ini file.
• Change you BIOS settings to enable/use only one CPU.
• File a problem report with Microsoft Technical Support and keep bugging the *** out of them until they eventually fix mspdbsrv.

今年4月zlib發布了1.2.5版，修正了幾個bug，增加了新功能（目前我還用不上).
最近準備在自己的程序中用這個版本。結果怎么也編譯通不過。折騰了我一整天才搞定，發現是兩個小的設置沒有弄好。哎。。。
新的1.2.5版本只提供了vc9、vc10兩個project配置文件.我用項目版本轉換文件怎么也不能轉到vc7.1下。沒辦法只好裝了一個vc2008重新編譯。
把zlib 1.2.5加入自己的項目，編譯時有兩點要注意
1.就是zlib 1.2.5源代碼包中\contrib\vstudio\readme.txt中說的在使用zlib要預定義宏ZLIB_WINAPI，否則無法編譯通過。
- To use zlibwapi.dll in your application, you must define the  macro ZLIB_WINAPI when compiling your application's source files.
2.鏈接時，除了#pragma comment(lib, "zlibvc.lib")添加引入庫外，還要注意Character Set的設置要統一。否則也會出現鏈接錯誤，提示找不到_compress外部變量。

后記（2011-6-19）
我的編程環境已升級VS2008，又想在項目中使用ASM版本的ZLIB，重新從zlib.net下載后，直接使用zlib-1.2.5\contrib\vstudio\vc9下的zlibvc項目文件編譯出錯。發現是zlib-1.2.5\contrib\masmx86下的OBJ文件沒有生成。進入VS2008命令行環境，運行bld_ml32.bat生成兩個obj文件。重新在集成環境下編譯就沒問題了。但是如果是使用ZLIB的靜態庫版本，一定注意要將這兩個obj文件包含到最終的zlibvc.lib中去。否則在自己的應用項目中編譯時會提示如下錯誤。1>zlibr.lib(inflate.obj) : error LNK2001: unresolved external symbol _inflate_fast
1>zlibr.lib(deflate.obj) : error LNK2001: unresolved external symbol _longest_match
1>zlibr.lib(deflate.obj) : error LNK2001: unresolved external symbol _match_init
把兩個obj文件包含到zlibvc.lib的方法是，Project->Property->Librarian->Additional Dependencies 加入inffas32.obj match686.obj，同時Additional Library Directories設置正確。
另外，如果使用命令行編譯進入zlib-1.2.5\win32目錄運行下面的命令就可以了。
nmake -f win32/Makefile.msc LOC="-DASMV -DASMINF" OBJA="inffas32.obj match686.obj"               (use ASM code, x86)
nmake -f win32/Makefile.msc AS=ml64 LOC="-DASMV -DASMINF"  OBJA="inffasx64.obj gvmat64.obj inffas8664.c"  (use ASM code, x64)

M$的編譯器，低版本的總是無法打開高版本的project項目文件，讓人非常郁悶。其實有些小型項目用VC6.0或者vc2003就足夠了。沒必要裝那么大腹便便的vs2008，或者最新的vs2010.這時候一個不同版本間的項目轉換工具就非常必要了。常用工具收藏于此，查閱方便。
Visual Studio Project Converter
http://sourceforge.net/projects/vspc/
VSPC is the console utility for converting between project formats for various versions of Microsoft Visual Studio. Currently the project supports VS 2002, 2003, 2005 and 2008. Original version of the code was created by Stoyan Damov
命令行工具，支持VS2002,2003,2005以及2008不同版本之間的互相轉換，非常方便。似乎不支持vc6.0與以上版本互相轉換。

vc7.0轉換VC6.0項目的工具要看這里
http://www.arstdesign.com/articles/prjconverter.html
或者從codeproject下載
http://www.codeproject.com/KB/applications/prjconverter.aspx

值得一提的是，以上兩個工具都是開源的，有興趣的可以研究下不同版本間格式的變化。

最近一直在學習STL 標準容器的用法，感覺相關資料太少，上手不易。大多數學習資料使用的例子是關于int或者char*等簡單數據的，對于自定義結構、類的標準容器講述很少。今天搜索到baidu上的暈暈倒倒網,感覺關于標準容器的用法總結的非常好，實例詳盡，一看就明白。欣喜之下，不告而取，以防遺忘。如果原作者有意見，不讓轉貼，請郵件告知，必當立即清除。