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

From Vigyanwiki
Revision as of 14:28, 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 पीई के अनुरूप प्रारूप हैं।

इतिहास

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

तकनीकी विवरण

लेआउट

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

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


आयात तालिका

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


स्थानांतरण

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

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

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

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

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

पीई प्रारूप का उपयोग रिएक्टोस द्वारा भी किया जाता है, क्योंकि रिएक्टोस का उद्देश्य बाइनरी-कोड संगतता है। विंडोज के साथ बाइनरी-संगत। यह स्काईओएस और बीओएस आर3 सहित कई अन्य ऑपरेटिंग सिस्टमों द्वारा भी ऐतिहासिक रूप से उपयोग किया गया है। हालाँकि, SkyOS और BeOS दोनों अंततः निष्पादन योग्य और लिंक करने योग्य प्रारूप में चले गए।[citation needed] जैसा कि मोनो (सॉफ्टवेयर) माइक्रोसॉफ्ट .NET फ्रेमवर्क के साथ बाइनरी संगत होने का इरादा रखता है, यह माइक्रोसॉफ्ट कार्यान्वयन के समान पीई प्रारूप का उपयोग करता है। वही Microsoft के अपने क्रॉस-प्लेटफ़ॉर्म .NET Core के लिए जाता है।

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

IA-32 और x86-64 Linux पर कोई भी लोड लाइब्रेरी के तहत Microsoft Windows की डायनेमिक-लिंक लाइब्रेरी चला सकता है।[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=68538’