傳道解惑 軟體開發技術名詞解密

[轉載]
http://www.sjhf.net/blog/user1/sjhf/archives/2006/2006412173840.htm

序：去年為了總結自己所學習/接觸過的技術，也順便為初學者少走彎路指明一些方向，可惜後來諸事纏身未能繼續，十分遺憾，現放到自己的BLOG上來鼓勵自己將此繼續下去。
　　"Win32編程”

　 　很不幸，我從開始學習編程到理解這個名詞中間隔了很長的時間（上個世紀的學習環境可見一斑）。很長時間裡我都不明白32是指什麼，我用過Dos, Win31,win95,win97...但好像沒用過名為Win32的作業系統啊？很久以後我才知道，32在這裡並不是指作業系統的版本號碼,而是指32 位。微軟作業系統在win31及其以前都是DOS系統，windows只是在dos下啟動並執行一個大程式而已。在其後win95則稍有改變，windows 除了DOS核心以外也真正成為了作業系統的一部分，提供著各類作業系統提供的服務。應該說，在win95之後的windows(新近的64位win系統以 前)都可以稱之為win32系統平台(95/98實際上是16與32位混合)。所以在這樣的平台上，直接或間接使用系統提供的API編程，就稱之為 Win32編程。對Visual Studio而言，Win32編程一般指SDK、MFC、ATL這幾類開發方法,其中ATL在國內應用不是很廣泛，一般應用於以COM組件為架構的中大型 軟體產品。

　　"SDK" ：Software Development Kit,常譯為軟體開發（工具）包

　　在 Win32編程領域一般指與MFC這類架構編程相區別的，直接調用Windows提供的API的開發方式，與字面原意有一些區別。另外一個經常見到的說法 就是某軟體（硬體）帶有自己的一套SDK，這裡其實一般是指一套API庫函數或者類庫，供上一層的開發人員調用。又譬如常說的DX的SDK，其實是微軟開發 的一套COM組件，供上層開發人員使用。總之，供程式員使用的比較完備的程式碼程式庫，就可以稱之為SDK；

　　“MFC”: Microsoft Fundation classes 微軟基礎類庫

　 　大家都知道，使用SDK編程方式往往有很多每次都重複的固定不變的一些代碼，為了提高編程的效率，減少上千個API帶給開發人員巨大的精神壓力，微軟開 發出了這麼一個類庫，注意，這個類庫與作業系統本身無任何關係，它只是對API進行了一個物件導向的封裝，當然，還給出了一系列編程的架構。使用SDK的 方法，使用Visual Studio，通過調用Windows API，MFC你也可以做得出來。MFC把一些固定不變的代碼已經寫好了，只在編譯時間候鏈上，所以我們的代碼裡看不到WinMain(),而事實上整個程 序的運行，和SDK的方式無任何區別，初學者請記住這一點。另，補充一點個人感想，MFC的初衷，帶給開發人員更多的便利，我覺得並不太成功。學習MFC 所費的力氣和最終的所得，並不太成正比。

　　"API"：Application Programming Interface，應用程式介面

　　這個詞的出現頻率很高，從某種意義上來說，也可以看作是SDK的一個子集。這也是做給程式員的程式，不過一般指用匯出函數的方式提供服務的函數庫，不包括類庫和組件。

　　“GDI”：Graphic Device Interface，圖形裝置介面

　 　這個是Win32程式下最常用的顯示方式，與DirectX、OpenGL處於同一級。在DOS要顯示一些東東可不是容易的事，最簡單的是調用一些C的 圖形庫函數來實現顯示，不過一般也就是些畫線，填色，輸出幾個文字，效果很弱（所以DOS程式介面一般都不怎麼樣，且實現起來不是一般的複雜），要複雜一 點的動畫/圖片顯示什麼的，經常要用到的就是硬體中斷，調用一些顯卡自身的子程式(固化在顯卡內的）來做。因為每一個顯卡都不同，所以DOS的遊戲相容常 常由於顯卡的差異而很糟糕。到Windows下大家就幸福多了，Windows將硬體這一層屏蔽起來，用一個表格（Device Context）來代表一個顯示，我們要做的就是在這個表格上填好相關參數，然後畫上我們想畫的東東，然後作業系統會依照這個表格（DC），把相應的顯示 內容（一般是一塊顯示記憶體） 傳送到指定顯卡的指定的顯存，再由顯卡傳給顯示屏。我們不再需要與不同的顯卡打交通，這是一個十分偉大的勝利！GDI中最常用的是雙緩衝技術，就是說你可 以在記憶體中建立（也就是複製）一個DC，只不過在這個DC中顯示的不再被傳送到顯示器上。有什麼用呢？因為它的各參數是與當前螢幕DC一致的（COPY嘛 ，當然是這個結果），所以它的顯示內容可以完整無失真地傳送到螢幕DC上。我們通常在記憶體DC上畫圖，譬如畫一圓，再畫一條直線，畫完後一次性地傳送到屏 幕DC上，這樣對使用者來說螢幕只重新整理了一次，可以解決你畫一點內容螢幕即重新整理一次導致的閃爍問題。當然，雙緩衝甚至多緩衝還有很多別的用處，那就要靠自己 揣摩了。

　　"DirectX"

　　通常簡稱為DX（讀音：低叉）這是個很吸引人眼球的名詞，讀起來就很上口：）。 Windows為我們作了許多屏蔽底層硬體的工作，其中DX是最知名的技術之一。作業系統要與各類硬體打交道，特別是多媒體相關的，譬如顯卡、音效卡、手柄 輸入、多媒體流的網路傳輸等等，這些事情如果都自己來弄的話，那就太要命了（這些一般都涉及系統底層，自己也很難做出來）。而DX則正是這麼一套作業系統 提供的隔離多媒體硬體與程式員的間質，DX自身一般並不實現處理的能力，它是一個標準，要求硬體來滿足，好比DX提供一個函數名，硬體來實現函數內容一 樣。通過它我們可以非常簡單而快速地調用硬體提供的各類服務。它主要包括DirectDraw(通過直接存取顯示硬體來提供快速的圖象處理能力), DirectSound(提供了軟硬體的低延遲聲音混頻和回放，以及直接存取音訊裝置的能力),DirectPlay (它明確的提供了通用環境串連能力來簡化你應用程式之間的通訊服務),Direct3D(DirectDraw的3D版），DirectInput（簡化 你的應用程式訪問滑鼠、鍵盤和操縱杆裝置的能力），DX5.0之後又增加了一些(如DirectShow)，不再詳述。DX一個重要的特點就是你可以通過 它直接存取硬體而無需知道硬體的具體細節。譬如DirectDraw,就能夠越過記憶體而直接存取顯存，這樣的速度將比GDI快很多，不在一個數量級上。補 充一點：DX是以組件的方式提供的，而不是通常的匯出API的形式。DX SDK的最新版本是9.0

　　"COM”：component object model，元件物件模型，一般簡稱組件。

　 　這是微軟為瞭解決代碼重用的一個重要機制。重用代碼的最簡單辦法是原始碼重用，把寫好的函數和類加到自己當前的代碼中,編譯即可。簡單是簡單，敝病卻顯 然的多。另一個常用的方法是單獨做成模組，以DLL的形式分發，DLL匯出函數或者類，客戶程式用動態/靜態連結的方法將其載入，這顯然比前一種原始碼的 方法好一些，難度也不大，最為常用。但DLL也有一些不足，最根本的，它不是二進位相容，DLL版本升級一次就需要與客戶程式碼重連結一次，有些時候這 幾乎是不可能的任務。為了更好地讓編程像“搭積木”一樣簡單，讓模組可以完美地配合，完美地替換，COM產生了。COM不是類庫，不是代碼，不是作業系統 的服務，而是一套編程模型，理論上來說，它與語言無關，與作業系統無關，unix下同樣可以做COM。COM是一種程式結構模型標準，你做的DLL或 EXE在結構上滿足這麼一個標準，那這個DLL或EXE就是一個組件，它將在該平台上成為二進位相容。COM主要利用了註冊表來登記本模組的資訊。客戶程 序調用時首先查註冊表，找到所需組件的位置（這實現了位置透明），然後就用Loadlibrary把它載入進來，這和普通調用沒有本質區別，區別在於由於 組件特殊的實現方法使得整個過程中使用者程式都不知道組件的位置，組件的類的執行個體化過程，如何銷毀，不能直接存取組件的任何實現細節，使用者只與組件的幾個 public介面打交道。這將實現真正的模組之間的獨立。對使用者程式而言，對於目標組件的認識，除了介面，一無所知。在介面不變的情況下，組件可任 意替換而客戶程式不作任何改動，無需編譯，僅這一點，在中大型程式的模組整合的過程中就將節約相當多的時間。 "STL"：Standard Template Library,標準模板庫

　　這是最早由Alexander Stepanov和Meng Lee（蠻像中國人的名字）完成，於1994年提交給ANSI/ISO 標準C++委員會並通過而成為標準C++的一部分。望文生義即可知這是一個程式碼程式庫標準，不是文法標準。簡單地說，STL是以C++中的模板文法為基礎建立 起來的一套包含基礎資料結構和演算法的程式碼程式庫。STL的特點是實現了“型別參數化”，即STL的代碼中可處理任意自訂類型的對象，如果不使用模板技術的 話，這是一件相當困難的事。也因為這個原因，在最新的java及C#文法中均加入了對模板文法的支援，可見其重要性。另外一個有關STL重要的話題是GP （Generic Programming),泛型。這是與物件導向相併列的另外的一個編程模型，它以模板為基礎，弱化了實體類型的差異，簡化了編程時問題抽象的模型，提供 了更好的封裝性和彈性，對於繁雜的物件導向編程毫無疑問是一種解脫，至少是精神上的。GP並不是用來取代物件導向的，而是作為一個有益的補充體，是面向對 象很好的夥伴。ＧＰ是最近幾年軟體架構的一個研究熱點，但國內真正的應用似乎並不多見，這項技術本身還基本處於研究前沿。<< Modern C++ Design>>一書對C++中的GP應用有很好的詮釋，而這本書對腦細胞的殺傷力之大，也是其它C++書藉望塵莫及的。想知道C++的代碼 技巧可以做到怎樣的出神入化嗎？不妨看看這本書。

　　"ATL"：Active Template Library，Active Template Library

　　這在VC編程下 應該算是比較進階的話題了，它集COM和模板技術於一身，帶來了極方便的組件編寫方法和極高的學習門檻。可以說，進入ATL領域就算是進入了中級以上的編 程領域。ATL是為組件而生，它的目的是為了讓程式員更方便地編寫組件（純用C++寫一個最簡單的組件實現一個“Hello　World”對初學者來說都 是要命的），同時它使用模板技術來類似於MFC一樣建立了一個開發COM的架構程式碼程式庫(模板庫），使用該架構及模板庫可以相對方便地進行組件開發。ATL 中的一個特點就是你自己的類將成為ＡＴＬ程式碼程式庫中某些類的父類，這是一件很有趣的事（這也是模板技術的一個特點）。

　　"HANDLE": 控制代碼

　 　這是一個中文翻譯很古怪的字，對初學者來說是百思不得其解的東東。這其實等價於void*（順便提一下，初學者往往對VC代碼中各種古怪的符號、類型標 記/宏等百思不得其解，其實它們大多來自基本類型的#define或者typedef,請將游標移到這些符號上（譬如HANDLE），然後按下F12，編 譯器自會把你帶到它的聲明處，反覆使用幾次，你終會見到它的原貌，然後長籲一口氣：原來不過如此而已。沒用過的初學者請牢記：F12）。很多初學者總想知 道一個HANDLE代表一個什麼對象，我的建議是不要去理解為某對象，而就是理解為訪問某一個對象的入口，事實上HANDLE大多數時候是一個整數索引 （標誌該對象在作業系統的某表中的位置,就好像一個數組的下標一樣），Windows系統核心中主要是幾張大表，這樣一個整數索引就是標記目標在這個表中 的位置，供作業系統訪問時查詢用。偶而它的確是指向某對象的指標，有時它還攜帶一些額外輔助資訊。總之，我們不要去直接存取它，把訪問HANDLE的任務 交給作業系統好了，除非你還嫌寫程式不累：）。

　　"DLL": Dynamic Link Library 動態連結程式庫

　 　DLL的一個特點就是可以動態載入（顧名思義），即在主程式（我更喜歡稱為客戶程式）需要該模組時才由作業系統載入到記憶體。畢竟一個大型應用程式我們經 常使用到的功能並不多，這樣一些不常用的功能模組（DLL）在程式運行時一般將不被載入，可極大節省記憶體開銷。DLL同時也是目前最常用的分發模組的方 法，便於彼此協作。程式中對DLL的調用主要有兩種方法：1 針對使用DEF檔案匯出函數的DLL，使用API函數LoadLibrary（“DLLModuleName" ）載入，然後使用GetProcAddress（）得到函數指標，進而調用 2 直接將類、函數等匯出，客戶程式使用同一份標頭檔聲明，加入對應的lib連結庫，即可在客戶程式中直接使用DLL中的類或函數，無需 LoadLibrary。

　　"Process": 進程

　　進程是一個動態概念,包括從進程的建立申請,PCB (Process Control Block進程式控制制塊,一般作業系統實現為一個表格(struct))的建立,地址空間的記憶體配置,模組代碼載入並執行,執行完以後進行撤銷,整個過程被 稱為"進程"。在Win32下，一個進程有4G的邏輯空間。但我們也常把它作為靜態概念來使用，在Win32下，一個EXE的執行就是一個進程(如果它內 部又開了新進程，另當別論）。

　　"Thread": 線程

　　為了更有效提高CPU的利用率，更好地實現多任務並 發，微軟將進程進行進一步分割，實現了CPU任務調度的新對像：線程。一個進程擁有至少一個線程。我們在實現多任務並發的時候通常是建立一個新線程（建立 線程的系統開銷要小於進程），線程以我們自己的一個函數作為入口,函數執行完畢自動撤銷（當然你也可以在執行過程中強制結束該線程）。順便提一下，在 UNIX下並沒有線程這個概念，想來是因為UNIX主要是以多進程的並發服務為主（所以它更適合於做伺服器），系統運行時通常已經有了太多的進程，所以沒 有必要再對進程進行細化，因為這樣做甚至會降低系統效率（CPU調度不過來）,當然，這是我個人的猜想：）

　　"C語言"

　 　到目前為止，C語言應該是傳播最為廣泛的語言，特別在UNIX的世界裡依然扮演著主角的位置，在其餘如硬體開發，嵌入式系統（如手機）皆有十分突出的表 現，即便在win32平台下SDK的開發中也有一席之地。更主要的是它是大多數國內（國外我不敢說）程式員的啟蒙語言，通過它許多人才領會了程式的思維。 C最大的特點就是快，除了彙編以外效率可以達到最高，而它的靈活性，對硬體的直訪性也完全符合程式員自由的天性。如果說學習別的技術尚有猶豫和徘徊，那麼 學C只有一句話：相信我，沒錯的！也有許多人主張可以直接學習物件導向語言，我不太同意。物件導向語言對機器模型的抽象十分容易讓程式員迷糊，心中難以建 立準確的程式運行時的模型。畢竟我們是程式員，不是使用者，我們不能把所有的問題都想當然地交給編譯器和作業系統去解決，它們也解決不了。至少學習一門面向 過程的語言，才能知其所以然。

　　C++

　　這是貝爾實驗室的又一傑作，同時，也傷透了全球太多程式員的心,腦細胞殺傷 力十分之大。C++比大多數初學者想像的都要複雜得多，它基本包括：一個類化了的C語言，模板，標準模板庫.很多初學者掌握的C++僅僅只是一個類化了的 C語言的一個子集（不相信的話，你不妨看一看<<Modern C++ Design>>中的C++代碼，看看能理解多少）。更麻煩的是使用C++不得不談到物件導向的編程風格，這同樣比初學者想像的難很多，要有 打持久戰的準備。而最讓我這類C++愛好者憂心的還是它目前在Win平台中的前景,在.net平台上很難找出不用C#而使用C++寫新代碼的理由：（ 。而它的複雜性和目前許多諸如java/C#及一些動態語言(python/ruby)比起來，開發效率顯然的低，大有退出上層應用程式開發的趨勢。這麼 一個包含了最多範式的近乎完美的語言，我實在不想放棄。我唯有祈禱在未來C++的路可以走得更遠更好一些。

　　原始碼版本控制

　 　這是軟體開發中一個十分重要的工程手段，幾乎是必須的一個Process(過程)。很多作坊式的Team Dev在採用軟體工程的一些方法的時候，第一個要進行 改進或增加的，往往就是這個過程。對初學者學習而言，建議在開始進行實踐小項目的階段即進行原始碼版本控制，因為這在以後的工作中，是一定會用到的。

　　原始碼版本控制的基本原理如下：

　 　在伺服器端建立該項目的資料庫，並儲存你選定的項目源檔案的第一個版本。用戶端任一使用者要獲得某源檔案的修改權利，需進行check out操作。之後用戶端一般每完成一個無編譯錯誤的版本想儲存的時候，進行check in操作，將目前的版本儲存在伺服器端上並成為最新版本（注意，不是覆蓋以前的喲）。任一用戶端可以方便地得到伺服器上的檔案的任意版本（如果有許可權的 話）。一般還實現了一個重要的功能是版本比較，任一用戶端可以利用版本控制工具對某檔案的不同版本進行版本比較，它會標記出不同版本的同名檔案的不同點， 可以輕易地看出版本內容的演化，這一招很常用。 下面介紹一下我接觸過的三種版本控制工具（也是國內用得比較多的）：

　　VSS: Visual Sourcesafe

　 　這是微軟Visual Studio內建的原始碼版本控制工具，它最大的特點就是易安裝（與Visual Studio整合在一起，裝VC/VB的時候就順便搞定，不用別外費工夫），使用簡單（伺服器端設定相對容易，一般個人稍加摸索就可以輕鬆搞定，用戶端更 是只管check in/out），準系統完善，版本比較很直觀（我喜歡）。它的特點是某人check out了某版本以後，別人將無法對此版本check out,也就是說同一時間只有一個可以修改某一個檔案，這樣就避免了不同的人對同一檔案的修改造成彼此衝突（註：可通過設定伺服器端實現多人check out,但幾乎不會這樣做，因為那樣就失去了VSS的一個最重要的功能）。另，VSS可整合於VS環境，但根據我的經驗，直接在VC裡對版本的check 操作，常常不生效，所以最好還是到VSS程式裡去進行check操作。補充：單機上也可以使用VSS，這樣的好處是在對當前某些檔案進行了誤操作或大規模 地誤修改之後，可以恢複到最近的無錯誤的版本，最大程度地挽回損失。VSS實際應用較普遍，如果你是走Visual Studio路線的話，一定要用一下。

　　CVS: Concurrent Versions System

　　這個也 是一個大名鼎鼎的開源的版本控制工具，主要活躍在UNIX世界。CVS我使用不多，一般而言好像功能比較偏向於命令列方式（UNIX下開發很多人也都使用 著命令列方式）。當然，Windows下面也實現了幾個版本的CVS，也可以整合於VS，好像還有一個可以掛接在IE上的，我沒試過。著名的開源專案管理 網站sf.net也是用的CVS，如果你要和全世界的程式員一起協作開發，CVS是必須要安裝的。在JAVA的世界裡，也是以CVS為主。

　　Rational Clearcase

　 　這個工具就比較上檔次了，Rational公司(現在是IBM）的出品，價格昂貴。我最初參加工作的時候用過一小段時間，簡單談一下。這個工具的特點是 複雜，安裝及設定就十分複雜，我的印像中用戶端甚至不得不加入到NT域裡面去，導致我在原生許可權都不夠，安裝新程式都很麻煩，很鬱悶（不知道是不是我們 公司的相關人員安裝設定錯了，想來應該是這樣，但其複雜性可見一斑）。對使用而言，它有一個功能挺有用的，就是它能夠根據你每次check的版本號碼，自動 產生版本樹（一個樹狀圖表），你可以清晰地看到版本的演化過程。所以嚴格地說，像CVS/Clearcase這樣的才真正稱得上“版本”控制，VSS還太 勉強。Clearcase的功能十分強大，我不詳述了（我還不想出書），較適於大型軟體公司實施軟體組態管理時採用。雖然它的名氣十分之響亮，但我不知道 國內有多少公司在真正使用正版的Clearcase這樣的工具，想來應該是十分之少。

　　OpenGL

　　OpenGL至 今頗有一點英雄落寞的味道，這一套標準是實現得如此之好，以至於曾經一度成為遊戲介面華麗的標準。它的低落也是一個必然，畢竟在微軟的強力打壓下鮮有不挫 敗的。但它曾經能夠給微軟帶來如此的壓力，至今也依然在工業界被廣泛使用，大多數遊戲/顯卡依然保留著對它的支援（CS裡我喜歡的還是OpenGL)。而 它的效能在某些方面與D3D比較，依然佔著上風。不幸的是DirectX在不停地向前發展，而它，幾乎止步不前了，前景並不光明。OpenGL目前在工業 領域應用較為廣泛，它的優秀的向量圖的操作效能，華麗的色彩，在專業的圖形影像處理領域表現突出。遊戲中使用相對以前而言則是越來越少。新近聽說微軟的最 新作業系統Vista對OpenGL進行了極大的打壓，不但效能上折扣，支援的版本也只到1.4(最新版本好像是2.0)，不知道最後如何收場，拭目以 待。

　　DirectDraw & D3D

　　大凡像樣的2維Windows遊戲，幾乎都是採用此技術來實現顯 示的。DirectDraw有兩種模式：全屏和視窗。其中全屏應用更多一些。在全屏下，DirectDraw有一個十分著名的“換頁”技術，即在兩個顯示 頁面之間用“交換”來實現顯示重新整理，這個速度十分地快，只是一個顯存內一個指標的交換，比你用BitBlt複製一屏的像素快太多太多，遊戲的高效的動畫效 果大多源於此技術。DirectDraw主要用於娛樂領域和一些即時顯示要求較高的場合，如醫學映像。D3D是目前大多三維遊戲的標準採用，我沒鑽研過， 不敢多言。它的效果嘛，玩玩遊戲就知道了：）

　　UML:Unified Modeling Language，多譯為整合模組化語言

　 　這個語言是一種圖形語言，主要是作為設計時建模的一種標準的圖形模型，便於程式員與程式員、程式員與客戶、設計員與代碼員之間的溝通，同時它也協助設計 人員將頭腦中的基於程式碼的對程式功能的理解形成文檔，便於理清頭緒，進行下一步編碼的工作。換言之，設計過程的產品，可以表現為一些文字文件，或者一 些架構代碼，或者一些虛擬碼，但比較標準通用的，是表現為一堆UML圖。UML包括動態圖和靜態圖兩大類，其中靜態圖中的類圖最為常用。很多人初學時不知 道該怎麼做設計，寫小軟體時常常沒有設計過程，其實很簡單，把軟體的類圖畫出來就好了。學做設計時未必要找一個像Together或者Rational Rose一樣的巨無霸。用一些簡單的可以做UML圖的工具就好，專門用來畫UML圖的小工具很多,網上容易找。補充一點：畫UML圖不要面面俱到，不要什 麼都畫，突出重點方便理解就好，甚至使用不規範的記號也不要緊（當UML的功能是草稿的時候）。

　　RTTI: Runtime Type Information 運行時類型資訊

　 　在程式中，當我們得到某一個對象的執行個體或者指標時，大多數時候並不能直接肯定它的類型（都是繼承以及類型轉換惹的禍），這個時候，依靠VC4.0或更高 版本的編譯器提供的RTTI支援，調用庫函數typeid()即可在運行時擷取這個對象的“類型資訊”，在一些動態處理中“類型資訊”很重要,擷取了類型 資訊以後，你就可以有十分把握地調用該類型的相關操作，或者類型轉換，或動態產生。因其重要性，在JAVA和.net庫中藉助單根繼承和“虛擬機器”對此有 了更優雅的做法，每一個自object繼承的類天然就有了表述自己類型資訊的能力（繼承的好處），並且容易擴充，現在你需要類型資訊的時候，大可直接 ask那個對象：tell me, what type are you?它就會告訴你答案。

　　debug & release 調試 & 發行

　 　大家都知道，debug是調試版，release是發行版，區別在於debug版產生的程式中包含大量供調試用的情境代碼（不是真正運行需要的），而 release一般去掉了這些資訊，並進行了某些代碼最佳化，所以release版的程式會比debug版的程式小很多，運行速度也快一些。同時， debug版為了便於調試，往往會對調試使用的診斷代碼加上DEBUG一類的宏，使得在release下不對這些代碼進行編譯。正由於兩種版本編譯使用的 原始碼的差異（以及release糟糕的最佳化），常常使得兩種版本運行時產生截然不同的效果，一個正常一個崩潰是大多數人都遇到過的。導致問題的可能性很 多，注意事項詳見各論壇的諸多精華貼。另，同一個程式如果DLL之間的連結使用了不同版本（譬如EXE是release版，dll是debug版），有時 會無法正常運行，所以我一般的做法是每一個DLL針對不同版本使用兩個DEF檔案，編譯產生不同名的兩個檔案（debug版檔案名稱後加d)，調用時各個版 本針對自己的版本調用，這在一定程度上可避免混亂。另，release也是可調試的，在工程設定裡把調試資訊開啟即可。

　　XP:eXtreme Programming 極限編程

　　這是近幾年才時興起來的開發模型,國內大致是01/02年開始有所宣傳。

　 　它主要是針對中小型Team Dev在開發時間要求緊、需求不穩定的中小項目（大多數軟體項目都是這個情況）時使用。它打破了傳統軟體工程的架構，非常新巧。譬 如整個開發過程中文檔很少，大量使用“卡片 （如CRC卡片）”來描述開發計劃和內容；沒有真正意義上的軟體功能規格說明書，取而代之的是一系列可測試的用例；沒有獨立的設計和測試階段，它們總是在 迭代中增量反覆進行；設計：儘可能小和簡單；一般沒有代碼複審（code review),大家共同擁有代碼。而它的最顯著的一個外在特徵是它常使用“成對開發”，即一台機器前坐兩個開發人員，共同開發（一個看，一個寫），這乍 聽起來真是蠻有趣的：）,它的基本出發點是認為成對開發的效率在一定條件下要高於兩個人獨立開發的和。不要覺得天方夜譚，在很多項目中，這種做法的有效性已經被證實。

　 　XP的特點可以用“快、小、靈”來概括，它和傳統瀑布模型（自頂向下）的區別在於它使用迭代增量（設計->代碼->測試->設計- >代碼...)的方式。想法很簡單：沒有什麼目標是可以一開始就容易確定的。用爬山來做一下比喻的話，傳統的是在山下研究地圖，選好一條路線，然後 沿著此路前進，XP則是走一走，停一停，看一看，對下一步的方向作出新的選擇，在很多時候，這樣做會讓你選擇到更好的捷徑。

　　ICONIX:

　 　這個字相信很多人都沒見過，我也不知道是什麼字拼起來的，作為開拓眼界，我還是提一下吧。這是一種界於XP和RUP（Rational Unified Process)之間的開發模型，換言之，它比XP“大”，比“RUP”要小。它採用了UML的一個子集，特點是用例驅動，保持良好的進度跟蹤能力。它的 目標是用最短的時間來把用例變成代碼。具體來說，這種開發模型相對精簡的XP而言，更加強調用例的建立、分析和代碼化，用例是其中心地位。

　　RUP：Rational Unified Process

　 　前面已經提到了，相信你已經感覺出它是一個豐富的軟體開發模型。這是由IBM提出來的軟體工程模型，它使用完整的UML圖，對開發的各階段（需求、設 計、代碼、測試、維護）均有十分完善而複雜的標準，就不詳述了。RUP本質上是迭代式開發，在每一次迭代中均完成以下四個階段：初始階段 （inception)、詳述階段（elaboration）、構建階段（construction）、轉換階段（transition）。

　　CMM:Capability Maturity Model 軟體成熟度等級模型

　 　這是卡內基*梅隆大學軟體工程研究所（我的專業正是軟體工程，所以這也成為我心目中的聖地）的一大力作，一度曾形成了席捲全球軟體開發的CMM浪潮。 CMM分為五級，大多數軟體企業都處於第一級，而得到第五級認證的全球也沒有多少，國內去除掉掛羊頭賣狗肉的，也是寥若星辰（嗯，比星辰是寥多了）。所以 CMM實施一般是從第二級開始，能做到第三級的都是頗有實力的軟體公司了。CMM是以Process（過程）為中心的模型，從二級始每一級都有幾個Key Process(關鍵過程），每一個KP又分為若干Key Active(關鍵活動）。CMM的實施一般不能越級實施，並且每一級的實施通常都要一年以上，所以要達到較高等級是一級很困難的事。另，CMM不僅可用 於較大規模公司，同樣也可實施於小公司，小項目組（這是很多人所不知道的）。實施視具體情況等級之間可交叉，譬如實施時採用二級的某些KP再加上三級甚至 四級的KP，但你只有實施了所有二級的KP，你才能也只能通過二級認證，即便你採用了某些四級的KP。CMM最新發展成果是CMMI （Integration),這主要是新考慮了軟體與非純軟體因素的關係（譬如系統），以及團隊之間的協作問題。CMM在國內的發展似乎有點走向ISO同 樣的道路，這實在不是一個好訊息。

　　Callback Function: 回呼函數

　　在侯sir的< <深入淺出>>中一開始就提出了這個概念,大概的提法是說回呼函數是作業系統調用而你永遠不要去調用的函數。這個提法讓初學者有點望而 生畏，以為是一種多麼高深而難以領會的系統底層的核心技術。其實不然，這個技術本質很簡單，而且很常用。它實質就是函數指標的基本運用（如果不知道什麼是 函數指標的話，翻翻書）。在一個模組中，有時想讓一部分功能由其它模組實現，譬如說一個做顯示的模組，它只想實現顯示的資源配備，畫面的重新整理，縮放等控制 功能，而把畫具體實體（譬如圓、多邊形，都可以有很多種不同效率的實現方法）的代碼由別的模組來實現，怎麼辦呢？用函數指標。在自己的類中放一個畫圓的函 數指標，使用時由外部為這個函數指標賦值（其實就是指向了一個外部的函數），在自己的代碼中直接調用這個函數指標來畫就可以了（本模組完全不知道外部模組 是怎麼畫圓的）。那個外部的函數在這裡就是回呼函數！

　　在很多系統API中就使用了這種函數回調的方法，讓我們開發的代碼實現可以嵌入到API的代碼實現當中，其實我們就是傳了一個函數地址給它而已。換句話說，這些API搭好了某些啟動並執行代碼架構，我們來為它具體實現。

　　XML: Extensible Markup Language 可擴充標記語言

　 　也許你還在為選擇.net和j2ee而徘徊不前，如果是這樣的話，不妨先著手學一下它們所共通的一個基礎：XML。有了HTML為什麼我們還要XML？ 很簡單，HTML重在表現文本/圖片以及一些多媒體內容，它很難表達資料，因為它的標記是固定的，而資料類型千千萬，根本無法描述。.net和j2ee都 要解決一個資訊傳輸格式標準化的難題，這個格式要能承載文本/資料，最好還能描述程式介面，同時又應該像HTML一樣簡單，具有通用性，能夠在HTTP下 很好的運作。在這種要求下，XML產生了。它的特點正如其名，和HTTP一樣，它也是一種標記語言，但是它的標記不是固定的，是可自訂（也就可無限擴 展）的，這些自訂標籤能夠很好的描述資料類型以及對應的資料內容（乍看起來很像資料庫表的定義）。除此以外，XML還可以描述程式介面，所以XML可以 方便地與網路程式構件（COM、EJB等）直接互動。由於它也是一種ASCII文字資料流，所以與當前的HTTP相容，在當前的internet上暢通無阻 （這很重要）。有了以上功能，XML就名副其實地成為了新一代互連網技術的標準資訊載體，在.net和j2ee的網路架構中，各種“構件”的資訊互動都交 給了XML，可謂任重而道遠。

　　XML我自己沒怎麼寫過，單就學習上的經驗而言，感覺文法上比HTML更瑣碎一些，小細節更多，沒那麼容易速成：） 好在根本同源，有HTML基礎甚至WEB開發基礎的，學起來也很輕鬆。

　　Java2:

　　這是近幾年最吸引福士焦點的語言,在Web開發,網路平台,移動開發的 世界裡發光發熱。你可以不用java,但你不可以不瞭解java，畢竟這是一個極大且豐富的軟體開發領域。有些沒使用過java的VS陣營裡的人可能還不 明白java2裡的那個2是什麼意思，容我先解釋一下。Java最初正式推出1.0時，並沒有受到如此多的好評，受到頗多責難，於是它不斷地推出新版本來 完善自己，其中變化顯著的一個版本是1.2(我沒記錯吧），Java的每一個新版本除了文法上的更新，還有一明顯的標誌，那就是JDK（Java Development Kit,就是Java內建的一套SDK）的更新，版本1.2以後的java為了在宣傳上與以前的java相區別，便被稱為java2。目前用得比較多的 jdk是1.3/1.4 ,最新的JDK是1.5(代號tiger)。java開發的IDE國內主要以JBuilder為主，另外就是在開源領域如雷貫耳的Eclipse,而 sun也力推自己的開源java IDE：Netbeans（從sun的網站上可下載，免費）。Java運行是虛擬機器機制，相當於在作業系統上增加了一個軟作業系統，源碼被編譯成一種位元組 中間碼，由虛擬機器解釋執行，只要有對應的虛擬機器，java程式就可以在該作業系統上運行，這就是java號稱的一次編譯，到處啟動並執行由來。而附帶而來的不 可避免的效能問題也讓Java難以成為傳統型程式開發的主流。補充一下：對初學者學習而言最好的Java IDE我推薦使用JCreator,這是一個C++寫成的IDE，幾MB的大小，比Eclipse快十倍以上的啟動速度，對初學者帶來極大的便利。

　　J2EE:

　 　Java實際上又被分為3類：J2EE/J2SE/J2ME,不同類分別對應不同的JDK，J2EE針對企業平台開發，J2SE是標準版，J2ME針對 移動平台開發。J2EE現在實在是熱得燙手，我前不久翻了一下程式員早期的雜誌，發現在第一期創刊號裡（2001.1)已經有了j2EE方面的討論，現在 已經是2004.6了，你對它的認知又多了多少？J2EE不是一種單純的技術，而是一種體系架構以及組成該架構的諸多標準。企業平台開發和案頭/簡單 Web資料庫開發有很大的不同，它的程式規模往往很大（不是一個或者幾個EXE可以搞定的），用到的往往是海量的資料庫和海量的通訊，並且常常是不可中斷 的，這些特殊性都使得企業平台開發更多地去關注架構的問題。而我們寫一個熟悉的java用戶端程式，或者訊息處理中介軟體，又或者資料庫處理常式，都只是這 樣一個架構裡的一小部分。J2EE是很寵大的，所以請不要寫了幾個EJB(這是java世界裡的構件，概念上大概是類似於COM）的例子程式就感覺自己精 通j2EE。

　　J2EE中傳遞訊息時往往引入了一個被稱作訊息管理器的中介軟體，在伺服器端使用EJB的容器來管理和調用EJB。在 J2EE中一個重要的概念是Transaction(事務）處理，事務的概念最早廣泛應用於資料庫技術。這實際上是一個封裝了很多操作的單元，它的作用是 中間任何一個操作失敗，可以自動依次整體撤銷，所以一個transaction就是操作成功/失敗的最小單元，不存在一個transaction只成功了 部分操作的情況。
在企業服務平台開發中比較知名的有一個叫BEA公司（這是一家不錯的公司，應該知道它的名字），它的產品是Weblogic。

　　.net

　 　.net是微軟為下一個十年準備的技術，你呢？.net也是一種平台技術，而不是單一技術。它主要分為.net運行時平台（對應java的虛擬機器）和. net類庫（對應java的jdk)。目前只有Windows2003是天然整合了.net運行時平台的作業系統，所以如是你寫的.net程式想要在別的 作業系統上運行，該作業系統必須先安裝.net平台，這是一件蠻煩人的事，也是為什麼到目前為止，還沒有太多的人改用.net來寫程式（儘管可極大提高開 發效率）。希望Longhorn的出現可以扭轉這一現狀。那我們就終於可以和MFC這樣過時的架構類庫說再見了，一大快事。
.net採用了很多最 新的技術和思想，對走VS路線的人來說（特別是有COM概念的），學起來相對輕鬆且很過癮，前人推薦的“.net架構程式設計“和”.net本質論“都是 很好的書。當然，看它們之前你最好基本掌握一門.net語言，譬如C#，掌握語言對我們來說是最easy的。

　　聊了這麼多技術,下面讓我們來放鬆一下:)

　　公用密鑰: （也常被譯為公開密鑰）

　 　"密碼"已經是一個老少皆知的詞,想從銀行裡把錢取出來嗎?沒密碼可萬萬不行。不知從什麼時候開始，這麼一個軍事級的詞彙已經走進了千家萬戶,婦孺皆 知。不過知道“密鑰”這個詞的人就少多了，知道“公用密鑰”的人就更少了，不但知道而且瞭解其原理的人則少之又少，當然，如果你以前不清楚的話，那麼你即 將加入這少之又少的行列：）

　　long long ago,隨著軍事的日益發展，情報的重要性日益提高,如何獲得準確的情報成為軍事上的一大重點，伴隨而來的另一個問題則是如何盡量保證自己的情報在被敵人 截獲後（這總是無可避免的）敵人依然無法獲得該情報的資訊，防止情報外泄。不妨讓我們以今人的智慧來設身處地的想一想，有什麼好的解決方案……首先想到的 當然是用密文不要用明文，把明文按某種規則打亂為密文、或者讓明文與密文有某種一一對應的規則 ，這樣即使密文泄露，只要敵人不知道我的明文與密文之間轉換的規則，它將一無所獲。這是一種簡單且行之有效方法，即便到了近代一戰二戰中，還被廣泛使用 著，當然它的這個規則往往是動態，甚至可能相當複雜。然而這樣的方案在理論上有一個重大的缺陷，那就是你如何安全地傳遞“規則”？兩地之間要確保能互相 將密文變成明文，必須有共同的規則，那麼就至少需要"一次"安全地將“規則”從一地傳到另一地,這在理論上是無法保證的，所以整個的安全體系也就無法讓人 完全地放心，一旦規則泄露，對密文體系的打擊則是致命的。有沒有什麼更好的辦法呢？嗯，如果你以前沒有接觸過的話，我估計你是想不出了。解決的方法正是公 共密鑰體系。

　　讓我們再回頭來看一看我們是如何將明文變成密文的，最簡單的是將它重新打亂，或者進行某種線性或非線性 變換，立刻就讓人難以閱讀，但這也是最容易破譯的，因為這種自身的變換在數學上相對容易求解，在現在的電腦的協助下，通過一定量密文明文的統計分析，很 容易找到其變化的規則。進階一點的，可以再用一組密碼（可以是動態改變的，譬如隨日期而改變），讓明文與這組密碼進行某種組合變化，從而得到一組密文，這 樣，由於這個“組合變化”可能是非常複雜的一種數學變換，僅通過密文或者加上一定量的明文也很難找出這組密碼以及這個“組合變化”的規則。這就是目前絕大 多數加/解密的根本原理。而這裡的這組密碼，我們就把它稱作密鑰。

　　但是這隻是提高了獲得密文者的對密文的破譯難度，並沒有解決我們前 面提出的問題。現在就要來看看“共公（共開）”的含義了。在數學上有一種運算是單向的（在數學理論上截止目前為止），從一個方向算過去很簡單，但是它的逆 運算當缺少正向運算時加入的一些資訊時，就會變得幾乎不可能（譬如大素數的分解，分解是困難到幾乎不可能的，分解後的兩個數乘回去是簡單的，小學生就會， 這就是著名的RSA的原理）。這就構成了我們的“共公密鑰”的理論基礎。

　　具體使用如下：我們首先產生一對密鑰，一把稱為加密金鑰，一 把稱為解密密鑰，它們是相關但不相同的。加密時我們把明文與加密金鑰一起採取“無法復原”數學運算進行“組合變化”，形成密文，解密時把密文與解密密鑰一起 採取類似的運算進行解密，注意，這處因為加密金鑰與解密密鑰產生時即是相關連的，所以解密密鑰能夠完成這樣一個“逆運算”。同時，解密密鑰也可以用來加 密，相應的，加密密解也可以用來解“用解密祕密金鑰加密的密文”。具體使用的時候很簡單，把加密金鑰當作公用密鑰，分發給任何想要擷取的人，解密密鑰由自己妥 善保管作為私密金鑰。當擁有加密金鑰的人要傳遞密文給自己時，他只要使用自由擷取的我的公用密鑰來加密該明文即可，當然，他加密以後他自己也是不能解的，但是 傳到我手裡以後，我則可以用解密密鑰來解密，這樣就很好地解決了前面提出的無法安全傳輸“規則”的問題，現在我的公用密鑰是公開的，你要拿就拿去好了：） 而私密金鑰我自己好好儲存，不用把它放出來。

　　公用密鑰另一個重要作用就是用來簽名。我使用私密金鑰對自己的檔案加密後，你來使用我發放的公開金鑰來解密，如果解密成功，則可證明這的確是我發出來的檔案。

　　在現在網路資訊安全常常使用的認證體系中，“認證”的背後其實也是這樣的一種公用密鑰體系。