DLL: Porovnání verzí

Smazaný obsah Přidaný obsah
→‎Microsoft Visual Basic: drobnosti formulace
typografie, stylistika, doplnění a aktualizace odkazu + eliminace neplatného
Řádek 1:
'''DLL''' ('''Dynamic-link library''', dynamicky linkovaná [připojovaná] knihovna, knihovní modul)<ref name="petzold">{{citace monografie
'''DLL''' ('''Dynamic-link library''', dynamicky linkovaná knihovna) je v&nbsp;[[Informatika|informatice]] implementace konceptu [[Knihovna (programování)#Dynamické knihovny|sdílených knihoven]] společnosti [[Microsoft]] pro [[operační systém]] [[Microsoft Windows]], který je též používán v&nbsp;[[OS/2]]. [[Soubor]]y s knihovnami obvykle používají [[Přípona souboru|příponu]] <code>DLL</code>, <code>OCX</code> (pro [[ActiveX]] prvky) nebo <code>DRV</code> (pro staré [[Ovladač zařízení|systémové ovladače]]).
| příjmení = PETZOLD
Formát DLL souborů je stejný jako v&nbsp;případě [[EXE]] souborů, tedy [[Portable Executable]] (PE) pro [[32bitový|32bitové]] a&nbsp;[[64bitový|64bitové]] Windows nebo [[New Executable]] (NE) pro [[16bitový|16bitové]] Windows. Stejně jako EXE soubory mohou DLL obsahovat [[Strojový kód|kód]], [[data]] a&nbsp;zdroje v&nbsp;libovolné kombinaci.
| jméno = Charles
| titul = Programování ve Windows
| vydání = 1
| vydavatel = Computer Press
| místo = Praha
| rok = 1999
| isbn = 80-7226-206-8
'''DLL''' | ('''Dynamic-linkstrany library''',= dynamicky linkovaná knihovna)1047}}</ref> je v&nbsp;[[Informatika|informatice]] implementace konceptu [[Knihovna (programování)#Dynamické knihovny|sdílených knihoven]] společnosti [[Microsoft]] pro [[operační systém]] [[Microsoft Windows]], který je též používán v&nbsp;[[OS/2]]. Jde o jeden ze základních prvků struktury Windows.<ref name="petzold" /> [[Soubor]]y s &nbsp;knihovnami obvykle používají [[Přípona souboru|příponu]] <codett>DLL.dll</codett>, <codett>OCX.ocx</codett> (pro [[ActiveX]] prvky) nebo, <codett>DRV.drv</codett> (pro staré [[Ovladač zařízení|systémové ovladače]]) nebo <tt>.fon</tt> (pro [[Font#Rastrov.C3.A1_p.C3.ADsma|rastrová písma]]). Má-li knihovna jinou [[Přípona souboru|příponu]], pak ji program musí nahrát [[Explicitnost|explicitně]] voláním [[Podprogram|funkce]] <tt>[[LoadLibrary]]</tt> či <tt>[[LoadLibraryEx]]</tt>.<ref name="petzold2">{{citace monografie
| příjmení = PETZOLD
| jméno = Charles
| titul = Programování ve Windows
| vydání = 1
| vydavatel = Computer Press
| místo = Praha
| rok = 1999
| isbn = 80-7226-206-8
| strany = 1048}}</ref> Formát DLL souborů je stejný jako v&nbsp;případě [[EXE]] souborů, tedy [[Portable Executable]] (PE) pro [[32bitový|32bitové]] a&nbsp; [[64bitový|64bitové]] Windows nebo [[New Executable]] (NE) pro [[16bitový|16bitové]] Windows. Stejně jako EXE soubory mohou DLL obsahovat [[Strojový kód|kód]], [[data]] a&nbsp; zdroje v&nbsp;libovolné kombinaci.
 
== Historie DLL souborů ==
V&nbsp; prvních verzích operačního systému [[Microsoft Windows]] byly všechny procesy spouštěny v&nbsp;jednom [[Správa paměti#Adresový prostor procesu|adresovém prostoru]] paměti počíteče a&nbsp; díky [[Multitasking#Nepreemptivní multitasking|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í ([[API]]) pro vykreslování ([[GDI]], Graphics Device Interface) bylo implementováno v&nbsp;DLL zvané <codett>GDIgdi.EXEexe</codett> a&nbsp; uživatelské rozhraní v&nbsp;<codett>USERuser.EXEexe</codett>. Tyto vrstvy nad DOSem byly sdílené pro všechny běžící procesy (pod podmínkou provozu na strojích s&nbsp;alespoň jedním megabajtem paměti) s&nbsp;cílem umožnit procesům vzájemně spolupracovat. Kód v&nbsp;GDI překládal příkazy pro vykreslování do specifických instrukcí různých zařízení: v&nbsp;případě displeje byly měněny body ve [[framebuffer]]u, v&nbsp;případě tiskárny byly příkazy transformovány na pokyny pro tiskárnu. Aby GDI mohlo pracovat s&nbsp;různými zařízeními, načítaly se do paměti programy 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&nbsp;těchto programů volat API funkce knihoven USER a&nbsp; GDI. Tento koncept se nazývá ''dynamické linkování''.
V&nbsp;prvních verzích operačního systému [[Microsoft Windows]] byly všechny procesy spouštěny v&nbsp;jednom [[Správa paměti#Adresový prostor procesu|adresovém prostoru]] paměti počíteče a&nbsp;díky [[Multitasking#Nepreemptivní multitasking|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í ([[API]]) pro vykreslování ([[GDI]], Graphics Device Interface) bylo implementováno v&nbsp;DLL zvané <code>GDI.EXE</code> a&nbsp;uživatelské rozhraní v&nbsp;<code>USER.EXE</code>. Tyto vrstvy nad DOSem byly sdílené pro všechny běžící procesy (pod podmínkou provozu na strojích s&nbsp;alespoň jedním megabajtem paměti) s&nbsp;cílem umožnit procesům vzájemně spolupracovat. Kód v&nbsp;GDI překládal příkazy pro vykreslování do specifických instrukcí různých zařízení: v&nbsp;případě displeje byly měněny body ve [[framebuffer]]u, v&nbsp;případě tiskárny byly příkazy transformovány na pokyny pro tiskárnu. Aby GDI mohlo pracovat s&nbsp;různými zařízeními, načítaly se do paměti programy zvané [[ovladač zařízení|ovladače zařízení]].
 
U&nbsp; nesdílených, tedy ''statických'', knihoven se jejich kód jednoduše ve fázi ''linkování'' přidává do všech jednotlivých programů, které příslušný kód potřebují a volají. V&nbsp;případě dynamického linkování je sdílený kód umístěn do separátního souboru. Programy jsou s&nbsp;těmito soubory spojeny dynamicky pomocí operačního systému. To zlepšuje jak využití paměti, tak správu těchto dat. DLL soubory poskytují standardní výhody [[Knihovna (programování)#Dynamické knihovny|sdílených knihoven]], mezi které patří zejména [[modularita]].; Modularitata umožňuje provést změny v&nbsp;jedné knihovně sdílené více aplikacemi bez nutnosti tyto aplikace modifikovat. Další přínos modularity je v&nbsp;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&nbsp;modelu dílčích objektů [[COM]] (Component Object Model).
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&nbsp;těchto programů volat API funkce knihoven USER a&nbsp;GDI. Tento koncept se nazývá ''dynamické linkování''.
 
V&nbsp; systémech Windows 1.x, 2.x a&nbsp; 3.x sdílejí všechny 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&nbsp;nepřímé [[Meziprocesová komunikace|meziprocesové komunikaci]], ale také to mohlo vést k&nbsp;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 od této doby privátní s&nbsp;výjimkou explicitního vyžádání ze strany knihovny.
U&nbsp;nesdílených, tedy ''statických'', knihoven se jejich kód jednoduše ve fázi ''linkování'' přidává do všech jednotlivých programů, které příslušný kód potřebují a volají. V&nbsp;případě dynamického linkování je sdílený kód umístěn do separátního souboru. Programy jsou s&nbsp;těmito soubory spojeny dynamicky pomocí operačního systému. To zlepšuje jak využití paměti, tak správu těchto dat. DLL soubory poskytují standardní výhody [[Knihovna (programování)#Dynamické knihovny|sdílených knihoven]], mezi které patří zejména [[modularita]]. Modularita umožňuje provést změny v&nbsp;jedné knihovně sdílené více aplikacemi bez nutnosti tyto aplikace modifikovat. Další přínos modularity je v&nbsp;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&nbsp;modelu dílčích objektů [[COM]] (Component Object Model).
 
I&nbsp; když se DLL knihovny staly jádrem architektury systému Windows, mají mnoho nedostatků, které se souhrnně nazývají [[DLL peklo]] ({{Vjazyce2|en|''DLL hell''}}).<!--<ref name="DLL_Hell">{{Citace elektronické monografie
V&nbsp;systémech Windows 1.x, 2.x a&nbsp;3.x sdílejí všechny 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&nbsp;nepřímé [[Meziprocesová komunikace|meziprocesové komunikaci]], ale také to mohlo vést k&nbsp;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 od této doby privátní s&nbsp;výjimkou explicitního vyžádání ze strany knihovny.
 
I&nbsp;když se DLL knihovny staly jádrem architektury systému Windows, mají mnoho nedostatků, které se souhrnně nazývají [[DLL peklo]] ({{Vjazyce2|en|''DLL hell''}}).<ref name="DLL_Hell">{{Citace elektronické monografie
| titul = The End of DLL Hell
| vydavatel = Microsoft Corporation
| url = http://msdn.microsoft.com/en-us/library/ms811694.aspx
| datum přístupu = 2009-07-11}}</ref>--> V&nbsp;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&nbsp; [[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 ==
Vzhledem k&nbsp;tomu, že jsou DLL knihovny v&nbsp;podstatě stejnéshodné jakos EXE soubory, je vhodné použít DLL z&nbsp;důvodu větší přehlednosti programu a&nbsp; jejich možnosti exportu. DLL soubory není možné přímo spouštět, ke spuštění vyžadují EXE soubor, propočínaje operačníWindows systém95 jde o <tt>rundll32.exe</tt> – a nepřijímají [[Meziprocesová komunikace|zprávy]]; Zatozato poskytují mechanizmus pro sdílení kódu a&nbsp; dat, což umožňuje vývojáři aktualizaci funkcí bez nutnosti aplikace znovu linkovat nebo kompilovat. Některé DLL (např. soubory s písmy) obsahují pouze data a žádný kód. Z&nbsp;hlediska vývoje aplikací si lze Windows a&nbsp; 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&nbsp;v&nbsp;novějších verzích OS za předpokladu, že vydavatel OS zajistil, že jejich rozhraní a&nbsp; funkcionalita je kompatibilní.
Knihovny DLL jsou spouštěny v&nbsp;rámci volajícího procesu (tj. probíhajícího programu) a&nbsp; sdílejí s&nbsp;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&nbsp;DLL knihovně.
 
== 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&nbsp;tom, zda je například v&nbsp;sekci povolen zápis nebo je pouze pro čtení a &nbsp;také o tom, zda je vykonatelná (pro [[Strojový kód|kód]]) nebo není (je jen pro [[data]]).
 
Kód v&nbsp;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&nbsp; 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&nbsp; využít je k&nbsp;[[Meziprocesová komunikace|meziprocesové komunikaci]], což může být [[Zranitelnost|bezpečnostní problém]], protože poškození sdílených dat může způsobit nepřijatelné chování jiných procesů, které tato 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, který má vyšší oprávnění. To je důvod, proč se později upustilo od sdílených datových sekcí v&nbsp;DLL knihovnách.
 
=== Rozlišení a importování funkcí ===
Každá funkce exportovaná DLL knihovnou je identifikována číslem a&nbsp; volitelně i&nbsp;jménem. Stejně tak může být funkce importována z&nbsp;DLL buď na základě čísla nebo jména. Číslo reprezentuje pozici ukazatele funkce v&nbsp;tabulce adres exportovaných funkcí a&nbsp; 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&nbsp;moc rychlejší, protože tabulka exportovaných funkcí je seřazena podle jména, takže k&nbsp;nalezení funkce lze použít [[binární vyhledávání]]. V&nbsp;16bitových verzích systému Windows nebyla tabulka řazena, takže vyhledání mohlo být o&nbsp;něco pomalejší.
 
Spustitelný soubor je možné vázat na konkrétní verzi knihovny a&nbsp; zjistit adresu importované funkce již v&nbsp;době kompilace. V&nbsp;takovém případě uloží [[linker]] časovou značku a&nbsp; kontrolní součet knihovny, ze které se importuje. Windows pak za běhu zkontrolují, zda se požadovaná knihovna používá a&nbsp; pokud ano, obejde standardní proces importování. V&nbsp;opačném případě proběhne import klasickou cestou.
 
=== Odložené načtení ===
Řádek 47 ⟶ 64:
{{Citace elektronické monografie
| titul = Linker Support for Delay-Loaded DLLs
| vydavatel = Microsoft Corporation
| url = http://msdn.microsoft.com/en-us/library/151kt790.aspx
| datum přístupu = 2009-07-11}}</ref> V&nbsp;případě, že knihovna není nalezena, nelze ji načíst nebo konkrétní funkce neexistuje, vygeneruje operační systém [[Výjimka|výjimku]], kterou může aplikace zachytit a&nbsp; vhodně ošetřit. Pokud aplikace výjimku nezachytí, operační systém aplikaci ukončí s&nbsp;hlášením o&nbsp;chybě.
 
== Aspekty kompilátoru a programovacího jazyka ==
 
=== Delphi ===
V&nbsp; hlavičce zdrojového kódu se používá klíčové slovo <ttcode>library</ttcode> namísto <ttcode>program</ttcode>. Na konci souboru jsouje funkcevýčet funkcí, (které budou exportovány) vylistovány, v&nbsp;klauzuli <ttcode>exports</ttcode>.
 
[[Object Pascal|Delphi]] nepotřebuje <tt>LIB</tt> soubory pro import funkcí z&nbsp;DLL; k&nbsp;nalinkování DLL je užíváno klíčové slovo <ttcode>external</ttcode> v&nbsp;deklaraci funkce.
 
=== Microsoft Visual Basic ===
[[Visual Basic]] (VB), podporuje jen [[run-time]] nalinkování; navíc ale kromě používání <tt>[[LoadLibrary]]</tt> a&nbsp; <tt>[[GetProcAddress]]</tt> 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 <tt>DLL</tt> soubor nalezen. Vývojář může zachytit chybu a&nbsp; 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<ref>{{citeCitace webelektronické monografie
| lastpříjmení = PetrushaPETRUSHA
| firstjméno = Ron
| titletitul = Creating a&nbsp; Windows DLL with Visual Basic
| authorlink =
| publishervydavatel = O'Reilly Media
| coauthors =
| datedatum vydání = 2005-04-26
| title = Creating a&nbsp;Windows DLL with Visual Basic
| publisher = O'Reilly Media
| date = 2005-04-26
| url = http://www.windowsdevcenter.com/pub/a/windows/2005/04/26/create_dll.html?page=1
| accessdatedatum přístupu = 2009-07-11}}</ref> umožňující programátorovi explicitně zahrnout <tt>[[.DEF]]</tt> soubor linkerem. Ten obsahuje řadovou pozici a&nbsp; jméno každé exportované funkce. To umožňuje vývojáři vytvoření standardních Windows DLL (užitím Visual Basic), které mohou být referencovány „deklaračním“ vyjádřením.
 
=== C a C++ ===
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&nbsp;C++ kódu; toto bylo adoptováno i&nbsp;ostatními Windows [[C (programovací jazyk)|C]] a&nbsp; C++ kompilátory, zahrnujíc Windows verze [[GNU Compiler Collection|GCC]]. Tato rozšíření používají atribut <ttcode>__declspec</ttcode> před deklarací funkce. Jsou-li funkce jazyka C použity skrze jazyk C++, musí být deklarovány jako <ttcode>extern "C"</ttcode> v&nbsp;C++ kódu, pro informaci kompilátoru, že by mělo být použito nalinkování jazyka C.<ref>[http://msdn.microsoft.com/en-us/library/0603949d%28VS(v=vs.80%29140).aspx MSDN], Using extern to Specify Linkage</ref>
 
Mimo specifikování importovaných a&nbsp; exportovaných funkcí užitím <ttcode>__declspec</ttcode> atributů mohou být funkce vypsány v&nbsp;<ttcode>IMPORT</ttcode> nebo <ttcode>EXPORTS</ttcode> sekci <tt>[[.def file|DEF]]</tt> souboru použitém v&nbsp;projektu. <tt>DEF</tt> soubor je zpracován linkerem namísto kompilátoru.
 
Produktem DLL kompilace vyprodukujejsou <tt>DLL</tt> a&nbsp;<tt> LIB</tt> soubory. <tt>LIB soubor, tedy objektová knihovna,<ref name="petzold2" /tt> soubor je použit pro link k&nbsp;DLL během kompilace; není nezbytný pro run-time linkování. Pokud váš DLL je [[Component Object Model]] (COM) server, musí být <tt>DLL</tt> soubor umístěn v&nbsp;jednom z&nbsp;adresářů zapsaných v&nbsp;systémové proměnné <ttcode>PATH</ttcode> 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í <codett>regsvr32.exe</codett>, který umístí lokaci DLL a&nbsp; jeho globální unikátní ID ([[GUID]]) do registrů. Programy poté mohou použít DLL vyhledáním jeho GUID v&nbsp;registrech k&nbsp;nalezení jeho lokace (cesty).
 
== Odkazy ==
 
== Reference ==
<references/>
 
=== Literatura ===
* {{citace monografie
| příjmení = PETZOLD
| jméno = Charles
| titul = Programování ve Windows: legendární publikace o programování Win32 API
| překladatelé = Aleš Polcar, Jiří Veselský
| vydání = 1
| vydavatel = Computer Press
| místo = Praha
| rok = 1999
| rok copyrightu = 1999
| počet stran = 1216
| edice = Programování
| isbn = 80-7226-206-8
| poznámka = Obsahuje rejstřík
| jazyk = česky
}}
 
[[Kategorie:Souborové formáty]]