लाइब्रेरी (कंप्यूटिंग): Difference between revisions
No edit summary |
No edit summary |
||
| Line 97: | Line 97: | ||
=== रनटाइम पर पुस्तकालयों का पता लगाना === | === रनटाइम पर पुस्तकालयों का पता लगाना === | ||
साझा पुस्तकालयों के लिए लोडर कार्यक्षमता में व्यापक रूप से भिन्न होते हैं। कुछ पुस्तकालयों के लिए स्पष्ट पथों को संग्रहीत करने वाले निष्पादन योग्य पर निर्भर करते हैं। लाइब्रेरी के नामकरण या फ़ाइल सिस्टम के लेआउट में कोई भी परिवर्तन इन सिस्टमों को विफल कर देगा। सामान्यतः, केवल लाइब्रेरी का नाम (और पथ नहीं) निष्पादन योग्य में संग्रहीत किया जाता है, ऑपरेटिंग सिस्टम कुछ एल्गोरिदम के आधार पर डिस्क पर लाइब्रेरी ढूंढने के लिए विधि प्रदान करता है। | साझा पुस्तकालयों के लिए लोडर कार्यक्षमता में व्यापक रूप से भिन्न होते हैं। कुछ पुस्तकालयों के लिए स्पष्ट पथों को संग्रहीत करने वाले निष्पादन योग्य पर निर्भर करते हैं। इस प्रकार लाइब्रेरी के नामकरण या फ़ाइल सिस्टम के लेआउट में कोई भी परिवर्तन इन सिस्टमों को विफल कर देगा। सामान्यतः, केवल लाइब्रेरी का नाम (और पथ नहीं) निष्पादन योग्य में संग्रहीत किया जाता है, ऑपरेटिंग सिस्टम कुछ एल्गोरिदम के आधार पर डिस्क पर लाइब्रेरी ढूंढने के लिए विधि प्रदान करता है। | ||
यदि कोई साझा लाइब्रेरी जिस पर निष्पादन योग्य निर्भर है, हटा दी गई है, स्थानांतरित कर दी गई है, या उसका नाम बदल दिया गया है, या यदि लाइब्रेरी का असंगत संस्करण किसी ऐसे स्थान पर कॉपी किया गया है जो खोज में पहले है, तब निष्पादन योग्य लोड होने में विफल हो जाएगा। इसे [[निर्भरता नरक]] कहा जाता है, जो अनेक प्लेटफार्मों पर उपस्तिथ है। (कुख्यात) विंडोज़ संस्करण को सामान्यतः डीएलएल हेल के रूप में जाना जाता है। यह समस्या तब उत्पन्न नहीं हो सकती यदि प्रत्येक लाइब्रेरी के प्रत्येक संस्करण को विशिष्ट रूप से पहचाना जाता है और प्रत्येक प्रोग्राम लाइब्रेरी को केवल उनके पूर्ण अद्वितीय पहचानकर्ताओं द्वारा संदर्भित करता है। पहले विंडोज़ संस्करणों के साथ डीएलएल समस्याएँ प्रोग्रामों में गतिशील लिंक को हल करने के लिए केवल पुस्तकालयों के नामों का उपयोग करने से उत्पन्न हुईं, जिनके अद्वितीय होने की गारंटी नहीं थी। (डीएलएल नरक से बचने के लिए, विंडोज़ के पश्चात् के संस्करण बड़े पैमाने पर निजी डीएलएल स्थापित करने के लिए प्रोग्राम के विकल्पों पर निर्भर करते हैं - अनिवार्य रूप से साझा पुस्तकालयों के उपयोग से आंशिक वापसी - साथ ही साझा सिस्टम डीएलएल को पुराने संस्करणों के साथ बदलने से रोकने के लिए तंत्र पर।) | यदि कोई साझा लाइब्रेरी जिस पर निष्पादन योग्य निर्भर है, हटा दी गई है, स्थानांतरित कर दी गई है, या उसका नाम बदल दिया गया है, या यदि लाइब्रेरी का असंगत संस्करण किसी ऐसे स्थान पर कॉपी किया गया है जो खोज में पहले है, तब निष्पादन योग्य लोड होने में विफल हो जाएगा। इस प्रकार इसे [[निर्भरता नरक]] कहा जाता है, जो अनेक प्लेटफार्मों पर उपस्तिथ है। (कुख्यात) विंडोज़ संस्करण को सामान्यतः डीएलएल हेल के रूप में जाना जाता है। इस प्रकार यह समस्या तब उत्पन्न नहीं हो सकती यदि प्रत्येक लाइब्रेरी के प्रत्येक संस्करण को विशिष्ट रूप से पहचाना जाता है और प्रत्येक प्रोग्राम लाइब्रेरी को केवल उनके पूर्ण अद्वितीय पहचानकर्ताओं द्वारा संदर्भित करता है। इस प्रकार पहले विंडोज़ संस्करणों के साथ डीएलएल समस्याएँ प्रोग्रामों में गतिशील लिंक को हल करने के लिए केवल पुस्तकालयों के नामों का उपयोग करने से उत्पन्न हुईं, जिनके अद्वितीय होने की गारंटी नहीं थी। ('''"डीएलएल नरक"''' से बचने के लिए, विंडोज़ के पश्चात् के संस्करण बड़े पैमाने पर निजी डीएलएल स्थापित करने के लिए प्रोग्राम के विकल्पों पर निर्भर करते हैं - अनिवार्य रूप से साझा पुस्तकालयों के उपयोग से आंशिक वापसी - साथ ही साझा सिस्टम डीएलएल को पुराने संस्करणों के साथ बदलने से रोकने के लिए तंत्र पर।) निर्भर हैं। | ||
====माइक्रोसॉफ्ट विंडोज़==== | ====माइक्रोसॉफ्ट विंडोज़==== | ||
माइक्रोसॉफ्ट विंडोज [[ घटक वस्तु मॉडल |घटक वस्तु मॉडल]] को क्रियान्वित करने वाले डीएलएल को लोड करने के लिए उचित स्थान निर्धारित करने के लिए [[ विंडोज़ रजिस्ट्री |विंडोज़ रजिस्ट्री]] की जांच करता है, किन्तु अन्य डीएलएल के लिए यह निर्धारित क्रम में निर्देशिकाओं की जांच करेगा। सबसे पहले, विंडोज़ उस निर्देशिका की जाँच करता है जहाँ उसने प्रोग्राम (निजी डीएलएल)।<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 | |url = http://msdn.microsoft.com/en-us/library/ms682586.aspx | ||
|title = Dynamic-Link Library Search Order | |title = Dynamic-Link Library Search Order | ||
| Line 115: | Line 115: | ||
====ओपनस्टेप==== | ====ओपनस्टेप==== | ||
ओपनस्टेप ने अधिक लचीली प्रणाली का उपयोग किया, जब सिस्टम पहली बार प्रारंभ होता है तब अनेक ज्ञात स्थानों (पीएटीएच अवधारणा के समान) से पुस्तकालयों की सूची एकत्र की जाती है। पुस्तकालयों को इधर-उधर ले जाने से कोई समस्या नहीं होती है, यद्यपि उपयोगकर्ताओं को पहली बार सिस्टम प्रारंभ करने में समय लगता है। | ओपनस्टेप ने अधिक लचीली प्रणाली का उपयोग किया, जब सिस्टम पहली बार प्रारंभ होता है तब अनेक ज्ञात स्थानों (पीएटीएच अवधारणा के समान) से पुस्तकालयों की सूची एकत्र की जाती है। इस प्रकार पुस्तकालयों को इधर-उधर ले जाने से कोई समस्या नहीं होती है, यद्यपि उपयोगकर्ताओं को पहली बार सिस्टम प्रारंभ करने में समय लगता है। | ||
====यूनिक्स जैसी प्रणालियाँ==== | ====यूनिक्स जैसी प्रणालियाँ==== | ||
अधिकांश यूनिक्स-जैसी प्रणालियों में फ़ाइल-सिस्टम [[निर्देशिका (कंप्यूटिंग)]] को निर्दिष्ट करने वाला खोज पथ होता है जिसमें गतिशील पुस्तकालयों को देखना होता है। कुछ सिस्टम [[विन्यास फाइल]] में डिफ़ॉल्ट पथ निर्दिष्ट करते हैं, अन्य इसे डायनेमिक लोडर में हार्ड-कोड करते हैं। कुछ [[निष्पादन]] योग्य प्रारूप अतिरिक्त निर्देशिकाएँ निर्दिष्ट कर सकते हैं जिनमें किसी विशेष कार्यक्रम के लिए पुस्तकालयों की खोज की जा सकती है। इसे सामान्यतः पर्यावरण चर के साथ ओवरराइड किया जा सकता है, चूंकि यह [[निर्धारित समय]] और समूहगिड प्रोग्राम के लिए अक्षम है, जिससे कि कोई उपयोगकर्ता ऐसे प्रोग्राम को रूट अनुमतियों के साथ इच्छानुसार कोड चलाने के लिए मजबूर न कर सके। पुस्तकालयों के डेवलपर्स को अपने गतिशील पुस्तकालयों को डिफ़ॉल्ट खोज पथ में स्थानों पर रखने के लिए प्रोत्साहित किया जाता है। ऋणात्मक पक्ष यह है कि इससे नए पुस्तकालयों की स्थापना समस्याग्रस्त हो सकती है, और यह ज्ञात स्थान तेजी से बढ़ती संख्या में पुस्तकालय फ़ाइलों का घर बन जाते हैं, जिससे प्रबंधन अधिक जटिल हो जाता है। | अधिकांश यूनिक्स-जैसी प्रणालियों में फ़ाइल-सिस्टम [[निर्देशिका (कंप्यूटिंग)]] को निर्दिष्ट करने वाला खोज पथ होता है जिसमें गतिशील पुस्तकालयों को देखना होता है। कुछ सिस्टम [[विन्यास फाइल]] में डिफ़ॉल्ट पथ निर्दिष्ट करते हैं, अन्य इसे डायनेमिक लोडर में हार्ड-कोड करते हैं। इस प्रकार कुछ [[निष्पादन]] योग्य प्रारूप अतिरिक्त निर्देशिकाएँ निर्दिष्ट कर सकते हैं जिनमें किसी विशेष कार्यक्रम के लिए पुस्तकालयों की खोज की जा सकती है। इसे सामान्यतः पर्यावरण चर के साथ ओवरराइड किया जा सकता है, चूंकि यह [[निर्धारित समय]] और समूहगिड प्रोग्राम के लिए अक्षम है, जिससे कि कोई उपयोगकर्ता ऐसे प्रोग्राम को रूट अनुमतियों के साथ इच्छानुसार कोड चलाने के लिए मजबूर न कर सके। पुस्तकालयों के डेवलपर्स को अपने गतिशील पुस्तकालयों को डिफ़ॉल्ट खोज पथ में स्थानों पर रखने के लिए प्रोत्साहित किया जाता है। ऋणात्मक पक्ष यह है कि इससे नए पुस्तकालयों की स्थापना समस्याग्रस्त हो सकती है, और यह ज्ञात स्थान तेजी से बढ़ती संख्या में पुस्तकालय फ़ाइलों का घर बन जाते हैं, जिससे प्रबंधन अधिक जटिल हो जाता है। | ||
===गतिशील लोडिंग=== | ===गतिशील लोडिंग=== | ||
{{Main|गतिशील लोडिंग}} | {{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 का संशोधित संस्करण, रिमोट एक्सेस का समर्थन करता है। | ||
| Line 139: | Line 139: | ||
क्लास लाइब्रेरीज़ पुराने प्रकार के कोड लाइब्रेरीज़ के समतुल्य OOP हैं। उनमें क्लास सम्मिलित है, जो विशेषताओं का वर्णन करता है और क्रियाओं ([[विधि (कंप्यूटर विज्ञान)|विधियों (कंप्यूटर विज्ञान)]]) को परिभाषित करता है जिसमें वस्तुएं सम्मिलित होती हैं। क्लास लाइब्रेरीज़ का उपयोग इंस्टेंस (कंप्यूटर विज्ञान), या विशिष्ट मानों पर समूह की गई विशेषताओं वाली ऑब्जेक्ट बनाने के लिए किया जाता है। जावा (प्रोग्रामिंग भाषा) जैसी कुछ ओओपी भाषाओं में, अंतर स्पष्ट है, कक्षाएं अधिकांशतः लाइब्रेरी फ़ाइलों (जैसे जावा के जार (फ़ाइल प्रारूप)) में निहित होती हैं और तत्काल ऑब्जेक्ट केवल मेमोरी में रहते हैं (चूंकि संभावित रूप से दृढ़ता बनाए जाने में सक्षम होते हैं) (कंप्यूटर विज्ञान) भिन्न फाइलों में)। दूसरों में, स्मॉलटॉक की तरह, क्लास लाइब्रेरीज़ [[ सिस्टम छवि |सिस्टम छवि]] के लिए प्रारंभिक बिंदु मात्र हैं जिसमें पर्यावरण की संपूर्ण स्थिति, कक्षाएं और सभी तात्कालिक ऑब्जेक्ट सम्मिलित होते हैं। | क्लास लाइब्रेरीज़ पुराने प्रकार के कोड लाइब्रेरीज़ के समतुल्य OOP हैं। उनमें क्लास सम्मिलित है, जो विशेषताओं का वर्णन करता है और क्रियाओं ([[विधि (कंप्यूटर विज्ञान)|विधियों (कंप्यूटर विज्ञान)]]) को परिभाषित करता है जिसमें वस्तुएं सम्मिलित होती हैं। क्लास लाइब्रेरीज़ का उपयोग इंस्टेंस (कंप्यूटर विज्ञान), या विशिष्ट मानों पर समूह की गई विशेषताओं वाली ऑब्जेक्ट बनाने के लिए किया जाता है। जावा (प्रोग्रामिंग भाषा) जैसी कुछ ओओपी भाषाओं में, अंतर स्पष्ट है, कक्षाएं अधिकांशतः लाइब्रेरी फ़ाइलों (जैसे जावा के जार (फ़ाइल प्रारूप)) में निहित होती हैं और तत्काल ऑब्जेक्ट केवल मेमोरी में रहते हैं (चूंकि संभावित रूप से दृढ़ता बनाए जाने में सक्षम होते हैं) (कंप्यूटर विज्ञान) भिन्न फाइलों में)। दूसरों में, स्मॉलटॉक की तरह, क्लास लाइब्रेरीज़ [[ सिस्टम छवि |सिस्टम छवि]] के लिए प्रारंभिक बिंदु मात्र हैं जिसमें पर्यावरण की संपूर्ण स्थिति, कक्षाएं और सभी तात्कालिक ऑब्जेक्ट सम्मिलित होते हैं। | ||
आज अधिकांश क्लास लाइब्रेरीज़ को [[ पैकेज भंडार |पैकेज भंडार]] (जैसे जावा के लिए मेवेन सेंट्रल) में संग्रहीत किया जाता है। क्लाइंट कोड स्पष्ट रूप से [[सॉफ्टवेयर निर्माण]] कॉन्फ़िगरेशन फ़ाइलों (जैसे जावा में मावेन पोम) में बाहरी पुस्तकालयों पर निर्भरता की घोषणा करता है। | आज अधिकांश क्लास लाइब्रेरीज़ को [[ पैकेज भंडार |पैकेज भंडार]] (जैसे जावा के लिए मेवेन सेंट्रल) में संग्रहीत किया जाता है। इस प्रकार क्लाइंट कोड स्पष्ट रूप से [[सॉफ्टवेयर निर्माण]] कॉन्फ़िगरेशन फ़ाइलों (जैसे जावा में मावेन पोम) में बाहरी पुस्तकालयों पर निर्भरता की घोषणा करता है। | ||
==दूरस्थ पुस्तकालय== | ==दूरस्थ पुस्तकालय== | ||
एक अन्य लाइब्रेरी विधि पूरी तरह से भिन्न निष्पादनयोग्य (अधिकांशतः कुछ हल्के रूप में) का उपयोग करती है और उन्हें नेटवर्क पर दूसरे कंप्यूटर पर रिमोट प्रक्रिया कॉल (आरपीसी) का उपयोग करके कॉल करती है। यह ऑपरेटिंग सिस्टम के पुन: उपयोग को अधिकतम करता है: लाइब्रेरी का समर्थन करने के लिए आवश्यक कोड वही कोड है जिसका उपयोग हर दूसरे प्रोग्राम के लिए एप्लिकेशन समर्थन और सुरक्षा प्रदान करने के लिए किया जा रहा है। इसके अतिरिक्त, ऐसी प्रणालियों के लिए लाइब्रेरी को उसी मशीन पर उपस्तिथ होने की आवश्यकता नहीं होती है, किन्तु वह नेटवर्क पर अनुरोधों को अग्रेषित कर सकते हैं। | एक अन्य लाइब्रेरी विधि पूरी तरह से भिन्न निष्पादनयोग्य (अधिकांशतः कुछ हल्के रूप में) का उपयोग करती है और उन्हें नेटवर्क पर दूसरे कंप्यूटर पर रिमोट प्रक्रिया कॉल (आरपीसी) का उपयोग करके कॉल करती है। यह ऑपरेटिंग सिस्टम के पुन: उपयोग को अधिकतम करता है: लाइब्रेरी का समर्थन करने के लिए आवश्यक कोड वही कोड है जिसका उपयोग हर दूसरे प्रोग्राम के लिए एप्लिकेशन समर्थन और सुरक्षा प्रदान करने के लिए किया जा रहा है। इस प्रकार इसके अतिरिक्त, ऐसी प्रणालियों के लिए लाइब्रेरी को उसी मशीन पर उपस्तिथ होने की आवश्यकता नहीं होती है, किन्तु वह नेटवर्क पर अनुरोधों को अग्रेषित कर सकते हैं। | ||
यद्यपि, इस तरह के दृष्टिकोण का कारण है कि प्रत्येक लाइब्रेरी कॉल के लिए अधिक मात्रा में ओवरहेड की आवश्यकता होती है। आरपीसी कॉल किसी साझा लाइब्रेरी को कॉल करने की तुलना में बहुत अधिक महंगी हैं जो पहले से ही उसी मशीन पर लोड की जा चुकी है। इस दृष्टिकोण का उपयोग सामान्यतः वितरित कंप्यूटिंग में किया जाता है जो ऐसे दूरस्थ कॉल, विशेष रूप से क्लाइंट-सर्वर सिस्टम और [[एंटरप्राइज़ जावा]]बीन्स जैसे [[अनुप्रयोग सर्वर]] का भारी उपयोग करता है। | यद्यपि, इस तरह के दृष्टिकोण का कारण है कि प्रत्येक लाइब्रेरी कॉल के लिए अधिक मात्रा में ओवरहेड की आवश्यकता होती है। इस प्रकार आरपीसी कॉल किसी साझा लाइब्रेरी को कॉल करने की तुलना में बहुत अधिक महंगी हैं जो पहले से ही उसी मशीन पर लोड की जा चुकी है। इस दृष्टिकोण का उपयोग सामान्यतः वितरित कंप्यूटिंग में किया जाता है जो ऐसे दूरस्थ कॉल, विशेष रूप से क्लाइंट-सर्वर सिस्टम और [[एंटरप्राइज़ जावा]]बीन्स जैसे [[अनुप्रयोग सर्वर]] का भारी उपयोग करता है। | ||
==कोड जनरेशन लाइब्रेरी== | ==कोड जनरेशन लाइब्रेरी== | ||
कोड जनरेशन लाइब्रेरी उच्च-स्तरीय एपीआई [[अप्लिकेशन प्रोग्रामिंग अंतरफलक]] हैं जो जावा (प्रोग्रामिंग भाषा) के लिए [[बाइट कोड]] उत्पन्न या परिवर्तित कर सकते हैं। इनका उपयोग पहलू-उन्मुख प्रोग्रामिंग, कुछ डेटा एक्सेस फ्रेमवर्क और गतिशील प्रॉक्सी ऑब्जेक्ट उत्पन्न करने के परीक्षण के लिए किया जाता है। इनका उपयोग फ़ील्ड पहुंच को रोकने के लिए भी किया जाता है।<ref>{{cite web | कोड जनरेशन लाइब्रेरी उच्च-स्तरीय एपीआई [[अप्लिकेशन प्रोग्रामिंग अंतरफलक]] हैं जो जावा (प्रोग्रामिंग भाषा) के लिए [[बाइट कोड]] उत्पन्न या परिवर्तित कर सकते हैं। इनका उपयोग पहलू-उन्मुख प्रोग्रामिंग, कुछ डेटा एक्सेस फ्रेमवर्क और गतिशील प्रॉक्सी ऑब्जेक्ट उत्पन्न करने के परीक्षण के लिए किया जाता है। इस प्रकार इनका उपयोग फ़ील्ड पहुंच को रोकने के लिए भी किया जाता है।<ref>{{cite web | ||
|access-date = 2010-03-03 | |access-date = 2010-03-03 | ||
|publisher = [[Source Forge]] | |publisher = [[Source Forge]] | ||
| Line 162: | Line 162: | ||
===अधिकांश आधुनिक यूनिक्स जैसी प्रणालियाँ=== | ===अधिकांश आधुनिक यूनिक्स जैसी प्रणालियाँ=== | ||
{{See also|UNIX- जैसे}} | {{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>, से प्रारम्भ होते हैं, और .a (संग्रह, स्थिर लाइब्रेरी) या .so (साझा ऑब्जेक्ट, गतिशील रूप से लिंक की गई लाइब्रेरी) के प्रत्यय के साथ समाप्त होते हैं। कुछ प्रणालियों में गतिशील रूप से जुड़ी लाइब्रेरी के लिए कई नाम हो सकते हैं। यह नाम सामान्यतः ही उपसर्ग साझा करते हैं और संस्करण संख्या को इंगित करने वाले भिन्न- भिन्न प्रत्यय होते हैं। अधिकांश नाम नवीनतम संस्करण के [[प्रतीकात्मक लिंक]] के नाम हैं। उदाहरण के लिए, कुछ प्रणालियों पर <code>libfoo.so.2</code> गतिशील रूप से लिंक की गई लाइब्रेरी <code>libfoo</code>के दूसरे प्रमुख इंटरफ़ेस संशोधन के लिए फ़ाइल नाम होगा। कभी-कभी लाइब्रेरी निर्देशिकाओं में पाई जाने वाली .la फ़ाइलें [[ 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|मैक ओएस}} | {{See also|मैक ओएस}} | ||
सिस्टम को [[बीएसडी]] से स्थैतिक लाइब्रेरी कन्वेंशन विरासत में मिलती है, लाइब्रेरी एक .a फ़ाइल में संग्रहीत होती है, और .so-शैली गतिशील रूप से लिंक की गई लाइब्रेरी (इसके अतिरिक्त .dylib प्रत्यय के साथ) का उपयोग कर सकती है। यद्यपि, 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> | ||
===माइक्रोसॉफ्ट विंडोज़=== | ===माइक्रोसॉफ्ट विंडोज़=== | ||
| Line 189: | Line 189: | ||
|archive-date = 24 September 2015 | |archive-date = 24 September 2015 | ||
}} | }} | ||
</ref> यद्यपि अन्य फ़ाइल नाम एक्सटेंशन विशिष्ट-उद्देश्यीय गतिशील रूप से जुड़े पुस्तकालयों की पहचान कर सकते हैं, उदाहरण के लिए लाइब्रेरीज़ के लिए<code>*.OCX</code> इंटरफ़ेस संशोधन या तब फ़ाइल नामों में एन्कोड किए गए हैं, या COM-ऑब्जेक्ट इंटरफ़ेस का उपयोग करके | </ref> यद्यपि अन्य फ़ाइल नाम एक्सटेंशन विशिष्ट-उद्देश्यीय गतिशील रूप से जुड़े पुस्तकालयों की पहचान कर सकते हैं, उदाहरण के लिए लाइब्रेरीज़ के लिए<code>*.OCX</code> इंटरफ़ेस संशोधन या तब फ़ाइल नामों में एन्कोड किए गए हैं, या COM-ऑब्जेक्ट इंटरफ़ेस का उपयोग करके पृथक कर दिए गए हैं। इस पर निर्भर करता है कि उन्हें उन्हें संकलित करने के विधि के आधार पर <code>*.LIB</code> फ़ाइलें या तब स्थिर पुस्तकालय हो सकती हैं या केवल संकलन के समय आवश्यक गतिशील रूप से लिंक करने योग्य पुस्तकालयों का प्रतिनिधित्व कर सकती हैं, जिन्हें '''"आयात पुस्तकालय"''' के रूप में जाना जाता है। [[यूनिक्स]] विश्व के विपरीत, जो विभिन्न फ़ाइल एक्सटेंशन का उपयोग करता है‚ विंडोज़ में<code>.LIB</code> फ़ाइल के विरुद्ध लिंक करते समय पहले यह जानना होगा कि क्या यह एक नियमित स्थैतिक लाइब्रेरी या एक आयात लाइब्रेरी है। पश्चात् वाले मामले में, एक .DLL फ़ाइल रनटाइम पर उपस्तिथ होनी चाहिए। | ||
==यह भी देखें== | ==यह भी देखें== | ||
Revision as of 13:09, 20 July 2023
कंप्यूटर विज्ञान में, लाइब्रेरी गैर-वाष्पशील संसाधनों का संग्रह है जिसका उपयोग कंप्यूटर प्रोग्राम द्वारा अधिकांशतः सॉफ्टवेयर विकास के लिए किया जाता है। इस प्रकार इनमें कॉन्फ़िगरेशन डेटा, दस्तावेज़ीकरण, सहायता डेटा, संदेश टेम्पलेट, पूर्व-लिखित कोड और सबरूटीन, कक्षाएं, मान या डेटा प्रकार विनिर्देश सम्मिलित हो सकते हैं। आईबीएम के ओएस/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
टिप्पणियाँ
- ↑ Some older systems, e.g., Burroughs MCP, Multics, also have only a single format for executable files, regardless of whether they are shared.
संदर्भ
- ↑ 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
.dllfilename 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
