① 如何在windows下編譯Chrome源代碼
一，編譯之前的准備。
1） 了解代碼組織結構。
Chrome source非常龐大，並且在其主目錄下還包含有工具和組件，任何一個工具和組件也附帶有其源代碼。首先得熟悉這些源代碼的組織結構，在http://src.chromium.org/svn/中包含如下子目錄：releases,曾經發布過的chrome源代碼的正式版本；trunk，當前最新的源代碼。由於releases中的代碼比較舊，這里就不做說明了，只說明trunk的結構。在trunk下面有3個重要的目錄，deps包含了chrome編譯和運行所需要的全部組件的代碼。src裡麵包含的則是chrome的主程序的代碼，tools包含的是下載和配置編譯所需要的第三方工具的壓縮包和源代碼，其中就有svn和python這2個比較重要的工具，後面再詳細介紹。暫時做這樣一個簡單的介紹，因為其組織結構比較負責，以後再作補充斧正。
2）如何下載和同步源代碼。
首先談談下載：
1，最簡單的方法是從chrome官網上直接下載源代碼壓縮包，地址是http://build.chromium.org/buildbot/archives/chromium_tarball.html。
2，或者採用svn從http://src.chromium.org/svn/trunk/src這個地方heckout,這要求你先在本地建一個源代碼的主目錄。
3，另外一個辦法則是採用google提供的一個部署工具depot_tools。雖然這幾種辦法都可下載完整的源代碼，但目前的情況是：chrome基於Visual Stdio 2005 進行編譯，如果順利完成編譯工作，自然少不了sln文件，較早的源代碼中包含有現成的sln和vcproject文件，但後來做了修改，這些文件被拋棄掉，Google自己開發了一種腳本工具叫做GYP,這個工具採用python編寫，GYP採用了自定義的一套規則，用於生成各種工程文件。而關鍵的python則包含於depot_tools中，因此不論採用什麼方法下載的代碼，都得下載depot_tools這個工具，以獲得必須的工程文件。
depot_tools位於 http://src.chromium.org/svn/trunk/tools 下面，包括一個目錄和一個zip格式的壓縮包。
3）關於編譯器
前面提到Chrome採用Visual Stdio 2005進行編譯，根據http://dev.chromium.org的說明，需進行如下操作正常編譯
a, 安裝Visual Studio 2005.
b, 安裝Visual Studio 2005 Service Packe 1.
c, 安裝Visual Studio Hotfix 947315.
d, 如果是vista系統，還需安裝Visual Studio 2005 Service Packe 1 Update for Windows Vista.
e, 安裝Windows 2008 SDK，如果是Visual Studio 2008則不需要這一步。
f, 配置Windows 2008 SDK，使2008 SDK成為首選開發庫，以獲得一些新功能和特性。辦法是在開始->程序->Microsoft Windows SDK v6.1 > Visual Studio Registration > Windows SDK Configuration Tool，選擇make current按鈕。也可以在VS裡面手動配置include和libary路徑，效果是一樣的。
二，如何配置工程文件
1，如果是採用depot_tools，那麼從代碼下載到生成sln文件會自動完成。其步驟是
（1）下載depot_tools到本地存儲，假設位於d:/depot_tools.
（2）將d:/depot_tools添加到系統環境變數中。
（3）創建一個源代碼根目錄，假設為 d:/chrome,目錄不得包含空格。
（4）在命令行下切換當前目錄到d:/chrome。
（5）執行命令 gclient config http://src.chromium.org/svn/trunk/src ,該命令會首先下載svn和python分別到d:/depot_tools/svn_bin和d:/depot_tools/python_bin。
（6）執行命令 gclient sync 這個命令會調用svn同步源代碼。這個過程會比較漫長。全部完成之後全部源代碼就保存在d:/chrome裡面。未編譯的代碼大約有4個G左右，過程將十分漫長。這樣獲得的源代碼已經包含所有的工程文件，可直接打開。
重點說明一下gclient，它實際上是一個批處理文件，它主要做了如下一些事情，首先設置環境變數，如代碼根目錄，工具根目錄等。其次調用win_tools.bat從伺服器下載svn和python。最後調用python.exe對Chrome.gyp進行解析生成所有工程文件。
另外需要說明的是，gclient sync的過程非常漫長，根據命令行的提示來看總共需要同步67個項目（不是工程），期間可能會因為一些原因導致錯誤而退出這個過程，需要繼續調用sync。比如網路出現故障svn會多次進入sleep狀態然後重試，如果多次失敗就會報錯退出，還有的情況是某些子目錄的屬性問題無法同步，可根據提示進行操作。還有個目前新出現的問題，下面2個目錄「src/webkit/data/layout_tests/LayoutTests」和「src/third_party/WebKit/LayoutTests」的源代碼是從src.webkit.org簽出來的，但是這個網站目前存在問題無法簽出代碼， 需要屏蔽掉這2個目錄，由於裡面是測試代碼，即使丟棄也不會影響整個工程的編譯，方法是打開trunk下面的.gclient文件，向裡面添加如下內容
"custom_deps" : {
"src/webkit/data/layout_tests/LayoutTests":None,
"src/third_party/WebKit/LayoutTests":None,
},
這樣svn就能完成代碼的同步了。最後gclient會調用depot_tools/python_bin/python.exe 對 src/build/gyp_
chromium進行處理，這樣就得到了所有的sln和vcproject文件。
2，如果是下載的代碼壓縮包或者checkout的代碼，代碼目錄裡面沒有sln文件，這個時候需要調用命令行進入源代碼根目錄，然後執行命令 gclient runhooks --force，命令執行後會直接對Chrome.gyp進行解析,生成sln文件。
在實際下載過程中，最開始的時候我用TortoiseSVN從http://src.chromium.org/svn/trunk/src checkout源代碼，但是得到的代碼只有幾百兆，執行gclient runhooks --force命令後也沒有找到sln文件，具體原因未知，不建議使用此方式。而直接下載代碼壓縮包的方式沒有嘗試過，不知道是否可行。因此最穩妥的方法還是使用depot_tools來部署和處理源代碼。
三 編譯工程
啟動Visual Studio 2005打開 src/chrome/browser/chrome.sln,或者打開src/build/all.sln,如果打開的是chrome.sln裡麵包含480個工程，而all.sln則包含507個工程，一些09年的編譯說明提到有300左右的工程，可見chrome的代碼變動比較大。對整個解決方案進行編譯，打開需要2個小時才能完成編譯，視硬體環境而定，內存越大越快，推薦4G以上內存，酷睿2核或者4核。編譯完成以後據說會佔用30G的空間。編譯後的文件位於 d:/chorme/chrome/debug 目錄或者 d:/chorme/chrome/release目錄下。
四 chrome涉及的開源項目
Chrome 採用了很多開源項目，這里把它們列出來以備後用，目前Chrome涉及25個開源代碼：
1、Google Breakpad
/src/breakpad
開源的跨開台程序崩潰報告系統。
2、Google URL
/src/googleurl
Google小巧的URL解析整理庫。
3、Skia
/src/skia
矢量圖引擎。
4、Google v8
/src/v8
Google開源的JavaScript引擎。V8實現了ECMA-262第三版的ECMAScript規范，可運行於Windows XP 和 Vista, Mac OS X 10.5 (Leopard), 及 Linux等基於IA-32 或 ARM 的系統之上。V8可單獨運行也可嵌入到任何C++程序中。
5、Webkit
/src/webki
開源的瀏覽器引擎
6、Netscape Portable Runtime (NSPR)
/src/base/third_party/nspr
Netscape Portable Runtime (NSPR) 提供了系統級平台無關的API及類似libc的函數。
7、Network Security Services (NSS)
/src/base/third_party/nss
Network Security Services (NSS) 一套用於支持伺服器端與客戶端安全開發的跨平台函數庫。程序通過NSS可支持SSL v2 and v3, TLS, PKCS #5, PKCS #7, PKCS #11, PKCS #12, S/MIME, X.509 v3 認證及其它一些安全標准。
8、Hunspell
/src/chrome/third_party/hunspell
Spell checker and morphological analyzer library and program designed for languages with rich morphology and complex word compounding or character encoding.
9、Windows Template Library
/src/chrome/third_party/wtl
用於開發Windows程序與UI組件的C++ library。WTL擴展了ATL (Active Template Library) 並提供一套用於controls, dialogs, frame windows, GDI objects等開發的類。
10、Google C++ Testing Framework
/src/testing/gtest
Google用於編寫C++測試的基於xUnit架構的框架，可用於多種平台上：Linux, Mac OS X, Windows, Windows CE, and Symbian。支持自動測試發現，有一套豐富的Assertions斷言，用於可自定義斷言，death tests, fatal and non-fatal failures, various options for running the tests, and XML test report generation.
11、bsdiff 與 bspatch
/src/third_party/bsdiff 及 /src/third_party/bspatch
bsdiff 與 bspatch 用於為二進制文件生成補丁。
12、bzip2
/src/third_party/bzip2
bzip2使用Burrows-Wheeler block sorting text compression 演算法與Huffman編碼壓縮文件。
13、International Components for Unicode (ICU)
/src/third_party/icu38
ICU是一套成熟並被廣泛使用的C/C++ 及 Java 庫，可為軟體提供Unicode與全球化支持。
14、libjpeg
/src/third_party/libjpeg
用於處理JPEG (JFIF)圖像格式的庫。
15、libpng
/src/third_party/libpng
PNG圖像格式庫。支持絕大部分的PNG特性，可擴展。已經被廣泛地使用了13年以上了。
16、libxml
/src/third_party/libxml
C語言的XML解析庫。
17、libxslt
/src/third_party/libxslt
C語言的XSLT庫。
18、LZMA
/src/third_party/lzma_sdk
LZMA為7-Zip軟體中7z格式壓縮所使用的壓縮演算法，有很好的壓縮效果。
19、stringencoders
/src/third_party/modp_b64
一系列高性能的c-string轉換函數，比如：base 64 encoding/decoding。通常比其標准實現快兩倍以上。
20、Netscape Plugin Application Programming Interface (NPAPI)
/src/third_party/npapi
多種瀏覽器使用的跨平台插件架構。
21、Pthreads-w32
/src/third_party/pthread
用於編寫多線程程序的API
22、SCons - a software construction tool
/src/third_party/scons
開源的軟體構建工具——下一代的編譯工具。可以認為SCons是改進過的跨平台配上autoconf/automake與ccache的Make工具的子系統。
23、sqlite
/src/third_party/sqlite
大名鼎鼎的嵌入式資料庫引擎。自管理、零配置、無需伺服器、支持事務。
24、TLS Lite
/src/third_party/tlslite
SSL 3.0, TLS 1.0, and TLS 1.1的Python免費實現庫。TLS Lite支持這些安全驗證方式：SRP, shared keys, and cryptoIDs in addition to X.509 certificates。註：Chrome並不包涵Python。TLS Lite用於Chrome開發過程中的代碼覆蓋、依賴檢查、網頁載入時間測試及生成html結果比較等。
25、zlib
/src/third_party/zlib
zlib為一套用於任意平台與機器的無損數據壓縮的庫，它免費、自由、無任何法律專利問題。
② lzmaDecode 是什麼演算法
LZMA，（Lempel-Ziv-Markov chain-Algorithm的縮寫），是一個Deflate和LZ77演算法改良和優化後的壓縮演算法，開發者是Igor Pavlov，2001年被首次應用於7-Zip壓縮工具中，是 2001年以來得到發展的一個數據壓縮演算法。它使用類似於 LZ77 的字典編碼機制，在一般的情況下壓縮率比 bzip2 為高，用於壓縮的可變字典最大小可達4GB.
C++ 語言寫成的的 LZMA 開放源碼壓縮庫使用了區間編碼支持的 LZ77 改進壓縮演算法以及特殊的用於二進制的預處理程序。
數據流、重復序列大小以及重續序列位置單獨進行了壓縮。
LZMA 支持幾種散列鏈變體、二叉樹以及基數樹作為它的字典查找演算法基礎。
BCJ / BCJ2
BCJ / BCJ2 壓縮工具所附帶的 LZMA SDK 包括：在 X86、ARM、PowerPC、IA-64 以及 ARM Thumb 處理器上在壓縮之前跳轉目標進行歸一化處理。對於 x86 平台來說，這是一個近跳轉、近調用以及近條件跳轉需要從「向後跳 1665 位元組」這樣的機器語言歸一化到「跳轉到 5554」這樣的格式，但是短跳轉及短條件跳轉不需要進行這樣的處理。
7-Zip
盡管 7-Zip BCJ2 使用 32 位的偏移地址，但是 UPX 這樣的可執行文件壓縮工具當檢測到 16 位 DOS 二進制文件格式的時候仍然可以使用 16 位的數值。RAR 壓縮工具對 32 位的 x86 可執行文件以及 IA64 Itanium 可執行文件進行偏移地址壓縮。
BCJ / BCJ2 二進制文件壓縮
BCJ 與 BCJ2 之間的區別在於前者只將近跳轉及近調用目標地址轉換到歸一化的形式，而 BCJ2 只將 x86 平台下的近跳轉、近調用及條件近跳轉目標分別進行壓縮。
7-Zip 實現
在GNU LGPL通用公共許可證下發布的7-zip中使用的LZMA有以下幾個特點：
* 高壓縮比；
* 解壓縮程式碼較小：約 5 KB；
* 解壓縮時僅需少量內存 (取決於字典大小)；
* 可變更字典大小 (最大 4 GB)；
* 壓縮速度：在一部2GHz的處理器上運行，約可達到1MB每秒的速度；
* 解壓縮速度：在一部2GHz的處理器上運行，約可達10-20MB每秒的速度；
* 支援多線程、多核心（多處理器）和Pentium 4處理器的超線程(Hyper-Threading)；
這個特點使得這個這個演算法的解壓過程非常適合於嵌入式系統應用的場合。
可移植性
一些微軟Windows專有的特性深深嵌入在源程序中，這樣就很難生成一個與 Unix 兼容的版本。但是，已經有兩個移植到類 Unix 平台的版本：
* p7zip 是一個或多或少地完全將 7z 及 7za 移植到 POSIX 的 7-zip 版本，這些系統包括 Linux、Solaris、OpenBSD、FreeBSD、Cygwin 等 Unix 系統以及 Mac OS X 和 BeOS等。
* LZMA Unix Port 是一個只移植了 LZMA 中代碼的版本，它是一個類似於 gzip 的基於數據流的壓縮工具。它不是一個歸檔工具，而只是一個普通的壓縮工具，並且由於它在沒有數據頭中沒有未壓縮文件大小的 UInt64 變數，所以它與 7-zip 生成的 LZMA 數據流中不同。7-zip 使用一種更加靈活的歸檔格式 7z，因此二者都不能互相使用對方生成的數據，至少在目前是這樣。
應用
使用或者支持 LZMA 的軟體有：
* Nullsoft Scriptable Install System
* Inno Setup
* cramfs and SquashFS, with applied patches
* lrzip ("long range zip", or "LZMA rzip")
* PyLZMA，Igor Pavlov 的 LZMA SDK 的 Python 語言介面
* FreeArc, 歸檔工具及 LZMA SDK 的 Haskell 語言介面
* 用於 Pascal 語言的 LZMA SDK
③ 濡備綍緙栬瘧lzma搴
涓嬭澆lzma938.7z鍖咃紝騫惰В鍘嬬緝銆
絎涓姝ワ細鎵撳紑VS2010鎺у埗鍙般
絎浜屾ワ細杞鍒頒笅闈㈢殑鍦板潃
D:\SDK\lzma938\CPP\7zip\Bundles\Format7zR
絎涓夋ワ細浣跨敤鍛戒護鈥渘make NEW_COMPILER=1 MY_STATIC_LINK=1鈥
浜х敓7zra.dll鍜7zra.lib鏂囦歡銆