लाइब्रेरी (कंप्यूटिंग)

"Software library" redirects here. Not to be confused with library software.

This article is about a software development concept. For a repository of digital assets, see Digital library.

एक एप्लिकेशन का चित्रण जो Ogg Vorbis फ़ाइल को चलाने के लिए libvorbisfile का उपयोग करता है

कंप्यूटर विज्ञान में, लाइब्रेरी गैर-वाष्पशील मेमोरी|गैर-वाष्पशील संसाधनों का एक संग्रह है जिसका उपयोग कंप्यूटर प्रोग्राम द्वारा अक्सर सॉफ्टवेयर विकास के लिए किया जाता है। इनमें कॉन्फ़िगरेशन डेटा, दस्तावेज़ीकरण, सहायता डेटा, संदेश टेम्पलेट, कोड पुन: उपयोग|पूर्व-लिखित कोड और सबरूटीन, क्लास (कंप्यूटर विज्ञान), मान (कंप्यूटर विज्ञान) या डेटा प्रकार विनिर्देश शामिल हो सकते हैं। ओएस/360 और उसके उत्तराधिकारियों में|आईबीएम के ओएस/360 और उसके उत्तराधिकारियों को डेटा सेट (आईबीएम मेनफ्रेम)#विभाजित डेटासेट के रूप में संदर्भित किया जाता है। एक पुस्तकालय व्यवहार के कार्यान्वयन का एक संग्रह भी है, जो एक भाषा के संदर्भ में लिखा गया है, जिसमें एक अच्छी तरह से परिभाषित इंटरफ़ेस (कंप्यूटिंग) है जिसके द्वारा व्यवहार को लागू किया जाता है। उदाहरण के लिए, जो लोग उच्च-स्तरीय प्रोग्राम लिखना चाहते हैं, वे सिस्टम कॉल को बार-बार लागू करने के बजाय सिस्टम कॉल करने के लिए लाइब्रेरी का उपयोग कर सकते हैं। इसके अलावा, व्यवहार को कई स्वतंत्र कार्यक्रमों द्वारा पुन: उपयोग के लिए प्रदान किया जाता है। एक प्रोग्राम भाषा के एक तंत्र के माध्यम से पुस्तकालय द्वारा प्रदत्त व्यवहार का आह्वान करता है। उदाहरण के लिए, सी (प्रोग्रामिंग भाषा) जैसी सरल अनिवार्य भाषा में, लाइब्रेरी में व्यवहार को सी के सामान्य फ़ंक्शन-कॉल का उपयोग करके लागू किया जाता है। कॉल को लाइब्रेरी फ़ंक्शन के रूप में और उसी प्रोग्राम में किसी अन्य फ़ंक्शन के रूप में अलग करने का तरीका सिस्टम में कोड को व्यवस्थित करने का तरीका है। लाइब्रेरी कोड को इस तरह से व्यवस्थित किया जाता है कि इसका उपयोग कई प्रोग्रामों द्वारा किया जा सकता है जिनका एक-दूसरे से कोई संबंध नहीं होता है, जबकि कोड जो एक प्रोग्राम का हिस्सा होता है उसे केवल उस एक प्रोग्राम के भीतर उपयोग करने के लिए व्यवस्थित किया जाता है। जब कोई प्रोग्राम बड़ा हो जाता है, जैसे मल्टी-मिलियन-लाइन प्रोग्राम, तो यह अंतर एक पदानुक्रमित धारणा प्राप्त कर सकता है। उस स्थिति में, ऐसे आंतरिक पुस्तकालय हो सकते हैं जिनका बड़े प्रोग्राम के स्वतंत्र उप-भागों द्वारा पुन: उपयोग किया जाता है। विशिष्ट विशेषता यह है कि एक पुस्तकालय को स्वतंत्र कार्यक्रमों या उप-कार्यक्रमों द्वारा पुन: उपयोग किए जाने के उद्देश्य से व्यवस्थित किया जाता है, और उपयोगकर्ता को केवल इंटरफ़ेस जानने की आवश्यकता होती है, न कि पुस्तकालय के आंतरिक विवरण की।

किसी लाइब्रेरी का मूल्य मानकीकृत प्रोग्राम तत्वों के पुन: उपयोग में निहित है। जब कोई प्रोग्राम किसी लाइब्रेरी का आह्वान करता है, तो वह उस व्यवहार को लागू किए बिना ही उस लाइब्रेरी के अंदर लागू व्यवहार को प्राप्त कर लेता है। पुस्तकालय मॉड्यूलर प्रोग्रामिंग फैशन में कोड साझा करने को प्रोत्साहित करते हैं और कोड के वितरण को आसान बनाते हैं।

लाइब्रेरी द्वारा कार्यान्वित व्यवहार को विभिन्न प्रोग्राम जीवनचक्र चरणों में इनवोकिंग प्रोग्राम से जोड़ा जा सकता है। यदि लाइब्रेरी के कोड को इनवोकिंग प्रोग्राम के निर्माण के दौरान एक्सेस किया जाता है, तो लाइब्रेरी को स्थैतिक पुस्तकालय कहा जाता है। एक विकल्प यह है कि इनवोकिंग प्रोग्राम के निष्पादन योग्य का निर्माण किया जाए और उसे लाइब्रेरी कार्यान्वयन से स्वतंत्र रूप से वितरित किया जाए। निष्पादन योग्य को निष्पादित करने के बाद लाइब्रेरी व्यवहार जुड़ा हुआ है, या तो निष्पादन शुरू करने की प्रक्रिया के हिस्से के रूप में, या निष्पादन के बीच में। इस मामले में लाइब्रेरी को गतिशील पुस्तकालय (रनटाइम (प्रोग्राम जीवनचक्र चरण) पर लोड) कहा जाता है। निष्पादन के लिए प्रोग्राम तैयार करते समय लिंकर (कंप्यूटिंग) द्वारा एक गतिशील लाइब्रेरी को लोड और लिंक किया जा सकता है। वैकल्पिक रूप से, निष्पादन के बीच में, एक एप्लिकेशन स्पष्ट रूप से अनुरोध कर सकता है कि एक मॉड्यूल गतिशील लोडिंग हो।

अधिकांश संकलित भाषाओं में एक मानक लाइब्रेरी होती है, हालाँकि प्रोग्रामर अपनी स्वयं की मानक पुस्तकालय भी बना सकते हैं। अधिकांश आधुनिक सॉफ्टवेयर सिस्टम लाइब्रेरी प्रदान करते हैं जो अधिकांश सिस्टम सेवाओं को लागू करते हैं। ऐसे पुस्तकालयों ने उन सेवाओं को व्यवस्थित किया है जिनकी आधुनिक अनुप्रयोग के लिए आवश्यकता होती है। इस प्रकार, आधुनिक अनुप्रयोगों द्वारा उपयोग किया जाने वाला अधिकांश कोड इन सिस्टम लाइब्रेरीज़ में प्रदान किया जाता है।

इतिहास

कंप्यूटर लाइब्रेरी का विचार चार्ल्स बैबेज द्वारा बनाए गए पहले कंप्यूटर से जुड़ा है। उनके विश्लेषणात्मक इंजन पर 1888 के एक पेपर में सुझाव दिया गया कि कंप्यूटर संचालन को संख्यात्मक इनपुट से अलग कार्डों पर पंच किया जा सकता है। यदि इन ऑपरेशन पंच कार्डों को पुन: उपयोग के लिए सहेजा जाता तो धीरे-धीरे इंजन के पास अपनी एक लाइब्रेरी होती।

एक महिला ईडीएसएसी कंप्यूटर के लिए छिद्रित टेप की रीलों पर सबरूटीन लाइब्रेरी वाली फाइलिंग कैबिनेट के बगल में काम कर रही है।

1947 में हरमन गोल्डस्टाइन और जॉन वॉन न्यूमैन ने अनुमान लगाया कि आईएएस मशीन पर अपने काम के लिए सबरूटीन्स की एक लाइब्रेरी बनाना उपयोगी होगा, एक प्रारंभिक कंप्यूटर जो उस समय तक चालू नहीं था। उन्होंने चुंबकीय तार रिकॉर्डिंग की एक भौतिक लाइब्रेरी की कल्पना की, जिसमें प्रत्येक तार में पुन: प्रयोज्य कंप्यूटर कोड संग्रहीत था।

वॉन न्यूमैन से प्रेरित होकर, मौरिस विल्केस और उनकी टीम ने ईडीएसएसी का निर्माण किया। छिद्रित टेप की एक फाइलें रखने की अलमारी में इस कंप्यूटर के लिए सबरूटीन लाइब्रेरी थी। ईडीएसएसी के कार्यक्रमों में एक मुख्य कार्यक्रम और सबरूटीन लाइब्रेरी से कॉपी किए गए सबरूटीन्स का एक क्रम शामिल होता है। 1951 में टीम ने प्रोग्रामिंग पर पहली पाठ्यपुस्तक, इलेक्ट्रॉनिक डिजिटल कंप्यूटर के लिए प्रोग्राम की तैयारी, प्रकाशित की, जिसमें लाइब्रेरी के निर्माण और उद्देश्य का विवरण दिया गया था। COBOL ने 1959 में एक पुस्तकालय प्रणाली के लिए आदिम क्षमताओं को शामिल किया, लेकिन जीन ई. सम्मेट ने उन्हें पूर्वव्यापी रूप से अपर्याप्त पुस्तकालय सुविधाओं के रूप में वर्णित किया।

उल्लासपूर्ण के पास एक संचार पूल (COMPOOL) था, जो मोटे तौर पर हेडर फ़ाइलों की एक लाइब्रेरी थी।

आधुनिक पुस्तकालय अवधारणा में एक और प्रमुख योगदानकर्ता फोरट्रान के Subprogram नवाचार के रूप में आया। फोरट्रान उपप्रोग्रामों को एक दूसरे से स्वतंत्र रूप से संकलित किया जा सकता है, लेकिन कंपाइलर में लिंकर (कंप्यूटिंग) का अभाव था। इसलिए फोरट्रान-90 में मॉड्यूल की शुरूआत से पहले, फोरट्रान के बीच टाइप चेकिंग करें रेफरी समूह = एनबी>यह पहले संभव था, उदाहरण के लिए, एडा उपप्रोग्राम।</ref> उपप्रोग्राम असंभव था।

1960 के दशक के मध्य तक, असेंबलरों के लिए कॉपी और मैक्रो लाइब्रेरी आम थीं। आईबीएम सिस्टम/360 की लोकप्रियता के साथ शुरू होकर, अन्य प्रकार के टेक्स्ट तत्वों, जैसे सिस्टम पैरामीटर, वाले पुस्तकालय भी आम हो गए।

शुरुआत पहली ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग भाषा थी, और इसकी कक्षा (कंप्यूटर विज्ञान) जावा (प्रोग्रामिंग भाषा), सी ++ और सी शार्प (प्रोग्रामिंग भाषा) | सी # में उपयोग की जाने वाली आधुनिक अवधारणा के लगभग समान थी। सिमुला की वर्ग अवधारणा एडा (प्रोग्रामिंग भाषा) में पैकेज और मॉड्यूला-2 के मॉड्यूल की भी पूर्वज थी। मूल रूप से 1965 में विकसित होने पर भी, सिमुला कक्षाओं को लाइब्रेरी फ़ाइलों में शामिल किया जा सकता था और संकलन समय पर जोड़ा जा सकता था।

लिंकिंग

Main articles: Link time and Linker (computing)

लाइब्रेरी प्रोग्राम लिंकिंग या बाइंडिंग प्रक्रिया में महत्वपूर्ण हैं, जो लाइब्रेरी मॉड्यूल के लिंक या प्रतीकों के रूप में ज्ञात संदर्भों को हल करती है। लिंकिंग प्रक्रिया आमतौर पर एक लिंकर (कंप्यूटिंग) या बाइंडर प्रोग्राम द्वारा स्वचालित रूप से की जाती है जो किसी दिए गए क्रम में पुस्तकालयों और अन्य मॉड्यूल के एक सेट की खोज करता है। आमतौर पर इसे त्रुटि नहीं माना जाता है यदि किसी दिए गए पुस्तकालयों के सेट में एक लिंक लक्ष्य कई बार पाया जा सकता है। लिंकिंग तब की जा सकती है जब एक निष्पादन योग्य फ़ाइल बनाई जाती है (स्थैतिक लिंकिंग), या जब भी प्रोग्राम का उपयोग रनटाइम (प्रोग्राम जीवनचक्र चरण) (डायनामिक लिंकिंग) में किया जाता है।

हल किए जा रहे संदर्भ जंप और अन्य नियमित कॉल के पते हो सकते हैं। वे मुख्य कार्यक्रम में, या दूसरे के आधार पर एक मॉड्यूल में हो सकते हैं। संदर्भित प्रत्येक मॉड्यूल के स्मृति खंड के लिए रनटाइम मेमोरी आवंटित करके उन्हें निश्चित या स्थानांतरित करने योग्य पते (एक सामान्य आधार से) में हल किया जाता है।

कुछ प्रोग्रामिंग भाषाएं स्मार्ट लिंकिंग नामक एक सुविधा का उपयोग करती हैं, जिससे लिंकर कंपाइलर के बारे में जानता है या उसके साथ एकीकृत होता है, जैसे कि लिंकर को पता होता है कि बाहरी संदर्भों का उपयोग कैसे किया जाता है, और लाइब्रेरी में कोड जो वास्तव में कभी भी उपयोग नहीं किया जाता है, भले ही आंतरिक रूप से संदर्भित हो, हो सकता है संकलित अनुप्रयोग से हटा दिया गया। उदाहरण के लिए, एक प्रोग्राम जो अंकगणित के लिए केवल पूर्णांक का उपयोग करता है, या बिल्कुल भी अंकगणितीय संचालन नहीं करता है, फ़्लोटिंग-पॉइंट लाइब्रेरी रूटीन को बाहर कर सकता है। इस स्मार्ट-लिंकिंग सुविधा से एप्लिकेशन फ़ाइल का आकार छोटा हो सकता है और मेमोरी का उपयोग कम हो सकता है।

स्थानांतरण

Main article: Relocation (computer science)

किसी प्रोग्राम या लाइब्रेरी मॉड्यूल में कुछ संदर्भ सापेक्ष या प्रतीकात्मक रूप में संग्रहीत होते हैं जिन्हें तब तक हल नहीं किया जा सकता जब तक कि सभी कोड और लाइब्रेरी को अंतिम स्थिर पते नहीं दिए जाते। स्थानांतरण इन संदर्भों को समायोजित करने की प्रक्रिया है, और यह लिंकर या लोडर (कंप्यूटिंग) द्वारा किया जाता है। सामान्य तौर पर, व्यक्तिगत पुस्तकालयों में स्थानांतरण स्वयं नहीं किया जा सकता है क्योंकि मेमोरी में पते उनका उपयोग करने वाले प्रोग्राम और उनके साथ संयुक्त अन्य पुस्तकालयों के आधार पर भिन्न हो सकते हैं। स्थिति-स्वतंत्र कोड पूर्ण पतों के संदर्भ से बचता है और इसलिए स्थानांतरण की आवश्यकता नहीं होती है।

स्थैतिक पुस्तकालय

Main article: Static library

जब निष्पादन योग्य या किसी अन्य ऑब्जेक्ट फ़ाइल के निर्माण के दौरान लिंकिंग की जाती है, तो इसे स्टैटिक लिंकिंग या अर्ली बाइंडिंग के रूप में जाना जाता है। इस मामले में, लिंकिंग आमतौर पर एक लिंकर (कंप्यूटिंग) द्वारा की जाती है, लेकिन संकलक द्वारा भी की जा सकती है। एक स्थैतिक पुस्तकालय, जिसे एक संग्रह के रूप में भी जाना जाता है, का उद्देश्य स्थैतिक रूप से जुड़ा होना है। मूलतः, केवल स्थैतिक पुस्तकालय ही अस्तित्व में थे। किसी भी मॉड्यूल को पुन: संकलित करते समय स्टेटिक लिंकिंग अवश्य की जानी चाहिए।

किसी प्रोग्राम के लिए आवश्यक सभी मॉड्यूल कभी-कभी स्थिर रूप से लिंक किए जाते हैं और निष्पादन योग्य फ़ाइल में कॉपी किए जाते हैं। यह प्रक्रिया, और परिणामी स्टैंड-अलोन फ़ाइल, प्रोग्राम के स्थिर निर्माण के रूप में जानी जाती है। यदि आभासी मेमोरी का उपयोग किया जाता है और कोई पता स्थान लेआउट यादृच्छिकीकरण वांछित नहीं है, तो एक स्थैतिक निर्माण को किसी और स्थानांतरण (कंप्यूटर विज्ञान) की आवश्यकता नहीं हो सकती है।

साझा पुस्तकालय

"Shared object" redirects here. For the synchronization mechanism, see Monitor (synchronization).

एक साझा लाइब्रेरी या साझा ऑब्जेक्ट एक फ़ाइल है जिसका उद्देश्य निष्पादन योग्य फ़ाइलों और आगे साझा ऑब्जेक्ट फ़ाइलों द्वारा साझा किया जाना है। किसी प्रोग्राम द्वारा उपयोग किए जाने वाले मॉड्यूल को लोड समय या रनटाइम (प्रोग्राम जीवनचक्र चरण) पर अलग-अलग साझा ऑब्जेक्ट से मेमोरी में लोड किया जाता है, न कि किसी लिंकर द्वारा कॉपी किए जाने पर जब यह प्रोग्राम के लिए एकल मोनोलिथिक निष्पादन योग्य फ़ाइल बनाता है।

साझा पुस्तकालयों को संकलन-समय के दौरान स्थिर रूप से जोड़ा जा सकता है, जिसका अर्थ है कि पुस्तकालय मॉड्यूल के संदर्भों को हल किया जाता है और निष्पादन योग्य फ़ाइल बनने पर मॉड्यूल को मेमोरी आवंटित की जाती है। लेकिन अक्सर साझा लाइब्रेरीज़ को लोड होने तक लिंक करना स्थगित कर दिया जाता है।

सबसे आधुनिक ऑपरेटिंग सिस्टम इसमें निष्पादन योग्य फ़ाइलों के समान प्रारूप की साझा लाइब्रेरी फ़ाइलें हो सकती हैं। यह दो मुख्य लाभ प्रदान करता है: पहला, इसमें दोनों के लिए दो के बजाय केवल एक लोडर बनाने की आवश्यकता होती है (एकल लोडर को इसकी अतिरिक्त जटिलता के लायक माना जाता है). दूसरे, यह निष्पादनयोग्यों को साझा पुस्तकालयों के रूप में भी उपयोग करने की अनुमति देता है, यदि उनके पास एक प्रतीक तालिका है। विशिष्ट संयुक्त निष्पादन योग्य और साझा लाइब्रेरी प्रारूप निष्पादन योग्य और लिंक करने योग्य प्रारूप और मच-ओ (दोनों यूनिक्स में) और पोर्टेबल निष्पादन योग्य (विंडोज़) हैं।

कुछ पुराने परिवेशों जैसे कि 16-बिट विंडोज़ या एचपी 3000 के लिए एचपी मल्टी-प्रोग्रामिंग एक्जीक्यूटिव में, साझा-लाइब्रेरी कोड में केवल स्टैक-आधारित डेटा (स्थानीय) की अनुमति थी, या साझा-लाइब्रेरी कोड पर अन्य महत्वपूर्ण प्रतिबंध लगाए गए थे।

स्मृति साझा करना

Main article: Shared memory

लाइब्रेरी कोड को कई प्रक्रिया (कंप्यूटिंग) द्वारा मेमोरी में और डिस्क पर साझा किया जा सकता है। यदि वर्चुअल मेमोरी का उपयोग किया जाता है, तो प्रक्रियाएं रैम के उसी भौतिक पृष्ठ को निष्पादित करेंगी जिसे प्रक्रियाओं के विभिन्न पता स्थानों में मैप किया जाता है। इसके फायदे हैं. उदाहरण के लिए, ओपनस्टेप सिस्टम पर, एप्लिकेशन अक्सर केवल कुछ सौ किलोबाइट आकार के होते थे और तेज़ी से लोड होते थे; उनका अधिकांश कोड उन पुस्तकालयों में स्थित था जिन्हें ऑपरेटिंग सिस्टम द्वारा पहले ही अन्य उद्देश्यों के लिए लोड किया जा चुका था।

प्रोग्राम स्थिति-स्वतंत्र कोड का उपयोग करके रैम साझाकरण को पूरा कर सकते हैं, जैसे कि यूनिक्स में, जो एक जटिल लेकिन लचीली वास्तुकला की ओर ले जाता है, या सामान्य आभासी पते का उपयोग करके, जैसा कि विंडोज और ओएस/2 में होता है। ये सिस्टम विभिन्न माध्यमों से सुनिश्चित करते हैं, जैसे पता स्थान को पूर्व-मैपिंग करना और प्रत्येक साझा लाइब्रेरी के लिए स्लॉट आरक्षित करना, उस कोड को साझा किए जाने की उच्च संभावना है। तीसरा विकल्प एकल स्तरीय दुकान है, जैसा कि आईबीएम सिस्टम/38 और उसके उत्तराधिकारियों द्वारा उपयोग किया जाता है। यह स्थिति-निर्भर कोड की अनुमति देता है, लेकिन कोड को कहां रखा जा सकता है या इसे कैसे साझा किया जा सकता है, इस पर कोई महत्वपूर्ण प्रतिबंध नहीं लगाया गया है।

कुछ मामलों में, साझा पुस्तकालयों के विभिन्न संस्करण समस्याएँ पैदा कर सकते हैं, खासकर जब विभिन्न संस्करणों के पुस्तकालयों का फ़ाइल नाम समान होता है, और सिस्टम पर स्थापित विभिन्न अनुप्रयोगों में से प्रत्येक को एक विशिष्ट संस्करण की आवश्यकता होती है। ऐसे परिदृश्य को DLL नरक के रूप में जाना जाता है, जिसका नाम Windows और OS/2 DLL फ़ाइल के नाम पर रखा गया है। 2001 के बाद अधिकांश आधुनिक ऑपरेटिंग सिस्टमों में ऐसी स्थितियों को खत्म करने या एप्लिकेशन-विशिष्ट निजी पुस्तकालयों का उपयोग करने के लिए सफाई के तरीके हैं।

डायनेमिक लिंकिंग

Main article: Dynamic linker

डायनामिक लिंकिंग या देर से बंधन वह लिंकिंग है जो प्रोग्राम लोड होने (लोड समय) या निष्पादित होने (रनटाइम (प्रोग्राम जीवनचक्र चरण)) के दौरान की जाती है, न कि तब जब निष्पादन योग्य फ़ाइल बनाई जाती है। एक गतिशील रूप से लिंक की गई लाइब्रेरी (डायनामिक-लिंक लाइब्रेरी, या DLL, Microsoft Windows और OS/2 के अंतर्गत; OpenVMS के अंतर्गत साझा करने योग्य छवि; डायनेमिक शेयर्ड ऑब्जेक्ट, या डीएसओ, यूनिक्स जैसी प्रणालियों के तहत) डायनेमिक लिंकिंग के लिए बनाई गई एक लाइब्रेरी है। जब निष्पादन योग्य फ़ाइल बनाई जाती है तो लिंकर (कंप्यूटिंग) द्वारा केवल न्यूनतम मात्रा में काम किया जाता है; यह केवल यह रिकॉर्ड करता है कि प्रोग्राम को किस लाइब्रेरी रूटीन की आवश्यकता है और लाइब्रेरी में रूटीन के सूचकांक नाम या संख्याएँ। लिंकिंग का अधिकांश कार्य एप्लिकेशन लोड होने के समय (लोड समय) या निष्पादन (रनटाइम) के दौरान किया जाता है। आमतौर पर, आवश्यक लिंकिंग प्रोग्राम, जिसे डायनेमिक लिंकर या लिंकिंग लोडर कहा जाता है, वास्तव में अंतर्निहित ऑपरेटिंग सिस्टम का हिस्सा होता है। (हालाँकि, ऐसा प्रोग्राम लिखना संभव है, और अत्यधिक कठिन नहीं है, जो डायनेमिक लिंकिंग का उपयोग करता है और इसमें अपना डायनेमिक लिंकर भी शामिल है, यहां तक ​​कि एक ऑपरेटिंग सिस्टम के लिए भी जो डायनेमिक लिंकिंग के लिए कोई समर्थन प्रदान नहीं करता है।)

प्रोग्रामर्स ने मूल रूप से 1964 में शुरू हुए मॉलटिक्स ऑपरेटिंग सिस्टम और 1960 के दशक के अंत में निर्मित एमटीएस (मिशिगन टर्मिनल सिस्टम) में डायनेमिक लिंकिंग विकसित की।

अनुकूलन

चूंकि अधिकांश सिस्टम पर साझा लाइब्रेरी अक्सर नहीं बदलती हैं, सिस्टम जरूरत पड़ने से पहले सिस्टम पर प्रत्येक साझा लाइब्रेरी के लिए संभावित लोड पते की गणना कर सकता है और उस जानकारी को लाइब्रेरी और निष्पादन योग्य में संग्रहीत कर सकता है। यदि लोड की गई प्रत्येक साझा लाइब्रेरी इस प्रक्रिया से गुज़री है, तो प्रत्येक अपने पूर्व निर्धारित पते पर लोड होगी, जो गतिशील लिंकिंग की प्रक्रिया को गति देती है। इस अनुकूलन को क्रमशः macOS और Linux पर प्रीबाइंडिंग के रूप में जाना जाता है। IBM z/VM एक समान तकनीक का उपयोग करता है, जिसे डिसकंटिन्यूअस सेव्ड सेगमेंट (DCSS) कहा जाता है। इस तकनीक के नुकसान में हर बार साझा लाइब्रेरी बदलने पर इन पतों की पूर्व-गणना करने में लगने वाला समय, एड्रेस स्पेस लेआउट रैंडमाइजेशन का उपयोग करने में असमर्थता और उपयोग के लिए पर्याप्त वर्चुअल एड्रेस स्पेस की आवश्यकता शामिल है (एक समस्या जो 64 को अपनाने से कम हो जाएगी) 64-बिट आर्किटेक्चर, कम से कम कुछ समय के लिए)।

रनटाइम पर पुस्तकालयों का पता लगाना

साझा पुस्तकालयों के लिए लोडर कार्यक्षमता में व्यापक रूप से भिन्न होते हैं। कुछ पुस्तकालयों के लिए स्पष्ट पथों को संग्रहीत करने वाले निष्पादन योग्य पर निर्भर करते हैं। लाइब्रेरी के नामकरण या फ़ाइल सिस्टम के लेआउट में कोई भी परिवर्तन इन सिस्टमों को विफल कर देगा। आमतौर पर, केवल लाइब्रेरी का नाम (और पथ नहीं) निष्पादन योग्य में संग्रहीत किया जाता है, ऑपरेटिंग सिस्टम कुछ एल्गोरिदम के आधार पर डिस्क पर लाइब्रेरी ढूंढने के लिए एक विधि प्रदान करता है।

यदि कोई साझा लाइब्रेरी जिस पर निष्पादन योग्य निर्भर है, हटा दी गई है, स्थानांतरित कर दी गई है, या उसका नाम बदल दिया गया है, या यदि लाइब्रेरी का असंगत संस्करण किसी ऐसे स्थान पर कॉपी किया गया है जो खोज में पहले है, तो निष्पादन योग्य लोड होने में विफल हो जाएगा। इसे निर्भरता नरक कहा जाता है, जो कई प्लेटफार्मों पर मौजूद है। (कुख्यात) विंडोज़ संस्करण को आमतौर पर डीएलएल हेल के रूप में जाना जाता है। यह समस्या तब उत्पन्न नहीं हो सकती यदि प्रत्येक लाइब्रेरी के प्रत्येक संस्करण को विशिष्ट रूप से पहचाना जाता है और प्रत्येक प्रोग्राम लाइब्रेरी को केवल उनके पूर्ण अद्वितीय पहचानकर्ताओं द्वारा संदर्भित करता है। पहले विंडोज़ संस्करणों के साथ डीएलएल समस्याएँ प्रोग्रामों में गतिशील लिंक को हल करने के लिए केवल पुस्तकालयों के नामों का उपयोग करने से उत्पन्न हुईं, जिनके अद्वितीय होने की गारंटी नहीं थी। (डीएलएल नरक से बचने के लिए, विंडोज़ के बाद के संस्करण बड़े पैमाने पर निजी डीएलएल स्थापित करने के लिए प्रोग्राम के विकल्पों पर निर्भर करते हैं - अनिवार्य रूप से साझा पुस्तकालयों के उपयोग से आंशिक वापसी - साथ ही साझा सिस्टम डीएलएल को पुराने संस्करणों के साथ बदलने से रोकने के लिए तंत्र पर।)

माइक्रोसॉफ्ट विंडोज़

माइक्रोसॉफ्ट विंडोज घटक वस्तु मॉडल को लागू करने वाले डीएलएल को लोड करने के लिए उचित स्थान निर्धारित करने के लिए विंडोज़ रजिस्ट्री की जांच करता है, लेकिन अन्य डीएलएल के लिए यह एक निर्धारित क्रम में निर्देशिकाओं की जांच करेगा। सबसे पहले, विंडोज़ उस निर्देशिका की जाँच करता है जहाँ उसने प्रोग्राम लोड किया है (निजी DLL)।); किसी भी निर्देशिका को कॉल करके सेट करें SetDllDirectory() समारोह; System32, सिस्टम और Windows निर्देशिकाएँ; फिर वर्तमान कार्यशील निर्देशिका; और अंत में PATH पर्यावरण चर द्वारा निर्दिष्ट निर्देशिकाएँ। .NET फ्रेमवर्क (2002 से) के लिए लिखे गए एप्लिकेशन, DLL नरक की समस्या को दूर करने के लिए साझा dll फ़ाइलों के प्राथमिक स्टोर के रूप में ग्लोबल असेंबली कैश की भी जाँच करते हैं।

ओपनस्टेप

ओपनस्टेप ने एक अधिक लचीली प्रणाली का उपयोग किया, जब सिस्टम पहली बार शुरू होता है तो कई ज्ञात स्थानों (पीएटीएच अवधारणा के समान) से पुस्तकालयों की एक सूची एकत्र की जाती है। पुस्तकालयों को इधर-उधर ले जाने से कोई समस्या नहीं होती है, हालाँकि उपयोगकर्ताओं को पहली बार सिस्टम शुरू करने में समय लगता है।

यूनिक्स जैसी प्रणालियाँ

अधिकांश यूनिक्स-जैसी प्रणालियों में फ़ाइल-सिस्टम निर्देशिका (कंप्यूटिंग) को निर्दिष्ट करने वाला एक खोज पथ होता है जिसमें गतिशील पुस्तकालयों को देखना होता है। कुछ सिस्टम विन्यास फाइल में डिफ़ॉल्ट पथ निर्दिष्ट करते हैं, अन्य इसे डायनेमिक लोडर में हार्ड-कोड करते हैं। कुछ निष्पादन योग्य प्रारूप अतिरिक्त निर्देशिकाएँ निर्दिष्ट कर सकते हैं जिनमें किसी विशेष कार्यक्रम के लिए पुस्तकालयों की खोज की जा सकती है। इसे आमतौर पर एक पर्यावरण चर के साथ ओवरराइड किया जा सकता है, हालांकि यह निर्धारित समय और सेटगिड प्रोग्राम के लिए अक्षम है, ताकि कोई उपयोगकर्ता ऐसे प्रोग्राम को रूट अनुमतियों के साथ मनमाना कोड चलाने के लिए मजबूर न कर सके। पुस्तकालयों के डेवलपर्स को अपने गतिशील पुस्तकालयों को डिफ़ॉल्ट खोज पथ में स्थानों पर रखने के लिए प्रोत्साहित किया जाता है। नकारात्मक पक्ष यह है कि इससे नए पुस्तकालयों की स्थापना समस्याग्रस्त हो सकती है, और ये ज्ञात स्थान तेजी से बढ़ती संख्या में पुस्तकालय फ़ाइलों का घर बन जाते हैं, जिससे प्रबंधन अधिक जटिल हो जाता है।

गतिशील लोडिंग

Main article: Dynamic loading

डायनेमिक लोडिंग, डायनेमिक लिंकिंग का एक सबसेट, अनुरोध पर रनटाइम (प्रोग्राम जीवनचक्र चरण) पर डायनेमिक रूप से लिंक की गई लाइब्रेरी लोडिंग और अनलोडिंग शामिल है। ऐसा अनुरोध परोक्ष या स्पष्ट रूप से किया जा सकता है। अंतर्निहित अनुरोध तब किए जाते हैं जब एक कंपाइलर या स्टेटिक लिंकर लाइब्रेरी संदर्भ जोड़ता है जिसमें फ़ाइल पथ या बस फ़ाइल नाम शामिल होते हैं। स्पष्ट अनुरोध तब किए जाते हैं जब एप्लिकेशन किसी ऑपरेटिंग सिस्टम के एपीआई पर सीधे कॉल करते हैं।

अधिकांश ऑपरेटिंग सिस्टम जो गतिशील रूप से जुड़े पुस्तकालयों का समर्थन करते हैं, रनटाइम (प्रोग्राम जीवनचक्र चरण) | रन-टाइम लिंकर अप्लिकेशन प्रोग्रामिंग अंतरफलक के माध्यम से ऐसे पुस्तकालयों को गतिशील रूप से लोड करने का भी समर्थन करते हैं। उदाहरण के लिए, माइक्रोसॉफ्ट विंडोज़ एपीआई फ़ंक्शंस का उपयोग करता है LoadLibrary, LoadLibraryEx, FreeLibrary और GetProcAddress माइक्रोसॉफ्ट डायनामिक लिंक लाइब्रेरी के साथ; POSIX-आधारित प्रणालियाँ, जिनमें अधिकांश UNIX और UNIX-जैसी प्रणालियाँ शामिल हैं, उपयोग करती हैं dlopen, dlclose और dlsym. कुछ विकास प्रणालियाँ इस प्रक्रिया को स्वचालित करती हैं।

ऑब्जेक्ट लाइब्रेरी

हालाँकि मूल रूप से इसकी शुरुआत 1960 के दशक में हुई थी, लेकिन डायनेमिक लिंकिंग 1980 के दशक के अंत तक उपभोक्ताओं द्वारा उपयोग किए जाने वाले ऑपरेटिंग सिस्टम तक नहीं पहुँच पाई थी। यह आमतौर पर 1990 के दशक की शुरुआत तक अधिकांश ऑपरेटिंग सिस्टम में किसी न किसी रूप में उपलब्ध था। इसी अवधि के दौरान, ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग (ओओपी) प्रोग्रामिंग परिदृश्य का एक महत्वपूर्ण हिस्सा बन रहा था। रनटाइम बाइंडिंग के साथ OOP को अतिरिक्त जानकारी की आवश्यकता होती है जो पारंपरिक लाइब्रेरी प्रदान नहीं करती है। भीतर स्थित कोड के नाम और प्रवेश बिंदुओं के अलावा, उन्हें उन वस्तुओं की एक सूची की भी आवश्यकता होती है जिन पर वे निर्भर हैं। यह OOP की मूल अवधारणाओं में से एक, वंशानुक्रम का एक दुष्प्रभाव है, जिसका अर्थ है कि किसी भी विधि की पूरी परिभाषा के हिस्से अलग-अलग स्थानों पर हो सकते हैं। यह केवल यह सूचीबद्ध करने से कहीं अधिक है कि एक पुस्तकालय को दूसरे की सेवाओं की आवश्यकता होती है: एक सच्चे ओओपी सिस्टम में, पुस्तकालय स्वयं संकलन समय पर ज्ञात नहीं हो सकते हैं, और सिस्टम से सिस्टम में भिन्न होते हैं।

उसी समय कई डेवलपर्स ने मल्टी-टियर प्रोग्राम के विचार पर काम किया, जिसमें डेस्कटॉप कंप्यूटर पर चलने वाला डिस्प्ले डेटा स्टोरेज या प्रोसेसिंग के लिए मेनफ़्रेम कंप्यूटर या मिनी कंप्यूटर की सेवाओं का उपयोग करेगा। उदाहरण के लिए, जीयूआई-आधारित कंप्यूटर पर एक प्रोग्राम एक विशाल डेटासेट के छोटे नमूने प्रदर्शित करने के लिए एक मिनीकंप्यूटर को संदेश भेजेगा। दूरस्थ प्रक्रिया कॉल (आरपीसी) पहले से ही इन कार्यों को संभालती थी, लेकिन कोई मानक आरपीसी प्रणाली नहीं थी।

जल्द ही अधिकांश मिनीकंप्यूटर और मेनफ्रेम विक्रेताओं ने दोनों को संयोजित करने के लिए परियोजनाएं शुरू कीं, जिससे एक ओओपी लाइब्रेरी प्रारूप तैयार हुआ जिसे कहीं भी इस्तेमाल किया जा सकता था। ऐसी प्रणालियों को ऑब्जेक्ट लाइब्रेरी या वितरित ऑब्जेक्ट के रूप में जाना जाता था, यदि वे रिमोट एक्सेस का समर्थन करते थे (सभी ने नहीं किया)। माइक्रोसॉफ्ट का COM स्थानीय उपयोग के लिए ऐसी प्रणाली का एक उदाहरण है। DCOM, COM का एक संशोधित संस्करण, रिमोट एक्सेस का समर्थन करता है।

कुछ समय तक ऑब्जेक्ट लाइब्रेरियों को प्रोग्रामिंग जगत में अगली बड़ी चीज़ का दर्जा प्राप्त रहा। ऐसे सिस्टम बनाने के लिए कई प्रयास किए गए जो सभी प्लेटफार्मों पर चलेंगे, और कंपनियों ने डेवलपर्स को अपने सिस्टम में लॉक करने की कोशिश करने के लिए प्रतिस्पर्धा की। उदाहरणों में IBM का सिस्टम ऑब्जेक्ट मॉडल (SOM/DSOM), सन माइक्रोसिस्टम्स का सर्वत्र वस्तुएँ वितरित कीं (DOE), NeXT का पोर्टेबल वितरित वस्तुएँ (PDO), डिजिटल उपकरण निगम का ऑब्जेक्ट ब्रोकर , माइक्रोसॉफ्ट का घटक वस्तु मॉडल (COM/DCOM), और कोई भी CORBA शामिल हैं। -आधारित सिस्टम।

कक्षा पुस्तकालय

क्लास लाइब्रेरीज़ पुराने प्रकार के कोड लाइब्रेरीज़ के समतुल्य OOP हैं। उनमें क्लास (कंप्यूटर विज्ञान) शामिल है, जो विशेषताओं का वर्णन करता है और क्रियाओं (विधि (कंप्यूटर विज्ञान)) को परिभाषित करता है जिसमें वस्तुएं शामिल होती हैं। क्लास लाइब्रेरीज़ का उपयोग इंस्टेंस (कंप्यूटर विज्ञान), या विशिष्ट मानों पर सेट की गई विशेषताओं वाली ऑब्जेक्ट बनाने के लिए किया जाता है। जावा (प्रोग्रामिंग भाषा) जैसी कुछ ओओपी भाषाओं में, अंतर स्पष्ट है, कक्षाएं अक्सर लाइब्रेरी फ़ाइलों (जैसे जावा के जार (फ़ाइल प्रारूप)) में निहित होती हैं और तत्काल ऑब्जेक्ट केवल मेमोरी में रहते हैं (हालांकि संभावित रूप से दृढ़ता बनाए जाने में सक्षम होते हैं) (कंप्यूटर विज्ञान) अलग फाइलों में)। दूसरों में, स्मॉलटॉक की तरह, क्लास लाइब्रेरीज़ एक सिस्टम छवि के लिए शुरुआती बिंदु मात्र हैं जिसमें पर्यावरण की संपूर्ण स्थिति, कक्षाएं और सभी तात्कालिक ऑब्जेक्ट शामिल होते हैं।

आज अधिकांश क्लास लाइब्रेरीज़ को पैकेज भंडार (जैसे जावा के लिए मेवेन सेंट्रल) में संग्रहीत किया जाता है। क्लाइंट कोड स्पष्ट रूप से सॉफ्टवेयर निर्माण कॉन्फ़िगरेशन फ़ाइलों (जैसे जावा में मावेन पोम) में बाहरी पुस्तकालयों पर निर्भरता की घोषणा करता है।

दूरस्थ पुस्तकालय

एक अन्य लाइब्रेरी तकनीक पूरी तरह से अलग निष्पादनयोग्य (अक्सर कुछ हल्के रूप में) का उपयोग करती है और उन्हें एक नेटवर्क पर दूसरे कंप्यूटर पर रिमोट प्रक्रिया कॉल (आरपीसी) का उपयोग करके कॉल करती है। यह ऑपरेटिंग सिस्टम के पुन: उपयोग को अधिकतम करता है: लाइब्रेरी का समर्थन करने के लिए आवश्यक कोड वही कोड है जिसका उपयोग हर दूसरे प्रोग्राम के लिए एप्लिकेशन समर्थन और सुरक्षा प्रदान करने के लिए किया जा रहा है। इसके अतिरिक्त, ऐसी प्रणालियों के लिए लाइब्रेरी को उसी मशीन पर मौजूद होने की आवश्यकता नहीं होती है, लेकिन वे नेटवर्क पर अनुरोधों को अग्रेषित कर सकते हैं।

हालाँकि, इस तरह के दृष्टिकोण का मतलब है कि प्रत्येक लाइब्रेरी कॉल के लिए काफी मात्रा में ओवरहेड की आवश्यकता होती है। आरपीसी कॉल किसी साझा लाइब्रेरी को कॉल करने की तुलना में बहुत अधिक महंगी हैं जो पहले से ही उसी मशीन पर लोड की जा चुकी है। इस दृष्टिकोण का उपयोग आमतौर पर वितरित कंप्यूटिंग में किया जाता है जो ऐसे दूरस्थ कॉल, विशेष रूप से क्लाइंट-सर्वर सिस्टम और एंटरप्राइज़ जावाबीन्स जैसे अनुप्रयोग सर्वर का भारी उपयोग करता है।

कोड जनरेशन लाइब्रेरी

कोड जनरेशन लाइब्रेरी उच्च-स्तरीय अप्लिकेशन प्रोग्रामिंग अंतरफलक हैं जो जावा (प्रोग्रामिंग भाषा) के लिए बाइट कोड उत्पन्न या परिवर्तित कर सकते हैं। इनका उपयोग पहलू-उन्मुख प्रोग्रामिंग, कुछ डेटा एक्सेस फ्रेमवर्क और गतिशील प्रॉक्सी ऑब्जेक्ट उत्पन्न करने के परीक्षण के लिए किया जाता है। इनका उपयोग फ़ील्ड पहुंच को रोकने के लिए भी किया जाता है।

फ़ाइल नामकरण

अधिकांश आधुनिक यूनिक्स जैसी प्रणालियाँ

See also: Unix-like

सिस्टम स्टोर करता है libfoo.a और libfoo.so निर्देशिकाओं में फ़ाइलें जैसे /lib, /usr/lib या /usr/local/lib. फ़ाइल नाम हमेशा से प्रारंभ होते हैं lib, और के प्रत्यय के साथ समाप्त होता है .a (Ar (फ़ाइल स्वरूप), स्थैतिक पुस्तकालय) या का .so (साझा वस्तु, गतिशील रूप से जुड़ी हुई लाइब्रेरी)। कुछ प्रणालियों में गतिशील रूप से जुड़ी लाइब्रेरी के लिए कई नाम हो सकते हैं। ये नाम आम तौर पर एक ही उपसर्ग साझा करते हैं और संस्करण संख्या को इंगित करने वाले अलग-अलग प्रत्यय होते हैं। अधिकांश नाम नवीनतम संस्करण के प्रतीकात्मक लिंक के नाम हैं। उदाहरण के लिए, कुछ प्रणालियों पर libfoo.so.2 गतिशील रूप से लिंक की गई लाइब्रेरी के दूसरे प्रमुख इंटरफ़ेस संशोधन के लिए फ़ाइल नाम होगा libfoo. .la ई> कभी-कभी लाइब्रेरी निर्देशिकाओं में पाई जाने वाली फ़ाइलें libtool अभिलेखागार होती हैं, जो सिस्टम द्वारा उपयोग करने योग्य नहीं होती हैं।

मैकओएस

See also: macOS

सिस्टम को बीएसडी से स्थैतिक लाइब्रेरी कन्वेंशन विरासत में मिली है, जिसमें लाइब्रेरी संग्रहीत है .a फ़ाइल, और उपयोग कर सकते हैं .so-स्टाइल गतिशील रूप से जुड़े पुस्तकालय (के साथ .dylib इसके बजाय प्रत्यय)। हालाँकि, macOS में अधिकांश लाइब्रेरीज़ में फ्रेमवर्क शामिल होते हैं, जिन्हें बंडल (macOS) नामक विशेष निर्देशिकाओं के अंदर रखा जाता है, जो लाइब्रेरी की आवश्यक फ़ाइलों और मेटाडेटा को लपेटते हैं। उदाहरण के लिए, एक रूपरेखा कहा जाता है MyFramework नामक बंडल में लागू किया जाएगा MyFramework.framework, साथ MyFramework.framework/MyFramework या तो गतिशील रूप से लिंक की गई लाइब्रेरी फ़ाइल होना या गतिशील रूप से लिंक की गई लाइब्रेरी फ़ाइल का सिम्लिंक होना MyFramework.framework/Versions/Current/MyFramework.

माइक्रोसॉफ्ट विंडोज़

See also: Microsoft Windows

डायनामिक-लिंक लाइब्रेरी|डायनामिक-लिंक लाइब्रेरी में आमतौर पर प्रत्यय होता है *.DLL, हालाँकि अन्य फ़ाइल नाम एक्सटेंशन विशिष्ट-उद्देश्यीय गतिशील रूप से जुड़े पुस्तकालयों की पहचान कर सकते हैं, उदाहरण के लिए *.OCX जोडकर परनिगरानी और उद्देश् य लाइब्रेरीज़ के लिए। इंटरफ़ेस संशोधन या तो फ़ाइल नामों में एन्कोड किए गए हैं, या घटक ऑब्जेक्ट मॉडल | COM-ऑब्जेक्ट इंटरफ़ेस का उपयोग करके अलग कर दिए गए हैं। इस पर निर्भर करता है कि उन्हें कैसे संकलित किया गया है, *.LIB फ़ाइलें या तो स्थिर पुस्तकालय हो सकती हैं या केवल संकलन के दौरान आवश्यक गतिशील रूप से लिंक करने योग्य पुस्तकालयों का प्रतिनिधित्व कर सकती हैं, जिन्हें डायनेमिक-लिंक लाइब्रेरी#आयात लाइब्रेरी के रूप में जाना जाता है। यूनिक्स दुनिया के विपरीत, जो लिंक करते समय विभिन्न फ़ाइल एक्सटेंशन का उपयोग करता है .LIB Microsoft Windows में फ़ाइल को पहले यह जानना होगा कि यह एक नियमित स्थैतिक लाइब्रेरी है या एक आयात लाइब्रेरी है। बाद वाले मामले में, ए .DLL फ़ाइल रनटाइम पर मौजूद होनी चाहिए.

यह भी देखें

• Code reuse
• Linker (computing)
• Loader (computing) – Part of an operating system
• Dynamic-link library – Microsoft's implementation of the shared library concept in Windows and OS/2
• Object file – File containing relocatable format machine code
• Plug-in – Software component that adds a specific feature to an existing software application
• Prelink, also known as Prebinding
• Static library
• Runtime library
• Visual Component Library – Visual Library (वीसीएल)
• Component Library for Cross Platform (160)
• C standard library – Standard library for the C programming language
• Java Class Library
• Framework Class Library
• Generic programming – Style of computer programming (C++ मानक लाइब्रेरी द्वारा प्रयुक्त)
• soname – Field of data in a shared object file
• Method stub

अग्रिम पठन

• Levine, John R. (2000) [October 1999]. "Chapter 9: Shared Libraries & Chapter 10: Dynamic Linking and Loading". Linkers and Loaders. The Morgan Kaufmann Series in Software Engineering and Programming (1 ed.). San Francisco, USA: Morgan Kaufmann. ISBN 1-55860-496-0. OCLC 42413382. Archived from the original on 2012-12-05. Retrieved 2020-01-12. Code: [1][2] Errata: [3]
• Article Beginner's Guide to Linkers by David Drysdale
• Article Faster C++ program startups by improving runtime linking efficiency by Léon Bottou and John Ryland
• How to Create Program Libraries by Baris Simsek
• BFD - the Binary File Descriptor Library
• 1st Library-Centric Software Design Workshop LCSD'05 Archived 2019-08-28 at the Wayback Machine at OOPSLA'05
• 2nd Library-Centric Software Design Workshop LCSD'06 at OOPSLA'06
• How to create shared library by Ulrich Drepper (with much background info)
• Anatomy of Linux dynamic libraries at IBM.com