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

From Vigyanwiki
(Created page with "{{short description|Collection of non-volatile resources used by computer programs}} {{redirect-distinguish|Software library|library software}} {{About|a software development...")
 
No edit summary
 
(18 intermediate revisions by 3 users not shown)
Line 1: Line 1:
{{short description|Collection of non-volatile resources used by computer programs}}
{{short description|Collection of non-volatile resources used by computer programs}}
{{redirect-distinguish|Software library|library software}}
{{redirect-distinguish|सॉफ्टवेयर लाइब्रेरी|पुस्तकालय सॉफ्टवेयर}}
{{About|a software development concept|a repository of digital assets|Digital library}}
{{About|एक सॉफ्टवेयर विकास अवधारणा|डिजिटल संपत्तियों का भंडार|डिजिटल लाइब्रेरी}}
{{Use dmy dates|date=February 2020|cs1-dates=y}}
 
[[Image:Ogg vorbis libs and application dia.svg|thumb|277px|right|एक एप्लिकेशन का चित्रण जो [[Ogg Vorbis]] फ़ाइल को चलाने के लिए libvorbisfile का उपयोग करता है]]
[[Image:Ogg vorbis libs and application dia.svg|thumb|277px|right|एक एप्लिकेशन का चित्रण जो [[Ogg Vorbis]] फ़ाइल को चलाने के लिए libvorbisfile का उपयोग करता है]]


<!-- All of the things listed in the following paragraph have been referred to as libraries by at least IBM from the software of [[IBM System/360]] through the software on [[IBM System z]]. -->
<!-- निम्नलिखित पैराग्राफ में सूचीबद्ध सभी चीजों को कम से कम आईबीएम द्वारा [[आईबीएम सिस्टम/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>
|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>


[[ उल्लासपूर्ण ]] के पास एक संचार पूल (COMPOOL) था, जो मोटे तौर पर हेडर फ़ाइलों की एक लाइब्रेरी थी।
[[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>


आधुनिक पुस्तकालय अवधारणा में एक और प्रमुख योगदानकर्ता [[फोरट्रान]] के [[Subprogram]] नवाचार के रूप में आया। फोरट्रान उपप्रोग्रामों को एक दूसरे से स्वतंत्र रूप से संकलित किया जा सकता है, लेकिन कंपाइलर में लिंकर (कंप्यूटिंग) का अभाव था। इसलिए फोरट्रान-90 में मॉड्यूल की शुरूआत से पहले, फोरट्रान के बीच [[टाइप चेकिंग]] करें
[[ उल्लासपूर्ण | जोवियल]] के पास संचार पूल (COMPOOL) था, जो मोटे तौर पर हेडर फ़ाइलों की लाइब्रेरी थी।
रेफरी समूह = एनबी>यह पहले संभव था, उदाहरण के लिए, एडा उपप्रोग्राम।</ref> उपप्रोग्राम असंभव था।<ref name="Wilson_Clark_1988_126">{{Cite book |last1=Wilson |first1=Leslie B. |last2=Clark |first2=Robert G.
 
आधुनिक पुस्तकालय अवधारणा में और प्रमुख योगदानकर्ता [[फोरट्रान]] के [[Subprogram|उपप्रोग्राम]] नवाचार के रूप में आया। इस प्रकार फोरट्रान उपप्रोग्रामों को दूसरे से स्वतंत्र रूप से संकलित किया जा सकता है, किन्तु कंपाइलर में लिंकर (कंप्यूटिंग) का अभाव था। इसलिए फोरट्रान-90 में मॉड्यूल की प्रारंभ से पहले, फोरट्रान [एनबी 1] उपप्रोग्रामों के मध्य प्रकार की जांच असंभव थी।<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>
|title=तुलनात्मक प्रोग्रामिंग भाषाएँ|publisher=Addison-Wesley |year=1988 |publication-place=Wokingham, England |isbn=0-201-18483-4 |page=126 }}</ref>


1960 के दशक के मध्य तक, असेंबलरों के लिए कॉपी और मैक्रो लाइब्रेरी आम थीं। आईबीएम सिस्टम/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>


=={{anchor|Smart linking}}लिंकिंग==
==लिंकिंग==
{{main|Link time|Linker (computing)}}
{{main|लिंक समय|लिंकर (कंप्यूटिंग)}}


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


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


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


==स्थानांतरण==
==स्थानांतरण==
{{Main|Relocation (computer science)}}
{{Main|स्थानांतरण (कंप्यूटर विज्ञान)}}


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


==स्थैतिक पुस्तकालय==
==स्थैतिक पुस्तकालय==
{{Main|Static library}}
{{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>{{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>{{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>
==साझा पुस्तकालय==
==साझा पुस्तकालय==
{{redirect|Shared object|the synchronization mechanism|Monitor (synchronization)}}
{{redirect|साझा वस्तु|तुल्यकालन तंत्र|मॉनिटर (सिंक्रनाइज़ेशन)}}


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


साझा पुस्तकालयों को संकलन-समय के दौरान स्थिर रूप से जोड़ा जा सकता है, जिसका अर्थ है कि पुस्तकालय मॉड्यूल के संदर्भों को हल किया जाता है और निष्पादन योग्य फ़ाइल बनने पर मॉड्यूल को मेमोरी आवंटित की जाती है।{{cn|date=June 2023}} लेकिन अक्सर साझा लाइब्रेरीज़ को लोड होने तक लिंक करना स्थगित कर दिया जाता है।{{Dubious|date=May 2014}}
साझा पुस्तकालयों को संकलन-समय के समय स्थिर रूप से जोड़ा जा सकता है, जिसका अर्थ है कि पुस्तकालय मॉड्यूल के संदर्भों को हल किया जाता है और निष्पादन योग्य फ़ाइल बनने पर मॉड्यूल को मेमोरी आवंटित की जाती है। किन्तु अधिकांशतः साझा लाइब्रेरीज़ को लोड होने तक लिंक करना स्थगित कर दिया जाता है। जब तक कि वे लोड न हो जाएं।


सबसे आधुनिक [[ऑपरेटिंग सिस्टम]]<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> इसमें निष्पादन योग्य फ़ाइलों के समान प्रारूप की साझा लाइब्रेरी फ़ाइलें हो सकती हैं। यह दो मुख्य लाभ प्रदान करता है: पहला, इसमें दोनों के लिए दो के बजाय केवल एक लोडर बनाने की आवश्यकता होती है (एकल लोडर को इसकी अतिरिक्त जटिलता के लायक माना जाता है){{Citation Needed|date=April 2022}}. दूसरे, यह निष्पादनयोग्यों को साझा पुस्तकालयों के रूप में भी उपयोग करने की अनुमति देता है, यदि उनके पास एक [[प्रतीक तालिका]] है। विशिष्ट संयुक्त निष्पादन योग्य और साझा लाइब्रेरी प्रारूप [[निष्पादन योग्य और लिंक करने योग्य प्रारूप]] और [[मच-ओ]] (दोनों यूनिक्स में) और [[पोर्टेबल निष्पादन योग्य]] (विंडोज़) हैं।
सबसे आधुनिक [[ऑपरेटिंग सिस्टम]]<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|Shared memory}}
{{main|साझा मेमोरी}}


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


प्रोग्राम स्थिति-स्वतंत्र कोड का उपयोग करके रैम साझाकरण को पूरा कर सकते हैं, जैसे कि [[यूनिक्स]] में, जो एक जटिल लेकिन लचीली वास्तुकला की ओर ले जाता है, या सामान्य आभासी पते का उपयोग करके, जैसा कि विंडोज और ओएस/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
| url=http://msdn.microsoft.com/library/techart/dlldanger1.htm
| title=The End of DLL Hell
| title=The End of DLL Hell
Line 87: Line 87:
| quote=Private DLLs are DLLs that are installed with a specific application and used only by that application.
| quote=Private DLLs are DLLs that are installed with a specific application and used only by that application.
}}</ref>
}}</ref>
===डायनेमिक लिंकिंग===
===डायनेमिक लिंकिंग===
{{main|Dynamic linker}}
{{main|गतिशील लिंकर}}
 
डायनामिक लिंकिंग या [[ देर से बंधन ]] वह लिंकिंग है जो प्रोग्राम लोड होने (लोड समय) या निष्पादित होने (रनटाइम (प्रोग्राम जीवनचक्र चरण)) के दौरान की जाती है, न कि तब जब निष्पादन योग्य फ़ाइल बनाई जाती है। एक गतिशील रूप से लिंक की गई लाइब्रेरी ([[डायनामिक-लिंक लाइब्रेरी]], या DLL, [[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>


डायनामिक लिंकिंग या [[ देर से बंधन |देर से बंधन]] वह लिंकिंग है जो प्रोग्राम लोड होने (लोड समय) या निष्पादित होने (रनटाइम (प्रोग्राम जीवनचक्र चरण)) के समय की जाती है, न कि तब जब निष्पादन योग्य फ़ाइल बनाई जाती है। गतिशील रूप से लिंक की गई लाइब्रेरी ([[डायनामिक-लिंक लाइब्रेरी]], या डीएलएल, [[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>
===अनुकूलन===
===अनुकूलन===
चूंकि अधिकांश सिस्टम पर साझा लाइब्रेरी अक्सर नहीं बदलती हैं, सिस्टम जरूरत पड़ने से पहले सिस्टम पर प्रत्येक साझा लाइब्रेरी के लिए संभावित लोड पते की गणना कर सकता है और उस जानकारी को लाइब्रेरी और निष्पादन योग्य में संग्रहीत कर सकता है। यदि लोड की गई प्रत्येक साझा लाइब्रेरी इस प्रक्रिया से गुज़री है, तो प्रत्येक अपने पूर्व निर्धारित पते पर लोड होगी, जो गतिशील लिंकिंग की प्रक्रिया को गति देती है। इस अनुकूलन को क्रमशः macOS और Linux पर [[प्रीबाइंडिंग]] के रूप में जाना जाता है। IBM 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-बिट]] आर्किटेक्चर, कम से कम कुछ समय के लिए)।


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


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


====माइक्रोसॉफ्ट विंडोज़====
====माइक्रोसॉफ्ट विंडोज़====
माइक्रोसॉफ्ट विंडोज [[ घटक वस्तु मॉडल ]] को लागू करने वाले डीएलएल को लोड करने के लिए उचित स्थान निर्धारित करने के लिए [[ विंडोज़ रजिस्ट्री ]] की जांच करता है, लेकिन अन्य डीएलएल के लिए यह एक निर्धारित क्रम में निर्देशिकाओं की जांच करेगा। सबसे पहले, विंडोज़ उस निर्देशिका की जाँच करता है जहाँ उसने प्रोग्राम लोड किया है (निजी DLL)।<ref name="endofdllhell"/>); किसी भी निर्देशिका को कॉल करके सेट करें <code>SetDllDirectory()</code> समारोह; System32, सिस्टम और Windows निर्देशिकाएँ; फिर वर्तमान कार्यशील निर्देशिका; और अंत में 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 119: Line 115:


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


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


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


अधिकांश ऑपरेटिंग सिस्टम जो गतिशील रूप से जुड़े पुस्तकालयों का समर्थन करते हैं, रनटाइम (प्रोग्राम जीवनचक्र चरण) | रन-टाइम लिंकर [[अप्लिकेशन प्रोग्रामिंग अंतरफलक]] के माध्यम से ऐसे पुस्तकालयों को गतिशील रूप से लोड करने का भी समर्थन करते हैं। उदाहरण के लिए, माइक्रोसॉफ्ट विंडोज़ एपीआई फ़ंक्शंस का उपयोग करता है <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
  |access-date  = 2010-03-03
  |publisher  = [[Source Forge]]
  |publisher  = [[Source Forge]]
Line 162: Line 158:
}}</ref>
}}</ref>


 
== फ़ाइल नामकरण ==
==फ़ाइल नामकरण==


===अधिकांश आधुनिक यूनिक्स जैसी प्रणालियाँ===
===अधिकांश आधुनिक यूनिक्स जैसी प्रणालियाँ===
{{See also|Unix-like}}
{{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 ]] अभिलेखागार होती हैं, जो सिस्टम द्वारा उपयोग करने योग्य नहीं होती हैं।
सिस्टम <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|macOS}}
{{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|Microsoft Windows}}
{{See also|माइक्रोसॉफ़्ट विंडोज़}}
डायनामिक-लिंक लाइब्रेरी|डायनामिक-लिंक लाइब्रेरी में आमतौर पर प्रत्यय होता है <code>*.DLL</code>,<ref>
डायनामिक-लिंक लाइब्रेरी|डायनामिक-लिंक लाइब्रेरी में सामान्यतः प्रत्यय <code>*.DLL</code>होता है ,<ref>
{{cite book
{{cite book
  |last1            = Bresnahan
  |last1            = Bresnahan
Line 194: Line 189:
  |archive-date      = 24 September 2015
  |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 फ़ाइल रनटाइम पर उपस्तिथ होनी चाहिए।


==यह भी देखें==
==यह भी देखें==


* {{annotated link|Code reuse}}
* {{annotated link|कोड का पुन: उपयोग}}
* {{annotated link|Linker (computing)}}
* {{annotated link|लिंकर (कंप्यूटिंग)}}
* {{annotated link|Loader (computing)}}
* {{annotated link|Loader (computing)}}
* {{annotated link|Dynamic-link library}}
* {{annotated link|Dynamic-link library}}
Line 205: Line 200:
* {{annotated link|Plug-in (computing)|Plug-in}}
* {{annotated link|Plug-in (computing)|Plug-in}}
* {{annotated link|Prelink|aka=Prebinding}}
* {{annotated link|Prelink|aka=Prebinding}}
* {{annotated link|Static library}}
* {{annotated link|स्थैतिक पुस्तकालय}}
* {{annotated link|Runtime library}}
* {{annotated link|Runtime library}}
* {{annotated link|Visual Component Library}} (वीसीएल)
* {{annotated link|Visual Component Library}} (वीसीएल)
* {{annotated link|Component Library for Cross Platform}} (160)
* {{annotated link|Component Library for Cross Platform}} (160)
* {{annotated link|C standard library}}
* {{annotated link|C standard library}}
* {{annotated link|Java Class Library}}
* {{annotated link|जावा क्लास लाइब्रेरी}}
* {{annotated link|Framework Class Library}}
* {{annotated link|फ्रेमवर्क क्लास लाइब्रेरी}}
* {{annotated link|Generic programming}} (C++ मानक लाइब्रेरी द्वारा प्रयुक्त)
* {{annotated link|Generic programming}} (C++ मानक लाइब्रेरी द्वारा प्रयुक्त)
* {{annotated link|soname}}
* {{annotated link|soname}}
Line 219: Line 214:
{{reflist|group=NB}}
{{reflist|group=NB}}


 
संदर्भ
==संदर्भ==
{{reflist}}
{{reflist}}
==अग्रिम पठन==
==अग्रिम पठन==
* {{cite book |author-last=Levine |author-first=John R. |author-link=John R. Levine |title=Linkers and Loaders |date=2000 |orig-year=October 1999 |edition=1 |publisher=[[Morgan Kaufmann]] |series=The Morgan Kaufmann Series in Software Engineering and Programming |location=San Francisco, USA |isbn=1-55860-496-0 |oclc=42413382 |chapter=Chapter 9: Shared Libraries & Chapter 10: Dynamic Linking and Loading |url=https://www.iecc.com/linker/ |access-date=2020-01-12 |url-status=live |archive-url=https://archive.today/20121205032107/http://www.iecc.com/linker/ |archive-date=2012-12-05}} Code: [https://archive.today/20200114225034/https://linker.iecc.com/code.html][ftp://ftp.iecc.com/pub/linker/] Errata: [https://linker.iecc.com/<!-- https://archive.today/20200114224817/https://linker.iecc.com/ 2020-01-14 -->]
* {{cite book |author-last=Levine |author-first=John R. |author-link=John R. Levine |title=Linkers and Loaders |date=2000 |orig-year=October 1999 |edition=1 |publisher=[[Morgan Kaufmann]] |series=The Morgan Kaufmann Series in Software Engineering and Programming |location=San Francisco, USA |isbn=1-55860-496-0 |oclc=42413382 |chapter=Chapter 9: Shared Libraries & Chapter 10: Dynamic Linking and Loading |url=https://www.iecc.com/linker/ |access-date=2020-01-12 |url-status=live |archive-url=https://archive.today/20121205032107/http://www.iecc.com/linker/ |archive-date=2012-12-05}} Code: [https://archive.today/20200114225034/https://linker.iecc.com/code.html][ftp://ftp.iecc.com/pub/linker/] Errata: [https://linker.iecc.com/<!-- https://archive.today/20200114224817/https://linker.iecc.com/ 2020-01-14 -->]
Line 235: Line 227:
* [http://www.ibm.com/developerworks/linux/library/l-dynamic-libraries/ Anatomy of Linux dynamic libraries] at IBM.com
* [http://www.ibm.com/developerworks/linux/library/l-dynamic-libraries/ Anatomy of Linux dynamic libraries] at IBM.com


{{Application binary interface}}
{{DEFAULTSORT:Library (Computing)}}
{{Executables}}
{{Authority control}}
 
{{DEFAULTSORT:Library (Computing)}}[[Category: कंप्यूटर लाइब्रेरी| कंप्यूटर लाइब्रेरी]] [[Category: ऑपरेटिंग सिस्टम प्रौद्योगिकी]]
 
 


[[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:कंप्यूटर लाइब्रेरी| कंप्यूटर लाइब्रेरी]]

Latest revision as of 10:48, 27 July 2023

"सॉफ्टवेयर लाइब्रेरी" redirects here. Not to be confused with पुस्तकालय सॉफ्टवेयर.
This article is about एक सॉफ्टवेयर विकास अवधारणा. For डिजिटल संपत्तियों का भंडार, see डिजिटल लाइब्रेरी.
एक एप्लिकेशन का चित्रण जो 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]

लिंकिंग

Main articles: लिंक समय and लिंकर (कंप्यूटिंग)

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

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

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

स्थानांतरण

Main article: स्थानांतरण (कंप्यूटर विज्ञान)

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

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

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

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

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

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

"साझा वस्तु" redirects here. For तुल्यकालन तंत्र, see मॉनिटर (सिंक्रनाइज़ेशन).

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

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

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

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

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

Main article: साझा मेमोरी

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

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

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

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

Main article: गतिशील लिंकर

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

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

अनुकूलन

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

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

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

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

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

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

ओपनस्टेप

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

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

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

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

Main article: गतिशील लोडिंग

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

अधिकांश ऑपरेटिंग सिस्टम जो गतिशील रूप से जुड़े पुस्तकालयों का समर्थन करते हैं, रन-टाइम लिंकर एपीआई—अप्लिकेशन प्रोग्रामिंग अंतरफलक के माध्यम से ऐसे पुस्तकालयों को गतिशील रूप से लोड करने का भी समर्थन करते हैं। उदाहरण के लिए, माइक्रोसॉफ्ट विंडोज़ एपीआई फ़ंक्शंस 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]

फ़ाइल नामकरण

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

See also: UNIX- जैसे

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

मैकओएस

See also: मैक ओएस

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

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

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

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

यह भी देखें

टिप्पणियाँ

  1. ↑ 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.
  10. ↑ Wexelblat, Richard (1981). प्रोग्रामिंग भाषाओं का इतिहास. ACM Monograph Series. New York, NY: Academic Press (A subsidiary of Harcourt Brace). p. 274. ISBN 0-12-745040-8.
  11. ↑ वेक्सेलब्लैट, ऑप. सिट., पी. 258
  12. ↑ Wilson, Leslie B.; Clark, Robert G. (1988). तुलनात्मक प्रोग्रामिंग भाषाएँ. Wokingham, England: Addison-Wesley. p. 126. ISBN 0-201-18483-4.
  13. ↑ विल्सन और क्लार्क, ऑप. सिट., पी. 52
  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)
  17. ↑ 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.
  18. ↑ "वीएसआई ओपनवीएमएस लिंकर यूटिलिटी मैनुअल" (PDF). VSI. August 2019. Retrieved 2021-01-31.
  19. ↑ "एमटीएस का इतिहास". Information Technology Digest. 5 (5).
  20. ↑ IBM Corporation (2011). सहेजे गए खंड योजना और प्रशासन (PDF). Retrieved Jan 29, 2022.
  21. ↑ "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.
  22. ↑ "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.
  23. ↑ 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.

अग्रिम पठन

Retrieved from ‘https://www.vigyanwiki.in/index.php?title=लाइब्रेरी_(कंप्यूटिंग)&oldid=227073’