Omdat DLL ’s in wezen hetzelfde zijn als EXE’ s, waarvan de keuze om te produceren als onderdeel van het koppelen proces is voor de duidelijkheid, omdat het mogelijk is om functies en gegevens uit beide te exporteren.

Het is niet mogelijk om een DLL direct uit te voeren, omdat het een EXE vereist voor het besturingssysteem om het via een invoerpunt te laden, vandaar het bestaan van hulpprogramma ‘ s zoals RUNDLL.EXE of RUNDLL32.EXE die het toegangspunt en minimale framework bieden voor dll ‘ s die voldoende functionaliteit bevatten om uit te voeren zonder veel ondersteuning.,

DLL ‘ s bieden een mechanisme voor gedeelde code en gegevens, waardoor een ontwikkelaar van gedeelde code/gegevens functionaliteit kan upgraden zonder dat toepassingen opnieuw moeten worden gekoppeld of opnieuw moeten worden gecompileerd. Vanuit het oogpunt van de ontwikkeling van de toepassing Windows en OS / 2 kan worden beschouwd als een verzameling DLL ‘ s die zijn geüpgraded, waardoor toepassingen voor een versie van het besturingssysteem te werken in een latere, op voorwaarde dat de OS-leverancier heeft ervoor gezorgd dat de interfaces en functionaliteit compatibel zijn.,

DLL ‘ s worden uitgevoerd in de geheugenruimte van het aanroepende proces en met dezelfde toegangsrechten, wat betekent dat er weinig overhead in hun gebruik is, maar ook dat er geen bescherming is voor de aanroepende EXE als de DLL een soort bug heeft.

Geheugenbeheerdit

in Windows API worden de DLL-bestanden georganiseerd in secties. Elke sectie heeft zijn eigen set attributen, zoals beschrijfbaar of alleen-lezen, uitvoerbaar (voor code) of niet-uitvoerbaar (voor gegevens), enzovoort.,

de code in een DLL wordt meestal gedeeld tussen alle processen die de DLL gebruiken; dat wil zeggen, ze nemen één plaats in het fysieke geheugen in en nemen geen ruimte in in het paginabestand. Windows maakt geen gebruik van positie-onafhankelijke code voor de DLL ‘ s; in plaats daarvan de code ondergaat verhuizing als het wordt geladen, de vaststelling van adressen voor alle invoerpunten op locaties die vrij zijn in de geheugenruimte van het eerste proces om de DLL te laden., In oudere versies van Windows, waarin alle actieve processen een gemeenschappelijke adresruimte bezetten, zou een enkele kopie van de DLL-code altijd voldoende zijn voor alle processen. Echter, in nieuwere versies van Windows die aparte adresruimtes voor elk programma gebruiken, is het alleen mogelijk om dezelfde verplaatste kopie van de DLL te gebruiken in meerdere programma ‘ s als elk programma dezelfde virtuele adressen vrij heeft om de code van de DLL tegemoet te komen., Als sommige programma ’s (of hun combinatie van reeds geladen DLL’ s) deze adressen niet gratis hebben, dan moet een extra fysieke kopie van de DLL-code worden gemaakt, met behulp van een andere set van verplaatste toegangspunten. Als het fysieke geheugen dat door een codegedeelte wordt ingenomen, moet worden teruggewonnen, wordt de inhoud ervan weggegooid en later direct opnieuw geladen vanuit het DLL-bestand als dat nodig is.

in tegenstelling tot code secties, zijn de data secties van een DLL meestal privé; dat wil zeggen, elk proces dat de DLL gebruikt heeft zijn eigen kopie van alle data van de DLL., Optioneel kunnen datasecties gedeeld worden, waardoor interprocescommunicatie via dit gedeelde geheugengebied mogelijk is. Omdat gebruikersbeperkingen echter niet van toepassing zijn op het gebruik van gedeeld DLL-geheugen, creëert dit een beveiligingslek; namelijk, één proces kan de gedeelde gegevens beschadigen, wat er waarschijnlijk voor zal zorgen dat alle andere delen processen zich ongewenst gedragen. Een proces dat wordt uitgevoerd onder een gastaccount kan bijvoorbeeld een ander proces dat wordt uitgevoerd onder een geprivilegieerd account beschadigen. Dit is een belangrijke reden om het gebruik van gedeelde secties in dll ‘ s te vermijden.,

als een DLL gecomprimeerd is door bepaalde uitvoerbare pakketten (bijvoorbeeld UPX), worden alle codesecties gemarkeerd als lezen en schrijven, en worden ze niet gedeeld. Lees-en-schrijf code secties, net als privé data secties, zijn privé voor elk proces. Dus DLL ’s met gedeelde data secties moeten niet worden gecomprimeerd als ze bedoeld zijn om gelijktijdig te worden gebruikt door meerdere programma’ s, omdat elk programma instantie zijn eigen kopie van de DLL zou moeten dragen, wat resulteert in een verhoogd geheugenverbruik.

import librariesEdit

net als statische libraries worden import libraries voor dll ‘ s opgemerkt door de .,lib bestandsextensie. Bijvoorbeeld, kernel32.dll, de primaire dynamische bibliotheek voor Windows ‘ basisfuncties zoals het maken van bestanden en geheugenbeheer, is gekoppeld via kernel32.lib. De gebruikelijke manier om een importbibliotheek te onderscheiden van een juiste statische bibliotheek is door de grootte: de importbibliotheek is veel kleiner omdat het alleen symbolen bevat die verwijzen naar de werkelijke DLL, die op link-time verwerkt moet worden. Beide zijn echter Unix ar-bestanden.

linken naar dynamische bibliotheken wordt meestal afgehandeld door linken naar een importbibliotheek bij het bouwen of linken naar een uitvoerbaar bestand., Het gemaakte uitvoerbare bestand bevat vervolgens een import address table (IAT) waarmee alle DLL-functie aanroepen worden verwezen (elke DLL-functie bevat zijn eigen ingang in de IAT). Tijdens het draaien wordt de IAT gevuld met de juiste adressen die direct verwijzen naar een functie in de afzonderlijk geladen DLL.

in Cygwin/MSYS en MinGW krijgen importbibliotheken gewoonlijk het achtervoegsel .dll.a, waarbij zowel het Windows DLL-achtervoegsel als het Unix ar-achtervoegsel worden gecombineerd., Het bestandsformaat is vergelijkbaar, maar de symbolen die worden gebruikt om de import te markeren zijn verschillend (_head_foo_dll vs _ _ IMPORT _ DESCRIPTOR _ foo). Hoewel de GNU Binutils toolchain importbibliotheken kan genereren en ernaar kan linken, is het sneller om rechtstreeks naar de DLL te linken. Een experimentele tool in MinGW genaamd genlib kan worden gebruikt om import libs te genereren met MSVC-stijl symbolen.

Symboolresolutie en bindbedit

elke functie die door een DLL wordt geëxporteerd, wordt geïdentificeerd door een numerieke ordinaal en eventueel een naam. Ook kunnen functies uit een DLL worden geïmporteerd door ordinaal of door naam., De ordinaal vertegenwoordigt de positie van de adresaanwijzer van de functie in de DLL-adreslijst exporteren. Het is gebruikelijk dat interne functies alleen door ordinaal worden geëxporteerd. Voor de meeste Windows API-functies worden alleen de namen bewaard in verschillende Windows-releases; de ordinals kunnen worden gewijzigd. Zo kan men niet betrouwbaar importeren Windows API functies door hun ordinals.

het importeren van functies per ordinaal levert slechts iets betere prestaties dan het importeren van functies op naam: exporttabellen van DLL ‘ s worden geordend op naam, zodat een binaire zoekopdracht kan worden gebruikt om een functie te vinden., De index van de gevonden naam wordt dan gebruikt om de ordinaal op te zoeken in de export ordinaal tabel. In 16-bit vensters was de naamtabel niet gesorteerd, dus de naam lookup overhead was veel meer merkbaar.

het is ook mogelijk om een uitvoerbaar bestand te binden aan een specifieke versie van een DLL, dat wil zeggen om de adressen van geïmporteerde functies op te lossen tijdens het compileren. Voor gebonden import slaat de linker de tijdstempel en checksum op van de DLL waaraan de import gebonden is. Bij run-time Windows controleert om te zien of dezelfde versie van de bibliotheek wordt gebruikt, en zo ja, Windows omzeilt het verwerken van de invoer., Anders, als de bibliotheek is anders dan degene die was gebonden aan, Windows verwerkt de import op een normale manier.

geladen uitvoerbare bestanden worden iets sneller geladen als ze worden uitgevoerd in dezelfde omgeving waarvoor ze zijn gecompileerd, en precies dezelfde tijd als ze worden uitgevoerd in een andere omgeving, dus er is geen nadeel voor het binden van de import. Bijvoorbeeld, alle standaard Windows-toepassingen zijn gebonden aan het systeem dll ‘ s van hun respectieve Windows release. Een goede kans om de import van een toepassing te binden aan de doelomgeving is tijdens de installatie van de toepassing., Dit houdt de bibliotheken ‘gebonden’ tot de volgende OS-update. Het verandert echter wel de checksum van het uitvoerbare bestand, dus het is niet iets dat kan worden gedaan met ondertekende programma ‘s, of programma’ s die worden beheerd door een configuratiebeheerprogramma dat checksums gebruikt (zoals MD5 checksums) om bestandsversies te beheren. Zoals meer recente Windows-versies zijn verhuisd van het hebben van vaste adressen voor elke geladen bibliotheek (om veiligheidsredenen), de mogelijkheid en waarde van het binden van een uitvoerbaar bestand neemt af.,

expliciete runtime linkingEdit

DLL-bestanden kunnen expliciet worden geladen tijdens runtime, een proces dat door Microsoft simpelweg wordt aangeduid als runtime dynamic linking, met behulp van deLoadLibrary (ofLoadLibraryEx) API-functie. De API – functie GetProcAddress wordt gebruikt om geëxporteerde symbolen op naam op te zoeken, en FreeLibrary – om de DLL uit te laden. Deze functies zijn analoog aan dlopen, dlsym, en dlclose in de POSIX standaard API.,

de procedure voor expliciete runtime linking is hetzelfde in elke taal die pointers naar functies ondersteunt, omdat het afhangt van de Windows API in plaats van taalconstructies.

vertraagde loadingEdit

normaal gesproken zal een toepassing die gekoppeld is aan de IMPORTBIBLIOTHEEK van een DLL niet starten als de DLL niet gevonden kan worden, omdat Windows de toepassing niet zal uitvoeren tenzij het alle DLL ‘ s kan vinden die de toepassing nodig heeft. Een toepassing kan echter gekoppeld worden aan een importbibliotheek om vertraging in het laden van de dynamische bibliotheek toe te staan.,In dit geval zal het besturingssysteem niet proberen om de DLL te vinden of te laden wanneer de toepassing start; in plaats daarvan is een stub opgenomen in de toepassing door de linker die zal proberen om de DLL te vinden en te laden via LoadLibrary en GetProcAddress wanneer een van de functies wordt aangeroepen. Als de DLL niet kan worden gevonden of geladen, of de aangeroepen functie niet bestaat, zal de toepassing een uitzondering genereren, die kan worden gevangen en op de juiste manier worden behandeld. Als de toepassing de uitzondering niet behandelt, zal het worden gevangen door het besturingssysteem, dat het programma zal beëindigen met een foutmelding.,

het delay-loading mechanisme biedt ook notificatiehaken, waardoor de toepassing extra verwerking of foutafhandeling kan uitvoeren wanneer de DLL wordt geladen en / of een DLL-functie wordt aangeroepen.