DLL

Z Wikipedie, otevřené encyklopedie
Skočit na: Navigace, Hledání

DLL (Dynamic-link library, dynamicky linkovaná knihovna) je v informatice implementace konceptu sdílených knihoven společnosti Microsoft pro operační systém Microsoft Windows, který je též používán v OS/2. Soubory s knihovnami obvykle používají příponu DLL, OCX (pro ActiveX prvky) nebo DRV (pro staré systémové ovladače). Formát DLL souborů je stejný jako v případě EXE souborů, tedy Portable Executable (PE) pro 32bitové a 64bitové Windows nebo New Executable (NE) pro 16bitové Windows. Stejně jako EXE soubory mohou DLL obsahovat kód, data a zdroje v libovolné kombinaci.

Historie DLL souborů[editovat | editovat zdroj]

V prvních verzích operačního systému Microsoft Windows byly všechny procesy spouštěny v jednom adresovém prostoru a díky kooperativnímu multitaskingu se procesy explicitně vzdávaly procesoru. Všechny funkce operačního systému poskytoval MS-DOS, zatímco všechny vysokoúrovňové služby byly poskytovány pomocí DLL. Aplikační rozhraní pro vykreslování (GDI) bylo implementováno v DLL zvané GDI.EXE a uživatelské rozhraní v USER.EXE. Tyto vrstvy nad DOSem byly sdílené pro všechny běžící procesy ovšem nikoliv s cílem provozovat systém na strojích s méně než jedním megabajtem paměti, ale s cílem umožnit procesům vzájemně spolupracovat. Kód v GDI překládal příkazy pro vykreslování do specifických instrukcí různých zařízení. V případě displeje byly měněny body ve framebufferu, v případě tiskárny byly příkazy transformovány na pokyny pro tiskárnu. Aby GDI mohlo pracovat s různými zařízeními, načítaly se do paměti tak zvané ovladače zařízení.

Stejná architektura, pomocí které GDI načítalo ovladače pro různá zařízení, umožnila systému načíst programy tak, že bylo možné z těchto programů volat API funkce knihoven USER a GDI. Tento koncept se nazývá dynamické linkování.

U nesdílených, tedy statických, knihoven se jejich kód jednoduše ve fázi linkování přidává do programů, které příslušný kód volají. Pokud více programů volají stejnou rutinu, bude kód této rutiny přidán do obou programů. V případě dynamického linkování je sdílený kód umístěn do separátního souboru. Programy jsou s těmito soubory spojeny dynamicky pomocí operačního systému.

DLL soubory poskytují standardní výhody sdílených knihoven, mezi které patří zejména modularita. Modularita umožňuje provést změny v jedné knihovně sdílené více aplikacemi bez nutnosti tyto aplikace modifikovat. Další přínos modularity je v možnosti použití generického rozhraní pro zásuvné moduly. Rozhraní umožňuje integraci různých modulů do již existujících aplikací opět bez nutnosti aplikace modifikovat. Tento koncept dynamické rozšiřitelnosti je hojně využíván v modelu COM.

V systémech Windows 1.x, 2.x a 3.x sdílejí všechny okenní aplikace stejný adresní prostor, do kterého jsou DLL načteny pouze jednou. Data těchto knihoven jsou pak sdílena všemi aplikacemi, což mohlo být využito k nepřímé meziprocesové komunikaci, ale také to mohlo vést k poškození nějaké aplikace. Od Windows 95 měl pak každý proces svůj vlastní adresní prostor. Zatímco kód dynamických knihoven může být sdílen, data jsou privátní s výjimkou explicitního vyžádání ze strany knihovny.

I když se DLL knihovny staly jádrem architektury systému Windows, mají mnoho nedostatků, které se souhrnně nazývají DLL peklo (anglicky DLL hell).[1] V současné době Microsoft poskytuje několik řešení tohoto problému. Patří mezi ně platforma Microsoft .NET nebo virtualizace založená na Microsoft Virtual PC a Microsoft Application Virtualization, protože nabízí vysoký stupeň izolace aplikací. Dalším řešením pak je implementace Side-by-Side Assembly.

Funkce knihovny DLL[editovat | editovat zdroj]

Vzhledem k tomu, že jsou DLL knihovny v podstatě stejné jako EXE soubory je vhodné použít DLL z důvodu větší přehlednosti programu a jejich možnosti exportu. DLL soubory není možné přímo spouštět, ke spuštění vyžadují EXE soubor pro operační systém. Dále poskytují mechanizmus pro sdílení kódu a dat, což umožňuje vývojáři aktualizaci funkcí bez nutnosti aplikace znovu linkovat nebo kompilovat. Z hlediska vývoje aplikací si lze Windows a OS/2 představit jako kolekci DLL souborů, které jsou inovovány. To umožňuje aplikacím jedné verze operačního systému fungovat i v novějších verzích OS za předpokladu, že vydavatel OS zajistil, že jejich rozhraní a funkcionalita je kompatibilní. DLL jsou spouštěna v rámci volajícího procesu a sdílejí s ním paměťový prostor a přístupová práva. Tím je zajištěna nízká režie při použití, ale zároveň pro volající EXE soubor není zajištěna ochrana proti případným chybám v DLL knihovně.

Vlastnosti DLL souborů[editovat | editovat zdroj]

Správa paměti[editovat | editovat zdroj]

Ve Win32 jsou DLL soubory organizovány do sekcí, kde každá sekce obsahuje atributy informující o tom, zda je například v sekci povolen zápis nebo je pouze pro čtení a také zda je vykonatelná (pro kód) nebo není (pro data).

Kód v DLL knihovnách je obvykle sdílen všemi procesy, které tyto knihovny využívají. Knihovny jsou tak ve fyzické paměti načteny pouze jednou a nejsou odkládány do stránkovacího souboru.

Datové sekce jsou obvykle privátní, takže procesy využívající DLL mají vlastní kopii všech dat knihovny. Datové sekce lze ovšem sdílet a využít je k meziprocesové komunikaci, což může být bezpečnostní problém, protože poškození sdílených dat může způsobit nepřijatelné chování jiných procesů, které tyto data používají. Například proces běžící pod účtem běžného uživatele může pomocí sdílených dat ovládnout jiný proces běžící s vyšším oprávněním. Tento fakt je důvodem k upuštění od sdílených datových sekcí v DLL knihovnách.

Rozlišení a importování funkcí[editovat | editovat zdroj]

Každá funkce exportovaná DLL knihovnou je identifikována číslem a volitelně i jménem. Stejně tak může být funkce importována z DLL buď na základě čísla nebo jména. Číslo reprezentuje pozici ukazatele funkce v tabulce adres exportovaných funkcí a je běžné, že interní funkce jsou exportované pouze svým číslem. Ve Windows API se pak ve většině případů zachovávají mezi verzemi názvy, zatímco pořadí se může měnit, takže se nelze na takový import spoléhat.

Import funkcí pomocí pořadí není o moc rychlejší, protože tabulka exportovaných funkcí je seřazena podle jména, takže k nalezení funkce lze použít binární vyhledávání. V 16-bitových verzích systému Windows nebyla tabulka řazena, takže vyhledání mohlo být o něco pomalejší.

Spustitelný soubor je možné vázat na konkrétní verzi knihovny a zjistit adresu importované funkce již v době kompilace. V takovém případě uloží linker časovou značku a kontrolní součet knihovny, ze které se importuje. Windows pak za běhu zkontrolují, zda se požadovaná knihovna používá a pokud ano, obejde standardní proces importování. V opačném případě proběhne import klasickou cestou.

Odložené načtení[editovat | editovat zdroj]

Normálně se aplikace využívající jistou knihovnu nespustí, pokud tato knihovna nemůže být nalezena. Nicméně aplikace může být linkována tak, že se systém nesnaží nalézt knihovnu ihned, ale až když je zavolána nějaká funkce knihovny.[2] V případě, že knihovna není nalezena, nelze ji načíst nebo konkrétní funkce neexistuje, vygeneruje operační systém výjimku, kterou může aplikace zachytit a vhodně ošetřit. Pokud aplikace výjimku nezachytí, operační systém aplikaci ukončí s hlášením o chybě.

Aspekty kompilátoru a programovacího jazyka[editovat | editovat zdroj]

Delphi[editovat | editovat zdroj]

V hlavičce zdrojového kódu se používá klíčové slovo library namísto program. Na konci souboru jsou funkce (které budou exportovány) vylistovány v klauzuli exports.

Delphi nepotřebuje LIB soubory pro import funkcí z DLL; k nalinkování DLL je užíváno klíčové slovo external v deklaraci funkce.

Microsoft Visual Basic[editovat | editovat zdroj]

Visual Basic (VB), podporuje jen run-time nalinkování; navíc ale kromě používání LoadLibrary a GetProcAddress API funkcí, jsou povoleny deklarace importovaných funkcí.

Při importu DLL funkcí skrze deklarace VB vyhazuje run-time error (chybu), jestliže nemohl být DLL soubor nalezen. Vývojář může zachytit chybu a náležitě ji ošetřit.

Při vytváření DLL ve VB, IDE dovolí vytvářet pouze ActiveX DLL, nicméně byly vytvořeny metody[3] pro umožnění programátorovi explicitně zahrnout .DEF soubor skrze linker. Ten obsahuje řadovou pozici a jméno každé exportované funkce. Toto umožňuje vývojáři vytvoření standardních Windows DLL (užitím Visual Basic), které mohou být referencovány skrze „deklarační“ vyjádření.

C a C++[editovat | editovat zdroj]

Microsoft Visual C++ (MSVC) nabízí několik rozšíření oproti standardnímu C++, které umožňují funkcím být specifikované jako importované nebo exportované přímo v C++ kódu; toto bylo adoptováno i ostatními Windows C a C++ kompilátory, zahrnujíc Windows verze GCC. Tato rozšíření používají atribut __declspec před deklarací funkce. Jsou-li funkce jazyka C použity skrze jazyk C++, musí být deklarovány jako extern "C" v C++ kódu, pro informaci kompilátoru, že by mělo být použito nalinkování jazyka C.[4]

Mimo specifikování importovaných a exportovaných funkcí užitím __declspec atributů mohou být funkce vypsány v IMPORT nebo EXPORTS sekci DEF souboru použitém v projektu. DEF soubor je zpracován linkerem namísto kompilátoru.

DLL kompilace vyprodukuje DLL a LIB soubory. LIB soubor je použit pro link k DLL během kompilace; není nezbytný pro run-time linkování. Pokud váš DLL je Component Object Model (COM) server, musí být DLL soubor umístěn v jednom z adresářů zapsaných v systémové proměnné PATH ve výchozím systémovém adresáři nebo ve stejném adresáři jako je program. COM server DLL jsou registrovány pomocí regsvr32.exe, který umístí lokaci DLL a jeho globální unikátní ID (GUID) do registrů. Programy poté mohou použít DLL vyhledáním jeho GUID v registrech k nalezení jeho lokace (cesty).

Reference[editovat | editovat zdroj]

  1. The End of DLL Hell [online]. Microsoft Corporation, [cit. 2009-07-11]. Dostupné online.  
  2. Linker Support for Delay-Loaded DLLs [online]. Microsoft Corporation, [cit. 2009-07-11]. Dostupné online.  
  3. PETRUSHA, Ron. Creating a Windows DLL with Visual Basic [online]. O'Reilly Media, 2005-04-26, [cit. 2009-07-11]. Dostupné online. (anglicky) 
  4. MSDN, Using extern to Specify Linkage