[轉貼]深入C++Builder探訪動態連結函式庫(dll)

tim · 文章由 **tim** » 2008年 11月 27日, 14:19

轉貼自:
http://www2.borland.com.tw/tw/td001018.html

深入C++Builder
探訪動態連結函式庫 (Dynamic Linking Libraries,DLLs)

蕭永哲 [email protected]

打Windows 從娘胎出生後，動態連結函式庫(Dynamic Linking Libraries,DLLs) 宛如這個新生兒的血液一般的重要，DLLs 一直扮演著Windows 的基石這個角色。到了Win32 雄霸一方的世紀，DLLs 的威風更是不減當年，幾乎所有的Win32 API 都以隱身在DLLs 中的形式存在，Windows 血液裡流的盡乎都是DLLs 。在Windows 下DLL 通常是以『副檔名為DLL 的檔案』存在，DLL 內可以包含提供外部呼叫的函式、資源（Resource ）以及各種的變數，當DLLs 被應用程式載入時這些DLLs 內含的資料都會變為應用程式所屬行程的一部份。我們可以把DLL 當成一個函式庫（Library ），但因為還要能夠被動態載入，這個函式庫自然比傳統的函式庫複雜些。

DLL 一二說

DLLs 的出現提供了程式設計師一個將程式模組化的方法，別於C++ 類別的建構時期模組化，DLL 乃是執行時期模組化，因此程式設計師可以在建構程式時將所需要用到的函式分門別類的製造成DLLs 的形式。但為什麼我們要使用DLLs 呢？DLLs 充其量不就你把程式碼、資源等獨立到另一個檔案裡頭去，到底有什麼好處值得我們大費周章地把部份程式寫成DLLs 的形式呢？使用DLL 的好處大致可以如下歸類：

1 、有效率的重複使用程式碼

當程式設計師所撰寫的程式碼一多起來，必然地會發現有很多程式碼是在做相同的事情，通常當程式設計師遇到這些重複的程式碼，最平常不過的方法就是把這些重複的程式碼大則獨立成『函式』（Function ）小則獨立成『巨集』（Marco ）。但是，當這些函式不單單只在單一應用程式內會用到，而是在撰寫許多應用程式時都得用到時，這些常用的函式通常就會被製作成函式庫來使用，例如C 語言的Runtime Library （RTL ）；但編譯器在編譯應用程式遇到函式庫時，會把這些隱身在函式庫裡頭的函式實體內容如同我們在程式裡頭撰寫這些函式的原始碼般地加進應用程式的執行檔中，也就是說當你所用的函式庫越多時，你的執行檔也就相對的會越來越龐大，這個做法也就是我們所謂的靜態連結（Static Linking ）。因此為了避免應用程式的過分龐大，有人提出了動態連結（Dynamic Linking ）的做法，所謂動態連結就是提供了一個做法讓我們不需要把應用程式的執行檔變得如此龐大，但一樣可以享用這些使用頻率高的函式。也就是說這些函式會在程式執行時才被載入，而不是直接編譯在執行檔中。這樣一來可以讓我們更有效率使用這些函式。但相對的，當你所撰寫的程式得交給他人使用時，你除了得把你所編譯好的EXE 檔交給他之外，還得一併把編譯好的DLLs 檔交給他，否則執行起來一定會產生不可預期的錯誤。

2 、區分程式碼

依據先前的第一點，若有朝一日發現這些被包裝在DLLs 之中的函式的實作方法有點錯誤或是發現有更好的做法時，需要更動僅只有部份的DLLs 原始碼，重新將修改過的DLLs 給編譯後就可以達成更新程式的目的，至於應用程式端連動都不需要動一下；當然了，前提是這些個修改過的函式名稱與傳入的參數型別宣告都不能夠更動。根據這些個特性，咱們可以把整個應用程式中的函式依照功能或目的分類，並將這些分類好的函式組合成許多個DLLs 模組，將執行檔給分割城數個小檔案，讓這些DLLs 模組分工合作來完成應用程式所要達到的目的。這樣一來，對於應用程式的維護以及更新就不需要大費周章地從頭再編譯一次了，僅需把要有修改到的DLLs 從新編譯就可以達成程式的更新。

3 、節省記憶體的使用量

先前提到：DLLs 的載入是在應用程式執行時才被載入，甚至還可以是可以在應用程式所需用到函式時才被載入。此外DLLs 還有一個很重要的特性：若不同的應用程式但需要相同的DLL 中的函式時，DLL 僅在第一個使用到DLL 的應用程式執行時載入，只要這個應用程式尚未結束而其他的應用程式又正好需要使用到同一DLL 中的函式時，DLL 不需要再重新被載入到記憶體中就可以供第一個應用程式以外需要用到DLL 的應用程式使用，一直到沒有任何應用程式使用這個DLL 時，DLL 才會跟著最後一個使用DLL 的應用程式一起從記憶體裡頭消失，因此使用DLLs 來包裝常用的函式是個不錯能夠節省記憶體與系統資源的做法。

4 、將程式推向國際舞台

DLL 在設計時，就已經被設計不只是能夠放入函式而已，還能夠被放入許多的資源（Resource ），如：可以放入選單資料、字串資料、圖形資料等等 … 。也因此DLL 很常被拿來作為應用程式邁向國際舞台的一個墊腳石。你可以在應用程式被執行時檢查執行應用程式的作業系統語言版本，之後把當地語言版本的Resource DLL 給載入，讓所有的文字及畫面都達到當地語言化的目的。而這個功能在C++Builder 3 當中經由Borland C++Builder 部門工程師的努力，已經幫我們把這些煩人的步驟給簡化了許多，我們僅須按下選單上的New 並選擇Resource DLL Wizard ，並將將需要更改的文字給更改成不同的語言，並不須在執行時檢查執行平台的語言為何。其餘煩瑣的工作都已經被Borland 工程師給完成了。我們最後只需要重新編譯這個Resource DLL 並附在應用程式中就可以完成一個國際化的應用程式了。

既然DLLs 在Windows 上頭是那麼的重要且使用DLLs 還有那麼多的好處，當然值得咱們來好好的了解一下。先來討論DLLs 的基本架構。

Import 還是Export ？

我們已經知道當DLL 被應用程式載入時，DLL 內所含有的資料都會成為應用程式所屬行程中的一部份，這到底怎麼辦到的？其實在DLL 被應用程式載入時，DLL 會被先設定一個基底位址（Base Address ），若這個基底位址並沒有和應用程式中的其他資源互相衝突，則這個DLL 檔會被映射到載入端行程內的相同位址上讓載入端應用。那DLL 中到底有多少資訊可以被載入呢？先看看圖一：

圖一是使用C++Builder 內附上的tdump.exe 工具列出一個DLL 檔內所有的Section ，tdump 是個非常好用的工具，之後使用次會不少，先說明用法，用法很簡單：

tdump inputfile outputfile

這樣就可以把inputfile 裡頭的資料給格式化輸出到outputfile 裡頭，當然了，你的inputfile 得是tdump 認得的檔案：DOS 下的執行檔、PE 格式執行檔（註1 ）、.OBJ 檔、.LIB 檔，其餘的檔案若為文字格式就直接輸出，而Binary 格式的檔案就以HEX Dump 格式輸出。此外，在Microsoft Visual C++ 裡頭的dumpbin.exe 也提供相同功能來分析這些檔案。

圖一中的這些Section 表示著： Section 包含意義
.text 應用程式或DLL 的程式碼這個section 包含了一般性的程式碼，就是先前提到的除了自己所撰寫的程式碼外還有Runtime Library 的程式碼。
.data 具有初始值的資料這個section 存放了在編譯時期就已經具有初始值的資料；包括了全域變數（global variable ）、靜態變數（static variable ）以及 ”Hello World ” 這一類字串等等 … 。
.tls 執行緒內部儲存空間 thread local storage
.idata 輸入名稱表這個section 包含了有『從其他DLLs 中輸入過來的函式與資料』的相關資訊。
.edata 輸出名稱表這個section 恰好與.idate 相反，是存放了由此EXE 或DLL 輸出給外頭使用的函式與資料的相關資訊。
.rsrc 資源若你使用過Microsoft Visual C++ 或是Borland Resoure Workshop 來觀察過EXE 或DLL ，你所看到的那些resource date 就是儲存在這個section 裡。也就是編譯器將應用程式所需要用到的resource date 都整理好一起放到這個section 裡頭。
.reloc 修正表資訊這個section 裡頭含有一個base relocationsg 是一個調整值，先前說過當 …. 會，但若無法載入到預設的位址，就會依據這個調整值來作調整。

除了了解這些section 之外，你還必須知道的另一個觀念是所謂的相對虛擬位址（Relative Virtual Address ，RVA) 。PE 格式執行檔中有許多資料的位址都是以RVA 表示。簡單的來說RVA 是某一項資料從檔案被映射進來的起點算起的偏移值（offset ）。舉個例子，我們說Windows 載入器把一個PE 格式執行檔檔映射到虛擬位址空間0x400000 處，如果在此執行檔中有一個函式的函式指標起始於0x40C000 ，那麼這個函式指標的RVA 就是0x C000 ：

虛擬位址（0x40C000 ） ─ 基底位址（0x400000 ） = RVA （0xC000 ）

只要把相對虛擬位址加上基底位址，相對虛擬位址就可以被轉換為一個有用的指標。『基底位址』(Base Address) 也是另一個重要名詞，通常基底位址是用來描述被映射到記憶體中的EXE 或DLL 的起始位址。

另外圖一中『Key to section flags 』是這些section 的屬性旗標種類，如：唯讀、共享或可寫入等等 … 每個section 的屬相可以從『Object table 』最後一欄的『Flag 』中看出。

了解這些基本知識後，再回頭詳細看一看在圖一中的輸出輸入section ，我們已經知道，製作DLL 的主要目的是製造一個模組化的函式或資料供其他的程式應用，而這種提供給其他EXE 和DLL 使用的方式就稱為輸出（export ），反之若取用其他的EXE 或DLL 中的函式，就稱為輸入。在DLL 中，你可以輸出任何想要輸出的資料，如函式、類別（class ）或是資源等等 … ，我們把重點放在輸出輸入函式的部份，我們先來觀察一般的輸出函式：

一樣可以使用先前提到的tdump 來觀察DLL 中的輸出表格，由圖二中可以看到輸出函式表格包含了Ordinal 、RVA 以及Name 三個欄位表示。Name 就是輸出的函式名稱而RVA ─ 相對虛擬位址在前頭已經介紹過了，至於Ordinal 則是輸出表格中輸出函式的序號。這些輸出函式透過這個表格上的函式名稱與函式序號讓外界認得。當載入端最初在載入DLL 時並不知道DLL 內的輸出函式的正確位址只知道函式的序號與名稱，但在動態連結的過程中會建立起一個連連看表格將載入端的函式呼叫與被載入端內的函式正確位址給連結起來。

那我們要怎樣才能夠達成輸出的動作，其實很簡單，你只要在你的應用程式中需要輸出的函式前頭加上：__declspec(dllexport) 即可，如：

__declspec(dllexport) void Function(void);

這樣一來就會把Function(void) 這個函式給放到輸出表格上頭了。

先前還有提到還可以將C++ 類別透過DLL 來輸出，可以的一樣是加上__declspec(dllexport) ，如：

class __declspec(dllexport) __stdcall MyClass : public TObject{ … …};

當我們在看輸出表格時，會發現函式的輸出表格前頭好像有個如圖三一般的資料：

這就是函式的輸入表格，這裡列出來的是USER32.DLL 裡頭被我們使用到的函式。一樣的怎樣建立輸入表格呢？一般的Win32 API 都已經在其所屬的Header File 裡頭定義好了，我們只需加上#include <windows.h> 就可以安心使用了，而對於自行打造的DLL 中的輸出函式我們在載用此DLL 的載入端就得在函式的宣告前面加上__declspec(dllimport) ，如：

__declspec(dllimport) void Function(void);

目的是告訴編譯器Function(void) 這個函式是由外部輸入的。

Name Mangling

嗯！經過了先前的說明，讀者們應該知道若要在DLLs 中將函式輸出，僅需要在函式的宣告中加上__declspec(dllexport) 即可，若要載入別的DLLs 中的函式則須在函式的宣告中加上__declspec(dllimport) ，但這僅止於C 編譯器，在C++ 編譯器裡頭是行不通的，怎麼說呢？就拿一個多載（overloading ）的例子來說，如果函式的名稱都相同（當然所傳的參數型別不同），編譯器應該會如何處理？到底那個才是我們真正使用到的函式呢？其實在編譯器做編譯動作時，對這些同名的函式都動了點手腳讓同名的函式偷偷地變成不同名稱，以下面同名的三個函式為例：

int Func(int X);

int Func(float X);

void Func(double *d);

使用C++Builder 3.0 所編譯出來的函式名稱為：（註2 ）

@Func$qf

@Func$qi

@Func$qpd

而使用Visual C++ 6.0 所編譯出來的函式名稱為：（註3 ）

?Func@@YAHH@Z

?Func@@YAHM@Z

?Func@@YAXPAN@Z

編譯器這個偷偷修改函式名稱的行為稱為『name mangling 』，但除了函式名稱被改變外你是否發現還現另一件很嚴重的事情，就是同的編譯器竟然有著不同的name mangling 做法，這表示著若咱們若使用Borland C++Builder 編譯器來開發應用程式時將無法使用一個經由Microsoft Visual C++ 所編譯器完成的函式庫。此外，Naming Mangling 的作用不止於多載的函式上，C++ 程式中所有的global 函式以及class 中所有的成員（members ）都會被name mangling 這個動作給整型一下。那這樣不就沒戲唱了！若要在C++Builder 下使用Visual C++ 所編譯的DLLs 豈不都得擁有DLLs 的原始碼才能囉？其實不然，有方法可抑制name mangling 的作用，就是在函式的宣告錢加上extern “C ” 這個修飾詞，強制將函式以C 語言的行台重現，而非以C++ 語言的形態出現。但是要注意，多載函式可不能加上extern ”C ” 這個修飾詞，因為這個會造成一堆名稱相同的函式，若你硬是要使用extern “C ” 在多載含上，編譯器一定會送你一個ERROR （如下）做獎品。

in C++Builder ：

[C++Error]Project1.cpp(13): Only one of s set of overloaded functions can be “C ”.

in Visual C++

error C2733 : Second C linkage of overloaded function ‘Func ’ not allowed

因此若拿原先多載的例子給加上extern “C ” ：

extern “C ” int Func(int X);

則會被編譯器給編譯成：

in Visual C++ ：

_Func

in C++Builder ：

_Func

似乎兩個編譯器已經達成了一致的輸出。嗯！這樣一來就可以把DLLs 互相使用了，不不不！還沒有那麼簡單，還有一個重要的議題『Call Conventions 』，不過這個問題在此先不提，放到後頭在提，先談談怎樣使用C++Builder 來建立DLLs 吧！

　

建立DLL

使用C++Builder 來建立DLL 並不是什麼難事，只需要按下幾下滑鼠的左鍵即可。在C++Builder 下建立DLLs 大致分成兩種方法，先按選單上的File|New 後會出現New Items 對話盒（Dialog ）（圖四）：

選擇New Items 對話盒中的Console Wizard 選項按下OK 後再選擇DLL 即可。（圖五）
選擇New Items 對話盒中的DLL 那個選項按下OK 即可。
方法一是建立一個標準的DLL Project ，不允許使用任何VCL 類別，而方法二所打造出來的DLL 則是可建立包含了VCL 類別的DLL （當然你也可以不使用VCL 類別），而這兩個功能在Visual C++ 中差可比擬的是Win32 Dynamic-Link Library 與MFC AppWizard(dll) 。
按完OK 或Finish 後你會看到DLL Project 與些許程式碼的產生，這段由C++Builder 自動產生的程式碼中分兩大部分，第一部份是個很長一串的註解，最後就是所謂的DLL 進入點。先來了解這一長串的註解，由方法一與方法二製造出來的DLL Project 註解有點不相同，不過內容大致上差不多，內容如是說：如果我們的DLL 內使用到了字串物件如：AnsiString ，或是在輸出函式的參數或回傳值使用到長字串的話，就必須加入MEMMGR.LIB 這個函式庫。另外，若我們在另一個模組（如DLL ）中使用了例如new 或GetMem 等方法來配置記憶體，而在不同的模組（如EXE 應用程式）中使用了這塊記憶體或呼叫FreeMem 等方法來釋放記憶體，則MEMMGR.LIB 也是必須被加入的。此外還有一個值得注意的，就是MEMMGR.LIB 必須加在所有要用到函式庫的最前頭，以便在其他函式庫之前優先載入並接手相關的記憶體維護。同時要記住的是若你使用了MEMMGR.LIB 這個函式庫，那麼當你移交DLL 或是應用程式時，你必須連同BORLNDMM.DLL 一併移交給使用者。不過在這段聲明的倒數第二段中有提到，若要避免額外的檔案付給使用者（越多的檔案對使用這來說是一種負擔），你可以將有關字串的資料改由char * 或是shortstring 來傳送，這樣可以不動用到BORLNDMM.DLL 與MEMMGR.LIB 來作記憶體的配置。另外，聲明的最後一段中有提到，若你在 ProjectOptions 裡頭的Link 一頁勾選了Use Dynamic RTL 一項時，就不須額外手動將MEMMGR.LIB 給加到Project 裡頭了，因為C++Builder 會自動幫你做這個動作。

緊接著咱們來看一下DLL 的進入點

DLL 的進入點：DLLMain

以下是由方法二生產出來的DLL 原始碼：

//---------------------------------------------------------------------------
#include <vcl.h>
#pragma hdrstop
//---------------------------------------------------------------------------
int WINAPI DllEntryPoint(HINSTANCE hinst, unsigned long reason, void*)
{
return 1;
}
//---------------------------------------------------------------------------
在Win32 平台的程式設計中，明言規定DLL 的進入點函式定義為DllMain ，可是我們怎麼看到的是DllEntryPoint 呢？這是Borland 對於標準的DLL 所動的一點點手腳，當然你若執意把DllEntryPoint 給改成DllMain 也是可以的，但是你要注意，當你更動DllEntryPoint 時，C++Builder 工具列上頭的Run 會被Disable 喔！這是就是擺明了不給你編譯，即使你使用ProjectBuild All 也會送給你錯誤訊息，不過你可以在DllMain 函式之後加上#define WinMain 就可以編譯了，不過筆者並不建議在C++Builder 下這麼用。
早在討論輸入輸出表時就已經知道若不考慮到各個編譯器間DLL 的互相引用，我們大可把輸出函式這麼寫：

__declspec(dllexport) int MyFunc (void);

若要輸出整個類別則可以這樣寫：

class __declspec(dllexport) MyClass : public TObject{...};

但是注意，這若這樣寫僅可以在自己寫作DLL 的編譯器中來使用這個DLL 了，並沒辦法達到其他編譯器也可以使用的目的，大大的抹殺了軟體元件的構想，更何況DLL 是採用模組化的設計。當然了！類別的輸出當然不在考慮範圍內，但若對函式的輸出咱們還是乖一點，加上extern “C ” 來遏止name mangling 對我們函式名稱所動的手腳：

extern “C ” __declspec(dllexport) int MyFunc (void);

有了這些基礎知識後，咱們來來真正撰寫一個有用的DLL 試試看吧！那要做些什麼呢？咱們就做個簡單的訊息視窗即可，怎麼做，其實說穿了就是把Windows API MessageBox 給稍微包裝一下，不過還是用MessageBox 這個函式來實作內容，讀者們可能覺得，這麼無聊還在包裝一次MessageBox 函式幹嘛？這個嘛！不過做個測試嘛！

先使用Consol Wizard 來產生DLL Project ，並將此Project 儲存為ShowMsg.bpr ，在DLL 的進入點DllEntryPoint 之後加上以下的程式碼：

extern “C ” __declspec(dllexport) int ShowMsg(char *pText,HWND hWnd)
{
return MessageBox(hWnd,pText,"Information",MB_OK);
}
嗯！這樣一來咱們只要呼叫ShowMsg() 函式，並將要秀出來的文字與視窗代碼當作參數來傳即可。緊接著只需按下Ctrl+F9 就開始編譯了並產生出ShowMsg.dll 了。
使用DLLs 中的函式 ─DLLs 的載入

知道了怎樣建立起一個DLL 後，接著就是了解如何使用DLL 裡頭所提供的函式的時候了，在使用這些函式之前還必須做個更重要的動作，就是將DLL 給載入。載入DLLs 的方法大致上可以分成兩個：

Implicit Linking 與Explicit Linking 。

Implicit Linking

Implicitly Link （隱式聯結）又稱靜態載入，所謂靜態載入是指程式在聯結時期即與DLLs 所對應的import libraries 做靜態鏈結，於是可執行檔中便對所有的DLL 函式都有一份重定位表格(relocation table) 和待修正記錄(fixup record) 。當程式被Windows 載入器載入記憶體中，載入器會自動修正所有的fixup records ，而這個fixup records 就是記錄由DLL 中所有輸出資源的正確位址，也就是先前提到的RVA 加上DLL 被載入的基底位址，經過這樣的程序動態聯結便順利產生。也就是說，程式開始執行時，會用靜態載入方式所使用到的DLLs 都載入到行程的記憶體裡。先來看看靜態載入放是的優點：

1 、靜態載入方式所使用到的這個DLL 會在應用程式執行時載入，然後就可以呼叫出所有由DLL 中匯出的函式，就好像是包含在程式中一般。

2 、動作較為簡單，載入的方法由編譯器負責處理，咱們不須動腦筋。
而缺點是：

1 、當這個程式靜態載入方式所使用到的這個DLL 不存在時，這個程式在開始時就出現無法找到DLL 的訊息而導致應用程式無執行。

2 、編譯時需要加入額外的import library 。

3 、若是要載入的DLLs 一多，載入應用程式的速度會便慢。

4 、若遇到不同品牌的C++ 編譯器時，靜態載入可就沒有這麼簡單處理了，因為當函式經過Calling Conventions 的處理後，若要使用其他品牌編譯器所致造出的DLL 須得大動干戈才行。
Implicit Linking 範例：

以先前建立的ShowMsg.DLL 為例子，我們已知這個DLL 僅輸出一個函式：ShowMsg ，且知道這個函式的原始定義：

extern “C ” __declspec(dllexport) int ShowMsg(char *pText,HWND hWnd);

因此，若我們要載入這個函式則必須在應用程式中加入此輸入函式的宣告：

extern “C ” __declspec(dllimport) int ShowMsg(char *pText,HWND hWnd);

此外，還要加上這個DLL 的import library File ，要產生import library 的方法有兩個：

1 、ProjectOptions 的Linker 中的Geretate import library 勾選，在正常情況下，預設值是勾選起來的。

2 、若不小心把lib 檔案給刪除掉了，也可以利用implib.exe 這個C++Builder 所附上的工具來產生lib 檔，implib 是文字模式下的程式，因此必須到文字模式下使用，以我們現在的例子來說，使用方式為：implib ShowMsg.lib ShowMsg.dll ，這樣就會產生ShowMsg.lib 檔了。
緊接著就是加入這個lib 檔到咱們的Project 裡頭，可以使用【ProjectAdd to Project … 】來加入lib 檔。如此一來就可以在應用程式的任何地方使用ShowMsg 函式了。

不過在此我們發現一個小問題，若每次要匯入DLL 裡頭的函式，還必須把函式的原始定義給抄過來（雖然說複製 ─ 貼上這個動作很簡單），但有沒有更好的辦法呢？有的，咱們可以在DLL 原始碼的Header File 裡動點手腳，讓要使用DLL 的應用程式只需include 這個Header File 就可以了，怎麼做呢？就是使用前置處理符號，若是使用Borland C++ 或是Borland C++Builder 來編譯DLL 都必須加上#define __DLL__ 這個宣告，但是我們從C++Builder 所幫我建立的Project 裡面看不到這個，原因是C++Builder 已經在Make file 裡幫我們加上-WD 這個編譯參數來達成#define __DLL__ 所要的目的了。所以我們可以把ShowMsg.h 給改成：

程式列表一、ShowMsg.h

//---------------------------------------------------------------------------
#ifndef ShowMsgH
#define ShowMsgH
//---------------------------------------------------------------------------
#ifdef __DLL__
#define DLLAPI extern "C" __declspec(dllexport)
#else
#define DLLAPI extern "C" __declspec(dllimport)
#endif
DLLAPI int ShowMsg(char *pText,HWND hWnd);
#endif
程式列表二、ShowMsg.cpp
#include <windows.h>
#pragma hdrstop
#include <condefs.h>
USEFILE("ShowMsg.h");
//---------------------------------------------------------------------------
#pragma argsused
int WINAPI DllEntryPoint(HINSTANCE hinst, unsigned long reason, void*)
{
return 1;
}
//---------------------------------------------------------------------------
int ShowMsg(char *pText,HWND hWnd)
{
return MessageBox(hWnd,pText,"Information",MB_OK);
}
這樣一來，只需要在應用程式裡加入這個Header File 並將ShowMsg.lib 檔給加入這個Project 裡頭，就大功告成了
Explicit Linking

而所謂Explicitly link （顯式聯結）又稱動態載入，若是使用動態載入就是需要時才載入DLL ，然後在使用過後即釋放DLL ，嗯！似乎是很不錯的選擇，這種方法的優點有：

1 、DLL 只要需要時才會載入到記憶體中，可以更有效的使用記憶體。

2 、應用程式載入的速度較使用隱式鏈結時快，因為當程式開始載入時並不需要把DLL 給載入到行程中。

3 、編譯時不須額外的import library 檔。

4 、讓我們可以更清楚DLL 的載入流程。
但不光只有優點也是點缺點的，缺點就是必須寫多一點程式碼。首先，必須使用LoadLibrary 這個Windows API 來手動載入DLL ，並使用GetProcessAddress 來取得所要使用的函式的函式指標，最後不需要用到此DLL 時使用FreeLibrary 將DLL 釋放。所以，在學會動態載入DLL 時，必須先知道函式指標的用法。

Explicit Linking 範例：

咱們就拿一個常見的DLL ─ 控制TWAIN32 界面的DLL ：『Eztw32.dll 』來作動態載入的示範：

eztw32.dll 裡頭有四十多個輸出函式可以使用，不過只有以下這四個函式是我們所要用到的：

1 、void __stdcall TWAIN_SelectImageSource(HWND hwnd);

功能：用來選擇所要使用的TWAIN 介面裝置

2 、int __stdcall TWAIN_AcquireToClipboard(HWND hwnd, unsigned int pixmask);

功能：經由TWAIN 介面將資料置放到剪貼簿中

3 、int __stdcall TWAIN_LoadSourceManager(void);

功能：呼叫TWAIN 介面裝置程式

4 、int __stdcall TWAIN_UnloadSourceManager(void);

功能：關閉TWAIN 介面裝置程式

再度使用tdump 來觀察eztw32.dll 裡頭的輸出函式表：

Exports from EZTW32.dll

50 exported name(s), 50 export addresse(s). Ordinal base is 1.

Ordinal RVA Name

------- -------- ----

0000 00001000 DllMain

...

0003 000012c0 TWAIN_AcquireToClipboard

...

0029 00001650 TWAIN_LoadSourceManager

...

0038 000010a0 TWAIN_SelectImageSource

...

0046 00001980 TWAIN_UnloadSourceManager

...

先確認函式的名稱以及函式的序號，等一下會用到。

接著就是開始將DLL 載入了，Win32 API 有兩個函式提供了將DLL 載入的功能，分別是LoadLibrary 與LoadLibraryEx 。通常都使用LoadLibrary ，先看看LoadLibrary 的原始定義：

HINSTANCE LoadLibrary(

LPCTSTR lpLibFileName // address of filename of executable module

);

嗯！只需要傳入檔案名稱即可，若以我們所要使用的Eztw32.dll 為例：

HINSTANCE hDLL;

hDll = LoadLibrary( “Eztw32.dll ”);

若我們沒有指定副檔名，則自動會以『.DLL 』為副檔名，或許會感到納悶，那我還沒有指定DLL 的路徑啊！正確的做法應該是要指定路徑的，但是天曉得使用者會把DLL 給放到哪裡去呢？所以使用LoadLibrary 這個函式時，若參數中沒有指明路徑，系統會依特定的次序來找尋DLL 的存在與否，若不存在則LoadLibrary 函式則會回傳NULL ，以下就是搜尋次序：

1 、被執行的應用程式所存在的路徑。

2 、目前的目錄。

3 、Windows 系統目錄，對Windows 95/98 說是WindowsSystem ，而Windows NT 則是WinntSystem32 。目錄名稱可以使用GetSystemDirectory 這個API 來取得。

4 、Windows 目錄。目錄名稱可以使用GetWindowsDirectory 這個API 來取得。

5 、最後由設定的PATH 環境變數來尋找。
這也就是為什麼我們的WindowsSystem 目錄下有這麼多DLL 的原因之一了。

把DLL 載入記憶體後最重要的工作就是把函式指標指向函式在記憶體中正確的位址，要做到這個動作得透過GetProcAddress 這個API 來幫忙：

FARPROC GetProcAddress(

HMODULE hModule, // handle to DLL module

LPCSTR lpProcName // name of function

);

GetProcAddres 函式的第一個參數是經由LoadLibrary 所取得的DLL 的Handle ，而第二個參數是函式的名稱或是函式的輸出序號經由函式名稱取得函式的指標，以eztw32.dll 中的TWAIN_SelectImageSource 函式為例，應由函式名稱取得函式的位址的方法為：：

GetProcAddress(hDLL, ”TWAIN_SelectImageSource ”);

若經由函式輸出序號取得函式的位址則為：

GetProcAddress(hDLL, MAKEINTRESOURCE (39));

在此要注意序號的起始值是1 不是0 ，經由 tdump 所列出來的Ordinal 是由起始值開始的位移植，而Ordinal Base 為1 ，因此TWAIN_SelectImageSource 的序號是39 而不是 38 。

接著在此先複習一下函式指標的使用方式，一樣TWAIN_SelectImageSource 函式為例，TWAIN_SelectImageSource 函式的原始定義為：

void __stdcall TWAIN_SelectImageSource(HWND hwnd);

那就可以用：

void (__stdcall *TWAIN_SelectImageSource)(HWND hwnd);

來宣告TWAIN_SelectImageSource 為一個函式指標，之後再用：

TWAIN_SelectImageSource = (void (__stdcall *)(HWND hwnd))

GetProcAddress(hDLL, ”TWAIN_SelectImageSource ”);
來取得函式的位址，之後就在程式中若要使用TWAIN_SelectImageSource 這個函式就可以像是靜態載入般使用了。但這樣似乎得打蠻多字的，偷懶的我通常都使用另一個方法，就是使用typedef 來自訂型別。方法如下：

typedef void (__stdcall *_TWAIN_SelectImageSource)(HWND hwnd);

_TWA IN_SelectImageSource TWAIN_SelectImageSource;

TWAIN_SelectImageSource = (_TWAIN_SelectImageSource)

GetProcAddress(hDLL, ”TWAIN_SelectImageSource ”);

先使用typedef 把_TWAIN_SelectImageSource 給定義成一個特殊的型別，之後就可以直接引用，的確是可以少打點字。

最後當DLL 裡頭的函式不再需要使用時，咱們就得使用FreeLibrary 將DLL 從記憶體裡頭卸下來：

BOOL FreeLibrary(

HMODULE hLibModule // handle to loaded library module

);

使用方法很簡單只需將LoadLibrary 所傳回來的DLL Handle 當參數傳給FreeLibrary 傳入即可。

懂得這些動態載入DLL 的流程後，就可以實際動手來做做看。筆者發現TWAIN32 這些功能實在很適合包裝成一個物件，當物件誕生時，立即自動去LoadLibrary 並將函式指標的位址給連結起來，當這個物件被摧毀時，就自動去FreeLibrary ，嗯！似乎不錯，不過詳細的做法就不多做解釋了，相信讀者看了下面的程式列表應該就懂了。

程式列表三、CTWAIN.h ：

//---------------------------------------------------------------------------
#ifndef CTWAINH
#define CTWAINH
#include <clipbrd.hpp>
//---------------------------------------------------------------------------
// 用typedef 自訂函式指標的型別
typedef int (__stdcall *_TWAIN_AcquireToClipboard)
(HWND hwnd, unsigned int pixmask);
typedef int (__stdcall *_TWAIN_LoadSourceManager)
(void);
typedef void (__stdcall *_TWAIN_SelectImageSource)
(HWND hwnd);
typedef int (__stdcall *_TWAIN_UnloadSourceManager)
(void);
class CTWAIN
{
public:
__fastcall CTWAIN(void);
__fastcall ~CTWAIN(void);
void __fastcall SelectImageSource(HWND hWnd);// 選擇TWAIN32 設備
void __fastcall Acqure(HWND hWnd);// 經由TWAIN32 設備取得資料
Graphics::TPicture *Picture;
protected:
private:
// 宣告函式指標
_TWAIN_AcquireToClipboard TWAIN_AcquireToClipboard;
_TWAIN_LoadSourceManager TWAIN_LoadSourceManager;
_TWAIN_SelectImageSource TWAIN_SelectImageSource;
_TWAIN_UnloadSourceManager TWAIN_UnloadSourceManager;
HINSTANCE hDLL;
};
//---------------------------------------------------------------------------
extern bool __stdcall CheckTWAINDLL();// 檢驗DLL 檔案是否存在的函式
#endif
程式列表四、CTWAIN.cpp ：
//---------------------------------------------------------------------------
#include <vcl.h>
#pragma hdrstop
#include "CTWAIN.h"
//---------------------------------------------------------------------------
#pragma package(smart_init)
__fastcall CTWAIN::CTWAIN()
{
hDLL = ::LoadLibrary("Eztw32.dll");// 載入DLL 到行程的記憶體內
// 取得所需函式的函式指標
TWAIN_AcquireToClipboard = (_TWAIN_AcquireToClipboard)
::GetProcAddress(hDLL,"TWAIN_AcquireToClipboard");
TWAIN_LoadSourceManager = (_TWAIN_LoadSourceManager)
::GetProcAddress(hDLL,"TWAIN_LoadSourceManager");
TWAIN_SelectImageSource = (_TWAIN_SelectImageSource)
::GetProcAddress(hDLL,"TWAIN_SelectImageSource");
TWAIN_UnloadSourceManager = (_TWAIN_UnloadSourceManager)
::GetProcAddress(hDLL,"TWAIN_UnloadSourceManager");
Picture = new Graphics::TPicture;
}
//---------------------------------------------------------------------------
__fastcall CTWAIN::~CTWAIN()
{
delete Picture;
::FreeLibrary(hDLL);// 從記憶體中釋放DLL
}
//---------------------------------------------------------------------------
void __fastcall CTWAIN::SelectImageSource(HWND hWnd)// 選擇TWAIN32 設備
{
TWAIN_SelectImageSource(hWnd);
// 使用DLL 裡頭的TWAIN_SelectImageSource 函式
}
//---------------------------------------------------------------------------
void __fastcall CTWAIN::Acqure(HWND hWnd)// 經由TWAIN32 設備取得資料
{
if (TWAIN_LoadSourceManager() > 0)
// 使用DLL 裡頭的TWAIN_LoadSourceManager 函式
{
if (TWAIN_AcquireToClipboard(hWnd,0)>0)
// 使用DLL 裡頭的TWAIN_AcquireToClipboard 函式
{
Clipboard()->Open();
if (Clipboard()->Hasformat(CF_PICTURE))
Picture->Assign(Clipboard());
Clipboard()->Clear();
Clipboard()->Close();
}
TWAIN_UnloadSourceManager();
// 使用DLL 裡頭的TWAIN_UnloadSourceManager 函式
}
}
//---------------------------------------------------------------------------
bool __stdcall CheckTWAINDLL()// 檢驗DLL 檔案是否存在的函式
{
HANDLE hDll = ::LoadLibrary("EZTW32.DLL");
if(hDll == NULL)
{
::MessageDlg("Error! Could not found EZTWtw32.dll",
mtInformation,TMsgDlgButtons()<<mbOK, 0);
return false;
}
::FreeLibrary(hDll);
return true;
}
//---------------------------------------------------------------------------
當建構好這個CTWAIN 類別後，若我們要使用這剛剛建好的類別，我們可以寫成兩個函式：
1 、void SelectSource(HWND hWnd);

選擇TWAIN32 設備的來源

2 、void Acquire(HWND hWnd);

經由選定的TWAIN32 設備來源將資料取得

//---------------------------------------------------------------------------
void SelectSource(HWND hWnd)// 選擇TWAIN32 設備的來源
{
if (CheckTWAINDLL())
{
CTWAIN TWAIN;
TWAIN.SelectImageSource(hWnd);
}
}
//---------------------------------------------------------------------------
void Acquire(HWND hWnd)// 經由選定的TWAIN32 設備來源將資料取得
{
if (CheckTWAINDLL())
{
CTWAIN TWAIN;
TWAIN.AcqureScanner(hWnd);
if (TWAIN.Picture->Graphic != NULL)
{
//Do the processing that you want to do with the TWAIN.Picture
TWAIN.Picture->Graphic = NULL;
}
}
}
//---------------------------------------------------------------------------
相形之下，似乎靜態載入的方式方便多了，不用下這麼多工夫在手動載入DLL 並手動分派各函式的實際位址，若遇到一大堆輸出函式豈不光Keyin GetProcAddress 那一段就得花上許多時間。但若用到不同品牌的C++ 編譯器所產生的DLL 時，採用動態載入加上以函式輸出序號來取得函式指標的方式，僅需利用TDUMP 製造初一張序號表再加上勤勞的打字即可無須再動什麼腦筋。稍後會提到怎麼樣在C++Builder 下使用靜態載入來載入Visual C++ 所編譯出來的DLL 。這樣相形之下，反而又會覺得用動態載入方便些。
Calling Conventions

因為不同的語言間有不同的傳遞參數的方法，而C/C++ 編譯器為了能夠使用由其他語言開發出來的函式庫加上了這些參數傳遞方式不同的方式稱為calling conventions （呼叫慣例），如在C++Builder 裡頭常常看到的__fastcall ；一般常用的呼叫慣例有以下四種：
呼叫慣例說明參數傳遞方式
__cdecl 傳遞的參數由呼叫函式清除。由右往左的次序將參數傳遞到堆疊之中。
__stdcall 傳遞的參數由被呼叫函式清除。一般使用於Win32 的標準呼叫，在DLLs 間的呼叫大部分都使用__stdcall 。由右往左的次序將參數傳遞到堆疊之中。
__fastcall 傳遞的參數由被呼叫函式清除。在C++Builder 中__fastcall 為VCL 元件使用的內定呼叫慣例。 in C++Builder ：
由左往右的次序傳遞參數，第一個參數由EAX 傳遞，第二個由EDX 傳遞，第二個由ECX 傳遞，其餘操超過的參數再交由堆疊傳遞。

in Visual C++ ：

由左往右的次序傳遞參數，第一個參數由ECX 傳遞，第二個由EDX 傳遞，其餘操超過的參數再交由堆疊傳遞。

__pascal 傳遞的參數由被呼叫函式清除，在Windows 3.1 時期__pascall 為標準用法，但到了Windows 95/NT 後以鮮少使用。由左往右的次序將參數傳遞到堆疊之中。Visual C++ 已經不支援__pascal 此呼叫方式。因此在此不做__pascal 的討論。

但光是說說很難了解到這些參數傳遞方式有何異同，以下函式分別使用__cdecl 、__stdcall 與__fastcall 三種呼叫慣例當做範例：

void calltype MyFunc(char c, shorty s, int i , double f);

當我使用這個函式：

MyFunc( “x ”,12,8192,2.7183);

時會被編譯器編譯成如以下四圖：

　

由圖八與圖九中可以看出__fastcall 在兩個編譯器中有顯著的不同，C++Builder 使用了三個暫存器來存放參數，讓傳遞的速度更為加快，這也就是VCL 類別中的預設呼叫慣例為__fastcall 的原因。暫且撇開__fastcall 的不同，呼叫慣例造成的還不只這一樣差異，還有著與name mangling 有點類似的麻煩，就是函式的名稱更動問題。當你使用不同的呼叫慣例時，編譯器還是對動點手腳，動什麼手腳，筆者用以下的範例做觀察，先定義四個函式分別使用__fastcall 、__stdcall 與__cdecl 與不指定四種呼叫慣例：

#define DLLEXP extern "C" __declspec(dllexport)
DLLEXP int MyFunc_Default(char *c,int X)
{
return X;
}
DLLEXP int __fastcall MyFunc_Fast(char *c,int X)
{
return X;
}
DLLEXP int __stdcall MyFunc_Std(char *c,int X)
{
return X;
}
DLLEXP int __cdecl MyFunc_Cdecl(char *c,int X)
{
return X;
}
定義好後分別使用C++Builder 與Visual C++ 將這四個函式編譯成DLL 檔，編譯完成後使用tdump 與impdef 來觀察這些函式的輸出結果：（IMPDEF 的用法為 IMPDEF def_file dll_file ）
）

　

經由上述簡單的實驗可以將兩者的差異列出，並且可以找出編譯器預設的呼叫慣例：呼叫慣例原始函式 Borland C++Builder Microsoft Visual C++
__cdecl MyFunc_cdcel _MyFunc_cdcel MyFunc_cdcel
__stdcall MyFunc_std MyFunc_std _MyFunc_std@8
__fastcall MyFunc_fast @MyFunc_fast @MyFunc_fast@8
─ MyFunc_default _MyFunc_default MyFunc_default
預設呼叫慣例 ─ __cdecl __cdecl

由表上可以看出兩者間的差異還不少呢！而為什麼要討論到這一點呢？因為接著就要討論到如何拿Visual C++ 所編譯的DLL 到C++Builder 裡頭使用。

在Borland C++Builder 下使用Microsoft Visual C++ 所編譯的DLLs

若已經解決了name mangling 與calling convention 的理想狀況下，由C++Builder 下來呼叫Visual C++ 所編譯出來的DLLs 應該不是難事才對。但不幸的，只對了一半，怎麼說，幸運的那一半是，咱們可以利用先前提過的『動態載入』方式來載入DLLs 中的函式，即使因為calling convention 的問題導致函式名稱在編譯後會被更動，但是只要知道函式的輸出序號就可以照樣載入；不幸的那一半是若採用『靜態載入』的方法就又會遇上了個大難題：Borland 與Microsoft 所使用的OBJs 檔案格式不相同；Borland 採用Intel 所訂定的OMF （Object Module format ）格式而Microsoft 採用COFF （Common Object File format ）格式，因此若要拿Visual C++ 所編譯的DLLs 與LIBs 來使用，僅有DLLs 能夠用而已，LIBs 毫無用武之地，但謝天謝地，Borland 提供了一個工具IMPLIB.EXE ，可以直接從任何編譯器所編譯出的DLLs 裡頭將OMF 格式的LIBs 給製造出來。因此製造C++Builder 相容的OMF 格式LIBs 不算是個大問題了。但對於Calling Convention 所產生的問題就比較麻煩些，接下來咱們就來討論如何使用靜態載入來載入Visual C++ 所製造出來的DLLs 。

要將Visual C++ 所製造出了DLLs 搬到C++Builder 來用大致上分三個步驟：

A 、檢驗輸出函式的設呼叫慣例

由先前呼叫慣例的實驗裡看得出來，兩種編譯器的預設呼叫慣例皆為__cdecl ，而__cdecl 與__stdcall 的參數傳遞方式兩個編譯器也相同，但是在C++Builder 下__fastcall 為VCL 的標準呼叫慣例，而且為了加速參數的傳遞，參數傳遞的方法與Visual C++ 不同，若是硬搬到C++Builder 來使用，恐有問題出現；因此若要拿Visual C++ 所編譯的DLL 來使用，切記只能使用__cdecl 與__stdcall 這兩種呼叫慣例。

B 、查驗經過編譯器編譯後的函式名稱

由呼叫慣例的實驗結果裡看出，__cdecl 與__stdcall 在兩個編譯器下所編譯出的正式名稱稍有不同，以一個簡單的 void MyFunction(void); 為例：

呼叫慣例 Borland C++Builder Microsoft Visual C++
__cdecl _MyFunction MyFunction
__stdcall MyFunction _MyFunction@4

我們必須檢查看看哪些函式是使用__stdcall 而哪些函式是使用__cdecl ，接下來下一個步驟就是轉換這些名稱，將名稱由C++Builder 不認得變成認得。

C 、製作OMF 格式的LIBs

由於經過編譯器處理過後的函式名稱已經與原先函式名稱不相同了，因此若直接轉換成LIBs 檔也無啥效用，必須動點手腳。先前已經學過IMPDEF 的使用方法，先前是用在觀察輸出函式，現在也是，但還多了動手腳的部份。

利用先前測試的那個VC6TEST.DLL 來製造DEF 檔案：（__fastcall 的呼叫慣例部份記得要先除去）

IMPDEF VC6TEST.DEF VC6TEST.DLL

製造出來的DEF 檔：

LIBRARY VC6TEST.DLL

EXPORTS

MyFunc_Cdecl @1

MyFunc_Default @2

_MyFunc_Std@8 =_MyFunc_Std @3

這時候我們就來動手腳，把C++Builder 不認得給改承認得的。改成如下：

EXPORTS

;use this type of aliasing

;(Borland name) = (Name exported by Visual C++)

MyFunc_Std = _MyFunc_Std@8

_MyFunc_Cdecl = MyFunc_Cdecl

_MyFunc_Default = MyFunc_Default

最後再將DEF 檔給還原成LIB 檔，什麼？你有沒有說錯把DEF 這個文字檔變回LIB 檔？是的，其實靜態載入所需要用到的LIB 檔案只是個函式表格罷了，並沒有真正函式內容在裡頭，因此我們可以經由動過手腳的DEF 檔給還原成LIB 檔：

IMPLIB VC6TEST.lib VC6TEST.def

動完手腳後不忘還要去檢查一下是否函式輸出，可以使用TLIB 來觀察最後的test.lib 是否正確輸出：

TLIB VC6TEST.lib,VC6TEST.txt

Publics by module

_MyFunc_cdecl size = 0

_MyFunc_cdecl

_MyFunc_default size = 0

_MyFunc_default

MyFunc_std size = 0

MyFunc_std

可以由觀察test.txt 來檢驗輸出的正確與否，在確定輸出名稱無誤後就可以直接拿進C++Builder 做先前已經說明過的靜態載入測試了。我的測試方法為建立一個Console Application 來載入這個DLL 做測試。

#pragma hdrstop
#include <condefs.h>
//---------------------------------------------------------------------------
USELIB("VC6test.lib");
//---------------------------------------------------------------------------
#pragma argsused
#define DLLIMP extern "C" __declspec(dllimport)
DLLIMP int MyFunc_default(char *c,int X);
DLLIMP int __stdcall MyFunc_std(char *c,int X);
DLLIMP int __cdecl MyFunc_cdecl(char *c,int X);
#include <stdio.h>
#include <conio.h>
int main(int argc, char **argv)
{
printf("int x = MyFunc_std("x",123);n");
int x = MyFunc_std("x",123);
printf("Result : x = %dn",x);
printf("int y = MyFunc_cdecl("x",2323);n");
int y = MyFunc_cdecl("x",2323);
printf("Result : y = %dn",y);
getch();
return 0;
}
　
輸出結果：

int x = MyFunc_std("x",123);

Result : x = 123

int y = MyFunc_cdecl("x",2323);

Result : y = 2323

這樣一來算大功告成，但在筆者的經驗中使用Visual C++ 來寫作DLL 供Borland C++Builder 使用，有以下幾點是值得注意的：

抑制name mangling 的行為
一定要記住為輸出函式加上 extern “C ” 來抑制 name mangling 的動手腳。

禁止輸出類別
為什麼要禁止類別的輸出呢？因為Visual C++ 處理類別的方式與C++Builder 有著很大的不同。所以少用為妙。
結語
這次筆者大多著墨於DLLs 的使用，怎麼建立DLLs 的方法卻只大略一題，因為製造DLLs 的方法有很多，也有很多的技巧，若把這些通通都給寫出來，可能這個主題就要變成連載小說般分成好幾期來刊載了，一期為時一個月，討論這個主題的時間會拖得太久，且相差時間會過久，造成讀者的無法連貫，筆者只好忍痛割捨，不過筆者在此還是列出數本對於製作DLLs 一題著墨相當詳細的書籍：

1 、Adcanced Windows 3/E, Microsoft Press, Jeffrey Richter Chapter 12

2 、Programming Windows 95, Microsoft Press, Charles Petzold Chapter 19

3 、Multithreading Application in Win32, Addison Wesley, JimBeveridge, etc . Chapter 14

4 、Borland C++Builder 3 Unleashed, Sams Publishing, Charlie Calvert, etc. Chapter 35

註 1 、PE 格式的執行檔：PE ，Portable Executable ，是Microsoft 設計用於其所有Win32 作業系統（Win32s 、Windows NT 及Windows 95/98 ）的可執行檔格式。

註2 、在C++Builder 下觀看編譯器產生的真正名稱方法：

選單上『Project/Options 』裡的『Linker 』一頁中的Map File 選項中勾選derailed ：

註3 、在Visual C++ 下觀看編譯器產生的真正名稱方法：

選單上『Project/Settings … 』中『Link 』一頁且Category 為General 時將Generate mapfile 選項勾選。

參考資料、

Windows 95 System Programmung SECRETS, IDG BOOKS, Matt Pietrek
Adcanced Windows 3/E, Microsoft Press, Jeffrey Richter
Programming Windows 95, Microsoft Press, Charles Petzold
Borland C++Builder 3 Unleashed, Sams Publishing, Charlie Calvert
High Preformance Borland C++Builder, Coriolis Group Books, Matt Telles