以compiler角度看待com及dcom-delphiktop讨论区.docVIP

以 Compiler 角度看待 COM 及 DCOM .tw/~nms9115/articles/delphi/CompilerViewCOM/CompilerView.htm 作者：吳明皓2002 年 8 月 16日星期五 關於 COM 及 DCOM，讀者在很多程式語言的書籍之中，找到介紹它們的撰寫方法，網路上也有很多的官方資料可以提供參考。所以我在這個地方並不打算介紹如何去寫它們，而是嘗試用 Compiler 的角度來詮釋一下什麼是 COM 及 DCOM。這篇文章在 1999 年 1 月曾發表在某家資訊公司的技術論壇之中，現在我重新整理後，再次發表於『點空間』網站，希望有興趣的人能藉此更了解 COM 及 DCOM 的運作方式。 一、Function 與 Main Code。 在絕大部分的程式語言中，都可以將程式碼拆解成主程式部分（Main Code），也就是所謂的程式進入點的那段程式碼部分，以及函數部分（Function 或 Procedure）。而拆解的目的在於模組化我們的程式，並藉此讓程式更為有條不紊，我們以 C 語言為例 Main {?? a = = GotEmployeeName(code: Integer); ???? 。。。。。 } ? function? GotEmployeeName(code: Integer) { ???? 。。。。 } 上面的程式碼一個常見的標準寫法，然而經過編譯器編譯之後載入記憶體中執行，它將會呈現類似以下的樣子，主程式碼與函數分別位於不同的記憶體位址中。 我們將上面的範例，部分換成機器碼的示意圖，如下所示，我們將可以發現，其實編譯器對於指令「a == GotEmployeeName(code: Integer);」的做法是將參數 code 放入堆疊中，然後程式跳躍至 F12D:FFFF 的位址之上，執行完畢後再將結果指派給變數 a。當然這邊所指的位址是相對位址，而不是實體的真實位址。(詳細的技術細節請參閱編譯器及作業系統等相關資料) 上面的範例我們可以看到函數與主程式之間，是位於同一個程式 Source Code 之中，然而在絕大部分的情況之下，這樣的模組化程度並不夠。因為首先當系統開始龐大的時候，Source Code 也會日趨龐大，再則龐大的 Source Code 會使得維護上發生困難，同時也使得編譯的過程中，耗費大量的時間。 二、靜態連結機制（Include）。 為了解決上個小節所描述的問題，在 C 的程式語言中，提供一個所謂靜態連結的方法，全名稱之為「Static Library Link」如下面的範例所示。這樣的做法是將所謂的常用且公用函數，獨立出來，到一個所謂函數庫的『*.h』檔案中，然後在主程式裡，只要利用 #include 的指令，編譯器就會在編譯的過程，到函數庫的『*.h』檔案中，找到相對應的函數程式碼，並且將之編譯到執行檔中。 #include io.h Main {??? printf(‘Hello World !!’); ???? 。。。 }; 下圖所示主程式與函數庫之間分別位於不同的檔案之中 下圖則表示雖然 Source Code 位於不同的檔案中，但是編譯完後，還是會將程式彙整到同一個執行檔中 那麼編譯器是如何在編譯的過程之中，從函數庫裡面搜尋相對應的程式碼呢？我們從下圖中可以窺之一二。這是 IO.h 檔案的結構，編譯器就是依照檔案中的 Function Table，以查表的方式找到相對應的程式碼的，這個概念非常重要，因為在後面的章節裡，我們都可以看到相類似的情形 在這個地方雖然省略掉許多編譯器詳細的編譯過程，但是我要強調的是，雖然在 Source Code 的部分，函數庫與主程式之間是分開的，也達成所謂 Source 分享的目的，但是所編譯出來的執行檔，還是包括了主程式與函數的部分，因此編譯所需要的時間，與前一小節所提到的是一模一樣的，所以如果程式很龐大的話，編譯起來依舊很費時。而且重點是，所謂的公用函式庫通常異動的機率很小，如果每次的編譯，都是要將之重新編譯過一次，實在不符合成本上的效益。 然而在 Delphi 中的靜態連結則又是如何做的呢？我們從下面的範例中觀察得到，其實就是利用『Uses』的指令來做的。而 Delphi 編譯器對於靜態連結的做法，除了使用者自訂的 Unit 單元與? C 語言相同外，其餘 Delphi 預設的 Unit 單元，如 Windows、 Messages等等，都是採Object Code 方式作連結的。不過這是另外一個話題，在這個地方讀者只要知道『靜態連結』是怎麼樣一回事就好了 unit ; interface uses ? Windows, Messages, SysUtils, Classes, Graphic