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

Latest revision as of 10:48, 27 July 2023

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

कंप्यूटर विज्ञान में, लाइब्रेरी गैर-वाष्पशील संसाधनों का संग्रह है जिसका उपयोग कंप्यूटर प्रोग्राम द्वारा अधिकांशतः सॉफ्टवेयर विकास के लिए किया जाता है। इस प्रकार इनमें कॉन्फ़िगरेशन डेटा, दस्तावेज़ीकरण, सहायता डेटा, संदेश टेम्पलेट, पूर्व-लिखित कोड और सबरूटीन, कक्षाएं, मान या डेटा प्रकार विनिर्देश सम्मिलित हो सकते हैं। आईबीएम के ओएस/360 और उसके उत्तराधिकारियों में|आईबीएम के ओएस/360 और उसके उत्तराधिकारियों में उन्हें विभाजित डेटा समूह के रूप में संदर्भित किया जाता है।^[1]

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

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

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

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

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

इतिहास

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

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

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

वॉन न्यूमैन से प्रेरित होकर, विल्केस और उनकी टीम ने ईडीएसएसी का निर्माण किया। इस प्रकार छिद्रित टेप की फाइलिंग कैबिनेट में इस कंप्यूटर के लिए सबरूटीन लाइब्रेरी थी।^[7] ईडीएसएसी के कार्यक्रमों में मुख्य कार्यक्रम और सबरूटीन लाइब्रेरी से कॉपी किए गए सबरूटीन्स का क्रम सम्मिलित होता है।^[8] इस प्रकार वर्ष 1951 में टीम ने प्रोग्रामिंग पर पहली पाठ्यपुस्तक, इलेक्ट्रॉनिक डिजिटल कंप्यूटर के लिए प्रोग्राम की तैयारी, प्रकाशित की, जिसमें लाइब्रेरी के निर्माण और उद्देश्य का विवरण दिया गया था।^[9]

COBOL ने 1959 में "पुस्तकालय प्रणाली के लिए आदिम क्षमताओं" को सम्मिलित किया,^[10] किन्तु जीन ई. सैममेट ने उन्हें पूर्वव्यापी रूप से "अपर्याप्त पुस्तकालय सुविधाओं" के रूप में वर्णित किया।^[11]

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

आधुनिक पुस्तकालय अवधारणा में और प्रमुख योगदानकर्ता फोरट्रान के उपप्रोग्राम नवाचार के रूप में आया। इस प्रकार फोरट्रान उपप्रोग्रामों को दूसरे से स्वतंत्र रूप से संकलित किया जा सकता है, किन्तु कंपाइलर में लिंकर (कंप्यूटिंग) का अभाव था। इसलिए फोरट्रान-90 में मॉड्यूल की प्रारंभ से पहले, फोरट्रान [एनबी 1] उपप्रोग्रामों के मध्य प्रकार की जांच असंभव थी।^[12]

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

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

लिंकिंग

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

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

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

स्थानांतरण

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

अनुकूलन

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

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

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

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

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

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

ओपनस्टेप

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

फ़ाइल नामकरण

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

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

मैकओएस

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

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

डायनामिक-लिंक लाइब्रेरी|डायनामिक-लिंक लाइब्रेरी में सामान्यतः प्रत्यय *.DLLहोता है ,^[23] यद्यपि अन्य फ़ाइल नाम एक्सटेंशन विशिष्ट-उद्देश्यीय गतिशील रूप से जुड़े पुस्तकालयों की पहचान कर सकते हैं, उदाहरण के लिए लाइब्रेरीज़ के लिए*.OCX इंटरफ़ेस संशोधन या तब फ़ाइल नामों में एन्कोड किए गए हैं, या COM-ऑब्जेक्ट इंटरफ़ेस का उपयोग करके पृथक कर दिए गए हैं। इस पर निर्भर करता है कि उन्हें उन्हें संकलित करने के विधि के आधार पर *.LIB फ़ाइलें या तब स्थिर पुस्तकालय हो सकती हैं या केवल संकलन के समय आवश्यक गतिशील रूप से लिंक करने योग्य पुस्तकालयों का प्रतिनिधित्व कर सकती हैं, जिन्हें "आयात पुस्तकालय" के रूप में जाना जाता है। यूनिक्स विश्व के विपरीत, जो विभिन्न फ़ाइल एक्सटेंशन का उपयोग करता है‚ विंडोज़ में.LIB फ़ाइल के विरुद्ध लिंक करते समय पहले यह जानना होगा कि क्या यह एक नियमित स्थैतिक लाइब्रेरी या एक आयात लाइब्रेरी है। पश्चात् वाले मामले में, एक .DLL फ़ाइल रनटाइम पर उपस्तिथ होनी चाहिए।

यह भी देखें

कोड का पुन: उपयोग
लिंकर (कंप्यूटिंग)
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
स्थैतिक पुस्तकालय
Runtime library
Visual Component Library – Visual Library (वीसीएल)
Component Library for Cross Platform (160)
C standard library – Standard library for the C programming language
जावा क्लास लाइब्रेरी
फ्रेमवर्क क्लास लाइब्रेरी
Generic programming – Style of computer programming (C++ मानक लाइब्रेरी द्वारा प्रयुक्त)
soname – Field of data in a shared object file
Method stub

↑ dx.doi.org. doi:10.1107/s1600576715005518/fs5094sup1.zip http://dx.doi.org/10.1107/s1600576715005518/fs5094sup1.zip. Retrieved 2021-05-27. {{cite journal}}: Missing or empty |title= (help)
↑ Deshpande, Prasad (2013). फ़ंक्शन कॉल ग्राफ़ विश्लेषण का उपयोग करके मेटामॉर्फिक डिटेक्शन (Thesis). San Jose State University Library. doi:10.31979/etd.t9xm-ahsc.
↑ "स्थैतिक पुस्तकालय". TLDP. Archived from the original on 3 July 2013. Retrieved 3 October 2013.
↑ Babbage, H. P. (September 12, 1888). "The Analytical Engine". Proceedings of the British Association. Bath.
↑ Goldstine, Herman H. (2008-12-31). पास्कल से वॉन न्यूमैन तक का कंप्यूटर. Princeton: Princeton University Press. doi:10.1515/9781400820139. ISBN 978-1-4008-2013-9.
↑ Goldstine, Herman; von Neumann, John (1947). इलेक्ट्रॉनिक कंप्यूटिंग उपकरण के लिए समस्याओं की योजना बनाना और कोडिंग करना (Report). Institute for Advanced Study. p. 3, 21–22. OCLC 26239859. it will probably be very important to develop an extensive "library" of subroutines
↑ Wilkes, M. V. (1951). "The EDSAC Computer". 1951 International Workshop on Managing Requirements Knowledge. 1951 International Workshop on Managing Requirements Knowledge. IEEE. p. 79. doi:10.1109/afips.1951.13.
↑ Campbell-Kelly, Martin (September 2011). "'विल्केस, व्हीलर और गिल' की प्रशंसा में". Communications of the ACM. 54 (9): 25–27. doi:10.1145/1995376.1995386. S2CID 20261972.
↑ Wilkes, Maurice; Wheeler, David; Gill, Stanley (1951). इलेक्ट्रॉनिक डिजिटल कंप्यूटर के लिए प्रोग्राम तैयार करना. Addison-Wesley. p. 45, 80–91, 100. OCLC 641145988.
↑ Wexelblat, Richard (1981). प्रोग्रामिंग भाषाओं का इतिहास. ACM Monograph Series. New York, NY: Academic Press (A subsidiary of Harcourt Brace). p. 274. ISBN 0-12-745040-8.
↑ वेक्सेलब्लैट, ऑप. सिट., पी. 258
↑ Wilson, Leslie B.; Clark, Robert G. (1988). तुलनात्मक प्रोग्रामिंग भाषाएँ. Wokingham, England: Addison-Wesley. p. 126. ISBN 0-201-18483-4.
↑ विल्सन और क्लार्क, ऑप. सिट., पी. 52
↑ वेक्सेलब्लैट, ऑप. सिट., पी. 716
↑ Kaminsky, Dan (2008), "Portable Executable and Executable and Linking Formats", Reverse Engineering Code with IDA Pro, Elsevier, pp. 37–66, doi:10.1016/b978-1-59749-237-9.00003-x, ISBN 978-1-59749-237-9, retrieved 2021-05-27
↑ Christian Collberg, John H. Hartman, Sridivya Babu, Sharath K. Udupa (2003). "SLINKY: Static Linking Reloaded". Department of Computer Science, University of Arizona. Archived from the original on 23 March 2016. Retrieved 2016-03-17.{{cite web}}: CS1 maint: uses authors parameter (link)
↑ ^17.0 ^17.1 Anderson, Rick (2000-01-11). "The End of DLL Hell". microsoft.com. Archived from the original on 2001-06-05. Retrieved 2012-01-15. Private DLLs are DLLs that are installed with a specific application and used only by that application.
↑ "वीएसआई ओपनवीएमएस लिंकर यूटिलिटी मैनुअल" (PDF). VSI. August 2019. Retrieved 2021-01-31.
↑ "एमटीएस का इतिहास". Information Technology Digest. 5 (5).
↑ IBM Corporation (2011). सहेजे गए खंड योजना और प्रशासन (PDF). Retrieved Jan 29, 2022.
↑ "Dynamic-Link Library Search Order". Microsoft Developer Network Library. Microsoft. 2012-03-06. Archived from the original on 9 May 2012. Retrieved 2012-05-20.
↑ "Code Generation Library". Source Forge. Archived from the original on 12 January 2010. Retrieved 2010-03-03. Byte Code Generation Library is high level API to generate and transform JAVA byte code. It is used by AOP, testing, data access frameworks to generate dynamic proxy objects and intercept field access.
↑ Bresnahan, Christine; Blum, Richard (2015-04-27). LPIC-1 Linux Professional Institute Certification Study Guide: Exam 101-400 and Exam 102-400. John Wiley & Sons (published 2015). p. 82. ISBN 9781119021186. Archived from the original on 24 September 2015. Retrieved 2015-09-03. Linux shared libraries are similar to the dynamic link libraries (DLLs) of Windows. Windows DLLs are usually identified by .dll filename extensions.

अग्रिम पठन

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

[17] Some older systems, e.g., Burroughs MCP, Multics, also have only a single format for executable files, regardless of whether they are shared.

[1] dx.doi.org. doi:10.1107/s1600576715005518/fs5094sup1.zip http://dx.doi.org/10.1107/s1600576715005518/fs5094sup1.zip. Retrieved 2021-05-27. {{cite journal}}: Missing or empty |title= (help)

[2] Deshpande, Prasad (2013). फ़ंक्शन कॉल ग्राफ़ विश्लेषण का उपयोग करके मेटामॉर्फिक डिटेक्शन (Thesis). San Jose State University Library. doi:10.31979/etd.t9xm-ahsc.

[स्थैतिक_पुस्तकालय-3] "स्थैतिक पुस्तकालय". TLDP. Archived from the original on 3 July 2013. Retrieved 3 October 2013.

[4] Babbage, H. P. (September 12, 1888). "The Analytical Engine". Proceedings of the British Association. Bath.

[5] Goldstine, Herman H. (2008-12-31). पास्कल से वॉन न्यूमैन तक का कंप्यूटर. Princeton: Princeton University Press. doi:10.1515/9781400820139. ISBN 978-1-4008-2013-9.

[6] Goldstine, Herman; von Neumann, John (1947). इलेक्ट्रॉनिक कंप्यूटिंग उपकरण के लिए समस्याओं की योजना बनाना और कोडिंग करना (Report). Institute for Advanced Study. p. 3, 21–22. OCLC 26239859. it will probably be very important to develop an extensive "library" of subroutines

[7] Wilkes, M. V. (1951). "The EDSAC Computer". 1951 International Workshop on Managing Requirements Knowledge. 1951 International Workshop on Managing Requirements Knowledge. IEEE. p. 79. doi:10.1109/afips.1951.13.

[8] Campbell-Kelly, Martin (September 2011). "'विल्केस, व्हीलर और गिल' की प्रशंसा में". Communications of the ACM. 54 (9): 25–27. doi:10.1145/1995376.1995386. S2CID 20261972.

[9] Wilkes, Maurice; Wheeler, David; Gill, Stanley (1951). इलेक्ट्रॉनिक डिजिटल कंप्यूटर के लिए प्रोग्राम तैयार करना. Addison-Wesley. p. 45, 80–91, 100. OCLC 641145988.

[Wexelblat_1981_247-10] Wexelblat, Richard (1981). प्रोग्रामिंग भाषाओं का इतिहास. ACM Monograph Series. New York, NY: Academic Press (A subsidiary of Harcourt Brace). p. 274. ISBN 0-12-745040-8.

[Wexelblat_1981_258-11] वेक्सेलब्लैट, ऑप. सिट., पी. 258

[Wilson_Clark_1988_126-12] Wilson, Leslie B.; Clark, Robert G. (1988). तुलनात्मक प्रोग्रामिंग भाषाएँ. Wokingham, England: Addison-Wesley. p. 126. ISBN 0-201-18483-4.

[Wilson_Clark_1988_52-13] विल्सन और क्लार्क, ऑप. सिट., पी. 52

[Wexelblat_1981_716-14] वेक्सेलब्लैट, ऑप. सिट., पी. 716

[15] Kaminsky, Dan (2008), "Portable Executable and Executable and Linking Formats", Reverse Engineering Code with IDA Pro, Elsevier, pp. 37–66, doi:10.1016/b978-1-59749-237-9.00003-x, ISBN 978-1-59749-237-9, retrieved 2021-05-27

[16] Christian Collberg, John H. Hartman, Sridivya Babu, Sharath K. Udupa (2003). "SLINKY: Static Linking Reloaded". Department of Computer Science, University of Arizona. Archived from the original on 23 March 2016. Retrieved 2016-03-17.{{cite web}}: CS1 maint: uses authors parameter (link)

[endofdllhell-18] 17.0 ^17.1 Anderson, Rick (2000-01-11). "The End of DLL Hell". microsoft.com. Archived from the original on 2001-06-05. Retrieved 2012-01-15. Private DLLs are DLLs that are installed with a specific application and used only by that application.

[19] "वीएसआई ओपनवीएमएस लिंकर यूटिलिटी मैनुअल" (PDF). VSI. August 2019. Retrieved 2021-01-31.

[20] "एमटीएस का इतिहास". Information Technology Digest. 5 (5).

[21] IBM Corporation (2011). सहेजे गए खंड योजना और प्रशासन (PDF). Retrieved Jan 29, 2022.

[22] "Dynamic-Link Library Search Order". Microsoft Developer Network Library. Microsoft. 2012-03-06. Archived from the original on 9 May 2012. Retrieved 2012-05-20.

[23] "Code Generation Library". Source Forge. Archived from the original on 12 January 2010. Retrieved 2010-03-03. Byte Code Generation Library is high level API to generate and transform JAVA byte code. It is used by AOP, testing, data access frameworks to generate dynamic proxy objects and intercept field access.

[24] Bresnahan, Christine; Blum, Richard (2015-04-27). LPIC-1 Linux Professional Institute Certification Study Guide: Exam 101-400 and Exam 102-400. John Wiley & Sons (published 2015). p. 82. ISBN 9781119021186. Archived from the original on 24 September 2015. Retrieved 2015-09-03. Linux shared libraries are similar to the dynamic link libraries (DLLs) of Windows. Windows DLLs are usually identified by .dll filename extensions.

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12]

[13]

[14]

[15]

[16]

[NB 1]

[17]

[18]

[19]

[20]

[21]

[22]

[23]

@@ Line 6: / Line 6: @@
 <!-- निम्नलिखित पैराग्राफ में सूचीबद्ध सभी चीजों को कम से कम आईबीएम द्वारा [[आईबीएम सिस्टम/360]] के सॉफ्टवेयर के माध्यम से [[आईबीएम सिस्टम जेड]] पर लाइब्रेरी के रूप में संदर्भित किया गया है। -->
-[[कंप्यूटर विज्ञान]] में, लाइब्रेरी गैर-वाष्पशील मेमोरी|गैर-वाष्पशील संसाधनों का संग्रह है जिसका उपयोग [[कंप्यूटर प्रोग्राम]] द्वारा अधिकांशतः सॉफ्टवेयर विकास के लिए किया जाता है। इनमें कॉन्फ़िगरेशन डेटा, दस्तावेज़ीकरण, सहायता डेटा, संदेश टेम्पलेट, कोड पुन: उपयोग|पूर्व-लिखित कोड और [[सबरूटीन]], क्लास (कंप्यूटर विज्ञान), मान (कंप्यूटर विज्ञान) या [[डेटा प्रकार]] विनिर्देश सम्मिलित हो सकते हैं। ओएस/360 और उसके उत्तराधिकारियों में|आईबीएम के ओएस/360 और उसके उत्तराधिकारियों को डेटा समूह (आईबीएम मेनफ्रेम)#विभाजित डेटासमूह के रूप में संदर्भित किया जाता है।<ref>{{Cite journal|url=http://dx.doi.org/10.1107/s1600576715005518/fs5094sup1.zip|access-date=2021-05-27|website=dx.doi.org|doi=10.1107/s1600576715005518/fs5094sup1.zip}}</ref>
+[[कंप्यूटर विज्ञान]] में, '''लाइब्रेरी''' गैर-वाष्पशील संसाधनों का संग्रह है जिसका उपयोग [[कंप्यूटर प्रोग्राम]] द्वारा अधिकांशतः सॉफ्टवेयर विकास के लिए किया जाता है। इस प्रकार इनमें कॉन्फ़िगरेशन डेटा, दस्तावेज़ीकरण, सहायता डेटा, संदेश टेम्पलेट, पूर्व-लिखित कोड और [[सबरूटीन]], कक्षाएं, मान या [[डेटा प्रकार]] विनिर्देश सम्मिलित हो सकते हैं। आईबीएम के ओएस/360 और उसके उत्तराधिकारियों में|आईबीएम के ओएस/360 और उसके उत्तराधिकारियों में उन्हें विभाजित डेटा समूह के रूप में संदर्भित किया जाता है।<ref>{{Cite journal|url=http://dx.doi.org/10.1107/s1600576715005518/fs5094sup1.zip|access-date=2021-05-27|website=dx.doi.org|doi=10.1107/s1600576715005518/fs5094sup1.zip}}</ref>
-एक पुस्तकालय व्यवहार के कार्यान्वयन का संग्रह भी है, जो भाषा के संदर्भ में लिखा गया है, जिसमें अच्छी तरह से परिभाषित [[इंटरफ़ेस (कंप्यूटिंग)]] है जिसके द्वारा व्यवहार को क्रियान्वित किया जाता है। उदाहरण के लिए, जो लोग उच्च-स्तरीय प्रोग्राम लिखना चाहते हैं, वह [[सिस्टम कॉल|पद्धति कॉल]] को बार-बार क्रियान्वित करने के अतिरिक्त पद्धति कॉल करने के लिए लाइब्रेरी का उपयोग कर सकते हैं। इसके अतिरिक्त, व्यवहार को अनेक स्वतंत्र कार्यक्रमों द्वारा पुन: उपयोग के लिए प्रदान किया जाता है। प्रोग्राम भाषा के तंत्र के माध्यम से पुस्तकालय द्वारा प्रदत्त व्यवहार का आह्वान करता है। उदाहरण के लिए, [[सी (प्रोग्रामिंग भाषा)]] जैसी सरल [[अनिवार्य भाषा]] में, लाइब्रेरी में व्यवहार को सी के सामान्य फलन-कॉल का उपयोग करके क्रियान्वित किया जाता है। कॉल को लाइब्रेरी फलन के रूप में और उसी प्रोग्राम में किसी अन्य फलन के रूप में भिन्न करने का प्रणाली पद्धति में कोड को व्यवस्थित करने का प्रणाली है।<ref>{{Cite thesis|title=फ़ंक्शन कॉल ग्राफ़ विश्लेषण का उपयोग करके मेटामॉर्फिक डिटेक्शन|publisher=San Jose State University Library|first=Prasad|last=Deshpande| year=2013 |doi=10.31979/etd.t9xm-ahsc|doi-access=free}}</ref>
+'''लाइब्रेरी''' व्यवहार के कार्यान्वयन का संग्रह भी है, जो भाषा के संदर्भ में लिखा गया है, जिसमें अच्छी तरह से परिभाषित [[इंटरफ़ेस (कंप्यूटिंग)|इंटरफ़ेस]] होता है जिसके द्वारा व्यवहार को क्रियान्वित किया जाता है। उदाहरण के लिए, जो लोग उच्च-स्तरीय प्रोग्राम लिखना चाहते हैं, वह [[सिस्टम कॉल]] को बार-बार क्रियान्वित करने के अतिरिक्त सिस्टम कॉल करने के लिए लाइब्रेरी का उपयोग कर सकते हैं। इसके अतिरिक्त, व्यवहार को अनेक स्वतंत्र कार्यक्रमों द्वारा पुन: उपयोग के लिए प्रदान किया जाता है। इस प्रकार प्रोग्राम भाषा के तंत्र के माध्यम से पुस्तकालय द्वारा प्रदत्त व्यवहार का आह्वान करता है। उदाहरण के लिए, [[सी (प्रोग्रामिंग भाषा)]] जैसी सरल [[अनिवार्य भाषा]] में, सी के सामान्य फलन-कॉल का उपयोग करके लाइब्रेरी में व्यवहार को  क्रियान्वित किया जाता है। इस प्रकार कॉल को लाइब्रेरी फलन के रूप में और उसी प्रोग्राम में किसी अन्य फलन के रूप में भिन्न करने का प्रणाली सिस्टम में कोड को व्यवस्थित करने की प्रणाली है।<ref>{{Cite thesis|title=फ़ंक्शन कॉल ग्राफ़ विश्लेषण का उपयोग करके मेटामॉर्फिक डिटेक्शन|publisher=San Jose State University Library|first=Prasad|last=Deshpande| year=2013 |doi=10.31979/etd.t9xm-ahsc|doi-access=free}}</ref>
-लाइब्रेरी कोड को इस तरह से व्यवस्थित किया जाता है कि इसका उपयोग अनेक प्रोग्रामों द्वारा किया जा सकता है जिनका एक-दूसरे से कोई संबंध नहीं होता है, जबकि कोड जो प्रोग्राम का हिस्सा होता है उसे केवल उस प्रोग्राम के अंदर उपयोग करने के लिए व्यवस्थित किया जाता है। जब कोई प्रोग्राम बड़ा हो जाता है, जैसे मल्टी-मिलियन-लाइन प्रोग्राम, तब यह अंतर पदानुक्रमित धारणा प्राप्त कर सकता है। उस स्थिति में, ऐसे आंतरिक पुस्तकालय हो सकते हैं जिनका बड़े प्रोग्राम के स्वतंत्र उप-भागों द्वारा पुन: उपयोग किया जाता है। विशिष्ट विशेषता यह है कि पुस्तकालय को स्वतंत्र कार्यक्रमों या उप-कार्यक्रमों द्वारा पुन: उपयोग किए जाने के उद्देश्य से व्यवस्थित किया जाता है, और उपयोगकर्ता को केवल इंटरफ़ेस जानने की आवश्यकता होती है, न कि पुस्तकालय के आंतरिक विवरण की।
+लाइब्रेरी कोड को इस तरह से व्यवस्थित किया जाता है कि इसका उपयोग अनेक प्रोग्रामों द्वारा किया जा सकता है जिनका एक-दूसरे से कोई संबंध नहीं होता है, जबकि कोड जो प्रोग्राम का हिस्सा होता है उसे केवल उस प्रोग्राम के अंदर उपयोग करने के लिए व्यवस्थित किया जाता है। इस प्रकार जब कोई प्रोग्राम बड़ा हो जाता है, जैसे मल्टी-मिलियन-लाइन प्रोग्राम, तब यह अंतर पदानुक्रमित धारणा प्राप्त कर सकता है। उस स्थिति में, ऐसे आंतरिक पुस्तकालय हो सकते हैं जिनका बड़े प्रोग्राम के स्वतंत्र उप-भागों द्वारा पुन: उपयोग किया जाता है। विशिष्ट विशेषता यह है कि पुस्तकालय को स्वतंत्र कार्यक्रमों या उप-कार्यक्रमों द्वारा पुन: उपयोग किए जाने के उद्देश्य से व्यवस्थित किया जाता है, और उपयोगकर्ता को केवल इंटरफ़ेस जानने की आवश्यकता होती है, न कि पुस्तकालय के आंतरिक विवरण की आवश्यकता होती हैं।
-किसी लाइब्रेरी का मूल्य मानकीकृत प्रोग्राम तत्वों के पुन: उपयोग में निहित है। जब कोई प्रोग्राम किसी लाइब्रेरी का आह्वान करता है, तब वह उस व्यवहार को क्रियान्वित किए बिना ही उस लाइब्रेरी के अंदर क्रियान्वित व्यवहार को प्राप्त कर लेता है। पुस्तकालय [[मॉड्यूलर प्रोग्रामिंग]] फैशन में कोड साझा करने को प्रोत्साहित करते हैं और कोड के वितरण को आसान बनाते हैं।
+किसी लाइब्रेरी का मूल्य मानकीकृत प्रोग्राम तत्वों के पुन: उपयोग में निहित है। इस प्रकार जब कोई प्रोग्राम किसी लाइब्रेरी का आह्वान करता है, तब वह उस व्यवहार को क्रियान्वित किए बिना ही उस लाइब्रेरी के अंदर क्रियान्वित व्यवहार को प्राप्त कर लेता है। इस प्रकार पुस्तकालय [[मॉड्यूलर प्रोग्रामिंग]] फैशन में कोड साझा करने को प्रोत्साहित करते हैं और कोड के वितरण को आसान बनाते हैं।
-लाइब्रेरी द्वारा कार्यान्वित व्यवहार को विभिन्न प्रोग्राम जीवनचक्र चरणों में इनवोकिंग प्रोग्राम से जोड़ा जा सकता है। यदि लाइब्रेरी के कोड को इनवोकिंग प्रोग्राम के निर्माण के समय एक्सेस किया जाता है, तब लाइब्रेरी को [[स्थैतिक पुस्तकालय]] कहा जाता है।<ref name="स्थैतिक पुस्तकालय">{{cite web|title=स्थैतिक पुस्तकालय|url=http://tldp.org/HOWTO/Program-Library-HOWTO/static-libraries.html|publisher=TLDP|access-date=3 October 2013|url-status=live|archive-url=https://web.archive.org/web/20130703011904/http://tldp.org/HOWTO/Program-Library-HOWTO/static-libraries.html|archive-date=3 July 2013}}</ref> विकल्प यह है कि इनवोकिंग प्रोग्राम के निष्पादन योग्य का निर्माण किया जाए और उसे लाइब्रेरी कार्यान्वयन से स्वतंत्र रूप से वितरित किया जाए। निष्पादन योग्य को निष्पादित करने के पश्चात् लाइब्रेरी व्यवहार जुड़ा हुआ है, या तब निष्पादन प्रारंभ करने की प्रक्रिया के हिस्से के रूप में, या निष्पादन के मध्य में। इस स्थितियोंमें लाइब्रेरी को [[गतिशील पुस्तकालय]] ([[रनटाइम (प्रोग्राम जीवनचक्र चरण)]] पर लोड) कहा जाता है। निष्पादन के लिए प्रोग्राम तैयार करते समय [[लिंकर (कंप्यूटिंग)]] द्वारा गतिशील लाइब्रेरी को लोड और लिंक किया जा सकता है। वैकल्पिक रूप से, निष्पादन के मध्य में, एप्लिकेशन स्पष्ट रूप से अनुरोध कर सकता है कि मॉड्यूल [[गतिशील लोडिंग]] हो।
+लाइब्रेरी द्वारा कार्यान्वित व्यवहार को विभिन्न प्रोग्राम जीवनचक्र चरणों में इनवोकिंग प्रोग्राम से जोड़ा जा सकता है। यदि लाइब्रेरी के कोड को इनवोकिंग प्रोग्राम के निर्माण के समय एक्सेस किया जाता है, तब लाइब्रेरी को [[स्थैतिक पुस्तकालय]] कहा जाता है।<ref name="स्थैतिक पुस्तकालय">{{cite web|title=स्थैतिक पुस्तकालय|url=http://tldp.org/HOWTO/Program-Library-HOWTO/static-libraries.html|publisher=TLDP|access-date=3 October 2013|url-status=live|archive-url=https://web.archive.org/web/20130703011904/http://tldp.org/HOWTO/Program-Library-HOWTO/static-libraries.html|archive-date=3 July 2013}}</ref> इस प्रकार विकल्प यह है कि इनवोकिंग प्रोग्राम के निष्पादन योग्य का निर्माण किया जाए और उसे लाइब्रेरी कार्यान्वयन से स्वतंत्र रूप से वितरित किया जाए। निष्पादन योग्य को निष्पादित करने के पश्चात् लाइब्रेरी व्यवहार जुड़ा हुआ है, या तब निष्पादन प्रारंभ करने की प्रक्रिया के हिस्से के रूप में, या निष्पादन के मध्य में किया जाता है। इस प्रकार इस स्थितियों में लाइब्रेरी को लाइब्रेरी को डायनेमिक लाइब्रेरी (रनटाइम पर लोड) कहा जाता है। निष्पादन के लिए प्रोग्राम तैयार करते समय [[लिंकर (कंप्यूटिंग)]] द्वारा गतिशील लाइब्रेरी को लोड और लिंक किया जा सकता है। वैकल्पिक रूप से, निष्पादन के मध्य में, एप्लिकेशन स्पष्ट रूप से अनुरोध कर सकता है कि मॉड्यूल [[गतिशील लोडिंग]] किया जाए।
-अधिकांश [[संकलित भाषा]]ओं में मानक लाइब्रेरी होती है, यद्यपि प्रोग्रामर अपनी स्वयं की [[मानक पुस्तकालय]] भी बना सकते हैं। अधिकांश आधुनिक सॉफ्टवेयर पद्धति लाइब्रेरी प्रदान करते हैं जो अधिकांश पद्धति सेवाओं को क्रियान्वित करते हैं। ऐसे पुस्तकालयों ने उन सेवाओं को व्यवस्थित किया है जिनकी आधुनिक अनुप्रयोग के लिए आवश्यकता होती है। इस प्रकार, आधुनिक अनुप्रयोगों द्वारा उपयोग किया जाने वाला अधिकांश कोड इन पद्धति लाइब्रेरीज़ में प्रदान किया जाता है।
+अधिकांश [[संकलित भाषा]]ओं में मानक लाइब्रेरी होती है, यद्यपि प्रोग्रामर अपनी स्वयं की [[मानक पुस्तकालय]] भी बना सकते हैं। इस प्रकार अधिकांश आधुनिक सॉफ्टवेयर सिस्टम लाइब्रेरी प्रदान करते हैं जो अधिकांश सिस्टम सेवाओं को क्रियान्वित करते हैं। ऐसे पुस्तकालयों ने उन सेवाओं को व्यवस्थित किया है जिनकी आधुनिक अनुप्रयोग के लिए आवश्यकता होती है। इस प्रकार, आधुनिक अनुप्रयोगों द्वारा उपयोग किया जाने वाला अधिकांश कोड इन सिस्टम लाइब्रेरीज़ में प्रदान किया जाता है।
 ==इतिहास==
-कंप्यूटर लाइब्रेरी का विचार [[चार्ल्स बैबेज]] द्वारा बनाए गए पहले कंप्यूटर से जुड़ा है। उनके [[विश्लेषणात्मक इंजन]] पर 1888 के पेपर में सुझाव दिया गया कि कंप्यूटर संचालन को संख्यात्मक इनपुट से भिन्न कार्डों पर पंच किया जा सकता है। यदि इन ऑपरेशन पंच कार्डों को पुन: उपयोग के लिए सहेजा जाता तब धीरे-धीरे इंजन के पास अपनी लाइब्रेरी होती।<ref>{{cite journal |url=https://www.fourmilab.ch/babbage/hpb.html |first=H. P. |last=Babbage |journal=Proceedings of the British Association |date=September 12, 1888 |location=Bath
+कंप्यूटर लाइब्रेरी का विचार [[चार्ल्स बैबेज]] द्वारा बनाए गए पहले कंप्यूटर से जुड़ा है। उनके [[विश्लेषणात्मक इंजन]] पर सत्र 1888 के पेपर में सुझाव दिया गया कि कंप्यूटर संचालन को संख्यात्मक इनपुट से भिन्न कार्डों पर पंच किया जा सकता है। इस प्रकार यदि इन ऑपरेशन पंच कार्डों को पुन: उपयोग के लिए सहेजा जाता '''"कुछ हद तक इंजन की अपनी लाइब्रेरी होती।"'''<ref>{{cite journal |url=https://www.fourmilab.ch/babbage/hpb.html |first=H. P. |last=Babbage |journal=Proceedings of the British Association |date=September 12, 1888 |location=Bath
 |title=The Analytical Engine }}</ref>
-[[File:FirstCodeLibrary-ESDAC-ThePreparationOfProgramsForAnElectronicDigitalComputer-1951.jpg|thumb|एक महिला ईडीएसएसी कंप्यूटर के लिए छिद्रित टेप की रीलों पर सबरूटीन लाइब्रेरी वाली फाइलिंग कैबिनेट के बगल में काम कर रही है।]]1947 में [[हरमन गोल्डस्टाइन]] और [[जॉन वॉन न्यूमैन]] ने अनुमान लगाया कि [[आईएएस मशीन]] पर अपने काम के लिए सबरूटीन्स की लाइब्रेरी बनाना उपयोगी होगा, प्रारंभिक कंप्यूटर जो उस समय तक चालू नहीं था।<ref>{{Cite book|last=Goldstine|first=Herman H.|url=http://dx.doi.org/10.1515/9781400820139|title=पास्कल से वॉन न्यूमैन तक का कंप्यूटर|date=2008-12-31|publisher=Princeton University Press|isbn=978-1-4008-2013-9|location=Princeton|doi=10.1515/9781400820139}}</ref> उन्होंने [[चुंबकीय तार रिकॉर्डिंग]] की भौतिक लाइब्रेरी की कल्पना की, जिसमें प्रत्येक तार में पुन: प्रयोज्य कंप्यूटर कोड संग्रहीत था।<ref>{{cite report |last1=Goldstine |first1=Herman |last2=von Neumann |first2=John |author-link1=Herman Goldstine |author-link2=John von Neumann |date=1947 |title=इलेक्ट्रॉनिक कंप्यूटिंग उपकरण के लिए समस्याओं की योजना बनाना और कोडिंग करना|url= |publisher=Institute for Advanced Study |page=3, 21–22 |oclc=26239859 |quote=it will probably be very important to develop an extensive "library" of subroutines}}</ref>
+[[File:FirstCodeLibrary-ESDAC-ThePreparationOfProgramsForAnElectronicDigitalComputer-1951.jpg|thumb|एक महिला ईडीएसएसी कंप्यूटर के लिए छिद्रित टेप की रीलों पर सबरूटीन लाइब्रेरी वाली फाइलिंग कैबिनेट के बगल में काम कर रही है।]]वर्ष 1947 में [[हरमन गोल्डस्टाइन|गोल्डस्टाइन]] और [[जॉन वॉन न्यूमैन|वॉन न्यूमैन]] ने अनुमान लगाया कि [[आईएएस मशीन]] पर अपने काम के लिए सबरूटीन्स की '''"लाइब्रेरी"''' बनाना उपयोगी होगा, प्रारंभिक कंप्यूटर जो उस समय तक चालू नहीं था।<ref>{{Cite book|last=Goldstine|first=Herman H.|url=http://dx.doi.org/10.1515/9781400820139|title=पास्कल से वॉन न्यूमैन तक का कंप्यूटर|date=2008-12-31|publisher=Princeton University Press|isbn=978-1-4008-2013-9|location=Princeton|doi=10.1515/9781400820139}}</ref> इस प्रकार उन्होंने [[चुंबकीय तार रिकॉर्डिंग]] की भौतिक लाइब्रेरी की कल्पना की, जिसमें प्रत्येक तार में पुन: प्रयोज्य कंप्यूटर कोड संग्रहीत था।<ref>{{cite report |last1=Goldstine |first1=Herman |last2=von Neumann |first2=John |author-link1=Herman Goldstine |author-link2=John von Neumann |date=1947 |title=इलेक्ट्रॉनिक कंप्यूटिंग उपकरण के लिए समस्याओं की योजना बनाना और कोडिंग करना|url= |publisher=Institute for Advanced Study |page=3, 21–22 |oclc=26239859 |quote=it will probably be very important to develop an extensive "library" of subroutines}}</ref>
-वॉन न्यूमैन से प्रेरित होकर, [[मौरिस विल्केस]] और उनकी टीम ने ईडीएसएसी का निर्माण किया। [[छिद्रित टेप]] की [[ फाइलें रखने की अलमारी |फाइलें रखने की अलमारी]] में इस कंप्यूटर के लिए सबरूटीन लाइब्रेरी थी।<ref>{{Cite conference|last=Wilkes|first=M. V.| title=1951 International Workshop on Managing Requirements Knowledge |date=1951|chapter=The EDSAC Computer| page=79 |chapter-url=http://dx.doi.org/10.1109/afips.1951.13|conference=1951 International Workshop on Managing Requirements Knowledge|publisher=IEEE|doi=10.1109/afips.1951.13}}</ref> ईडीएसएसी के कार्यक्रमों में मुख्य कार्यक्रम और सबरूटीन लाइब्रेरी से कॉपी किए गए सबरूटीन्स का क्रम सम्मिलित होता है।<ref>{{cite journal |last1=Campbell-Kelly |first1=Martin |date=September 2011 |title='विल्केस, व्हीलर और गिल' की प्रशंसा में|url=https://cacm.acm.org/magazines/2011/9/122802-in-praise-of-wilkes-wheeler-and-gill/fulltext |journal=Communications of the ACM |volume=54 |issue=9 |pages=25–27 |doi=10.1145/1995376.1995386|s2cid=20261972 }}</ref> 1951 में टीम ने प्रोग्रामिंग पर पहली पाठ्यपुस्तक, इलेक्ट्रॉनिक डिजिटल कंप्यूटर के लिए प्रोग्राम की तैयारी, प्रकाशित की, जिसमें लाइब्रेरी के निर्माण और उद्देश्य का विवरण दिया गया था।<ref>{{cite book |last1=Wilkes |first1=Maurice |last2=Wheeler |first2=David |last3=Gill |first3=Stanley |author-link1=Maurice Wilkes |author-link2=David Wheeler (computer scientist) |author-link3=Stanley Gill |date=1951 |title=इलेक्ट्रॉनिक डिजिटल कंप्यूटर के लिए प्रोग्राम तैयार करना|oclc=641145988 |url=https://archive.org/details/programsforelect00wilk/page/80/mode/2up?q=library |location= |publisher=Addison-Wesley |page=45, 80–91, 100 |isbn=}}</ref>
+वॉन न्यूमैन से प्रेरित होकर, [[मौरिस विल्केस|विल्केस]] और उनकी टीम ने ईडीएसएसी का निर्माण किया। इस प्रकार [[छिद्रित टेप]] की [[ फाइलें रखने की अलमारी |फाइलिंग कैबिनेट]] में इस कंप्यूटर के लिए सबरूटीन लाइब्रेरी थी।<ref>{{Cite conference|last=Wilkes|first=M. V.| title=1951 International Workshop on Managing Requirements Knowledge |date=1951|chapter=The EDSAC Computer| page=79 |chapter-url=http://dx.doi.org/10.1109/afips.1951.13|conference=1951 International Workshop on Managing Requirements Knowledge|publisher=IEEE|doi=10.1109/afips.1951.13}}</ref> ईडीएसएसी के कार्यक्रमों में मुख्य कार्यक्रम और सबरूटीन लाइब्रेरी से कॉपी किए गए सबरूटीन्स का क्रम सम्मिलित होता है।<ref>{{cite journal |last1=Campbell-Kelly |first1=Martin |date=September 2011 |title='विल्केस, व्हीलर और गिल' की प्रशंसा में|url=https://cacm.acm.org/magazines/2011/9/122802-in-praise-of-wilkes-wheeler-and-gill/fulltext |journal=Communications of the ACM |volume=54 |issue=9 |pages=25–27 |doi=10.1145/1995376.1995386|s2cid=20261972 }}</ref> इस प्रकार वर्ष 1951 में टीम ने प्रोग्रामिंग पर पहली पाठ्यपुस्तक, इलेक्ट्रॉनिक डिजिटल कंप्यूटर के लिए प्रोग्राम की तैयारी, प्रकाशित की, जिसमें लाइब्रेरी के निर्माण और उद्देश्य का विवरण दिया गया था।<ref>{{cite book |last1=Wilkes |first1=Maurice |last2=Wheeler |first2=David |last3=Gill |first3=Stanley |author-link1=Maurice Wilkes |author-link2=David Wheeler (computer scientist) |author-link3=Stanley Gill |date=1951 |title=इलेक्ट्रॉनिक डिजिटल कंप्यूटर के लिए प्रोग्राम तैयार करना|oclc=641145988 |url=https://archive.org/details/programsforelect00wilk/page/80/mode/2up?q=library |location= |publisher=Addison-Wesley |page=45, 80–91, 100 |isbn=}}</ref>
-[[COBOL]] ने 1959 में पुस्तकालय प्रणाली के लिए आदिम क्षमताओं को सम्मिलित किया,<ref name="Wexelblat_1981_247">{{Cite book |last=Wexelblat |first=Richard |title=प्रोग्रामिंग भाषाओं का इतिहास|publisher=Academic Press (A subsidiary of [[Harcourt Brace]]) |year=1981 |series=ACM Monograph Series |publication-place=New York, NY |isbn=0-12-745040-8 |page=[https://archive.org/details/historyofprogram0000hist/page/274 274] |url=https://archive.org/details/historyofprogram0000hist/page/274 }}</ref> किन्तु जीन ई. सम्मेट ने उन्हें पूर्वव्यापी रूप से अपर्याप्त पुस्तकालय सुविधाओं के रूप में वर्णित किया।<ref name="Wexelblat_1981_258">वेक्सेलब्लैट, ऑप. सिट., पी. 258</ref>
+[[COBOL]] ने 1959 में '''"पुस्तकालय प्रणाली के लिए आदिम क्षमताओं"''' को सम्मिलित किया,<ref name="Wexelblat_1981_247">{{Cite book |last=Wexelblat |first=Richard |title=प्रोग्रामिंग भाषाओं का इतिहास|publisher=Academic Press (A subsidiary of [[Harcourt Brace]]) |year=1981 |series=ACM Monograph Series |publication-place=New York, NY |isbn=0-12-745040-8 |page=[https://archive.org/details/historyofprogram0000hist/page/274 274] |url=https://archive.org/details/historyofprogram0000hist/page/274 }}</ref> किन्तु जीन ई. सैममेट ने उन्हें पूर्वव्यापी रूप से '''"अपर्याप्त पुस्तकालय सुविधाओं"''' के रूप में वर्णित किया।<ref name="Wexelblat_1981_258">वेक्सेलब्लैट, ऑप. सिट., पी. 258</ref>
-[[ उल्लासपूर्ण | उल्लासपूर्ण]] के पास संचार पूल (COMPOOL) था, जो मोटे तौर पर हेडर फ़ाइलों की लाइब्रेरी थी।
+[[ उल्लासपूर्ण | जोवियल]] के पास संचार पूल (COMPOOL) था, जो मोटे तौर पर हेडर फ़ाइलों की लाइब्रेरी थी।
-आधुनिक पुस्तकालय अवधारणा में और प्रमुख योगदानकर्ता [[फोरट्रान]] के [[Subprogram]] नवाचार के रूप में आया। फोरट्रान उपप्रोग्रामों को दूसरे से स्वतंत्र रूप से संकलित किया जा सकता है, किन्तु कंपाइलर में लिंकर (कंप्यूटिंग) का अभाव था। इसलिए फोरट्रान-90 में मॉड्यूल की प्रारंभआत से पहले, फोरट्रान के मध्य [[टाइप चेकिंग]] करें
+आधुनिक पुस्तकालय अवधारणा में और प्रमुख योगदानकर्ता [[फोरट्रान]] के [[Subprogram|उपप्रोग्राम]] नवाचार के रूप में आया। इस प्रकार फोरट्रान उपप्रोग्रामों को दूसरे से स्वतंत्र रूप से संकलित किया जा सकता है, किन्तु कंपाइलर में लिंकर (कंप्यूटिंग) का अभाव था। इसलिए फोरट्रान-90 में मॉड्यूल की प्रारंभ से पहले, फोरट्रान [एनबी 1] उपप्रोग्रामों के मध्य प्रकार की जांच असंभव थी।<ref name="Wilson_Clark_1988_126">{{Cite book |last1=Wilson |first1=Leslie B. |last2=Clark |first2=Robert G.
-रेफरी समूह = एनबी>यह पहले संभव था, उदाहरण के लिए, एडा उपप्रोग्राम।</ref> उपप्रोग्राम असंभव था।<ref name="Wilson_Clark_1988_126">{{Cite book |last1=Wilson |first1=Leslie B. |last2=Clark |first2=Robert G.
 |title=तुलनात्मक प्रोग्रामिंग भाषाएँ|publisher=Addison-Wesley |year=1988 |publication-place=Wokingham, England |isbn=0-201-18483-4 |page=126 }}</ref>
-के दशक के मध्य तक, असेंबलरों के लिए कॉपी और मैक्रो लाइब्रेरी आम थीं। आईबीएम सिस्टम/360 की लोकप्रियता के साथ प्रारंभ होकर, अन्य प्रकार के टेक्स्ट तत्वों, जैसे पद्धति पैरामीटर, वाले पुस्तकालय भी आम हो गए।
+इस प्रकार वर्ष 1960 के दशक के मध्य तक, असेंबलरों के लिए कॉपी और मैक्रो लाइब्रेरी सामान्य थीं। आईबीएम सिस्टम/360 की लोकप्रियता के साथ प्रारंभ होकर, अन्य प्रकार के टेक्स्ट तत्वों, जैसे सिस्टम पैरामीटर, वाले पुस्तकालय भी सामान्य हो गए।
-[[ शुरुआत | शुरुआत]] पहली [[ ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग |ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग]] भाषा थी, और इसकी कक्षा (कंप्यूटर विज्ञान) [[जावा (प्रोग्रामिंग भाषा)]], सी ++ और सी शार्प (प्रोग्रामिंग भाषा) | सी # में उपयोग की जाने वाली आधुनिक अवधारणा के लगभग समान थी। सिमुला की वर्ग अवधारणा [[एडा (प्रोग्रामिंग भाषा)]] में पैकेज और मॉड्यूला-2 के मॉड्यूल की भी पूर्वज थी।<ref name="Wilson_Clark_1988_52">विल्सन और क्लार्क, ऑप. सिट., पी. 52</ref> मूल रूप से 1965 में विकसित होने पर भी, सिमुला कक्षाओं को लाइब्रेरी फ़ाइलों में सम्मिलित किया जा सकता था और संकलन समय पर जोड़ा जा सकता था।<ref name="Wexelblat_1981_716">वेक्सेलब्लैट, ऑप. सिट., पी. 716</ref>
+[[ शुरुआत | सिमुला]] पहली [[ ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग |ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग]] भाषा थी, और इसकी कक्षाएं [[जावा (प्रोग्रामिंग भाषा)]], सी ++ और सी # में उपयोग की जाने वाली आधुनिक अवधारणा के लगभग समान थी। सिमुला की वर्ग अवधारणा [[एडा (प्रोग्रामिंग भाषा)]] में पैकेज और मॉड्यूला-2 के मॉड्यूल की भी जनक थी।<ref name="Wilson_Clark_1988_52">विल्सन और क्लार्क, ऑप. सिट., पी. 52</ref> इस प्रकार मूल रूप से वर्ष 1965 में विकसित होने पर भी, सिमुला कक्षाओं को लाइब्रेरी फ़ाइलों में सम्मिलित किया जा सकता था और संकलन समय पर जोड़ा जा सकता था।<ref name="Wexelblat_1981_716">वेक्सेलब्लैट, ऑप. सिट., पी. 716</ref>
 ==लिंकिंग==
 {{main|लिंक समय|लिंकर (कंप्यूटिंग)}}
-लाइब्रेरी प्रोग्राम लिंकिंग या बाइंडिंग प्रक्रिया में महत्वपूर्ण हैं, जो लाइब्रेरी मॉड्यूल के लिंक या प्रतीकों के रूप में ज्ञात संदर्भों को हल करती है। लिंकिंग प्रक्रिया सामान्यतः लिंकर (कंप्यूटिंग) या बाइंडर प्रोग्राम द्वारा स्वचालित रूप से की जाती है जो किसी दिए गए क्रम में पुस्तकालयों और अन्य मॉड्यूल के समूह की खोज करता है। सामान्यतः इसे त्रुटि नहीं माना जाता है यदि किसी दिए गए पुस्तकालयों के समूह में लिंक लक्ष्य अनेक बार पाया जा सकता है। लिंकिंग तब की जा सकती है जब निष्पादन योग्य फ़ाइल बनाई जाती है (स्थैतिक लिंकिंग), या जब भी प्रोग्राम का उपयोग रनटाइम (प्रोग्राम जीवनचक्र चरण) (डायनामिक लिंकिंग) में किया जाता है।
+लाइब्रेरी प्रोग्राम लिंकिंग या बाइंडिंग प्रक्रिया में महत्वपूर्ण हैं, जो लाइब्रेरी मॉड्यूल के लिंक या प्रतीकों के रूप में ज्ञात संदर्भों को हल करती है। इस प्रकार लिंकिंग प्रक्रिया सामान्यतः लिंकर (कंप्यूटिंग) या बाइंडर प्रोग्राम द्वारा स्वचालित रूप से की जाती है जो किसी दिए गए क्रम में पुस्तकालयों और अन्य मॉड्यूल के समूह की खोज करता है। इस प्रकार सामान्यतः इसे त्रुटि नहीं माना जाता है यदि किसी दिए गए पुस्तकालयों के समूह में लिंक लक्ष्य अनेक बार पाया जा सकता है। इस प्रकार लिंकिंग तब की जा सकती है जब निष्पादन योग्य फ़ाइल बनाई जाती है (स्थैतिक लिंकिंग), या जब भी प्रोग्राम का उपयोग रनटाइम (डायनामिक लिंकिंग) में किया जाता है।
-हल किए जा रहे संदर्भ जंप और अन्य नियमित कॉल के पते हो सकते हैं। वह मुख्य कार्यक्रम में, या दूसरे के आधार पर मॉड्यूल में हो सकते हैं। संदर्भित प्रत्येक मॉड्यूल के [[ स्मृति खंड |स्मृति खंड]] के लिए रनटाइम मेमोरी आवंटित करके उन्हें निश्चित या स्थानांतरित करने योग्य पते (एक सामान्य आधार से) में हल किया जाता है।
+हल किए जा रहे संदर्भ जंप और अन्य नियमित कॉल के पते हो सकते हैं। वह मुख्य कार्यक्रम में, या दूसरे के आधार पर मॉड्यूल में हो सकते हैं। संदर्भित प्रत्येक मॉड्यूल के [[ स्मृति खंड |मेमोरी सेगमेंट]] के लिए रनटाइम मेमोरी आवंटित करके उन्हें निश्चित या स्थानांतरित करने योग्य पते (एक सामान्य आधार से) में हल किया जाता है।
-कुछ प्रोग्रामिंग भाषाएं स्मार्ट लिंकिंग नामक सुविधा का उपयोग करती हैं, जिससे लिंकर कंपाइलर के बारे में जानता है या उसके साथ एकीकृत होता है, जैसे कि लिंकर को पता होता है कि बाहरी संदर्भों का उपयोग कैसे किया जाता है, और लाइब्रेरी में कोड जो वास्तव में कभी भी उपयोग नहीं किया जाता है, यदि  आंतरिक रूप से संदर्भित हो, हो सकता है संकलित अनुप्रयोग से हटा दिया गया। उदाहरण के लिए, प्रोग्राम जो अंकगणित के लिए केवल पूर्णांक का उपयोग करता है, या बिल्कुल भी अंकगणितीय संचालन नहीं करता है, फ़्लोटिंग-पॉइंट लाइब्रेरी रूटीन को बाहर कर सकता है। इस स्मार्ट-लिंकिंग सुविधा से एप्लिकेशन फ़ाइल का आकार छोटा हो सकता है और मेमोरी का उपयोग कम हो सकता है।
+कुछ प्रोग्रामिंग भाषाएं स्मार्ट लिंकिंग नामक सुविधा का उपयोग करती हैं, जिससे लिंकर कंपाइलर के बारे में जानता है या उसके साथ एकीकृत होता है, जैसे कि लिंकर को पता होता है कि बाहरी संदर्भों का उपयोग कैसे किया जाता है, और लाइब्रेरी में कोड जो वास्तव में कभी भी उपयोग नहीं किया जाता है, इस प्रकार यदि आंतरिक रूप से संदर्भित हो, संकलित एप्लिकेशन से से हटाया जा सकता है। उदाहरण के लिए, प्रोग्राम जो अंकगणित के लिए केवल पूर्णांक का उपयोग करता है, या बिल्कुल भी अंकगणितीय के लिए केवल पूर्णांक का उपयोग करता है, या बिल्कुल भी अंकगणितीय संचालन नहीं करता है, इस प्रकार फ़्लोटिंग-पॉइंट लाइब्रेरी रूटीन को बाहर कर सकता है। इस स्मार्ट-लिंकिंग सुविधा से एप्लिकेशन फ़ाइल का आकार छोटा हो सकता है और मेमोरी का उपयोग कम हो सकता है।
 ==स्थानांतरण==
@@ Line 55: / Line 54: @@
 {{Main|स्थैतिक पुस्तकालय}}
-जब निष्पादन योग्य या किसी अन्य ऑब्जेक्ट फ़ाइल के निर्माण के समय लिंकिंग की जाती है, तब इसे स्टैटिक लिंकिंग या अर्ली बाइंडिंग के रूप में जाना जाता है। इस स्थितियोंमें, लिंकिंग सामान्यतः लिंकर (कंप्यूटिंग) द्वारा की जाती है, किन्तु [[ संकलक |संकलक]] द्वारा भी की जा सकती है।<ref>{{Citation|last=Kaminsky|first=Dan|title=Portable Executable and Executable and Linking Formats|date=2008|url=http://dx.doi.org/10.1016/b978-1-59749-237-9.00003-x|work=Reverse Engineering Code with IDA Pro|pages=37–66|publisher=Elsevier|doi=10.1016/b978-1-59749-237-9.00003-x|isbn=978-1-59749-237-9|access-date=2021-05-27}}</ref> स्थैतिक पुस्तकालय, जिसे संग्रह के रूप में भी जाना जाता है, का उद्देश्य स्थैतिक रूप से जुड़ा होना है। मूलतः, केवल स्थैतिक पुस्तकालय ही अस्तित्व में थे। किसी भी मॉड्यूल को पुन: संकलित करते समय स्टेटिक लिंकिंग अवश्य की जानी चाहिए।
+जब निष्पादन योग्य या किसी अन्य ऑब्जेक्ट फ़ाइल के निर्माण के समय लिंकिंग की जाती है, तब इसे स्टैटिक लिंकिंग या अर्ली बाइंडिंग के रूप में जाना जाता है। इन स्थितियों    में, लिंकिंग सामान्यतः लिंकर (कंप्यूटिंग) द्वारा की जाती है, किन्तु [[ संकलक |कंपाइलर]] द्वारा भी की जा सकती है।<ref>{{Citation|last=Kaminsky|first=Dan|title=Portable Executable and Executable and Linking Formats|date=2008|url=http://dx.doi.org/10.1016/b978-1-59749-237-9.00003-x|work=Reverse Engineering Code with IDA Pro|pages=37–66|publisher=Elsevier|doi=10.1016/b978-1-59749-237-9.00003-x|isbn=978-1-59749-237-9|access-date=2021-05-27}}</ref> स्थैतिक पुस्तकालय, जिसे संग्रह के रूप में भी जाना जाता है, का उद्देश्य स्थैतिक रूप से जुड़ा होना है। मूलतः, केवल स्थैतिक पुस्तकालय ही अस्तित्व में थे। किसी भी मॉड्यूल को पुन: संकलित करते समय स्टेटिक लिंकिंग अवश्य की जानी चाहिए।
-किसी प्रोग्राम के लिए आवश्यक सभी मॉड्यूल कभी-कभी स्थिर रूप से लिंक किए जाते हैं और निष्पादन योग्य फ़ाइल में कॉपी किए जाते हैं। यह प्रक्रिया, और परिणामी स्टैंड-अलोन फ़ाइल, प्रोग्राम के स्थिर निर्माण के रूप में जानी जाती है। यदि [[ आभासी मेमोरी |आभासी मेमोरी]] का उपयोग किया जाता है और कोई [[पता स्थान लेआउट यादृच्छिकीकरण]] वांछित नहीं है, तब [[स्थैतिक निर्माण]] को किसी और [[स्थानांतरण (कंप्यूटर विज्ञान)]] की आवश्यकता नहीं हो सकती है।<ref>{{cite web|url=http://usenix.org/legacy/publications/library/proceedings/usenix05/tech/general/full_papers/collberg/collberg_html/main.html|title=SLINKY: Static Linking Reloaded|authors=Christian Collberg, John H. Hartman, Sridivya Babu, Sharath K. Udupa|publisher=Department of Computer Science, [[University of Arizona]]|access-date=2016-03-17|year=2003|url-status=live|archive-url=https://web.archive.org/web/20160323214637/https://www.usenix.org/legacy/publications/library/proceedings/usenix05/tech/general/full_papers/collberg/collberg_html/main.html|archive-date=23 March 2016}}</ref>
+किसी प्रोग्राम के लिए आवश्यक सभी मॉड्यूल कभी-कभी स्थिर रूप से लिंक किए जाते हैं और निष्पादन योग्य फ़ाइल में कॉपी किए जाते हैं। यह प्रक्रिया, और परिणामी स्टैंड-अलोन फ़ाइल, प्रोग्राम के स्थिर निर्माण के रूप में जानी जाती है। यदि [[ आभासी मेमोरी |वर्चुअल मेमोरी]] का उपयोग किया जाता है और कोई [[पता स्थान लेआउट यादृच्छिकीकरण|पता स्थान लेआउट रैंडमाइजेशन]] वांछित नहीं है, तब [[स्थैतिक निर्माण]] को किसी और [[स्थानांतरण (कंप्यूटर विज्ञान)|स्थानांतरण]] की आवश्यकता नहीं हो सकती है।<ref>{{cite web|url=http://usenix.org/legacy/publications/library/proceedings/usenix05/tech/general/full_papers/collberg/collberg_html/main.html|title=SLINKY: Static Linking Reloaded|authors=Christian Collberg, John H. Hartman, Sridivya Babu, Sharath K. Udupa|publisher=Department of Computer Science, [[University of Arizona]]|access-date=2016-03-17|year=2003|url-status=live|archive-url=https://web.archive.org/web/20160323214637/https://www.usenix.org/legacy/publications/library/proceedings/usenix05/tech/general/full_papers/collberg/collberg_html/main.html|archive-date=23 March 2016}}</ref>
 ==साझा पुस्तकालय==
 {{redirect|साझा वस्तु|तुल्यकालन तंत्र|मॉनिटर (सिंक्रनाइज़ेशन)}}
-एक साझा लाइब्रेरी या साझा ऑब्जेक्ट फ़ाइल है जिसका उद्देश्य निष्पादन योग्य फ़ाइलों और आगे साझा [[ऑब्जेक्ट फ़ाइल]]ों द्वारा साझा किया जाना है। किसी प्रोग्राम द्वारा उपयोग किए जाने वाले मॉड्यूल को लोड समय या रनटाइम (प्रोग्राम जीवनचक्र चरण) पर भिन्न- भिन्न साझा ऑब्जेक्ट से मेमोरी में लोड किया जाता है, न कि किसी लिंकर द्वारा कॉपी किए जाने पर जब यह प्रोग्राम के लिए एकल मोनोलिथिक निष्पादन योग्य फ़ाइल बनाता है।
+एक '''साझा लाइब्रेरी''' या '''साझा ऑब्जेक्ट''' फ़ाइल है जिसका उद्देश्य निष्पादन योग्य फ़ाइलों और आगे साझा [[ऑब्जेक्ट फ़ाइल|ऑब्जेक्ट फ़ाइलों]] द्वारा साझा किया जाना है। किसी प्रोग्राम द्वारा उपयोग किए जाने वाले मॉड्यूल को लोड समय या रनटाइम  पर भिन्न- भिन्न साझा ऑब्जेक्ट से मेमोरी में लोड किया जाता है, न कि किसी लिंकर द्वारा कॉपी किए जाने पर जब यह प्रोग्राम के लिए एकल मोनोलिथिक निष्पादन योग्य फ़ाइल बनाता है।
-साझा पुस्तकालयों को संकलन-समय के समय स्थिर रूप से जोड़ा जा सकता है, जिसका अर्थ है कि पुस्तकालय मॉड्यूल के संदर्भों को हल किया जाता है और निष्पादन योग्य फ़ाइल बनने पर मॉड्यूल को मेमोरी आवंटित की जाती है। किन्तु अधिकांशतः साझा लाइब्रेरीज़ को लोड होने तक लिंक करना स्थगित कर दिया जाता है।
+साझा पुस्तकालयों को संकलन-समय के समय स्थिर रूप से जोड़ा जा सकता है, जिसका अर्थ है कि पुस्तकालय मॉड्यूल के संदर्भों को हल किया जाता है और निष्पादन योग्य फ़ाइल बनने पर मॉड्यूल को मेमोरी आवंटित की जाती है। किन्तु अधिकांशतः साझा लाइब्रेरीज़ को लोड होने तक लिंक करना स्थगित कर दिया जाता है। जब तक कि वे लोड न हो जाएं।
 सबसे आधुनिक [[ऑपरेटिंग सिस्टम]]<ref group=NB>Some older systems, e.g., [[Burroughs MCP]], [[Multics]], also have only a single format for executable files, regardless of whether they are shared.</ref> इसमें निष्पादन योग्य फ़ाइलों के समान प्रारूप की साझा लाइब्रेरी फ़ाइलें हो सकती हैं। यह दो मुख्य लाभ प्रदान करता है: पहला, इसमें दोनों के लिए दो के अतिरिक्त केवल लोडर बनाने की आवश्यकता होती है (एकल लोडर को इसकी अतिरिक्त जटिलता के लायक माना जाता है). दूसरे, यह निष्पादनयोग्यों को साझा पुस्तकालयों के रूप में भी उपयोग करने की अनुमति देता है, यदि उनके पास [[प्रतीक तालिका]] है। विशिष्ट संयुक्त निष्पादन योग्य और साझा लाइब्रेरी प्रारूप [[निष्पादन योग्य और लिंक करने योग्य प्रारूप]] और [[मच-ओ]] (दोनों यूनिक्स में) और [[पोर्टेबल निष्पादन योग्य]] (विंडोज़) हैं।
-कुछ पुराने परिवेशों जैसे कि [[16-बिट विंडोज़]] या [[एचपी 3000]] के लिए [[एचपी मल्टी-प्रोग्रामिंग एक्जीक्यूटिव]] में, साझा-लाइब्रेरी कोड में केवल स्टैक-आधारित डेटा (स्थानीय) की अनुमति थी, या साझा-लाइब्रेरी कोड पर अन्य महत्वपूर्ण प्रतिबंध लगाए गए थे।
+कुछ पुराने परिवेशों जैसे कि [[16-बिट विंडोज़]] या [[एचपी 3000]] के लिए [[एचपी मल्टी-प्रोग्रामिंग एक्जीक्यूटिव|एमपीई— मल्टी-प्रोग्रामिंग एक्जीक्यूटिव]] में, साझा-लाइब्रेरी कोड में केवल स्टैक-आधारित डेटा (स्थानीय) की अनुमति थी, या साझा-लाइब्रेरी कोड पर अन्य महत्वपूर्ण प्रतिबंध लगाए गए थे।
 ===स्मृति साझा करना===
-{{main|शारेड मेमोरी}}
+{{main|साझा मेमोरी}}
-लाइब्रेरी कोड को अनेक [[ प्रक्रिया (कंप्यूटिंग) |प्रक्रिया (कंप्यूटिंग)]] द्वारा मेमोरी में और डिस्क पर साझा किया जा सकता है। यदि वर्चुअल मेमोरी का उपयोग किया जाता है, तब प्रक्रियाएं रैम के उसी भौतिक पृष्ठ को निष्पादित करेंगी जिसे प्रक्रियाओं के विभिन्न पता स्थानों में मानचित्र किया जाता है। इसके फायदे हैं. उदाहरण के लिए, [[ओपनस्टेप]] पद्धति पर, एप्लिकेशन अधिकांशतः केवल कुछ सौ किलोबाइट आकार के होते थे और तेज़ी से लोड होते थे; उनका अधिकांश कोड उन पुस्तकालयों में स्थित था जिन्हें ऑपरेटिंग पद्धति द्वारा पहले ही अन्य उद्देश्यों के लिए लोड किया जा चुका था।
+लाइब्रेरी कोड को अनेक [[ प्रक्रिया (कंप्यूटिंग) |प्रक्रियाओं (कंप्यूटिंग)]] द्वारा मेमोरी में और डिस्क पर साझा किया जा सकता है। यदि वर्चुअल मेमोरी का उपयोग किया जाता है, तब प्रक्रियाएं रैम के उसी भौतिक पृष्ठ को निष्पादित करेंगी जिसे प्रक्रियाओं के विभिन्न पता स्थानों में मानचित्र किया जाता है। इसके फायदे हैं. उदाहरण के लिए, [[ओपनस्टेप]] सिस्टम पर, एप्लिकेशन अधिकांशतः केवल कुछ सौ किलोबाइट आकार के होते थे और तेज़ी से लोड होते थे; उनका अधिकांश कोड उन पुस्तकालयों में स्थित था जिन्हें ऑपरेटिंग सिस्टम द्वारा पहले ही अन्य उद्देश्यों के लिए लोड किया जा चुका था।
-प्रोग्राम स्थिति-स्वतंत्र कोड का उपयोग करके रैम साझाकरण को पूरा कर सकते हैं, जैसे कि [[यूनिक्स]] में, जो जटिल किन्तु लचीली वास्तुकला की ओर ले जाता है, या सामान्य आभासी पते का उपयोग करके, जैसा कि विंडोज और ओएस/2 में होता है। यह पद्धति विभिन्न माध्यमों से सुनिश्चित करते हैं, जैसे पता स्थान को पूर्व-मानचित्रिंग करना और प्रत्येक साझा लाइब्रेरी के लिए स्लॉट आरक्षित करना, उस कोड को साझा किए जाने की उच्च संभावना है। तीसरा विकल्प [[ एकल स्तरीय दुकान |एकल स्तरीय दुकान]] है, जैसा कि आईबीएम सिस्टम/38 और उसके उत्तराधिकारियों द्वारा उपयोग किया जाता है। यह स्थिति-निर्भर कोड की अनुमति देता है, किन्तु कोड को कहां रखा जा सकता है या इसे कैसे साझा किया जा सकता है, इस पर कोई महत्वपूर्ण प्रतिबंध नहीं लगाया गया है।
+प्रोग्राम स्थिति-स्वतंत्र कोड का उपयोग करके रैम साझाकरण को पूरा कर सकते हैं, जैसे कि [[यूनिक्स]] में, जो जटिल किन्तु लचीली वास्तुकला की ओर ले जाता है, या सामान्य आभासी पते का उपयोग करके, जैसा कि विंडोज और ओएस/2 में होता है। यह सिस्टम विभिन्न माध्यमों से सुनिश्चित करते हैं, जैसे पता स्थान को पूर्व-मानचित्रिंग करना और प्रत्येक साझा लाइब्रेरी के लिए स्लॉट आरक्षित करना, उस कोड को साझा किए जाने की उच्च संभावना है। तीसरा विकल्प [[ एकल स्तरीय दुकान |एकल स्तरीय दुकान]] है, जैसा कि आईबीएम सिस्टम/38 और उसके उत्तराधिकारियों द्वारा उपयोग किया जाता है। यह स्थिति-निर्भर कोड की अनुमति देता है, किन्तु कोड को कहां रखा जा सकता है या इसे कैसे साझा किया जा सकता है, इस पर कोई महत्वपूर्ण प्रतिबंध नहीं लगाया गया है।
-कुछ स्थितियोंमें, साझा पुस्तकालयों के विभिन्न संस्करण समस्याएँ उत्पन्न कर सकते हैं, खासकर जब विभिन्न संस्करणों के पुस्तकालयों का फ़ाइल नाम समान होता है, और पद्धति पर स्थापित विभिन्न अनुप्रयोगों में से प्रत्येक को विशिष्ट संस्करण की आवश्यकता होती है। ऐसे परिदृश्य को DLL नरक के रूप में जाना जाता है, जिसका नाम Windows और OS/2 DLL फ़ाइल के नाम पर रखा गया है। 2001 के पश्चात् अधिकांश आधुनिक ऑपरेटिंग सिस्टमों में ऐसी स्थितियों को खत्म करने या एप्लिकेशन-विशिष्ट निजी पुस्तकालयों का उपयोग करने के लिए सफाई के तरीके हैं।<ref name="endofdllhell">{{cite web
+कुछ स्थितियों में, साझा पुस्तकालयों के विभिन्न संस्करण समस्याएँ उत्पन्न कर सकते हैं, खासकर जब विभिन्न संस्करणों के पुस्तकालयों का फ़ाइल नाम समान होता है, और सिस्टम पर स्थापित विभिन्न अनुप्रयोगों में से प्रत्येक को विशिष्ट संस्करण की आवश्यकता होती है। ऐसे परिदृश्य को DLL नरक के रूप में जाना जाता है, जिसका नाम Windows और OS/2 DLL फ़ाइल के नाम पर रखा गया है। वर्ष 2001 के पश्चात् अधिकांश आधुनिक ऑपरेटिंग सिस्टमों में ऐसी स्थितियों को खत्म करने या एप्लिकेशन-विशिष्ट '''"निजी"''' पुस्तकालयों का उपयोग करने के लिए क्लीन-अप विधियाँ हैं।<ref name="endofdllhell">{{cite web
 | url=http://msdn.microsoft.com/library/techart/dlldanger1.htm
 | title=The End of DLL Hell
@@ Line 91: / Line 90: @@
 {{main|गतिशील लिंकर}}
-डायनामिक लिंकिंग या [[ देर से बंधन |देर से बंधन]] वह लिंकिंग है जो प्रोग्राम लोड होने (लोड समय) या निष्पादित होने (रनटाइम (प्रोग्राम जीवनचक्र चरण)) के समय की जाती है, न कि तब जब निष्पादन योग्य फ़ाइल बनाई जाती है। गतिशील रूप से लिंक की गई लाइब्रेरी ([[डायनामिक-लिंक लाइब्रेरी]], या डीएलएल, [[Microsoft Windows|माइक्रोसॉफ़्ट विंडोज़]] और OS/2 के अंतर्गत; [[OpenVMS]] के अंतर्गत साझा करने योग्य छवि;<ref>{{cite web|url=https://vmssoftware.com/docs/VSI_Linker_Manual.pdf|title=वीएसआई ओपनवीएमएस लिंकर यूटिलिटी मैनुअल|date=August 2019|access-date=2021-01-31|publisher=VSI}}</ref> डायनेमिक शेयर्ड ऑब्जेक्ट, या डीएसओ, यूनिक्स जैसी प्रणालियों के अनुसार ) डायनेमिक लिंकिंग के लिए बनाई गई लाइब्रेरी है। जब निष्पादन योग्य फ़ाइल बनाई जाती है तब लिंकर (कंप्यूटिंग) द्वारा केवल न्यूनतम मात्रा में काम किया जाता है; यह केवल यह रिकॉर्ड करता है कि प्रोग्राम को किस लाइब्रेरी रूटीन की आवश्यकता है और लाइब्रेरी में रूटीन के सूचकांक नाम या संख्याएँ। लिंकिंग का अधिकांश कार्य एप्लिकेशन लोड होने के समय (लोड समय) या निष्पादन (रनटाइम) के समय किया जाता है। सामान्यतः, आवश्यक लिंकिंग प्रोग्राम, जिसे डायनेमिक लिंकर या लिंकिंग लोडर कहा जाता है, वास्तव में अंतर्निहित ऑपरेटिंग पद्धति का हिस्सा होता है। (यद्यपि, ऐसा प्रोग्राम लिखना संभव है, और अत्यधिक कठिन नहीं है, जो डायनेमिक लिंकिंग का उपयोग करता है और इसमें अपना डायनेमिक लिंकर भी सम्मिलित है, यहां तक कि ऑपरेटिंग पद्धति के लिए भी जो डायनेमिक लिंकिंग के लिए कोई समर्थन प्रदान नहीं करता है।)
+डायनामिक लिंकिंग या [[ देर से बंधन |देर से बंधन]] वह लिंकिंग है जो प्रोग्राम लोड होने (लोड समय) या निष्पादित होने (रनटाइम (प्रोग्राम जीवनचक्र चरण)) के समय की जाती है, न कि तब जब निष्पादन योग्य फ़ाइल बनाई जाती है। गतिशील रूप से लिंक की गई लाइब्रेरी ([[डायनामिक-लिंक लाइब्रेरी]], या डीएलएल, [[Microsoft Windows|माइक्रोसॉफ़्ट विंडोज़]] और OS/2 के अंतर्गत; [[OpenVMS]] के अंतर्गत साझा करने योग्य छवि;<ref>{{cite web|url=https://vmssoftware.com/docs/VSI_Linker_Manual.pdf|title=वीएसआई ओपनवीएमएस लिंकर यूटिलिटी मैनुअल|date=August 2019|access-date=2021-01-31|publisher=VSI}}</ref> डायनेमिक शेयर्ड ऑब्जेक्ट, या डीएसओ, यूनिक्स जैसी प्रणालियों के अनुसार ) डायनेमिक लिंकिंग के लिए बनाई गई लाइब्रेरी है। जब निष्पादन योग्य फ़ाइल बनाई जाती है तब लिंकर (कंप्यूटिंग) द्वारा केवल न्यूनतम मात्रा में काम किया जाता है; यह केवल यह रिकॉर्ड करता है कि प्रोग्राम को किस लाइब्रेरी रूटीन की आवश्यकता है और लाइब्रेरी में रूटीन के सूचकांक नाम या संख्याएँ। लिंकिंग का अधिकांश कार्य एप्लिकेशन लोड होने के समय (लोड समय) या निष्पादन (रनटाइम) के समय किया जाता है। सामान्यतः, आवश्यक लिंकिंग प्रोग्राम, जिसे डायनेमिक लिंकर या लिंकिंग लोडर कहा जाता है, वास्तव में अंतर्निहित ऑपरेटिंग सिस्टम का हिस्सा होता है। (यद्यपि, ऐसा प्रोग्राम लिखना संभव है, और अत्यधिक कठिन नहीं है, जो डायनेमिक लिंकिंग का उपयोग करता है और इसमें अपना डायनेमिक लिंकर भी सम्मिलित है, यहां तक कि ऑपरेटिंग सिस्टम के लिए भी जो डायनेमिक लिंकिंग के लिए कोई समर्थन प्रदान नहीं करता है।)
-प्रोग्रामर्स ने मूल रूप से 1964 में प्रारंभ हुए [[ मॉलटिक्स |मॉलटिक्स]] ऑपरेटिंग पद्धति और 1960 के दशक के अंत में निर्मित एमटीएस ([[मिशिगन टर्मिनल सिस्टम]]) में डायनेमिक लिंकिंग विकसित की।<ref>{{cite journal | title=एमटीएस का इतिहास| journal=Information Technology Digest | volume=5 | issue=5}}</ref>
+प्रोग्रामर्स ने मूल रूप से 1964 में प्रारंभ हुए [[ मॉलटिक्स |मॉलटिक्स]] ऑपरेटिंग सिस्टम और 1960 के दशक के अंत में निर्मित एमटीएस ([[मिशिगन टर्मिनल सिस्टम]]) में डायनेमिक लिंकिंग विकसित की।<ref>{{cite journal | title=एमटीएस का इतिहास| journal=Information Technology Digest | volume=5 | issue=5}}</ref>
 ===अनुकूलन===
-चूंकि अधिकांश पद्धति पर साझा लाइब्रेरी अधिकांशतः नहीं बदलती हैं, पद्धति आवश्यकता पड़ने से पहले पद्धति पर प्रत्येक साझा लाइब्रेरी के लिए संभावित लोड पते की गणना कर सकता है और उस जानकारी को लाइब्रेरी और निष्पादन योग्य में संग्रहीत कर सकता है। यदि लोड की गई प्रत्येक साझा लाइब्रेरी इस प्रक्रिया से गुज़री है, तब प्रत्येक अपने पूर्व निर्धारित पते पर लोड होगी, जो गतिशील लिंकिंग की प्रक्रिया को गति देती है। इस अनुकूलन को क्रमशः macOS और लिनक्स पर [[प्रीबाइंडिंग]] के रूप में जाना जाता है। आईबीएम z/VM समान विधि  का उपयोग करता है, जिसे डिसकंटिन्यूअस सेव्ड सेगमेंट (DCSS) कहा जाता है।<ref>{{cite book |last1=IBM Corporation |title=सहेजे गए खंड योजना और प्रशासन|date=2011 |url=http://publibfp.boulder.ibm.com/epubs/pdf/hcsg4c10.pdf |access-date=Jan 29, 2022}}</ref> इस विधि  के हानि में हर बार साझा लाइब्रेरी बदलने पर इन पतों की पूर्व-गणना करने में लगने वाला समय, एड्रेस स्पेस लेआउट रैंडमाइजेशन का उपयोग करने में असमर्थता और उपयोग के लिए पर्याप्त वर्चुअल एड्रेस स्पेस की आवश्यकता सम्मिलित है (एक समस्या जो 64 को अपनाने से कम हो जाएगी) [[64-बिट]] आर्किटेक्चर, कम से कम कुछ समय के लिए)।
+चूंकि अधिकांश सिस्टम पर साझा लाइब्रेरी अधिकांशतः नहीं बदलती हैं, सिस्टम आवश्यकता पड़ने से पहले सिस्टम पर प्रत्येक साझा लाइब्रेरी के लिए संभावित लोड पते की गणना कर सकता है और उस जानकारी को लाइब्रेरी और निष्पादन योग्य में संग्रहीत कर सकता है। यदि लोड की गई प्रत्येक साझा लाइब्रेरी इस प्रक्रिया से गुज़री है, तब प्रत्येक अपने पूर्व निर्धारित पते पर लोड होगी, जो गतिशील लिंकिंग की प्रक्रिया को गति देती है। इस अनुकूलन को क्रमशः macOS और लिनक्स पर [[प्रीबाइंडिंग]] के रूप में जाना जाता है। आईबीएम z/VM समान विधि  का उपयोग करता है, जिसे डिसकंटिन्यूअस सेव्ड सेगमेंट (DCSS) कहा जाता है।<ref>{{cite book |last1=IBM Corporation |title=सहेजे गए खंड योजना और प्रशासन|date=2011 |url=http://publibfp.boulder.ibm.com/epubs/pdf/hcsg4c10.pdf |access-date=Jan 29, 2022}}</ref> इस विधि  के हानि में हर बार साझा लाइब्रेरी बदलने पर इन पतों की पूर्व-गणना करने में लगने वाला समय, एड्रेस स्पेस लेआउट रैंडमाइजेशन का उपयोग करने में असमर्थता और उपयोग के लिए पर्याप्त वर्चुअल एड्रेस स्पेस की आवश्यकता सम्मिलित है (एक समस्या जो 64 को अपनाने से कम हो जाएगी) [[64-बिट]] आर्किटेक्चर, कम से कम कुछ समय के लिए)।
 === रनटाइम पर पुस्तकालयों का पता लगाना ===
-साझा पुस्तकालयों के लिए लोडर कार्यक्षमता में व्यापक रूप से भिन्न होते हैं। कुछ पुस्तकालयों के लिए स्पष्ट पथों को संग्रहीत करने वाले निष्पादन योग्य पर निर्भर करते हैं। लाइब्रेरी के नामकरण या फ़ाइल पद्धति के लेआउट में कोई भी परिवर्तन इन सिस्टमों को विफल कर देगा। सामान्यतः, केवल लाइब्रेरी का नाम (और पथ नहीं) निष्पादन योग्य में संग्रहीत किया जाता है, ऑपरेटिंग पद्धति कुछ एल्गोरिदम के आधार पर डिस्क पर लाइब्रेरी ढूंढने के लिए विधि प्रदान करता है।
+साझा पुस्तकालयों के लिए लोडर कार्यक्षमता में व्यापक रूप से भिन्न होते हैं। कुछ पुस्तकालयों के लिए स्पष्ट पथों को संग्रहीत करने वाले निष्पादन योग्य पर निर्भर करते हैं। इस प्रकार लाइब्रेरी के नामकरण या फ़ाइल सिस्टम के लेआउट में कोई भी परिवर्तन इन सिस्टमों को विफल कर देगा। सामान्यतः, केवल लाइब्रेरी का नाम (और पथ नहीं) निष्पादन योग्य में संग्रहीत किया जाता है, ऑपरेटिंग सिस्टम कुछ एल्गोरिदम के आधार पर डिस्क पर लाइब्रेरी ढूंढने के लिए विधि प्रदान करता है।
-यदि कोई साझा लाइब्रेरी जिस पर निष्पादन योग्य निर्भर है, हटा दी गई है, स्थानांतरित कर दी गई है, या उसका नाम बदल दिया गया है, या यदि लाइब्रेरी का असंगत संस्करण किसी ऐसे स्थान पर कॉपी किया गया है जो खोज में पहले है, तब निष्पादन योग्य लोड होने में विफल हो जाएगा। इसे [[निर्भरता नरक]] कहा जाता है, जो अनेक प्लेटफार्मों पर उपस्तिथ है। (कुख्यात) विंडोज़ संस्करण को सामान्यतः डीएलएल हेल के रूप में जाना जाता है। यह समस्या तब उत्पन्न नहीं हो सकती यदि प्रत्येक लाइब्रेरी के प्रत्येक संस्करण को विशिष्ट रूप से पहचाना जाता है और प्रत्येक प्रोग्राम लाइब्रेरी को केवल उनके पूर्ण अद्वितीय पहचानकर्ताओं द्वारा संदर्भित करता है। पहले विंडोज़ संस्करणों के साथ डीएलएल समस्याएँ प्रोग्रामों में गतिशील लिंक को हल करने के लिए केवल पुस्तकालयों के नामों का उपयोग करने से उत्पन्न हुईं, जिनके अद्वितीय होने की गारंटी नहीं थी। (डीएलएल नरक से बचने के लिए, विंडोज़ के पश्चात् के संस्करण बड़े पैमाने पर निजी डीएलएल स्थापित करने के लिए प्रोग्राम के विकल्पों पर निर्भर करते हैं - अनिवार्य रूप से साझा पुस्तकालयों के उपयोग से आंशिक वापसी - साथ ही साझा पद्धति डीएलएल को पुराने संस्करणों के साथ बदलने से रोकने के लिए तंत्र पर।)
+यदि कोई साझा लाइब्रेरी जिस पर निष्पादन योग्य निर्भर है, हटा दी गई है, स्थानांतरित कर दी गई है, या उसका नाम बदल दिया गया है, या यदि लाइब्रेरी का असंगत संस्करण किसी ऐसे स्थान पर कॉपी किया गया है जो खोज में पहले है, तब निष्पादन योग्य लोड होने में विफल हो जाएगा। इस प्रकार इसे [[निर्भरता नरक]] कहा जाता है, जो अनेक प्लेटफार्मों पर उपस्तिथ है। (कुख्यात) विंडोज़ संस्करण को सामान्यतः डीएलएल हेल के रूप में जाना जाता है। इस प्रकार यह समस्या तब उत्पन्न नहीं हो सकती यदि प्रत्येक लाइब्रेरी के प्रत्येक संस्करण को विशिष्ट रूप से पहचाना जाता है और प्रत्येक प्रोग्राम लाइब्रेरी को केवल उनके पूर्ण अद्वितीय पहचानकर्ताओं द्वारा संदर्भित करता है। इस प्रकार पहले विंडोज़ संस्करणों के साथ डीएलएल समस्याएँ प्रोग्रामों में गतिशील लिंक को हल करने के लिए केवल पुस्तकालयों के नामों का उपयोग करने से उत्पन्न हुईं, जिनके अद्वितीय होने की गारंटी नहीं थी। ('''"डीएलएल नरक"''' से बचने के लिए, विंडोज़ के पश्चात् के संस्करण बड़े पैमाने पर निजी डीएलएल स्थापित करने के लिए प्रोग्राम के विकल्पों पर निर्भर करते हैं - अनिवार्य रूप से साझा पुस्तकालयों के उपयोग से आंशिक वापसी - साथ ही साझा सिस्टम डीएलएल को पुराने संस्करणों के साथ बदलने से रोकने के लिए तंत्र पर।) निर्भर हैं।
 ====माइक्रोसॉफ्ट विंडोज़====
-माइक्रोसॉफ्ट विंडोज [[ घटक वस्तु मॉडल |घटक वस्तु मॉडल]] को क्रियान्वित करने वाले डीएलएल को लोड करने के लिए उचित स्थान निर्धारित करने के लिए [[ विंडोज़ रजिस्ट्री |विंडोज़ रजिस्ट्री]] की जांच करता है, किन्तु अन्य डीएलएल के लिए यह निर्धारित क्रम में निर्देशिकाओं की जांच करेगा। सबसे पहले, विंडोज़ उस निर्देशिका की जाँच करता है जहाँ उसने प्रोग्राम लोड किया है (निजी डीएलएल)।<ref name="endofdllhell"/>); किसी भी निर्देशिका को कॉल करके समूह करें <code>SetDllDirectory()</code> फंक्शन; System32, पद्धति और विंडोज़ निर्देशिकाएँ; फिर वर्तमान कार्यशील निर्देशिका; और अंत में PATH पर्यावरण चर द्वारा निर्दिष्ट निर्देशिकाएँ।<ref>{{cite web
+माइक्रोसॉफ्ट विंडोज [[ घटक वस्तु मॉडल |घटक वस्तु मॉडल]] को क्रियान्वित करने वाले डीएलएल को लोड करने के लिए उचित स्थान निर्धारित करने के लिए [[ विंडोज़ रजिस्ट्री |विंडोज़ रजिस्ट्री]] की जांच करता है, किन्तु अन्य डीएलएल के लिए यह निर्धारित क्रम में निर्देशिकाओं की जांच करेगा। इस प्रकार सबसे पहले, विंडोज़ उस निर्देशिका की जाँच करता है जहाँ उसने प्रोग्राम (निजी डीएलएल)।<ref name="endofdllhell"/>); <code>SetDllDirectory()</code>फंक्शन को कॉल करके समूह की गई कोई भी निर्देशिका; System32, सिस्टम और विंडोज़ निर्देशिकाएँ; फिर वर्तमान कार्यशील निर्देशिका; और अंत में PATH पर्यावरण चर द्वारा निर्दिष्ट निर्देशिकाएँ।<ref>{{cite web
   |url         = http://msdn.microsoft.com/en-us/library/ms682586.aspx
   |title       = Dynamic-Link Library Search Order
@@ Line 116: / Line 115: @@
 ====ओपनस्टेप====
-ओपनस्टेप ने अधिक लचीली प्रणाली का उपयोग किया, जब पद्धति पहली बार प्रारंभ होता है तब अनेक ज्ञात स्थानों (पीएटीएच अवधारणा के समान) से पुस्तकालयों की सूची एकत्र की जाती है। पुस्तकालयों को इधर-उधर ले जाने से कोई समस्या नहीं होती है, यद्यपि उपयोगकर्ताओं को पहली बार पद्धति प्रारंभ करने में समय लगता है।
+ओपनस्टेप ने अधिक लचीली प्रणाली का उपयोग किया, जब सिस्टम पहली बार प्रारंभ होता है तब अनेक ज्ञात स्थानों (पीएटीएच अवधारणा के समान) से पुस्तकालयों की सूची एकत्र की जाती है। इस प्रकार पुस्तकालयों को इधर-उधर ले जाने से कोई समस्या नहीं होती है, यद्यपि उपयोगकर्ताओं को पहली बार सिस्टम प्रारंभ करने में समय लगता है।
 ====यूनिक्स जैसी प्रणालियाँ====
-अधिकांश यूनिक्स-जैसी प्रणालियों में फ़ाइल-पद्धति [[निर्देशिका (कंप्यूटिंग)]] को निर्दिष्ट करने वाला खोज पथ होता है जिसमें गतिशील पुस्तकालयों को देखना होता है। कुछ पद्धति [[विन्यास फाइल]] में डिफ़ॉल्ट पथ निर्दिष्ट करते हैं, अन्य इसे डायनेमिक लोडर में हार्ड-कोड करते हैं। कुछ [[निष्पादन]] योग्य प्रारूप अतिरिक्त निर्देशिकाएँ निर्दिष्ट कर सकते हैं जिनमें किसी विशेष कार्यक्रम के लिए पुस्तकालयों की खोज की जा सकती है। इसे सामान्यतः पर्यावरण चर के साथ ओवरराइड किया जा सकता है, चूंकि यह [[निर्धारित समय]] और समूहगिड प्रोग्राम के लिए अक्षम है, जिससे कि कोई उपयोगकर्ता ऐसे प्रोग्राम को रूट अनुमतियों के साथ इच्छानुसार कोड चलाने के लिए मजबूर न कर सके। पुस्तकालयों के डेवलपर्स को अपने गतिशील पुस्तकालयों को डिफ़ॉल्ट खोज पथ में स्थानों पर रखने के लिए प्रोत्साहित किया जाता है। ऋणात्मक पक्ष यह है कि इससे नए पुस्तकालयों की स्थापना समस्याग्रस्त हो सकती है, और यह ज्ञात स्थान तेजी से बढ़ती संख्या में पुस्तकालय फ़ाइलों का घर बन जाते हैं, जिससे प्रबंधन अधिक जटिल हो जाता है।
+अधिकांश यूनिक्स-जैसी प्रणालियों में फ़ाइल-सिस्टम [[निर्देशिका (कंप्यूटिंग)]] को निर्दिष्ट करने वाला खोज पथ होता है जिसमें गतिशील पुस्तकालयों को देखना होता है। कुछ सिस्टम [[विन्यास फाइल]] में डिफ़ॉल्ट पथ निर्दिष्ट करते हैं, अन्य इसे डायनेमिक लोडर में हार्ड-कोड करते हैं। इस प्रकार कुछ [[निष्पादन]] योग्य प्रारूप अतिरिक्त निर्देशिकाएँ निर्दिष्ट कर सकते हैं जिनमें किसी विशेष कार्यक्रम के लिए पुस्तकालयों की खोज की जा सकती है। इसे सामान्यतः पर्यावरण चर के साथ ओवरराइड किया जा सकता है, चूंकि यह [[निर्धारित समय]] और समूहगिड प्रोग्राम के लिए अक्षम है, जिससे कि कोई उपयोगकर्ता ऐसे प्रोग्राम को रूट अनुमतियों के साथ इच्छानुसार कोड चलाने के लिए मजबूर न कर सके। पुस्तकालयों के डेवलपर्स को अपने गतिशील पुस्तकालयों को डिफ़ॉल्ट खोज पथ में स्थानों पर रखने के लिए प्रोत्साहित किया जाता है। ऋणात्मक पक्ष यह है कि इससे नए पुस्तकालयों की स्थापना समस्याग्रस्त हो सकती है, और यह ज्ञात स्थान तेजी से बढ़ती संख्या में पुस्तकालय फ़ाइलों का घर बन जाते हैं, जिससे प्रबंधन अधिक जटिल हो जाता है।
 ===गतिशील लोडिंग===
 {{Main|गतिशील लोडिंग}}
-डायनेमिक लोडिंग, डायनेमिक लिंकिंग का सबसमूह, अनुरोध पर रनटाइम (प्रोग्राम जीवनचक्र चरण) पर डायनेमिक रूप से लिंक की गई लाइब्रेरी लोडिंग और अनलोडिंग सम्मिलित है। ऐसा अनुरोध परोक्ष या स्पष्ट रूप से किया जा सकता है। अंतर्निहित अनुरोध तब किए जाते हैं जब कंपाइलर या स्टेटिक लिंकर लाइब्रेरी संदर्भ जोड़ता है जिसमें फ़ाइल पथ या बस फ़ाइल नाम सम्मिलित होते हैं। स्पष्ट अनुरोध तब किए जाते हैं जब एप्लिकेशन किसी ऑपरेटिंग पद्धति के एपीआई पर सीधे कॉल करते हैं।
+डायनेमिक लोडिंग, डायनेमिक लिंकिंग का सबसमूह, अनुरोध पर रनटाइम (प्रोग्राम जीवनचक्र चरण) पर डायनेमिक रूप से लिंक की गई लाइब्रेरी लोडिंग और अनलोडिंग सम्मिलित है। इस प्रकार ऐसा अनुरोध परोक्ष या स्पष्ट रूप से किया जा सकता है। अंतर्निहित अनुरोध तब किए जाते हैं जब कंपाइलर या स्टेटिक लिंकर लाइब्रेरी संदर्भ जोड़ता है जिसमें फ़ाइल पथ या बस फ़ाइल नाम सम्मिलित होते हैं। स्पष्ट अनुरोध तब किए जाते हैं जब एप्लिकेशन किसी ऑपरेटिंग सिस्टम के एपीआई पर सीधे कॉल करते हैं।
-अधिकांश ऑपरेटिंग पद्धति जो गतिशील रूप से जुड़े पुस्तकालयों का समर्थन करते हैं, रनटाइम (प्रोग्राम जीवनचक्र चरण) | रन-टाइम लिंकर [[अप्लिकेशन प्रोग्रामिंग अंतरफलक]] के माध्यम से ऐसे पुस्तकालयों को गतिशील रूप से लोड करने का भी समर्थन करते हैं। उदाहरण के लिए, माइक्रोसॉफ्ट विंडोज़ एपीआई फ़ंक्शंस का उपयोग करता है <code>LoadLibrary</code>, <code>LoadLibraryEx</code>, <code>FreeLibrary</code> और <code>GetProcAddress</code> [[माइक्रोसॉफ्ट डायनामिक लिंक लाइब्रेरी]] के साथ; [[POSIX]]-आधारित प्रणालियाँ, जिनमें अधिकांश UNIX और UNIX-जैसी प्रणालियाँ सम्मिलित हैं, उपयोग करती हैं <code>dlopen</code>, <code>dlclose</code> और <code>dlsym</code>. कुछ विकास प्रणालियाँ इस प्रक्रिया को स्वचालित करती हैं।
+अधिकांश ऑपरेटिंग सिस्टम जो गतिशील रूप से जुड़े पुस्तकालयों का समर्थन करते हैं, रन-टाइम लिंकर एपीआई—[[अप्लिकेशन प्रोग्रामिंग अंतरफलक]] के माध्यम से ऐसे पुस्तकालयों को गतिशील रूप से लोड करने का भी समर्थन करते हैं। उदाहरण के लिए, माइक्रोसॉफ्ट विंडोज़ एपीआई फ़ंक्शंस <code>LoadLibrary</code>, <code>LoadLibraryEx</code>, <code>FreeLibrary</code> और <code>GetProcAddress</code> का उपयोग करता है; [[माइक्रोसॉफ्ट डायनामिक लिंक लाइब्रेरी]] के साथ; [[POSIX]]-आधारित प्रणालियाँ, जिनमें अधिकांश UNIX और UNIX-जैसी प्रणालियाँ सम्मिलित हैं,  <code>dlopen</code>, <code>dlclose</code> और <code>dlsym</code>. का उपयोग करती हैं। कुछ विकास प्रणालियाँ इस प्रक्रिया को स्वचालित करती हैं।
 ==ऑब्जेक्ट लाइब्रेरी==
-यद्यपि मूल रूप से इसकी शुरुआत 1960 के दशक में हुई थी, किन्तु डायनेमिक लिंकिंग 1980 के दशक के अंत तक उपभोक्ताओं द्वारा उपयोग किए जाने वाले ऑपरेटिंग पद्धति तक नहीं पहुँच पाई थी। यह सामान्यतः 1990 के दशक की शुरुआत तक अधिकांश ऑपरेटिंग पद्धति में किसी न किसी रूप में उपलब्ध था। इसी अवधि के समय, ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग (ओओपी) प्रोग्रामिंग परिदृश्य का महत्वपूर्ण हिस्सा बन रहा था। रनटाइम बाइंडिंग के साथ OOP को अतिरिक्त जानकारी की आवश्यकता होती है जो पारंपरिक लाइब्रेरी प्रदान नहीं करती है। अंदर स्थित कोड के नाम और प्रवेश बिंदुओं के अतिरिक्त, उन्हें उन वस्तुओं की सूची की भी आवश्यकता होती है जिन पर वह निर्भर हैं। यह OOP की मूल अवधारणाओं में से एक, वंशानुक्रम का दुष्प्रभाव है, जिसका अर्थ है कि किसी भी विधि की पूरी परिभाषा के हिस्से भिन्न- भिन्न स्थानों पर हो सकते हैं। यह केवल यह सूचीबद्ध करने से कहीं अधिक है कि पुस्तकालय को दूसरे की सेवाओं की आवश्यकता होती है: सच्चे ओओपी पद्धति में, पुस्तकालय स्वयं [[संकलन समय]] पर ज्ञात नहीं हो सकते हैं, और पद्धति से पद्धति में भिन्न होते हैं।
+यद्यपि मूल रूप से इसकी प्रारम्भ सत्र1960 के दशक में हुई थी, किन्तु डायनेमिक लिंकिंग सत्र 1980 के दशक के अंत तक उपभोक्ताओं द्वारा उपयोग किए जाने वाले ऑपरेटिंग सिस्टम तक नहीं पहुँच पाई थी। यह सामान्यतः 1990 के दशक की प्रारम्भ तक अधिकांश ऑपरेटिंग सिस्टम में किसी न किसी रूप में उपलब्ध था। इसी अवधि के समय, ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग (ओओपी) प्रोग्रामिंग परिदृश्य का महत्वपूर्ण भाग रहा था। रनटाइम बाइंडिंग के साथ OOP को अतिरिक्त जानकारी की आवश्यकता होती है जो पारंपरिक लाइब्रेरी प्रदान नहीं करती है। इस प्रकार अंदर स्थित कोड के नाम और प्रवेश बिंदुओं के अतिरिक्त, उन्हें उन वस्तुओं की सूची की भी आवश्यकता होती है जिन पर वह निर्भर हैं। यह OOP की मूल अवधारणाओं में से एक, वंशानुक्रम का दुष्प्रभाव है, जिसका अर्थ है कि किसी भी विधि की पूरी परिभाषा के हिस्से भिन्न- भिन्न स्थानों पर हो सकते हैं। यह केवल यह सूचीबद्ध करने से कहीं अधिक है कि पुस्तकालय को दूसरे की सेवाओं की आवश्यकता होती है: सच्चे ओओपी सिस्टम में, पुस्तकालय स्वयं [[संकलन समय]] पर ज्ञात नहीं हो सकते हैं, और सिस्टम से सिस्टम में भिन्न होते हैं।
-उसी समय अनेक डेवलपर्स ने मल्टी-टियर प्रोग्राम के विचार पर काम किया, जिसमें डेस्कटॉप कंप्यूटर पर चलने वाला डिस्प्ले डेटा स्टोरेज या प्रोसेसिंग के लिए [[ मेनफ़्रेम कंप्यूटर |मेनफ़्रेम कंप्यूटर]] या [[मिनी कंप्यूटर]] की सेवाओं का उपयोग करेगा। उदाहरण के लिए, जीयूआई-आधारित कंप्यूटर पर प्रोग्राम विशाल डेटासमूह के छोटे नमूने प्रदर्शित करने के लिए मिनीकंप्यूटर को संदेश भेजेगा। दूरस्थ प्रक्रिया कॉल (आरपीसी) पहले से ही इन कार्यों को संभालती थी, किन्तु कोई मानक आरपीसी प्रणाली नहीं थी।
+उसी समय अनेक डेवलपर्स ने मल्टी-टियर प्रोग्राम के विचार पर काम किया, जिसमें डेस्कटॉप कंप्यूटर पर चलने वाला '''"डिस्प्ले"''' डेटा स्टोरेज या प्रोसेसिंग के लिए [[ मेनफ़्रेम कंप्यूटर |मेनफ़्रेम कंप्यूटर]] या [[मिनी कंप्यूटर]] की सेवाओं का उपयोग करेगा। इस प्रकार उदाहरण के लिए, जीयूआई-आधारित कंप्यूटर पर प्रोग्राम विशाल डेटासमूह के छोटे नमूने प्रदर्शित करने के लिए मिनीकंप्यूटर को संदेश भेजेगा। दूरस्थ प्रक्रिया कॉल (आरपीसी) पहले से ही इन कार्यों को संभालती थी, किन्तु कोई मानक आरपीसी प्रणाली नहीं थी।
-जल्द ही अधिकांश मिनीकंप्यूटर और मेनफ्रेम विक्रेताओं ने दोनों को संयोजित करने के लिए परियोजनाएं प्रारंभ कीं, जिससे ओओपी लाइब्रेरी प्रारूप तैयार हुआ जिसे कहीं भी उपयोग किया जा सकता था। ऐसी प्रणालियों को ऑब्जेक्ट लाइब्रेरी या वितरित ऑब्जेक्ट के रूप में जाना जाता था, यदि वह रिमोट एक्सेस का समर्थन करते थे (सभी ने नहीं किया)। माइक्रोसॉफ्ट का COM स्थानीय उपयोग के लिए ऐसी प्रणाली का उदाहरण है। DCOM, COM का संशोधित संस्करण, रिमोट एक्सेस का समर्थन करता है।
+जल्द ही अधिकांश मिनीकंप्यूटर और मेनफ्रेम विक्रेताओं ने दोनों को संयोजित करने के लिए परियोजनाएं प्रारंभ कीं, जिससे ओओपी लाइब्रेरी प्रारूप तैयार हुआ जिसे कहीं भी उपयोग किया जा सकता था। ऐसी प्रणालियों को '''ऑब्जेक्ट लाइब्रेरी''' या '''वितरित ऑब्जेक्ट''' के रूप में जाना जाता था, यदि वह रिमोट एक्सेस का समर्थन करते थे (सभी ने नहीं किया)। माइक्रोसॉफ्ट का COM स्थानीय उपयोग के लिए ऐसी प्रणाली का उदाहरण है। DCOM, COM का संशोधित संस्करण, रिमोट एक्सेस का समर्थन करता है।
-कुछ समय तक ऑब्जेक्ट लाइब्रेरियों को प्रोग्रामिंग जगत में अगली बड़ी चीज़ का अंकिता प्राप्त रहा। ऐसे पद्धति बनाने के लिए अनेक प्रयास किए गए जो सभी प्लेटफार्मों पर चलेंगे, और कंपनियों ने डेवलपर्स को अपने पद्धति में लॉक करने की कोशिश करने के लिए प्रतिस्पर्धा की। उदाहरणों में [[IBM|आईबीएम]] का [[सिस्टम ऑब्जेक्ट मॉडल|पद्धति ऑब्जेक्ट मॉडल]] (SOM/DSOM), [[सन माइक्रोसिस्टम्स]] का [[सर्वत्र वस्तुएँ वितरित कीं]] (DOE), [[NeXT]] का [[पोर्टेबल वितरित वस्तुएँ]] (PDO), [[ डिजिटल उपकरण निगम |डिजिटल उपकरण निगम]] का [[ ऑब्जेक्ट ब्रोकर |ऑब्जेक्ट ब्रोकर]] , माइक्रोसॉफ्ट का [[ घटक वस्तु मॉडल |घटक वस्तु मॉडल]] (COM/DCOM), और कोई भी [[CORBA]] सम्मिलित हैं। -आधारित सिस्टम।
+कुछ समय तक ऑब्जेक्ट लाइब्रेरियों को प्रोग्रामिंग जगत में '''"अगली बड़ी रचना"''' की श्रेणी प्राप्त की। ऐसे सिस्टम बनाने के लिए अनेक प्रयास किए गए जो सभी प्लेटफार्मों पर चलेंगे, और कंपनियों ने डेवलपर्स को अपने सिस्टम में लॉक करने की कोशिश करने के लिए प्रतिस्पर्धा की। उदाहरणों में [[IBM|आईबीएम]] का [[सिस्टम ऑब्जेक्ट मॉडल]] (SOM/DSOM), [[सन माइक्रोसिस्टम्स]] का [[सर्वत्र वस्तुएँ वितरित कीं]] (DOE), [[NeXT]] का [[पोर्टेबल वितरित वस्तुएँ]] (PDO), [[ डिजिटल उपकरण निगम |डिजिटल उपकरण निगम]] का [[ ऑब्जेक्ट ब्रोकर |ऑब्जेक्ट ब्रोकर]] , माइक्रोसॉफ्ट का [[ घटक वस्तु मॉडल |घटक वस्तु मॉडल]] (COM/DCOM), और कोई भी [[CORBA]] सम्मिलित हैं। -आधारित सिस्टम।
 ==कक्षा पुस्तकालय==
-क्लास लाइब्रेरीज़ पुराने प्रकार के कोड लाइब्रेरीज़ के समतुल्य OOP हैं। उनमें क्लास (कंप्यूटर विज्ञान) सम्मिलित है, जो विशेषताओं का वर्णन करता है और क्रियाओं ([[विधि (कंप्यूटर विज्ञान)]]) को परिभाषित करता है जिसमें वस्तुएं सम्मिलित होती हैं। क्लास लाइब्रेरीज़ का उपयोग इंस्टेंस (कंप्यूटर विज्ञान), या विशिष्ट मानों पर समूह की गई विशेषताओं वाली ऑब्जेक्ट बनाने के लिए किया जाता है। जावा (प्रोग्रामिंग भाषा) जैसी कुछ ओओपी भाषाओं में, अंतर स्पष्ट है, कक्षाएं अधिकांशतः लाइब्रेरी फ़ाइलों (जैसे जावा के जार (फ़ाइल प्रारूप)) में निहित होती हैं और तत्काल ऑब्जेक्ट केवल मेमोरी में रहते हैं (चूंकि संभावित रूप से दृढ़ता बनाए जाने में सक्षम होते हैं) (कंप्यूटर विज्ञान) भिन्न फाइलों में)। दूसरों में, स्मॉलटॉक की तरह, क्लास लाइब्रेरीज़ [[ सिस्टम छवि |पद्धति छवि]] के लिए प्रारंभिक बिंदु मात्र हैं जिसमें पर्यावरण की संपूर्ण स्थिति, कक्षाएं और सभी तात्कालिक ऑब्जेक्ट सम्मिलित होते हैं।
+क्लास लाइब्रेरीज़ पुराने प्रकार के कोड लाइब्रेरीज़ के समतुल्य OOP हैं। उनमें क्लास सम्मिलित है, जो विशेषताओं का वर्णन करता है और क्रियाओं ([[विधि (कंप्यूटर विज्ञान)|विधियों (कंप्यूटर विज्ञान)]]) को परिभाषित करता है जिसमें वस्तुएं सम्मिलित होती हैं। क्लास लाइब्रेरीज़ का उपयोग इंस्टेंस (कंप्यूटर विज्ञान), या विशिष्ट मानों पर समूह की गई विशेषताओं वाली ऑब्जेक्ट बनाने के लिए किया जाता है। जावा (प्रोग्रामिंग भाषा) जैसी कुछ ओओपी भाषाओं में, अंतर स्पष्ट है, कक्षाएं अधिकांशतः लाइब्रेरी फ़ाइलों (जैसे जावा के जार (फ़ाइल प्रारूप)) में निहित होती हैं और तत्काल ऑब्जेक्ट केवल मेमोरी में रहते हैं (चूंकि संभावित रूप से दृढ़ता बनाए जाने में सक्षम होते हैं) (कंप्यूटर विज्ञान) भिन्न फाइलों में)। दूसरों में, स्मॉलटॉक की तरह, क्लास लाइब्रेरीज़ [[ सिस्टम छवि |सिस्टम छवि]] के लिए प्रारंभिक बिंदु मात्र हैं जिसमें पर्यावरण की संपूर्ण स्थिति, कक्षाएं और सभी तात्कालिक ऑब्जेक्ट सम्मिलित होते हैं।
-आज अधिकांश क्लास लाइब्रेरीज़ को [[ पैकेज भंडार |पैकेज भंडार]] (जैसे जावा के लिए मेवेन सेंट्रल) में संग्रहीत किया जाता है। क्लाइंट कोड स्पष्ट रूप से [[सॉफ्टवेयर निर्माण]] कॉन्फ़िगरेशन फ़ाइलों (जैसे जावा में मावेन पोम) में बाहरी पुस्तकालयों पर निर्भरता की घोषणा करता है।
+आज अधिकांश क्लास लाइब्रेरीज़ को [[ पैकेज भंडार |पैकेज भंडार]] (जैसे जावा के लिए मेवेन सेंट्रल) में संग्रहीत किया जाता है। इस प्रकार क्लाइंट कोड स्पष्ट रूप से [[सॉफ्टवेयर निर्माण]] कॉन्फ़िगरेशन फ़ाइलों (जैसे जावा में मावेन पोम) में बाहरी पुस्तकालयों पर निर्भरता की घोषणा करता है।
 ==दूरस्थ पुस्तकालय==
-एक अन्य लाइब्रेरी विधि  पूरी तरह से भिन्न निष्पादनयोग्य (अधिकांशतः कुछ हल्के रूप में) का उपयोग करती है और उन्हें नेटवर्क पर दूसरे कंप्यूटर पर रिमोट प्रक्रिया कॉल (आरपीसी) का उपयोग करके कॉल करती है। यह ऑपरेटिंग पद्धति के पुन: उपयोग को अधिकतम करता है: लाइब्रेरी का समर्थन करने के लिए आवश्यक कोड वही कोड है जिसका उपयोग हर दूसरे प्रोग्राम के लिए एप्लिकेशन समर्थन और सुरक्षा प्रदान करने के लिए किया जा रहा है। इसके अतिरिक्त, ऐसी प्रणालियों के लिए लाइब्रेरी को उसी मशीन पर उपस्तिथ होने की आवश्यकता नहीं होती है, किन्तु वह नेटवर्क पर अनुरोधों को अग्रेषित कर सकते हैं।
+एक अन्य लाइब्रेरी विधि पूरी तरह से भिन्न निष्पादनयोग्य (अधिकांशतः कुछ हल्के रूप में) का उपयोग करती है और उन्हें नेटवर्क पर दूसरे कंप्यूटर पर रिमोट प्रक्रिया कॉल (आरपीसी) का उपयोग करके कॉल करती है। यह ऑपरेटिंग सिस्टम के पुन: उपयोग को अधिकतम करता है: लाइब्रेरी का समर्थन करने के लिए आवश्यक कोड वही कोड है जिसका उपयोग हर दूसरे प्रोग्राम के लिए एप्लिकेशन समर्थन और सुरक्षा प्रदान करने के लिए किया जा रहा है। इस प्रकार इसके अतिरिक्त, ऐसी प्रणालियों के लिए लाइब्रेरी को उसी मशीन पर उपस्तिथ होने की आवश्यकता नहीं होती है, किन्तु वह नेटवर्क पर अनुरोधों को अग्रेषित कर सकते हैं।
-यद्यपि, इस तरह के दृष्टिकोण का कारणहै कि प्रत्येक लाइब्रेरी कॉल के लिए अधिक  मात्रा में ओवरहेड की आवश्यकता होती है। आरपीसी कॉल किसी साझा लाइब्रेरी को कॉल करने की तुलना में बहुत अधिक महंगी हैं जो पहले से ही उसी मशीन पर लोड की जा चुकी है। इस दृष्टिकोण का उपयोग सामान्यतः वितरित कंप्यूटिंग में किया जाता है जो ऐसे दूरस्थ कॉल, विशेष रूप से क्लाइंट-सर्वर पद्धति और [[एंटरप्राइज़ जावा]]बीन्स जैसे [[अनुप्रयोग सर्वर]] का भारी उपयोग करता है।
+यद्यपि, इस तरह के दृष्टिकोण का कारण है कि प्रत्येक लाइब्रेरी कॉल के लिए अधिक  मात्रा में ओवरहेड की आवश्यकता होती है। इस प्रकार आरपीसी कॉल किसी साझा लाइब्रेरी को कॉल करने की तुलना में बहुत अधिक महंगी हैं जो पहले से ही उसी मशीन पर लोड की जा चुकी है। इस दृष्टिकोण का उपयोग सामान्यतः वितरित कंप्यूटिंग में किया जाता है जो ऐसे दूरस्थ कॉल, विशेष रूप से क्लाइंट-सर्वर सिस्टम और [[एंटरप्राइज़ जावा]]बीन्स जैसे [[अनुप्रयोग सर्वर]] का भारी उपयोग करता है।
 ==कोड जनरेशन लाइब्रेरी==
-कोड जनरेशन लाइब्रेरी उच्च-स्तरीय [[अप्लिकेशन प्रोग्रामिंग अंतरफलक]] हैं जो जावा (प्रोग्रामिंग भाषा) के लिए [[बाइट कोड]] उत्पन्न या परिवर्तित कर सकते हैं। इनका उपयोग पहलू-उन्मुख प्रोग्रामिंग, कुछ डेटा एक्सेस फ्रेमवर्क और गतिशील प्रॉक्सी ऑब्जेक्ट उत्पन्न करने के परीक्षण के लिए किया जाता है। इनका उपयोग फ़ील्ड पहुंच को रोकने के लिए भी किया जाता है।<ref>{{cite web
+कोड जनरेशन लाइब्रेरी उच्च-स्तरीय एपीआई [[अप्लिकेशन प्रोग्रामिंग अंतरफलक]] हैं जो जावा (प्रोग्रामिंग भाषा) के लिए [[बाइट कोड]] उत्पन्न या परिवर्तित कर सकते हैं। इनका उपयोग पहलू-उन्मुख प्रोग्रामिंग, कुछ डेटा एक्सेस फ्रेमवर्क और गतिशील प्रॉक्सी ऑब्जेक्ट उत्पन्न करने के परीक्षण के लिए किया जाता है। इस प्रकार इनका उपयोग फ़ील्ड पहुंच को रोकने के लिए भी किया जाता है।<ref>{{cite web
   |access-date  = 2010-03-03
   |publisher   = [[Source Forge]]
@@ Line 159: / Line 158: @@
 }}</ref>
-फ़ाइल नामकरण
+== फ़ाइल नामकरण ==
 ===अधिकांश आधुनिक यूनिक्स जैसी प्रणालियाँ===
 {{See also|UNIX- जैसे}}
-पद्धति स्टोर करता है <code>libfoo.a</code> और <code>libfoo.so</code> निर्देशिकाओं में फ़ाइलें जैसे <code>/lib</code>, <code>/usr/lib</code> या <code>/usr/local/lib</code>. फ़ाइल नाम सदैव से प्रारंभ होते हैं <code>lib</code>, और के प्रत्यय के साथ समाप्त होता है <code>.a</code> (Ar (फ़ाइल स्वरूप), स्थैतिक पुस्तकालय) या का <code>.so</code> (साझा वस्तु, गतिशील रूप से जुड़ी हुई लाइब्रेरी)। कुछ प्रणालियों में गतिशील रूप से जुड़ी लाइब्रेरी के लिए अनेक नाम हो सकते हैं। यह नाम सामान्यतः ही उपसर्ग साझा करते हैं और संस्करण संख्या को इंगित करने वाले भिन्न- भिन्न प्रत्यय होते हैं। अधिकांश नाम नवीनतम संस्करण के [[प्रतीकात्मक लिंक]] के नाम हैं। उदाहरण के लिए, कुछ प्रणालियों पर <code>libfoo.so.2</code> गतिशील रूप से लिंक की गई लाइब्रेरी के दूसरे प्रमुख इंटरफ़ेस संशोधन के लिए फ़ाइल नाम होगा <code>libfoo</code>. <code>.la</code> ई> कभी-कभी लाइब्रेरी निर्देशिकाओं में पाई जाने वाली फ़ाइलें [[ libtool |libtool]] अभिलेखागार होती हैं, जो पद्धति द्वारा उपयोग करने योग्य नहीं होती हैं।
+सिस्टम <code>libfoo.a</code> और <code>libfoo.so</code> फ़ाइलों को <code>/lib</code>, <code>/usr/lib</code> या <code>/usr/local/lib</code>जैसी निर्देशिकाओं में संग्रहीत करता है। इस प्रकार फ़ाइल नाम सदैव<code>lib</code>, से प्रारम्भ होते हैं, और .a (संग्रह, स्थिर लाइब्रेरी) या .so (साझा ऑब्जेक्ट, गतिशील रूप से लिंक की गई लाइब्रेरी) के प्रत्यय के साथ समाप्त होते हैं। कुछ प्रणालियों में गतिशील रूप से जुड़ी लाइब्रेरी के लिए कई नाम हो सकते हैं। इस प्रकार यह नाम सामान्यतः ही उपसर्ग साझा करते हैं और संस्करण संख्या को इंगित करने वाले भिन्न- भिन्न प्रत्यय होते हैं। अधिकांश नाम नवीनतम संस्करण के [[प्रतीकात्मक लिंक]] के नाम हैं। उदाहरण के लिए, कुछ प्रणालियों पर <code>libfoo.so.2</code> गतिशील रूप से लिंक की गई लाइब्रेरी <code>libfoo</code>के दूसरे प्रमुख इंटरफ़ेस संशोधन के लिए फ़ाइल नाम होगा। इस प्रकार कभी-कभी लाइब्रेरी निर्देशिकाओं में पाई जाने वाली .la फ़ाइलें [[ libtool |libtool]] संग्रह होती हैं, जो सिस्टम द्वारा उपयोग करने योग्य नहीं होती हैं।
 ===मैकओएस===
 {{See also|मैक ओएस}}
-पद्धति को [[बीएसडी]] से स्थैतिक लाइब्रेरी कन्वेंशन विरासत में मिली है, जिसमें लाइब्रेरी संग्रहीत है <code>.a</code> फ़ाइल, और उपयोग कर सकते हैं <code>.so</code>-स्टाइल गतिशील रूप से जुड़े पुस्तकालय (के साथ <code>.dylib</code> इसके अतिरिक्त प्रत्यय)। यद्यपि, macOS में अधिकांश लाइब्रेरीज़ में फ्रेमवर्क सम्मिलित होते हैं, जिन्हें बंडल (macOS) नामक विशेष निर्देशिकाओं के अंदर रखा जाता है, जो लाइब्रेरी की आवश्यक फ़ाइलों और मेटाडेटा को लपेटते हैं। उदाहरण के लिए, रूपरेखा कहा जाता है <code>MyFramework</code> नामक बंडल में क्रियान्वित किया जाएगा <code>MyFramework.framework</code>, साथ <code>MyFramework.framework/MyFramework</code> या तब गतिशील रूप से लिंक की गई लाइब्रेरी फ़ाइल होना या गतिशील रूप से लिंक की गई लाइब्रेरी फ़ाइल का सिम्लिंक होना <code>MyFramework.framework/Versions/Current/MyFramework</code>.
+सिस्टम को [[बीएसडी]] से स्थैतिक लाइब्रेरी कन्वेंशन विरासत में मिलती है, लाइब्रेरी एक .a फ़ाइल में संग्रहीत होती है, और .so-शैली गतिशील रूप से लिंक की गई लाइब्रेरी (इसके अतिरिक्त .dylib प्रत्यय के साथ) का उपयोग कर सकती है। इस प्रकार यद्यपि, macOS में अधिकांश लाइब्रेरीज़ में '''"फ्रेमवर्क"''' सम्मिलित होते हैं, जिन्हें '''"बंडल"''' नामक विशेष निर्देशिकाओं के अंदर रखा जाता है, जो लाइब्रेरी की आवश्यक फ़ाइलों और मेटाडेटा को लपेटते हैं। उदाहरण के लिए,  <code>MyFramework</code> नामक एक फ्रेमवर्क को <code>MyFramework.framework</code>नामक बंडल में क्रियान्वित किया जाएगा, जिसमें <code>MyFramework.framework/MyFramework</code> या तब गतिशील रूप से लिंक की गई लाइब्रेरी फ़ाइल होना या गतिशील रूप से लिंक की गई लाइब्रेरी फ़ाइल होगी या<code>MyFramework.framework/Versions/Current/MyFrameworkमें गतिशील रूप से लिंक की गई लाइब्रेरी फ़ाइल का सिम्लिंक होगा।</code>
 ===माइक्रोसॉफ्ट विंडोज़===
 {{See also|माइक्रोसॉफ़्ट विंडोज़}}
-डायनामिक-लिंक लाइब्रेरी|डायनामिक-लिंक लाइब्रेरी में सामान्यतः प्रत्यय होता है <code>*.DLL</code>,<ref>
+डायनामिक-लिंक लाइब्रेरी|डायनामिक-लिंक लाइब्रेरी में सामान्यतः प्रत्यय <code>*.DLL</code>होता है ,<ref>
 {{cite book
   |last1            = Bresnahan
@@ Line 189: / Line 189: @@
   |archive-date      = 24 September 2015
 }}
-</ref> यद्यपि अन्य फ़ाइल नाम एक्सटेंशन विशिष्ट-उद्देश्यीय गतिशील रूप से जुड़े पुस्तकालयों की पहचान कर सकते हैं, उदाहरण के लिए <code>*.OCX</code> [[जोडकर परनिगरानी और उद्देश् य]] लाइब्रेरीज़ के लिए। इंटरफ़ेस संशोधन या तब फ़ाइल नामों में एन्कोड किए गए हैं, या घटक ऑब्जेक्ट मॉडल | COM-ऑब्जेक्ट इंटरफ़ेस का उपयोग करके भिन्न कर दिए गए हैं। इस पर निर्भर करता है कि उन्हें कैसे संकलित किया गया है, <code>*.LIB</code> फ़ाइलें या तब स्थिर पुस्तकालय हो सकती हैं या केवल संकलन के समय आवश्यक गतिशील रूप से लिंक करने योग्य पुस्तकालयों का प्रतिनिधित्व कर सकती हैं, जिन्हें डायनेमिक-लिंक लाइब्रेरी#आयात लाइब्रेरी के रूप में जाना जाता है। [[यूनिक्स]] विश्व के विपरीत, जो लिंक करते समय विभिन्न फ़ाइल एक्सटेंशन का उपयोग करता है <code>.LIB</code> Microsoft Windows में फ़ाइल को पहले यह जानना होगा कि यह नियमित स्थैतिक लाइब्रेरी है या आयात लाइब्रेरी है। पश्चात् वाले स्थितियोंमें, ए <code>.DLL</code> फ़ाइल रनटाइम पर उपस्तिथ होनी चाहिए.
+</ref> यद्यपि अन्य फ़ाइल नाम एक्सटेंशन विशिष्ट-उद्देश्यीय गतिशील रूप से जुड़े पुस्तकालयों की पहचान कर सकते हैं, उदाहरण के लिए   लाइब्रेरीज़ के लिए<code>*.OCX</code> इंटरफ़ेस संशोधन या तब फ़ाइल नामों में एन्कोड किए गए हैं, या COM-ऑब्जेक्ट इंटरफ़ेस का उपयोग करके पृथक कर दिए गए हैं। इस पर निर्भर करता है कि उन्हें उन्हें संकलित करने के विधि के आधार पर <code>*.LIB</code> फ़ाइलें या तब स्थिर पुस्तकालय हो सकती हैं या केवल संकलन के समय आवश्यक गतिशील रूप से लिंक करने योग्य पुस्तकालयों का प्रतिनिधित्व कर सकती हैं, जिन्हें '''"आयात पुस्तकालय"''' के रूप में जाना जाता है। [[यूनिक्स]] विश्व के विपरीत, जो विभिन्न फ़ाइल एक्सटेंशन का उपयोग करता है‚ विंडोज़ में<code>.LIB</code> फ़ाइल के विरुद्ध लिंक करते समय पहले यह जानना होगा कि क्या यह एक नियमित स्थैतिक लाइब्रेरी या एक आयात लाइब्रेरी है। पश्चात् वाले मामले में, एक .DLL फ़ाइल रनटाइम पर उपस्तिथ होनी चाहिए।
 ==यह भी देखें==
@@ Line 227: / Line 227: @@
 * [http://www.ibm.com/developerworks/linux/library/l-dynamic-libraries/ Anatomy of Linux dynamic libraries] at IBM.com
-{{DEFAULTSORT:Library (Computing)}}[[Category: कंप्यूटर लाइब्रेरी| कंप्यूटर लाइब्रेरी]] [[Category: ऑपरेटिंग सिस्टम प्रौद्योगिकी]]
+{{DEFAULTSORT:Library (Computing)}}
-[[Category: Machine Translated Page]]
+[[Category:Articles with hatnote templates targeting a nonexistent page|Library (Computing)]]
-[[Category:Created On 06/07/2023]]
+[[Category:CS1]]
+[[Category:CS1 errors]]
+[[Category:CS1 maint]]
+[[Category:Created On 06/07/2023|Library (Computing)]]
+[[Category:Lua-based templates|Library (Computing)]]
+[[Category:Machine Translated Page|Library (Computing)]]
+[[Category:Missing redirects|Library (Computing)]]
+[[Category:Pages with script errors|Library (Computing)]]
+[[Category:Templates Vigyan Ready|Library (Computing)]]
+[[Category:Templates that add a tracking category|Library (Computing)]]
+[[Category:Templates that generate short descriptions|Library (Computing)]]
+[[Category:Templates using TemplateData|Library (Computing)]]
+[[Category:Webarchive template wayback links|Library (Computing)]]
+[[Category:ऑपरेटिंग सिस्टम प्रौद्योगिकी|Library (Computing)]]
+[[Category:कंप्यूटर लाइब्रेरी| कंप्यूटर लाइब्रेरी]]

Anonymous

Search

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

Namespaces

More

Page actions

Latest revision as of 10:48, 27 July 2023

Contents

इतिहास

लिंकिंग

स्थानांतरण

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

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

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

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

अनुकूलन

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

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

ओपनस्टेप

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

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

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

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

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

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

फ़ाइल नामकरण

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

मैकओएस

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

यह भी देखें

टिप्पणियाँ

अग्रिम पठन

Navigation

Navigation

Wiki tools

Wiki tools

Anonymous

Search

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

Latest revision as of 10:48, 27 July 2023

इतिहास

लिंकिंग

स्थानांतरण

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

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

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

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

अनुकूलन

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

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

ओपनस्टेप

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

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

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

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

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

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

फ़ाइल नामकरण

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

मैकओएस

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

यह भी देखें

टिप्पणियाँ

अग्रिम पठन

Navigation

Wiki tools

Page tools

Other projects

Categories