⑴ 用VS 如何由源代碼生成DLL文件
1:創建DLL工程
文件->新建->項目->visual c++->win32->win32控制台應用程序(win32項目也可以)
填寫項目名稱MyDLL->確定->下一步->DLL(附加選項 對空項目打鉤)->完成。
到這里DLL工程就創建完畢了,下面新建兩個文件MyDLL.cpp和MyDLL.h。
MyDLL.cpp內容如下:
testMyDLL.h內容如下
#pragmaonce
extern"C"_declspec(dllexport)intAdd(int&a,int&b);
現在可以編譯通過了,但是程序運行就報錯,還需要將MyDLL.dll復制到當前項目生成的可執行文件所在的目錄。(這一點非常重要)
這里需要注意testMyDLL.cpp文件中調用lib的這句話:
#pragmacomment(lib,"..\debug\MyDLL.lib")
這里需要指明lib所在的文件夾,當然我們也可以在生成dll的MyDLL工程中,指定lib和dll文件的輸出路徑,直接到testMyDLL工程下。
注意:如果只有dll文件,那麼必須在程序裡面調用LoadLibrary()函數才能使用,如果有lib文件,那麼有兩種方式可以馬上進行調用
⑵ QT中自己實現DLL及調用
在Qt中自己實現DLL和調用的具體步驟如下:
首先,新建一個Libary,並選擇共享庫,以便構建DLL。
接下來,編寫源碼。在dll.h文件中,定義了DLL的介面,並且包含了一些預處理指令,如使用命名空間std等。
在dll.h文件中定義了兩個類成員函數和兩個非類成員函數。類成員函數在C++中定義,而非類成員函數使用extern "C"來明確告訴編譯器按照C語言格式編譯,以確保與C語言兼容。
在dll.cpp文件中,實現上述函數的邏輯。注意,為了避免在控制台輸出中文時可能出現的亂碼問題,應當盡量使用英文輸出。
構建DLL項目時,使用如MinGW這樣的編譯器。編譯後,將生成dll.dll、libdll.a、dll.o三個文件。其中,dll.dll文件在Windows操作系統下使用,而dll.o文件在Linux或Unix下使用,libdll.a為靜態庫。
動態庫DLL的應用主要在於擴展應用程序的功能,但需要注意DLL文件應與應用程序一同發布,並確保編譯DLL和應用程序的Qt版本保持一致,以避免二進制兼容性問題。
調用動態庫的方法有兩種:
方法一:利用QLibrary進行顯示調用。步驟包括創建工程、拷貝相關文件、添加庫路徑、編寫源碼,具體操作包括創建Win類,使用QLibrary對象載入DLL,並通過成員指針調用類中的函數,或通過函數指針調用非類中的函數。
方法二:實現隱式調用,步驟包括創建工程、在源碼文件夾中建立包含頭文件的文件夾、在編譯文件夾中建立包含動態庫文件夾、在pro文件中添加庫路徑、導入頭文件並調用函數。這種方法簡化了調用過程,使得代碼更加簡潔。
⑶ .dll文件是用什麼編寫的呀
DLL是一種特殊的可執行文件。說它特殊主要是因為一般它都不能直接運行,需要宿主程序比如*.EXE程序或其他DLL的動態調用才能夠使用。簡單的說,在通常情況下DLL是經過編譯的函數和過程的集合。
使用DLL技術主要有以下幾個原因:
一、減小可執行文件大小。
DLL技術的產生有很大一部分原因是為了減小可執行文件的大小。當操作系統進入Windows時代後,其大小已經達到幾十兆乃至幾百兆。試想如果還是使用DOS時代的單執行文件體系的話一個可執行文件的大小可能將達到數十兆,這是大家都不能接受的。解決的方法就是採用動態鏈接技術將一個大的可執行文件分割成許多小的可執行程序。
二、實現資源共享。
這里指的資源共享包括很多方面,最多的是內存共享、代碼共享等等。早期的程序員經常碰到這樣的事情,在不同的編程任務中編寫同樣的代碼。這種方法顯然浪費了很多時間,為了解決這個問題人們編寫了各種各樣的庫。但由於編程語言和環境的不同這些庫一般都不能通用,而且用戶在運行程序時還需要這些庫才行,極不方便。DLL的出現就像制定了一個標准一樣,使這些庫有了統一的規范。這樣一來,用不同編程語言的程序員可以方便的使用用別的編程語言編寫的DLL。另外,DLL還有一個突出的特點就是在內存中只裝載一次,這一點可以節省有限的內存,而且可以同時為多個進程服務。
三、便於維護和升級。
細心的朋友可能發現有一些DLL文件是有版本說明的。(查看DLL文件的屬性可以看到,但不是每一個DLL文件都有)這是為了便於維護和升級。舉個例子吧,早期的Win95中有一個BUG那就是在閏年不能正確顯示2月29日這一天。後來,Microsoft發布了一個補丁程序糾正了這個BUG。值得一提的是,我們並沒有重裝Win95,而是用新版本的DLL代替了舊版本的DLL。(具體是哪一個DLL文件筆者一時想不起來了。)另一個常見的例子是驅動程序的升級。例如,著名的DirectX就多次升級,現在已經發展到了6.0版了。更妙的是,當我們試圖安裝較低版本的DLL時,系統會給我們提示,避免人為的操作錯誤。例如我們升級某硬體的驅動程序時,經常碰到Windows提示我們當前安裝的驅動程序比原來的驅動程序舊。
四、比較安全。
這里說的安全也包括很多方面。比如,DLL文件遭受病毒的侵害機率要比普通的EXE文件低很多。另外,由於是動態鏈接的,這給一些從事破壞工作的「高手」們多少帶來了一些反匯編的困難。
第二章 在Delphi中編寫DLL top
注意:在這里筆者假定讀者使用的是Delphi 3或Delphi 4開場白說了那麼多,總該言歸正傳了。編寫DLL其實也不是一件十分困難的事,只是要注意一些事項就夠了。為便於說明,我們先舉一個例子。
library Delphi;
uses
SysUtils,
Classes;
function TestDll(i:integer):integer;stdcall;
begin
Result:=i;
end;
exports
TestDll;
begin
end.
上面的例子是不是很簡單?熟悉Delphi的朋友可以看出以上代碼和一般的Delphi程序的編寫基本是相同的,只是在TestDll函數後多了一個stdcall參數並且用exports語句聲明了TestDll函數。只要編譯上面的代碼,就可以得到一個名為Delphi.dll的動態鏈接庫。現在,讓我們來看看有哪些需要注意的地方。 一、在DLL中編寫的函數或過程都必須加上stdcall調用參數。在Delphi 1或Delphi 2環境下該調用參數是far。從Delphi 3以後將這個參數變為了stdcall,目的是為了使用標準的Win32參數傳遞技術來代替優化的register參數。忘記使用stdcall參數是常見的錯誤,這個錯誤不會影響DLL的編譯和生成,但當調用這個DLL時會發生很嚴重的錯誤,導致操作系統的死鎖。原因是register參數是Delphi的默認參數。
二、所寫的函數和過程應該用exports語句聲明為外部函數。
正如大家看到的,TestDll函數被聲明為一個外部函數。這樣做可以使該函數在外部就能看到,具體方法是單激滑鼠右鍵用「快速查看(Quick View)」功能查看該DLL文件。(如果沒有「快速查看」選項可以從Windows CD上安裝。)TestDll函數會出現在Export Table欄中。另一個很充分的理由是,如果不這樣聲明,我們編寫的函數將不能被調用,這是大家都不願看到的。
三、當使用了長字元串類型的參數、變數時要引用ShareMem。
Delphi中的string類型很強大,我們知道普通的字元串長度最大為256個字元,但Delphi中string類型在默認情況下長度可以達到2G。(對,您沒有看錯,確實是兩兆。)這時,如果您堅持要使用string類型的參數、變數甚至是記錄信息時,就要引用ShareMem單元,而且必須是第一個引用的。既在uses語句後是第一個引用的單元。如下例:
uses
ShareMem,
SysUtils,
Classes;
還有一點,在您的工程文件(*.dpr)中而不是單元文件(*.pas)中也要做同樣的工作,這一點Delphi自帶的幫助文件沒有說清楚,造成了很多誤會。不這樣做的話,您很有可能付出死機的代價。避免使用string類型的方法是將string類型的參數、變數等聲明為Pchar或ShortString(如:s:string[10])類型。同樣的問題會出現在當您使用了動態數組時,解決的方法同上所述。
第三章 在Delphi中靜態調用DLL top
調用一個DLL比寫一個DLL要容易一些。首先給大家介紹的是靜態調用方法,稍後將介紹動態調用方法,並就兩種方法做一個比較。同樣的,我們先舉一個靜態調用的例子。
unit Unit1;
interface
uses
Windows, Messages, SysUtils, Classes, Graphics,
Controls, Forms, Dialogs, StdCtrls;
type
TForm1 = class(TForm)
Edit1: TEdit;
Button1: TButton;
procere Button1Click(Sender: TObject);
private
{ Private declarations }
public
{ Public declarations }
end;
var
Form1: TForm1;
implementation
{$R *.DFM}
//本行以下代碼為我們真正動手寫的代碼
function TestDll(i:integer):integer;stdcall;
external 』Delphi.dll』;
procere TForm1.Button1Click(Sender: TObject);
begin
Edit1.Text:=IntToStr(TestDll(1));
end;
end.
上面的例子中我們在窗體上放置了一個編輯框(Edit)和一個按鈕(Button),並且書寫了很少的代碼來測試我們剛剛編寫的Delphi.dll。大家可以看到我們唯一做的工作是將TestDll函數的說明部分放在了implementation中,並且用external語句指定了Delphi.dll的位置。(本例中調用程序和Delphi.dll在同一個目錄中。)讓人興奮的是,我們自己編寫的TestDll函數很快被Delphi認出來了。您可做這樣一個實驗:輸入「TestDll(」,很快Delphi就會用fly-by提示條提示您應該輸入的參數是什麼,就像我們使用Delphi中定義的其他函數一樣簡單。注意事項有以
下一些:
一、調用參數用stdcall。
和前面提到的一樣,當引用DLL中的函數和過程時也要使用stdcall參數,原因和前面提到的一樣。
二、用external語句指定被調用的DLL文件的路徑和名稱。
正如大家看到的,我們在external語句中指定了所要調用的DLL文件的名稱。沒有寫路徑是因為該DLL文件和調用它的主程序在同一目錄下。如果該DLL文件在C:\,則我們可將上面的引用語句寫為external 』C:\Delphi.dll』。注意文件的後綴.dll必須寫上。
三、不能從DLL中調用全局變數。
如果我們在DLL中聲明了某種全局變數,如:var s:byte 。這樣在DLL中s這個全局變數是可以正常使用的,但s不能被調用程序使用,既s不能作為全局變數傳遞給調用程序。不過在調用程序中聲明的變數可以作為參數傳遞給DLL。
四、被調用的DLL必須存在。
這一點很重要,使用靜態調用方法時要求所調用的DLL文件以及要調用的函數或過程等等必須存在。如果不存在或指定的路徑和文件名不正確的話,運行主程序時系統會提示「啟動程序時出錯」或「找不到*.dll文件」等運行錯誤。
第四章 在Delphi中動態調用DLL top
動態調用DLL相對復雜很多,但非常靈活。為了全面的說明該問題,這次我們舉一個調用由C++編寫的DLL的例子。首先在C++中編譯下面的DLL源程序。
#include
extern 」C」 _declspec(dllexport)
int WINAPI TestC(int i)
{
return i;
}
編譯後生成一個DLL文件,在這里我們稱該文件為Cpp.dll,該DLL中只有一個返回整數類型的函數TestC。為了方便說明,我們仍然引用上面的調用程序,只是將原來的Button1Click過程中的語句用下面的代碼替換掉了。
procere TForm1.Button1Click(Sender: TObject);
type
TIntFunc=function(i:integer):integer;stdcall;
var
Th:Thandle;
Tf:TIntFunc;
Tp:TFarProc;
begin
Th:=LoadLibrary(』Cpp.dll』); {裝載DLL}
if Th>0 then
try
Tp:=GetProcAddress(Th,PChar(』TestC』));
if Tp<>nil
then begin
Tf:=TIntFunc(Tp);
Edit1.Text:=IntToStr(Tf(1)); {調用TestC函數}
end
else
ShowMessage(』TestC函數沒有找到』);
finally
FreeLibrary(Th); {釋放DLL}
end
else
ShowMessage(』Cpp.dll沒有找到』);
end;
大家已經看到了,這種動態調用技術很復雜,但只要修改參數,如修改LoadLibrary(』Cpp.dll』)中的DLL名稱為』Delphi.dll』就可動態更改所調用的DLL。
一、定義所要調用的函數或過程的類型。
在上面的代碼中我們定義了一個TIntFunc類型,這是對應我們將要調用的函數TestC的。在其他調用情況下也要做同樣的定義工作。並且也要加上stdcall調用參數。
二、釋放所調用的DLL。
我們用LoadLibrary動態的調用了一個DLL,但要記住必須在使用完後手動地用FreeLibrary將該DLL釋放掉,否則該DLL將一直佔用內存直到您退出Windows或關機為止。
現在我們來評價一下兩種調用DLL的方法的優缺點。靜態方法實現簡單,易於掌握並且一般來說稍微快一點,也更加安全可靠一些;但是靜態方法不能靈活地在運行時裝卸所需的DLL,而是在主程序開始運行時就裝載指定的DLL直到程序結束時才釋放該DLL,另外只有基於編譯器和鏈接器的系統(如Delphi)才可以使用該方法。動態方法較好地解決了靜態方法中存在的不足,可以方便地訪問DLL中的函數和過程,甚至一些老版本DLL中新添加的函數或過程;但動態方法難以完全掌握,使用時因為不同的函數或過程要定義很多很復雜的類型和調用方法。對於初學者,筆者建議您使用靜態方法,待熟練後再使用動態調用方法。
第五章 使用DLL的實用技巧 top
一、編寫技巧。
1 、為了保證DLL的正確性,可先編寫成普通的應用程序的一部分,調試無誤後再從主程序中分離出來,編譯成DLL。
2 、為了保證DLL的通用性,應該在自己編寫的DLL中杜絕出現可視化控制項的名稱,如:Edit1.Text中的Edit1名稱;或者自定義非Windows定義的類型,如某種記錄。
3 、為便於調試,每個函數和過程應該盡可能短小精悍,並配合具體詳細的注釋。
4 、應多利用try-finally來處理可能出現的錯誤和異常,注意這時要引用SysUtils單元。
5 、盡可能少引用單元以減小DLL的大小,特別是不要引用可視化單元,如Dialogs單元。例如一般情況下,我們可以不引用Classes單元,這樣可使編譯後的DLL減小大約16Kb。
二、調用技巧。
1 、在用靜態方法時,可以給被調用的函數或過程更名。在前面提到的C++編寫的DLL例子中,如果去掉extern 」C」語句,C++會編譯出一些奇怪的函數名,原來的TestC函數會被命名為@TestC$s等等可笑的怪名字,這是由於C++採用了C++ name mangling技術。這個函數名在Delphi中是非法的,我們可以這樣解決這個問題:
改寫引用函數為
function TestC(i:integer):integer;stdcall;
external 』Cpp.dll』;name 』@TestC$s』;
其中name的作用就是重命名。
2 、可把我們編寫的DLL放到Windows目錄下或者Windows\system目錄下。這樣做可以在external語句中或LoadLibrary語句中不寫路徑而只寫DLL的名稱。但這樣做有些不妥,這兩個目錄下有大量重要的系統DLL,如果您編的DLL與它們重名的話其後果簡直不堪設想,況且您的編程技術還不至於達到將自己編寫的DLL放到系統目錄中的地步吧!
三、調試技巧。
1 、我們知道DLL在編寫時是不能運行和單步調試的。有一個辦法可以,那就是在Run|parameters菜單中設置一個宿主程序。在Local頁的Host Application欄中添上宿主程序的名字就可進行單步調試、斷點觀察和運行了。
2 、添加DLL的版本信息。開場白中提到了版本信息對於DLL是很重要的,如果包含了版本信息,DLL的大小會增加2Kb。增加這么一點空間是值得的。很不幸我們如果直接使用Project|options菜單中Version選項是不行的,這一點Delphi的幫助文件中沒有提到,經筆者研究發現,只要加一行代碼就可以了。如下例:
library Delphi;
uses
SysUtils,
Classes;
{$R *.RES}
//注意,上面這行代碼必須加在這個位置
function TestDll(i:integer):integer;stdcall;
begin
Result:=i;
end;
exports
TestDll;
begin
end.
3 、為了避免與別的DLL重名,在給自己編寫的DLL起名字的時候最好採用字元數字和下劃線混合的方式。如:jl_try16.dll。
4 、如果您原來在Delphi 1或Delphi 2中已經編譯了某些DLL的話,您原來編譯的DLL是16位的。只要將源代碼在新的Delphi 3或Delphi 4環境下重新編譯,就可以得到32位的DLL了。
[後記]:除了上面介紹的DLL最常用的使用方法外,DLL還可以用於做資源的載體。例如,在Windows中更改圖標就是使用的DLL中的資源。另外,熟練掌握了DLL的設計技術,對使用更為高級的OLE、COM以及ActiveX編程都有很多益處。
⑷ C++類庫是根據什麼生成DLL的 命名空間嗎
基本上回答是調不了,原因來自引用名和調用約定兩方面。這個需要從VC++導出類的原理說起。
類從本質上來說是數據結構和封裝的操作兩部分。數據結構定義在頭文件當中,編譯的時候就可以訪問到;而成員函數是從DLL中導出的。導出C++類庫的時候,這些函數名字會按照編譯器的標准做一個擴展,比如說
class B{
int Operator(int a, int b);
};
裡面的Operator這個成員函數,實際上會被編譯成類似於這樣的一個函數:
int __thiscall B_Operatorxxxxxx(B* _this, int a, int b);
(__thiscall這個關鍵字其實是C++里沒有的)
注意到名字後面增加了一些像亂碼一樣的東西,這是C++編譯器根據後面的參數列表自動生成的一個後綴。因為這個後綴的存在,相同名字不同參數的函數和成員函數才可以一起存在在代碼里(即所謂的重載)。
這也就是說,想要調用C++類庫里的函數的話,至少要知道編譯器把這個函數編譯成了什麼名字,但實際上不同的編譯器編譯出來的結果都不一樣。
其實這也算不上什麼問題,編譯的時候如果設置輸出詳細信息的話是有辦法能查到實際編譯成什麼名字了的。更嚴重的問題來自調用約定:
正如上文中提到的,C++的成員函數採用__thiscall的調用約定。所謂調用約定,是指在調用函數時如何傳遞參數,用什麼順序傳遞參數,以及由誰來負責清理堆棧的約定。__thiscall這個調用約定是不被託管程序的[DllImport]屬性支持的。
當然不排除一些拐彎抹角的方法是能調用的。即便如此也是極其不推薦的做法。
鍙傝 冭祫鏂欙細五湖四海皆春色 萬水千山盡得輝 萬象更新