Dll od podstaw




DLL od podstaw
Co właściwie
oznacza ten dziwny skrót? Po prostu Dynamic Link Library, czyli Dynamicznie Dołączana
Biblioteka. A po co one są? A po to, że jeśli używamy jakiegoś kodu wiele
razy w naszych programach (np. funkcje czy sub'y) to możemy stworzyć bibliotekę,
która będzie je przechowywała i będziemy mogli korzystać z nich w
programach, a, że nie będą one za każdym razem deklarowane i tworzone w każdym
programie, to zmniejszymy ilość zajmowanego przez programy miejsca, oraz
dodamy naszemu programowi charakter profesjonalny.
Używając
funkcji deklarowanych (tworzonych) w naszym programie stosujemy koncepcję
wczesnego wiązania (opisane także z innej strony w jednym z innych moich
artykułów), czyli program (kompilator, kompiluje go w myśl tej koncepcji) już
wie co to za funkcje, a jeśli korzystamy z koncepcji późnego wiązania, czyli
takiego jak przy użyciu DLL'i to program (kompilator, kompiluje go w myśl tej
koncepcji) nie wie co to za funkcje i w kodzie występować będzie nieznany
adres wirtualny do tej funkcji, który utworzy połączenie dopiero po pierwszym
użyciu danej importowanej funkcji.
W VB możemy używać
kilku typów DLL'i. Pierwszym z nich jest normalna biblioteka korzystająca z
konwencji (Calling Convention, konwencja wywoływania) Pascal'a, czyli 16
bitowej. Takie biblioteki wykorzystujemy poprzez instrukcje Declare.
Drugim typem jest
podobna, lecz 32-bitowa biblioteka. Różnica jest taka, że konwencja wywołania
ma teraz charakter stdcall, czyli Standard Call.
Wiem, że Visual
Basic'owcom będzie trudniej, bo skąd mają wiedzieć co to są te konwencje?
Otóż konwencje
znają programiści C++ i Object Pascal'a (Delphi). Są to ustawienia
kompilatora. Tamtejsze kompilatory umożliwiają dużo większą optymalizację
niż kompilator VB, i to zdaje mi się, że nawet może 10 razy (nie liczyłem,
ale zakładek jest o właśnie tyle więcej).
W obu w/w
bibliotekach występuje niżej przedstawiona struktura:
#include <vcl.h>
#pragma hdrstop

int WINAPI DllEntryPoint(HINSTANCE hinst, unsigned long reason, void*)
{
return 1;
}
Potem,
aby eksportować jakąś funkcję używa się extern'a, np:
extern
"C" __declspec(dllexport) [typ zmiennej zwrotu] [nazwa funkcji]([typy
danych parametrow]);
Trzecim typem, a
raczej grupą są biblioteki ActiveX DLL. W rzeczywistości są zupełnie inne
od swoich poprzedników. Tylko takie biblioteki możemy tworzyć w VB.
 
ActiveX DLL
ActiveX to znany
już wszystkim z kontrolek format współdzielenia kodu. I w zastosowaniu DLL'i
znalazł on zastosowanie. Te biblioteki, jak już wspomniałem mają mało wspólnego
z DLL'ami tych innych typów.
Takie biblioteki
to jedynie serwery COM (Component Object Model) i niestety nie ma odpowiednika
funkcji eksportującej extern. Możemy jedynie podpierać się prefiksami Public
i Private.
ActiveX DLL jest
podobny do ActiveX EXE, ale różni się tym, że jest komponentem działającym
w ramach procesu (proces - aplikacja).
Należy także
wspomnieć, że eksportowane funkcje ActiveX DLL'a muszą się znajdować w modułach
klas, dlatego by tworzyć takie biblioteki należy zapoznać się dobrze z metodą
programowania zorientowanego obiektowo.
 
Programuj
obiektowo
Programowanie
zorientowane obiektowo polega na tworzeniu małych komponentów używanych potem
przez większe, i większe. Polega to na określaniu złożonych operacji przez
prostsze od ich samych.
W
VB możemy tworzyć moduły i moduły klas oraz wklepywać do nich funkcje. Należy
precyzyjne przemyśleć czy dana funkcja ma być Public czy Private, oraz należy
zastanowić się nad parametrami (nazwy, ewentualnie optional itp.).
Właśnie
w tedy, kiedy postępuje się w myśl tego wzorca programowania, można tworzyć
biblioteki DLL.
 
Jak
się do tego zabrać?
Kiedy
zbierzemy już dostateczną ilość wspólnie używanych funkcji, należy je
powklejać do modułów klas, a deklaracje do oddzielnych modułów. Trzeba uważać,
by nie wystąpił błąd, bo moduły klas lubią psocić figle.
Po
stworzeniu wszystkiego i sprawdzeniu błędów czas na kompilację. Nie zapomnij
ustawić nazw wszystkich obiektów (także obiektu projektu).
Potem
zabierz się za kompilację. VB automatycznie zarejestruje twojego DLL'a, ale jeśli
jednak będziesz musiał to zrobić sam, to skorzystaj z Microsoft Register
Server, poprzez
komende
Regsvr32 
[tu nazwa
twojej nowej biblioteki], np.
Regsvr32
Mydll.dll
Wpisujemy
tę komendę w wierszu poleceń (Tryb MS-DOS).
 
Jak
używać
Są
dwie metody użycia takich bibliotek.
Sposób
I (opisywany już na łamach VBM przez Karola Kuczmarskiego):
Dim
KlasaDlla As MyDll.Grafika
Powyższy
kod (przykładowy) tworzy referencję do obiektu klasy Grafika będącą częścią
MyDll. Jest to metoda wczesnego wiązania. Tak samo można zrobić, gdy mamy do
czynienia z późnym wiązaniem, wtedy kod będzie miał postać
Dim
KlasaDlla As Object
Set
KlasaDLLa = CreateObject("MyDll.Grafika")
Później
możemy używać zapisanych w klasie funkcji. Minus jest ten, że musimy pamiętać
funkcje. A przy dużej ilości to jest niemożliwe.
Sposób
II:
Używamy
biblioteki dodając ją w menu Project/References.
Projektujemy
z jej pomocą następnie tak jak z DirectX lub innymi dołączanymi
referencjami. Tutaj plusem jest to, że każda funkcja jest widoczna, zarówno
od strony klasy jak i od strony parametrów.
 
Następnym
atutem takich bibliotek, jest możliwość używania i tworzenia ich w innych językach
programowania!
Wraz
z plikiem DLL tworzą się dwa inne pliki o rozszerzeniach exp i lib. Oba pliki
należy rozprowadzać wraz w biblioteką.
Możesz
sobie zobaczyć prostą bibliotekę jako przykład: dll.zip.
 
Myślę,
że ten artykuł przybliżył Ci programowanie komponentów współdzielenia
kodu. Życzę miłego kodowania.
 
<-DoogiE->
[e-mail]