विंडोज़ अभी भी डीएलएल का उपयोग करते हैं और मैक प्रोग्राम डीएलएल का उपयोग नहीं करते हैं। क्या तकनीक का उपयोग करने के फायदे या नुकसान हैं?डीएलएल का उपयोग करने के पेशेवर और विपक्ष क्या हैं?
यदि किसी प्रोग्राम इंस्टॉलेशन में सभी डीएलएल शामिल हैं तो इसकी आवश्यकता है ताकि यह 100% अच्छी तरह से काम करे, क्या यह सभी पुस्तकालयों को स्थिर रूप से जोड़ने जैसा ही होगा?
यूनिक्स के अन्य स्वादों की तरह मैकोज़ एक्स, साझा पुस्तकालयों का उपयोग करें, जो कि डीएलएल का एक और रूप है।
और हाँ दोनों फायदेमंद हैं क्योंकि डीएलएल या साझा लाइब्रेरी कोड को कई प्रक्रियाओं के बीच साझा किया जा सकता है। यह ओएस द्वारा डीएलएल या साझा लाइब्रेरी को लोड करने और इसे उपयोग करने वाली प्रक्रियाओं के वर्चुअल एड्रेस स्पेस में मैप करके करता है।
मैक प्रोग्राम आमतौर पर कैसे आते हैं इतना बड़ा, 27 एमबी या 106 एमबी की तरह? –
@ जियान लिन - क्या तुलना में बड़ा? –
@ कई बार रुस करें, विंडोज एक्सई बहुत छोटा है, जैसे 5 एमबी या 16 एमबी। –
विंडोज़ पर, आपको गतिशील रूप से लोड की गई लाइब्रेरी का उपयोग करना होगा क्योंकि जीडीआई और यूजर लाइब्रेरी केवल डीएलएल के रूप में उपलब्ध हैं। आप उनमें से किसी एक को प्रोटोकॉल का उपयोग करके उनसे लिंक नहीं कर सकते हैं या उनसे बात नहीं कर सकते हैं जिनमें गतिशील लोडिंग शामिल नहीं है।
अन्य ओएस पर, आप जटिल ऐप्स के लिए किसी भी तरह गतिशील लोडिंग का उपयोग करना चाहते हैं, अन्यथा आपकी बाइनरी किसी भी अच्छे कारण के लिए फूट नहीं जाएगी, और यह संभवतः आपके ऐप लंबे समय तक सिस्टम के साथ असंगत होगा (हालांकि, संक्षेप में स्थिर लिंकिंग कुछ हद तक आपको लाइब्रेरीज़ में छोटे ब्रेकिंग बदलावों से ढाल सकता है)। और आप उन ओएसई पर स्वामित्व पुस्तकालयों में लिंक नहीं कर सकते हैं जो उन पर भरोसा करते हैं।
विंडोज़ अभी भी डीएलएल और मैक प्रोग्राम का उपयोग डीएलएल का उपयोग नहीं करते हैं। क्या वे तकनीक का उपयोग कर के लाभ या नुकसान हैं?
किसी भी तरह का मॉड्यूलरलाइजेशन अच्छा है क्योंकि यह सॉफ़्टवेयर को आसान बनाता है, यानी यदि प्रोग्राम में कोई बग ठीक हो गया है तो आपको पूरे प्रोग्राम बाइनरी को अपडेट करने की आवश्यकता नहीं है। अगर कुछ डीएल में बग दिखाई देता है, तो केवल डीएल को अद्यतन करने की आवश्यकता है।
आईएमओ के साथ एकमात्र नकारात्मक पक्ष यह है कि आप कार्यक्रम के विकास में एक और जटिलता पेश करते हैं, उदाहरण के लिए अगर एक dll एक सी या C++ DLL, अलग बुला सम्मेलनों आदि
एक प्रोग्राम स्थापना शामिल है, तो है सब DLL यह की आवश्यकता है, यह एक ही रूप में स्थिर जोड़ने सभी पुस्तकालयों हो जाएगा?
अधिक या कम हाँ। इस पर निर्भर करता है कि क्या आप एक डीएलएल में फ़ंक्शंस कॉल कर रहे हैं, जिसके साथ आप स्थिर लिंकेज मानते हैं। डीएलएल भी एक "फ्री स्टैंडिंग" गतिशील लाइब्रेरी हो सकता है, जिसे आप केवल लोड लाइब्रेरी() और GetProcAddress() इत्यादि के माध्यम से एक्सेस कर सकते हैं
साझा लाइब्रेरीज़ का एक बड़ा फायदा (विंडोज़ पर डीएलएल या यूनिक्स पर एसएसएल) यह है कि आप लाइब्रेरी और उसके उपभोक्ताओं को अलग-अलग पुनर्निर्माण कर सकते हैं जबकि स्थिर पुस्तकालयों के साथ आपको लाइब्रेरी का पुनर्निर्माण करना होगा और फिर उन सभी उपभोक्ताओं को फिर से जोड़ना चाहिए जो यूनिक्स सिस्टम पर बहुत धीमी हैं और विंडोज़ पर बहुत तेज नहीं हैं।
मैकोज़ सॉफ्टवेयर "डीएलएस" का भी उपयोग करता है, इन्हें अलग-अलग नामांकित (साझा पुस्तकालय) नाम दिया जाता है।
डीएल की समझ में आता है यदि आपके पास कोड है जिसे आप अपने सॉफ़्टवेयर के विभिन्न घटकों में पुन: उपयोग करना चाहते हैं। अधिकतर यह बड़ी सॉफ्टवेयर परियोजनाओं में समझ में आता है।
स्थिर पुन: उपयोग करने के लिए कोई आवश्यकता नहीं होने पर स्थिर लिंकिंग छोटे एकल घटक अनुप्रयोगों के लिए समझ में आता है। यह वितरण को सरल बनाता है क्योंकि आपके घटक की बाहरी निर्भरता नहीं है।
हाँ, यह text देखें:
गतिशील जोड़ने निम्नलिखित लाभ हैं:
स्मृति बचाता है और अदला-बदली कम करता है। कई प्रक्रिया एक ही डीएलएल का उपयोग कर सकते हैं, मेमोरी में डीएलएल की एक प्रतिलिपि साझा करना। इसके विपरीत, विंडोज लाइब्रेरी कोड की प्रतिलिपि में प्रत्येक एप्लिकेशन के लिए को एक स्थिर लिंक लाइब्रेरी के साथ लोड करना होगा।
डिस्क स्थान बचाता है। कई अनुप्रयोग डिस्क पर DLL की एक प्रतिलिपि साझा कर सकते हैं। इसके विपरीत, एक स्थिर लिंक लाइब्रेरी के साथ निर्मित प्रत्येक एप्लिकेशन लाइब्रेरी कोड निष्पादन योग्य छवि में अलग प्रतिलिपि के रूप में लिंक किया गया है।
डीएलएल के लिए उन्नयन आसान है। जब एक DLL में फ़ंक्शंस में परिवर्तन होता है, तो का उपयोग करने वाले अनुप्रयोगों को पुन: संकलित करने की आवश्यकता नहीं होती है या फ़ंक्शन तर्क और वापसी मान परिवर्तन के रूप में तब तक रिंकिंक करने की आवश्यकता नहीं है। इसके विपरीत, सांख्यिकीय रूप से जुड़े ऑब्जेक्ट कोड की आवश्यकता है कि एप्लिकेशन को रिंकिंक किया जाए जब फ़ंक्शन बदल जाएंगे।
बाजार के समर्थन के बाद प्रदान करता है। उदाहरण के लिए, डिस्प्ले ड्राइवर डीएलएल को पर संशोधित किया जा सकता है जो उस प्रदर्शन का समर्थन करता है जो उपलब्ध नहीं था जब अनुप्रयोग भेजा गया था।
बहुभाषी प्रोग्राम का समर्थन करता है। में लिखे गए प्रोग्राम तक उसी DLL फ़ंक्शन को कॉल कर सकते हैं, प्रोग्राम फ़ंक्शन के कॉलिंग कन्वेंशन का पालन करते हैं। कार्यक्रमों और DLL समारोह निम्न तरीकों में संगत होना चाहिए: जिसमें आदेश समारोह उम्मीद करने के लिए अपने तर्क, ढेर पर धकेल दिया समारोह या आवेदन ढेर को साफ करने के लिए जिम्मेदार है या नहीं, और क्या कोई तर्क रजिस्टरों में पारित किया गया है।
एमएफसी लाइब्रेरी कक्षाओं का विस्तार करने के लिए एक तंत्र प्रदान करता है। आप मौजूदा एमएफसी कक्षाओं से कक्षाएं प्राप्त कर सकते हैं और उन्हें एमएफसी एक्सटेंशन डीएलएल में एमएफसी अनुप्रयोगों के उपयोग के लिए रख सकते हैं।
अंतर्राष्ट्रीय संस्करणों के निर्माण का निर्माण करता है। एक डीएलएल में संसाधनों को रखकर, एप्लिकेशन के अंतर्राष्ट्रीय संस्करण बनाने के लिए यह बहुत आसान है । आप अलग-अलग संसाधन DLL में अपने एप्लिकेशन के प्रत्येक भाषा संस्करण के लिए स्ट्रिंग्स डाल सकते हैं और अलग-अलग भाषा संस्करण उपयुक्त संसाधन लोड कर सकते हैं।
डीएलएल का उपयोग करने के लिए एक संभावित नुकसान यह है कि एप्लिकेशन स्वयं निहित नहीं है; यह एक अलग डीएलएल मॉड्यूल के अस्तित्व पर निर्भर करता है।
इन कारणों में से कुछ कारणों को समझ में आया था जब डिस्क स्थान महंगा था। कुछ आजकल करते हैं। जब भी संभव हो मैं व्यक्तिगत रूप से अपने ऐप्स को लिंक करना पसंद करता हूं। –
लेकिन बड़े उद्यम प्रणालियों में अलग मॉड्यूल रखने के लिए अधिक कुशल है, आपको सहमत होना चाहिए? – lsalamon
क्या के मामले में अधिक कुशल? –
स्मृति/डिस्क स्थान उपयोग इसके अलावा, साझा पुस्तकालयों का उपयोग करने का एक और महत्वपूर्ण लाभ यह है कि पुस्तकालय के लिए अपडेट हो जाता है प्रणाली है जो लाइब्रेरी का उपयोग पर सभी कार्यक्रमों द्वारा उठाया जाएगा।
जब InfoZIP ज़िप पुस्तकालयों में सुरक्षा भेद्यता थी, तो DLL/.so के अपडेट ने स्वचालित रूप से सभी सॉफ़्टवेयर को सुरक्षित बना दिया जो इनका उपयोग करते थे। सॉफ़्टवेयर जो स्थिर रूप से जुड़ा हुआ था, को फिर से सम्मिलित किया जाना था।
यह आमतौर पर एक नुकसान के रूप में देखा जाता है - कभी "डीएलएल नरक" के बारे में सुना? –
हां, लेकिन मुख्य रूप से एमएस विंडोज के संबंध में। जहां तक मैं कह सकता हूं, ऐसा इसलिए हुआ क्योंकि अधिकांश विंडोज़ (बीएसडी सिस्टम) जैसे एमएस विंडोज (का उपयोग) में उचित केंद्रीय पैकेज/सॉफ्टवेयर मैनेजर की कमी है। पैकेज प्रबंधक को ट्रैक करने वाले प्रतिबाधा के बिना, डीएलएल नरक वास्तव में एक समस्या है। लेकिन मुझे विश्वास था कि आधुनिक विंडोज संस्करणों ने इसे संबोधित किया था। – sleske
यूप - अब इसे एसएलएसएस (साइड बाय साइड) डीएलएल की स्थापना द्वारा संभाला जाता है। अब कई प्रतियां हो सकती हैं, इसलिए क्लासिक डीएलएल समस्या (पुराने संस्करण द्वारा डीएलएल को ओवरराइट करना) अब नहीं होना चाहिए। – MSalters
विंडोज़ अभी भी डीएलएल का उपयोग करते हैं और मैक प्रोग्राम डीएलएल का उपयोग नहीं करते हैं। क्या वे तकनीक का उपयोग करने के लाभ या नुकसान हैं?
दोनों साझा पुस्तकालयों का उपयोग करते हैं, वे बस एक अलग नाम का उपयोग करते हैं।
यदि किसी प्रोग्राम इंस्टॉलेशन में सभी डीएलएल शामिल हैं तो इसकी आवश्यकता है ताकि यह 100% अच्छी तरह से काम करे, क्या यह सभी पुस्तकालयों को स्थिर रूप से जोड़ने जैसा ही होगा?
कुछ हद तक। जब आप किसी प्रोग्राम में लाइब्रेरी को स्थिर रूप से लिंक करते हैं, तो आपको एक एकल, बहुत बड़ी फ़ाइल मिल जाएगी, डीएलएल के साथ, आपके पास कई फाइलें होंगी।
स्थैतिक रूप से लिंक की गई फ़ाइल को "साझा लाइब्रेरीज़ को हल करें" चरण की आवश्यकता नहीं होगी (जो प्रोग्राम लोड होने पर होता है)। बहुत समय पहले, एक स्थिर कार्यक्रम लोड करना मतलब था कि पूरा कार्यक्रम पहली बार राम में लोड किया गया था और फिर, "साझा पुस्तकालयों को हल करें" चरण हुआ। आज, केवल कार्यक्रम के कुछ हिस्सों, जिन्हें वास्तव में निष्पादित किया जाता है, मांग पर लोड होते हैं। तो एक स्थिर कार्यक्रम के साथ, आपको डीएलएल को हल करने की आवश्यकता नहीं है। डीएलएल के साथ, आपको उन्हें एक साथ लोड करने की आवश्यकता नहीं है। तो प्रदर्शन के अनुसार, वे बराबर होना चाहिए।
जो "डीएलएल नरक" छोड़ देता है। विंडोज़ पर कई प्रोग्राम उन्हें आवश्यक सभी डीएलएल लाते हैं और वे उन्हें विंडोज निर्देशिका में लिखते हैं। शुद्ध प्रभाव यह है कि अंतिम स्थापित प्रोग्राम काम करते हैं और बाकी सब कुछ टूटा जा सकता है। लेकिन एक सरल कामकाज है: डीएलएल को उसी निर्देशिका में EXE के रूप में स्थापित करें। विंडोज़ पहले और फिर विभिन्न विंडोज पथों को वर्तमान निर्देशिका की खोज करेगा। इस तरह, आप डिस्क की थोड़ी सी जगह बर्बाद कर देंगे लेकिन आपका प्रोग्राम काम करेगा और, सबसे महत्वपूर्ण बात यह है कि आप कुछ और नहीं तोड़ेंगे।
कोई यह तर्क दे सकता है कि आपको Windows निर्देशिका में पहले से मौजूद (उसी संस्करण के साथ) DLL इंस्टॉल नहीं करना चाहिए, लेकिन फिर, आप फिर से कुछ खराब ऐप के लिए कमजोर हैं जो आपके द्वारा तोड़ने वाले किसी संस्करण के साथ आवश्यक संस्करण को ओवरराइट करता है गर्दन। दोष यह है कि आपको अपने ऐप के लिए सुरक्षा सुधारों को वितरित करना होगा; आप अपने कोड को सुरक्षित करने के लिए विंडोज अपडेट या इसी तरह की चीजों पर भरोसा नहीं कर सकते हैं। यह एक तंग जगह है; क्रैकर्स सुरक्षा मुद्दों से बहुत पैसा कमा रहे हैं और जब कोई व्यक्ति अपने बैंकिंग डेटा चुराता है तो लोग आपको पसंद नहीं करेंगे क्योंकि आपने जल्द ही सुरक्षा सुधार जारी नहीं किए हैं।
यदि आप कई लोगों के लिए अपने आवेदन का समर्थन करने की योजना बनाते हैं, तो 20 साल, प्रोग्राम निर्देशिका में सभी डीएलएल स्थापित करना आपके लिए है। यदि नहीं, तो कोड लिखें जो जांचता है कि सभी डीएलएल के उपयुक्त संस्करण स्थापित हैं और उपयोगकर्ता को इसके बारे में बताएं, इसलिए उन्हें पता है कि आपका ऐप अचानक क्यों दुर्घटनाग्रस्त हो जाता है।
मेरे दृष्टिकोण से एक साझा घटक में कुछ फायदे हैं जिन्हें कभी-कभी नुकसान के रूप में महसूस किया जाता है।
तो मुझे लगता है कि साझा घटक का उपयोग सॉफ्टवेयर को बेहतर संगठित करने में मदद करेगा।
संभावित डुप्लिकेट [गतिशील बनाम स्थैतिक पुस्तकालयों का उपयोग कब करें] (http://stackoverflow.com/questions/140061/when-to-use- गतिशील- vs-static- पुस्तकालय) –