|
有感于講C語(yǔ)言的DLL文件的文章很少，自己查了半天，寫(xiě)了這么個(gè)非常簡(jiǎn)單的教程。自己也是摸C語(yǔ)言不久，依然感覺(jué)處于編程苦手的階段。
1）為什么使用DLL文件
C語(yǔ)言復(fù)用代碼有很多的形式，利用動(dòng)態(tài)鏈接庫(kù)（DLL）來(lái)復(fù)用代碼也是一種很有效的做法。使用DLL相比利用靜態(tài)庫(kù)來(lái)復(fù)用代碼有幾點(diǎn)不同：
a. 可以不用寫(xiě) header File，但是在編譯過(guò)程中需要在編譯器里把文件鏈接起來(lái)；
b. 更加靈活，可以只改動(dòng)和編譯DLL文件的內(nèi)容，而不用對(duì)程序其他部分進(jìn)行修改；
c. 利用DLL文件可以方便地與其他語(yǔ)言進(jìn)行鏈接（比如Python）。
2）創(chuàng)建DLL及C語(yǔ)言調(diào)用程序
目前看來(lái)，創(chuàng)建 DLL 文件和創(chuàng)建普通c語(yǔ)言文件沒(méi)有什么不同。創(chuàng)建 C++ 的 DLL 文件要更復(fù)雜一些，C
則相對(duì)簡(jiǎn)單。照著 C 代碼的格式寫(xiě)一個(gè)文件（注：C++ 似乎會(huì)不同，微軟就有教程，可以查閱VS的幫助文檔）。
以下是一個(gè)實(shí)例，文件名為 TestDll.c
//TestDll.c 然后寫(xiě)一個(gè)主程序來(lái)調(diào)用，文件名為 UseTestDll.c
//UseTestDLL.c 搞定。
3）編譯及運(yùn)行
測(cè)試使用的是 MinGW 下的 gcc 編譯器。
a. 編譯 DLL 文件
先將 c 文件編譯成 o 文件，然后再講 o 文件編譯成為 DLL 文件，在 cmd 里面代碼如下：
gcc -c TestDLL.c這樣就得到了 TestDll.dll 文件，如果文件多的話可以寫(xiě)個(gè)Batch文件來(lái)搞定。
b. 編譯使用文件
gcc -o UseTestDll
UseTestDll.c -L./ -lTestDll這樣就得到了 UseTestDll.exe 文件。UseTestDll.exe 和 TestDll.dll
形成了程序的兩個(gè)部分，缺一不可。
運(yùn)行一下：
 4）在Python中使用已有的Dll文件
DLL文件一樣可以在Python中使用。我們可以利用python自帶的ctypes模塊（python2.5后自帶，之前得自己再去下，不過(guò)現(xiàn)在也沒(méi)有人用2.5之前的了吧）。下面是一個(gè)示例文件，文件名為UseCDll.py
from ctypes
import *函數(shù)說(shuō)明：
運(yùn)行一下：
成功實(shí)現(xiàn)了在Python下使用DLL文件，這種方法可以減少代碼重復(fù)開(kāi)發(fā)，同時(shí)由于C的速度比Python大很多，還可以用這個(gè)方法對(duì)Python進(jìn)行加速。
5）APPENDIX
關(guān)于gcc編譯命令的一些說(shuō)明，來(lái)自gcc官方文檔。
-shared
Produce a shared object which can then be linked with other
objects to form an executable. Not all systems support this option.
For predictable results, you must also specify the same set of
options used for compilation (‘-fpic’, '-fPIC’, or model
suboptions) when you specify this linker option.1
-Ldir Add directory dir to the list of directories to be
searched for ‘-l’.
-o file Write output to file. This is the same as specifying file as
the second non-option argument to cpp. gcc has a different
interpretation of a second non-option argument, so you must use
‘-o’ to specify the output file.
-c Compile or assemble the source files, but do not link. The
linking stage simplyis not done. The ultimate output is in the form
of an object file for each source file. By default, the object file
name for a source file is made by replacing the suffix ‘.c’, ‘.i’,
‘.s’, etc., with ‘.o’.
Unrecognized input files, not requiring compilation or
assembly, are ignored.
-llibrary -l library
Search the library named library when linking. (The second
alternative with the library as a separate argument is only for
POSIX compliance and is not recommended.) It makes a difference
where in the command you write this option; the linker searches and
processes libraries and object files in the order they are
specified. Thus, ‘foo.o -lz bar.o’ searches library ‘z’ after file
‘foo.o’ but before
‘bar.o’. If ‘bar.o’ refers to functions in ‘z’, those
functions may not be loaded. The linker searches a standard list of
directories for the library, which is actually a file named
‘liblibrary.a’. The linker then uses this file as if it had been
specified precisely by name.
The directories searched include several standard system
directories plus any that you specify with ‘-L’.
Normally the files found this way are library files—archive
files whose members are object files. The linker handles an archive
file by scanning through it for members which define symbols that
have so far been referenced but not defined.
But if the file that is found is an ordinary object file, it
is linked in the usual fashion. The only difference between using
an ‘-l’ option and specifying a file name is that ‘-l’ surrounds
library with ‘lib’ and ‘.a’ and searches several directories.
|
|
|
