I informatikk er et bibliotek eller, kalt ved hjelp av språk, et bibliotek et sett med funksjonelle implementeringer, kodet i et programmeringsspråk , som tilbyr et veldefinert grensesnitt for funksjonaliteten som påberopes.
I motsetning til et kjørbart program, forventer ikke atferden implementert av et bibliotek å bli brukt autonomt (et program gjør det: det har et hovedinngangspunkt), men formålet er å brukes av andre programmer, uavhengig og samtidig. På den annen side trenger ikke oppførselen til et bibliotek være for forskjellig fra det som kan spesifiseres i et program. Videre kan noen biblioteker kreve at andre fungerer, siden atferden de definerer avgrenser eller endrer oppførselen til det originale biblioteket; eller gjør den tilgjengelig for en annen teknologi eller programmeringsspråk.
Biblioteker kan kobles til et program (eller til et annet bibliotek) ved forskjellige utviklings- eller utførelsespunkter, avhengig av hvilken type kobling du ønsker å etablere, som beskrevet i avsnittet "Typer".
De fleste moderne operativsystemer tilbyr biblioteker som implementerer systemtjenester. På denne måten har disse tjenestene blitt et «råmateriale» som enhver moderne applikasjon forventer at operativsystemet skal tilby. Som sådan er det meste av koden som brukes av moderne applikasjoner gitt i disse bibliotekene.
Begrepet bokhandel brukes vanligvis for å referere til et bibliotek, på grunn av dets likhet med det originale engelske biblioteket . Begge ordene, «bibliotek» og «bokhandel», er korrekte i henhold til definisjonene ( bibliotek , [ 1 ] bokhandel [ 2 ] ) til RAE . Til tross for det foregående, i henhold til en bokstavelig oversettelse, vil den korrekte betydningen være bibliotek , siden den engelske termen for "bokhandel" er bokhandel eller bokhandel (bokstavelig talt: "bokhandel"), eller bokhylle (hylle eller møbler for oppbevaring av bøker ). , bokhandel eller bokhandler). En mer direkte og bokstavelig oversettelse enn "bokhandel" vil være begrepet: "bokhandler". Det er også vanlig å referere til det med ordet av angelsaksisk opprinnelse verktøysett (sett, utstyr, koffert, eske, etui, sett (sett) med verktøy).
Tidlige biblioteklignende programmeringskonsepter forsøkte å skille datadefinisjoner fra programimplementering. COMPOOL ( Communication Pool)-konseptet ble popularisert av JOVIAL i 1959, selv om det lånte ideen fra programvaren til de store SAGE -systemene . Etter de datavitenskapelige prinsippene for problemseparasjon (isolering av små problemer som er enkle å takle) og informasjonsskjuling , "er formålet med COMPOOL å tillate utveksling av systemdata mellom ulike programmer, og gi en sentralisert beskrivelse av dem" (Wexelblat 1981: 369).
COBOL inkluderte et tidlig system av biblioteker i 1959 (Wexelblat 1981:274), men Jean Sammet beskrev dem retrospektivt som utilstrekkelige bibliotekressurser (Wexelblat 1981:258).
Et annet av de store bidragene til det moderne konseptet til biblioteket var innovasjonen av FORTRAN - appleten . Disse kan kompileres uavhengig av hverandre, men kompilatoren mangler en linker , så typesjekking mellom underprogrammer er umulig (Wilson et. al. 1988:126).
Til slutt bør nevnes innflytelsen som Simula 67 hadde på konseptet "bibliotek". Simula er det første objektorienterte programmeringsspråket , og dets klasser er nesten identiske med det nåværende konseptet som brukes i Java , C++ og C# . Simula-klassekonseptet var også opphavet til Ada - pakken og Modula-2- modulen ( Wilson et. al. 1988:52). Til tross for at de ble utviklet i 1965, kunne Simula-klasser inkluderes i biblioteksfiler og legges til ved kompilering (Wexelblat 1981:716).
Historisk sett kunne biblioteker bare være statiske. Et statisk bibliotek, også kjent som et arkiv , er en containerfil med flere objektkodefiler pakket inne, som under koblingsprosessen, under kompilering, vil bli kopiert og flyttet (om nødvendig) i den endelige kjørbare filen, sammen med resten av objektkodefilene. Denne prosessen, og den kjørbare filen, er kjent som en statisk oppbygging av målapplikasjonen. I dette tilfellet fungerer biblioteket ganske enkelt som en beholder for objektkodefiler som ikke skiller seg (mer enn semantisk) fra de mellomliggende objektfilene produsert under forrige programkompileringsstadium. I den statiske konstruksjonen av kompilerte filer blir adressene til de sammensatte subrutinene løst ved kompilering (mer spesifikt, på koblingsstadiet), slik at referanser til bibliotekssubrutiner løses statisk, på samme måte som referanser til enhver annen funksjon. av programmet. Dermed blir den faktiske adressen, referanser for hopp og andre rutineanrop lagret i en relativ eller symbolsk adresse.
Linkeren løser alle uløste adresser ved å konvertere dem til faste eller flyttbare adresser (fra en felles base) ved å laste all kode (inkludert biblioteker) inn i minneplasseringer under kjøring. Denne koblingsprosessen kan ta enda lengre tid enn kompileringsprosessen, og må gjøres hver gang en av modulene rekompileres.
En linker kan fungere på spesifikke typer objektfiler, og krever derfor spesifikke (kompatible) typer biblioteker. Rekompilerte objektfiler i et bibliotek kan enkelt distribueres og brukes. En klient, enten det er et program eller et annet bibliotek, får tilgang til et bibliotekobjekt ved kun å referere til navnet. Koblingsprosessen løser referansene ved å søke i bibliotekene i gitt rekkefølge. Vanligvis anses det ikke som en feil hvis et navn kan finnes flere ganger i et gitt sett med biblioteker.
Dynamiske , dynamisk koblede eller dynamiske lenkebiblioteker er filer som inneholder objektkode konstruert uavhengig av deres plassering [ 3 ] på en slik måte at de er forberedt på å bli forespurt og lastet inn under kjøring av et hvilket som helst program, i stedet for å måtte være koblet, tidligere, på kompileringstidspunktet. Derfor må de være tilgjengelige som filer uavhengig av det kjørbare programmet (vanligvis i systemkataloger). I koblingsprosessen (på kompileringstidspunktet) genereres en kjørbar fil med merknader om hvilke dynamiske biblioteker den krever (men ikke hvor man finner dem), og "skisse" funksjoner som tar seg av å delegere funksjonskallet til den dynamiske lasteren (eller dynamic-loader ) (på Linux, ld.so). I resten av programmet endres kallene til bibliotekfunksjonene til et kall til sketcher-funksjonen generert av linkeren.
På den annen side, når den kjørende applikasjonen trenger å få tilgang til rutinene som er lagret i et dynamisk bibliotek, og utfører skissefunksjonen, vil den dynamiske lenkelasteren kunne erstatte dette kallet med den faktiske funksjonen til det dynamiske biblioteket, og laste det inn i minnet hvis det ikke allerede var det, og kartlegge sidene av det til minneplassen til programmets prosess .
På noen operativsystemer kan du bestemme om et bibliotek skal være tilgjengelig umiddelbart eller bare når det refereres til en funksjon i det. Hvis sistnevnte bestemmes, vil et fenomen kalt load delay dukke opp , avledet fra å måtte laste biblioteket fra sekundærminnet, hvis det ikke allerede var i minnet, og justere det til adresserommet til programmet som det er koblet til.
Fordelene med dynamisk kobling fremfor statisk kobling er at den tillater gjenbruk ikke bare av kode, men av fysisk plass: den samme delte biblioteksfilen kan brukes av flere programmer uten at de kopierer innholdet i dem. Dette kan være ganske mye plass, avhengig av antall biblioteker et program krever. Hovedminne (RAM) kan også gjenbrukes for programmer som bruker samme bibliotek (for eksempel kan det hende at Qt -biblioteker må lastes bare én gang for alle programmer som bruker dem).
På den annen side er den største ulempen den økte innlastingstiden (på grunn av å måtte finne bibliotekfilen, laste den inn og flytte anropene i programmet) og den økte indirektionen når du kaller bibliotekfunksjonene. biblioteket.
Dynamisk kobling , i sin natur, har bare begrensningene som er angitt av programvarelisensene .
Teknologien som tillater dynamisk kobling av biblioteker er svært nyttig for å bygge plugins , spesielt når noen biblioteker kan erstattes av andre med lignende grensesnitt, men annen funksjonalitet. Programvare kan sies å ha en "plugin-arkitektur" dersom den bruker biblioteker med grunnleggende funksjonalitet som er ment å erstattes. Men bruken av dynamisk koblede biblioteker i en applikasjons arkitektur betyr ikke nødvendigvis at de kan erstattes.
Dynamisk kobling ble opprinnelig utviklet i Multics- operativsystemer som startet i 1964. Det var en funksjon i MTS ( Michigan Terminal System ), bygget på slutten av 1960-tallet .[ 4 ]
På forskjellige operativsystemer tar de forskjellige navn, for eksempel:
Et av problemene som lasteren må håndtere er at den faktiske plasseringen av bibliotekdataene ikke kan kjennes før den kjørbare filen og alle dynamiske biblioteker som har blitt koblet er lastet inn i minnet. Det er fordi plasseringene i minnet avhenger av hvilke dynamiske biblioteker som er lastet inn. Det er ikke mulig å avhenge av den absolutte adressen til dataene i den kjørbare filen, eller til og med i biblioteket, da det kan være konflikter mellom de forskjellige bibliotekene: hvis to av dem brukte de samme adressene eller adressene deres overlappet, ville det være umulig å bruke begge på samme måte. samme program.
Men i praksis, på mange systemer endres ikke bibliotekene ofte. Derfor er det mulig å beregne en sannsynlig lasteadresse for hvert delt bibliotek på systemet før det brukes, og lagre denne informasjonen i biblioteker og kjørbare filer. Hvis hvert bibliotek som lastes blir behandlet slik, vil hver av dem bli lastet på forhåndsbestemte adresser, noe som øker hastigheten på den dynamiske koblingsprosessen. Denne optimaliseringen er kjent som Prebinding på Mac OS X og Prelinking på Linux.
Ulempene med denne teknikken er tiden som kreves for å forhåndsberegne adresser hver gang de delte bibliotekene endres, manglende evne til å bruke teknikker som randomisering av adresserom og forbruket av virtuelt adresserom (et problem som reduseres ved bruk av 64-bits arkitekturer) , i det minste for øyeblikket).
En gammel metode var å undersøke programmet ved lastetid. Når alle bibliotekene er lastet, erstattes alle datareferanser i bibliotekene med pekere til passende minneplasseringer. I Windows 3.1 (og noen innebygde systemer som Texas Instruments-kalkulatorer) ble referanser håndtert som koblede lister, noe som muliggjorde enkel oppregning og erstatning. Nå binder de fleste dynamiske biblioteker en symboltabell med tomme adresser inn i programmet på kompileringstidspunktet. Alle referanser til kode eller data i biblioteket går gjennom denne tabellen. Ved innlastingstid endres tabellen med adressen til dataene/koden av linkeren. Denne prosessen er treg og påvirker hastigheten til programmer som kontinuerlig kaller andre programmer, for eksempel noen shell-skript.
Biblioteket inneholder en grentabell over alle metodene det inneholder, kalt inngangspunkter . Samtaler i biblioteket "hopper over" bordet, ser etter plasseringen av koden i minnet, og ber deretter om den. Disse forespørslene er svært stressende, men forsinkelsen er vanligvis så liten at den er ubetydelig.
Lokalisering av kjøretidsbibliotekerDynamiske linkere/lastere har svært bred funksjonalitet. Noen er avhengige av eksplisitte stier til biblioteker som er lagret i kjørbare filer. Enhver endring i filsystemnomenklatur eller design vil føre til at disse systemene mislykkes. Vanligvis er bare biblioteknavnet (ikke banen) lagret i den kjørbare filen, med operativsystemet som gir mekanismen for å finne biblioteket på disken ved hjelp av visse algoritmer.
En av de største ulempene med dynamisk kobling er at riktig drift av de kjørbare filene avhenger av en rekke biblioteker lagret isolert. Hvis biblioteket slettes, flyttes eller får nytt navn, eller hvis en inkompatibel versjon av DLL-en kopieres til en plassering som vises tidligere i søkebanen, vil den kjørbare filen ikke lastes inn. På Windows er dette kjent som DLL helvete .
Unix-systemerDe fleste Unix-lignende systemer har en "søkebane" som spesifiserer filsystemkatalogene der det skal søkes etter dynamiske biblioteker. På noen systemer er standardbanen spesifisert i en konfigurasjonsfil; i andre er det hardkodet i den dynamiske lasteren. Noen kjørbare filformater kan spesifisere flere kataloger for å søke etter biblioteker for et gitt program. Dette kan vanligvis overstyres av en miljøvariabel , selv om den er deaktivert for programmer som har setuid eller setgid , slik at brukeren ikke kan tvinge programmet til å kjøre vilkårlig kode. Det anbefales at bibliotekutviklere legger sine dynamiske biblioteker i kataloger som er i standardsøkebanen. Tvert imot kan dette gjøre installasjonen av nye biblioteker problematisk, siden det får disse katalogene til å vokse mye og bli kompliserte.
En annen løsning på bibliotekproblemet er å bruke helt separate kjørbare filer (ofte en lett versjon) og eksterne prosedyrekall (RPC) over nettverket til en annen datamaskin eller datamaskin. Denne tilnærmingen maksimerer gjenbruk av operativsystemet: koden som trengs for å støtte biblioteket, er den samme som brukes til å gi applikasjonen støtte og sikkerhet for alle andre programmer. I tillegg vil disse systemene ikke kreve at biblioteket lagres på samme maskin, og kan omdirigere forespørselen over nettverket.
En slik tilnærming innebærer imidlertid at hvert kall til biblioteket vil kreve en stor mengde overhead . RPC-anrop er mye dyrere enn prosedyreanrop på selve maskinen. Denne tilnærmingen brukes ofte i RPC-intensive distribuerte arkitekturer, i klient-serversystemer og i applikasjoner som Enterprise JavaBeans .