पोर्टेबल निष्पादन (एक्सक्यूटेबल)

From Vigyanwiki
Revision as of 18:35, 25 December 2022 by alpha>Rani Kumari (→‎स्थानांतरण)
Not to be confused with Portable application or Windows Preinstallation Environment.

पोर्टेबल निष्पादन (पीई) प्रारूप निष्पादनयोग्य, वस्तु संकेत, डीएलएल और अन्य के लिए फ़ाइल प्रारूप है। जो विंडोज़ ऑपरेटिंग सिस्टम के 32-बिट और 64-बिट संस्करणों में उपयोग किए जाने वाले है।[1] पीई प्रारूप डेटा संरचना है जो लिपटे हुए निष्पादन योग्य कोड को प्रबंधित करने के लिए विंडोज ओएस लोडर के लिए आवश्यक जानकारी को समाहित करता है। इसमें लिंकिंग, एपीआई निर्यात और आयात टेबल, संसाधन प्रबंधन डेटा और थ्रेड-लोकल स्टोरेज (टीएलएस) डेटा के लिए डायनेमिक लाइब्रेरी संदर्भ शामिल हैं। विंडोज एनटी ऑपरेटिंग प्रणाली पर, EXE, DLL, SYS (डिवाइस ड्राइवर), MUI और अन्य फ़ाइल प्रकारों के लिए पीई प्रारूप का उपयोग किया जाता है। एकीकृत एक्सटेंसिबल फ़र्मवेयर इंटरफ़ेस (यूईएफआई) विनिर्देश बताता है कि पीई, ईएफआई वातावरण में मानक निष्पादन योग्य प्रारूप है।Cite error: Closing </ref> missing for <ref> tag पीई के अनुरूप प्रारूप हैं।

इतिहास

माइक्रोसॉफ्ट ने विंडोज़ एनटी 3.1 ऑपरेटिंग प्रणाली की शुरुआत के साथ 16-बिट एनई निष्पादन योग्य स्वरूपों से पीई प्रारूप में विस्थापित किया। विंडोज के सभी बाद के संस्करण, विंडोज 95/98/ME और विंडोज 3.1x में शामिल Win32s सहित, फ़ाइल संरचना का समर्थन करते हैं। प्रारूप ने डॉस-आधारित और एनटी प्रणाली के बीच की दरार को पाटने के लिए सीमित विरासत समर्थन को बरकरार रखा है। उदाहरण के लिए, पीई/सीओएफएफ हेडर में अभी भी डॉस निष्पादन योग्य शामिल है, जो अनुपस्थिति रूप से डॉस स्टब है जो संदेश प्रदर्शित करता है जैसे "यह प्रोग्राम डॉस मोड में नहीं चलाया जा सकता" (या इसी तरह), हालांकि यह पूर्ण रूप से डॉस कार्यक्रम का संस्करण हो सकता है। ( बाद का उल्लेखनीय मामला विंडोज 98 एसई इंस्टॉलर है)।[2] यह वसा बाइनरी का रूप है। पीई भी बदलते विंडोज प्लेटफॉर्म की सेवा जारी रखता है। कुछ एक्सटेंशन में .NET पीई प्रारूप (नीचे देखें), 64-बिट एड्रेस स्पेस सपोर्ट वाला संस्करण है जिसे पीई32+ कहा जाता है,[3] और विंडोज सीई के लिए विनिर्देश शामिल है।

तकनीकी विवरण

लेआउट

एक पोर्टेबल निष्पादन योग्य 32 बिट की संरचना

पीई फाइल में कई हेडर और सेक्शन होते हैं जो गतिशील लिंकर को बताते हैं कि फाइल को मेमोरी में कैसे मैप किया जाए। निष्पादन योग्य छवि में कई अलग-अलग क्षेत्र होते हैं, जिनमें से प्रत्येक को अलग-अलग मेमोरी सुरक्षा की आवश्यकता होती है, इसलिए प्रत्येक अनुभाग की शुरुआत पृष्ठ सीमा से संरेखित होनी चाहिए।[4] उदाहरण के लिए, प्रायः .text अनुभाग (जिसमें प्रोग्राम कोड होता है) को निष्पादन/केवल-पढ़ने के लिए मैप किया जाता है, और .data अनुभाग (वैश्विक चर धारण करने वाले) को निष्पादन/पढ़ने के लिए लिखने के रूप में मानचित्र किया जाता है। हालाँकि, स्थान बर्बाद करने से बचने के लिए, विभिन्न अनुभागों को डिस्क पर पृष्ठ संरेखित नहीं किया जाता है। डायनेमिक लिंकर के काम का हिस्सा प्रत्येक अनुभाग को व्यक्तिगत रूप से मेमोरी में मानचित्र करना और हेडर में मिले निर्देशों के अनुसार परिणामी क्षेत्रों को सही अनुमति देना है।[5]

आयात तालिका

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


स्थानांतरण

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

.नेट, मेटाडेटा, और पीई प्रारूप

.नेट निष्पादन योग्य में, पीई कोड अनुभाग में एक स्टब होता है जो सीएलआर वर्चुअल मशीन स्टार्टअप प्रविष्टि को आमंत्रित करता है, _CorExeMain या _CorDllMain में mscoree.dll, बिल्कुल वैसा ही जैसा कि यह मूल दृश्य निष्पादनयोग्य में था। वर्चुअल मशीन तब मौजूद .नेट मेटाडेटा का उपयोग करती है, जिसका मूल, IMAGE_COR20_HEADER (जिसे "सीएलआर हेडर" भी कहा जाता है) द्वारा इंगित किया जाता है IMAGE_DIRECTORY_ENTRY_COMHEADER[6] पीई शीर्षलेख की डेटा निर्देशिका में प्रविष्टि। IMAGE_COR20_HEADER PE के वैकल्पिक हेडर से बहुत मिलता-जुलता है, अनिवार्य रूप से सीएलआर लोडर के लिए अपनी भूमिका निभा रहा है।[7]

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

अन्य ऑपरेटिंग सिस्टम पर प्रयोग करें

पीई प्रारूप का उपयोग प्रतिक्रिया द्वारा भी किया जाता है, क्योंकि प्रतिक्रिया का उद्देश्य विंडोज के साथ बाइनरी-संगत होना है। यह स्काईओएस और बीओएस आर3 सहित कई अन्य ऑपरेटिंग प्रणाली द्वारा भी ऐतिहासिक रूप से उपयोग किया गया है। हालाँकि, स्काईओएस और बीओएस दोनों अंततः निष्पादन योगिनी और लिंक करने योग्य प्रारूप में चले गए।[citation needed]

जैसा कि मोनो विकास मंच माइक्रोसॉफ्ट .NET फ्रेमवर्क के साथ बाइनरी संगत होने का इरादा रखता है, यह माइक्रोसॉफ्ट कार्यान्वयन के समान पीई प्रारूप का उपयोग करता है। वही माइक्रोसॉफ्ट के अपने क्रॉस-प्लेटफ़ॉर्म .NET Core के लिए जाता है।

x86(-64) पर यूनिक्स-जैसे ऑपरेटिंग सिस्टम, विंडोज बायनेरिज़ (पीई प्रारूप में) को वाइन के साथ निष्पादित किया जा सकता है। HX DOS एक्सटेंडर देशी DOS 32-बिट बायनेरिज़ के लिए पीई प्रारूप का भी उपयोग करता है, साथ ही यह कुछ हद तक, DOS में मौजूदा विंडोज़ बायनेरिज़ को निष्पादित कर सकता है, इस प्रकार DOS के लिए वाइन के समकक्ष कार्य करता है।

IA-32 और x86-64 लिनक्स पर कोई भी लोड पुस्तकालयों के अंतर्गत माइक्रोसॉफ्ट विंडोज़ की डीएलएल चला सकता है।[8]

मैक ओएस एक्स 10.5 में पीई फाइलों को लोड और पार्स करने की क्षमता है, लेकिन विंडोज के साथ बाइनरी संगत नहीं है।[9]

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

यह भी देखें

संदर्भ

  1. ↑ "पोर्टेबल निष्पादन योग्य (पीई) - परिभाषा - ट्रेंड माइक्रो इन". www.trendmicro.com. Retrieved 2022-11-10.
  2. ↑ E.g. Microsoft's linker has /STUB switch to attach one
  3. ↑ In order to know whether the executable code is 32- or 64-bit, check the Machine field in the IMAGE_FILE_HEADER. (PE trick explained: Telling 32 and 64 bit apart with naked eye by Karsten Hahn)
    To see if addresses in the executable are 32- or 64-bit, check the Magic field in the IMAGE_OPTIONAL_HEADER. 10B16 indicates a PE32 file, whereas 20B16 indicates a PE32+ file. (PE Format at Microsoft.com)
  4. ↑ "पोर्टेबल निष्पादन योग्य फ़ाइल ऊपर से नीचे तक". Retrieved 2017-10-21.
  5. ↑ 5.0 5.1 "पीई के अंदर झाँकना: Win32 पोर्टेबल निष्पादन योग्य फ़ाइल का एक दौरा". Retrieved 2017-10-21.
  6. ↑ The entry was previously used for COM+ metadata in COM+ applications, hence the name
  7. ↑ Cite error: Invalid <ref> tag; no text was provided for refs named PE Format (Windows)
  8. ↑ "गिटहब - टैविसो/लोड लाइब्रेरी: विंडोज डायनेमिक लिंक लाइब्रेरी को लिनक्स में पोर्ट करना". GitHub.
  9. ↑ Chartier, David (2007-11-30). "पर्दाफाश: सबूत है कि मैक ओएस एक्स जल्द ही विंडोज ऐप चला सकता है". Ars Technica. Retrieved 2007-12-03. ... स्टीवन एडवर्ड्स ने इस खोज का वर्णन किया है कि तेंदुए में स्पष्ट रूप से पोर्टेबल एक्जीक्यूटेबल्स के लिए एक गैर-दस्तावेजी लोडर शामिल है, एक प्रकार की फ़ाइल जो विंडोज के 32-बिट और 64-बिट संस्करणों में उपयोग की जाती है। चारों ओर अधिक पोकिंग से पता चला कि विंडोज़ बाइनरी लोड करने का प्रयास करते समय तेंदुए का अपना लोडर विंडोज डीएलएल फाइलों को खोजने का प्रयास करता है। {{cite web}}: no-break space character in |quote= at position 4 (help)


इस पेज में लापता आंतरिक लिंक की सूची

  • फाइल का प्रारूप
  • सुपर एच
  • मच-ओ
  • मैक ओएस
  • नया निष्पादन योग्य
  • मोटा बाइनरी
  • साझा पुस्तकालय
  • आधार पता
  • UNIX- जैसे
  • एचएक्स टू एक्सटेंडर
  • अर (यूनिक्स)

बाहरी संबंध

Retrieved from ‘https://www.vigyanwiki.in/index.php?title=पोर्टेबल_निष्पादन_(एक्सक्यूटेबल)&oldid=68542’