1.1 代碼提示功能
在vs中開發中，Visual Assist是一個很優秀的插件，我們仍然能夠使用它進行代碼的分析，但它僅僅能支援vcxprojproject，因而我們選擇對vcxproj的project進行擴充，這樣VisualAssist就能夠正常使用了。
此外，VS的智能感覺不支援GCC的一些擴充，在做代碼分析的時候可能出錯。我們採用強制包括頭檔案的方式解決一部分問題：
注意，這個檔案的目的是讓VS可以進行代碼的分析，而不是讓VS具有編譯這些代碼的能力！！
！
這個頭檔案類似于這種：
#pragmaonce
// 本檔案的作用僅在于使VS可以解決文法錯誤，而不在于讓程式正确執行！
。
#define__attribute__(x)
#define__signed__
signed
#defineinline__inline
#defineBITS_PER_LONG
4
#define_TIME_T
#define__inline__
#define__u64int
…….
1.2 代碼編譯
非常早之前，想通過移植GCC到cywin以下進行編譯，最後放棄了。
當中一個原因是cywin的速度較慢，盡管是windows下的本地應用。但它的編譯速度比虛拟機裡執行gcc還是要慢不少。
究其原因，主要是cywin在模拟fork操作時使用的技術影響了其速度（見其他文章的分析）。
放棄cywin的還有一個原因是嵌入式Linux平台提供的編譯器都是基于Linux的，非常難把這些編譯器做移植。
因而我們採用遠端編譯的方法，當VS進行編譯操作的時候，使用SSH登入到虛拟機的Linux系統中進行編譯，再分析編譯過程中産生的資訊，将之轉換為vs可以識别的資訊。這樣VS就行在IDE中正确定位發生錯誤的檔案！
在這樣的方式中。Make或者gcc生成的錯誤資訊因為編譯方式的不同産生的錯誤資訊是有差異的，為了處理這樣的差異，我們将這個過程用python來完畢。這樣在不同的項目中僅僅須要對python腳本做少量改動就能夠了。這個腳本全然能夠做為項目的一部分。
這樣的方式獲得的還有一個優點是大大減少VS擴充的代碼，進而保證了它不會影響到VS的穩定性。
1.3 生成過程控制
VS2012使用MSBUILD進行生成，它同意在一個項目改寫自己的生成過程。将預設行為指向自己定義的擴充，這也是我們要採用的方式。
1.4 參數配置
對照VC和GCC的編譯參數能夠發現有非常多參數是同樣的。如宏定義、附加檔案夾等等，這部分能夠直接使用。除此之外另一些特定的參數，我們通過為VS加入新的平台和屬性頁的方式進行支援。
這樣我們能夠通過VC的項目屬性來配置GCC的特定參數。
對于Linux核心的配置，實際上是由scripts/kconfig/mconf或者scripts/kconfig/qconf程式來完畢的。事實上現過程是讀取Kconfig檔案生成菜單。再依據使用者選擇生成.config檔案，我們将之簡單改動全然能夠在windows下進行配置：
在VS中依據project配置調用就能夠輕松搞定。
1.5 調試
對于應用程式的調試，VS提供了調試器的引擎。我們擴充此調試器引擎，在調試時使用ssh連接配接到虛拟機的系統，或者直接連接配接到目标闆。在其上使用gdb載入應用程式進行調試，或者使用gdb連接配接目标闆的gdbserver進行調試。
我們将使用gdb的machine interface，而不是經常使用的互動接口。
驅動的調試嘗試使用KGDB，沒玩過，玩的時候再說吧。
1.6 project模闆
在調試完畢後将UBOOT、LINUX等project固化成模闆，就像這種：
1.7 輔助功能
将python控制台、ssh控制台、序列槽控制台內建到VS中，嘿嘿，夠強大了吧~~~~