|
'''DLL''' ('''Dynamic-link library (DLL)''' neboli, dynamicky linkovaná knihovna) je v [[Informatika (počítačová věda)|informatice]] implementace koncepcekonceptu [[Knihovna (programování)#Dynamické knihovny|sdílených knihoven]] od společnosti [[Microsoft]] napro operačních[[Operační systémechsystém|operační systém]] [[Microsoft Windows]], který je též používán av [[OS/2]]. Tyto[[Soubor]]y knihovnys knihovnami obvykle používají [[Přípona souboru|příponu]] <ttcode>DLL</ttcode>, <ttcode>OCX</ttcode> (pro [[ActiveX]] prvky) nebo <ttcode>DRV</ttcode> (pro staré [[Ovladač zařízení|systémové ovladače]]).
Formát DLL souborů je stejný jako v případě [[EXE]] souborů, tedy [[Portable Executable]] (PE) pro [[32bitový|32-bitové32bitové]] a [[64bitový|64-bitové64bitové]] Windows nebo [[New Executable]] (NE) pro [[16bitový|16-bitové16bitové]] Windows. Stejně jako EXE soubory, mohou DLL obsahovat [[Kód|kód]], [[Data|data]] a zdroje v libovolné kombinaci.
== Historie DLL souborů ==
V prvních verzích operačního systému [[Microsoft Windows]] byly všechny procesy spouštěny v jednom [[Správa paměti#Adresový prostor procesu|adresovém prostoru]] a díky [[Multitasking#Nepreemptivní multitasking|kooperativnímu multitaskingu]] se procesy explicitně vzdávalivzdávaly procesoru. Všechny operace na úrovnifunkce operačního systému poskytoval [[MS-DOS]], zatímco všechny vysokoúrovňové služby poskytovalybyly '''dynamickyposkytovány linkovanépomocí knihovny'''DLL. [[API|Aplikační rozhraní]] pro vykreslování ([[Graphics Device Interface|GDI]]) bylo implementováno v DLL zvané <ttcode>GDI.EXE</ttcode> a uživatelské rozhraní v <ttcode>USER.EXE<ttcode>. 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 [[Graphics Device Interface|rozhraní grafického zařízení]] v GDI překládal příkazy pro vykrelovánívykreslování specifickýmdo zařízenímspecifických instrukcí různých zařízení. V případě displeje bylobyly manipulovánoměněny s pixelybody ve frame bufferu[[framebuffer]]u, v případě tiskárny byly příkazy transformovány na požadavkypokyny tiskárněpro tiskárnu. Aby GDI mohlo pracovat s různými zařízeními, načítaly se do paměti částitak kódu nazývanézvané '[[Ovladač zařízení|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'', knihovnenknihoven 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 [[Knihovna (programování)#Dynamické knihovny|sdílených knihoven]], mezi které patří zejména [[Modularita|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 [[Component Object Model|COM]].
V systémusystémech Windows 1.x, 2.x a 3.x sdílejí všechny okenní aplikace sdílejístejný adresovýadresní prostor, do kterého jsou DLL načteny pouze jednou. Data těchto knihoven jsou pak sdílena všemi applikacemiaplikacemi, což mohlo být využito k nepřímé [[Meziprocesová komunikace|meziprocesové komunikaci]], ale také to mohlo vést k poškození nějaké aplikace. Od [[Windows 95]] měl pak každý proces měl svůj vlastní adresový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 hell]]".<ref name=DLL_Hell>{{cite web
| title = The End of DLL Hell
| publisher = Microsoft Corporation
| url = http://msdn.microsoft.com/en-us/library/ms811694.aspx
| accessdate = 2009-07-11}}</ref> V současné době Microsoft poskytuje několik řešení DLLtohoto hellproblému. Patří mezi ně platforma [[Microsoft .NET]] nebo virtualizacivirtualizace založenouzalož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]]. ▼
| accessdate = 2009-07-11}}</ref>
▲V současné době Microsoft poskytuje několik řešení DLL hell. Patří mezi ně platforma [[Microsoft .NET]] nebo virtualizaci založenou 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]].
== Vlastnosti DLL souborů ==
=== Správa paměti ===
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 [[Strojový kód|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ánkování paměti|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á komunikace|meziprocesové komunikaci]], což může být [[Zranitelnost|bezpečnostní zranitelnostproblé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 hostaběžného uživatele může pomocí sdílených dat ovládnout jiný proces běžící s vyššímivyšším právyoprávněním. Tento fakt je důvoddůvodem k upuštění od sdílených datových sekcí v DLL knihovnách.
=== Rozlišení a importování funkcí ===
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í|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ší.
JeSpustitelný možnésoubor ''vázat''je spustitelnýmožné souborvázat na konkrétní verzi knihovny a zjistit adresu importované funkefunkce již v době kompilace. V takovém případě uloží [[Linker|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í ===
== Reference ==
<references/>
[[Kategorie:Souborové formáty]]
[[ar:مكتبة الربط الديناميكي]]
| 