पोर्टेबल निष्पादन (एक्सक्यूटेबल)
पोर्टेबल निष्पादन योग्य (पीई) प्रारूप निष्पादनयोग्य, वस्तु कोड, डीएलएल और विंडोज़ ऑपरेटिंग सिस्टम के 32-बिट और 64-बिट संस्करणों में उपयोग किए जाने वाले अन्य के लिए एक फ़ाइल प्रारूप है।[1] जो पीई प्रारूप डेटा संरचना है लिपटे हुए निष्पादन योग्य कोड को प्रबंधित करने के लिए विंडोज ओएस लोडर के लिए आवश्यक जानकारी को समाहित करता है। इसमें लिंकिंग, एपीआई निर्यात और आयात टेबल, संसाधन प्रबंधन डेटा और थ्रेड-लोकल स्टोरेज (टीएलएस) डेटा के लिए गत्यात्मक पुस्तकालय संदर्भ शामिल हैं। एनटी ऑपरेटिंग सिस्टम पर, EXE, DLL, SYS (डिवाइस ड्राइवर), MUI और अन्य फ़ाइल प्रकारों के लिए पीई प्रारूप का उपयोग किया जाता है। एकीकृत विस्तार योग्य फ़र्मवेयर इंटरफ़ेस (UEFI) विनिर्देश बताता है कि पीई, EFI वातावरण में सामान्य निष्पादन योग्य प्रारूप है।Cite error: Closing </ref> missing for <ref> tag
विंडोज एनटी ऑपरेटिंग सिस्टम पर, पीई वर्तमान में x86-32, x86-64 (एएमडी64/इंटेल 64), आईए-64, एआरएम और एआरएम64 निर्देश सेट वास्तुकला (ISAs) का समर्थन करता है। विंडोज 2000 से पहले, विंडोज एनटी (और इस प्रकार पीई) ने एमआईपीएस, अल्फा और पावरपीसी आईएसए का समर्थन किया था। क्योंकि पीई का उपयोग विंडोज सीई पर किया जाता है, यह MIPS, ARM (अंगूठे सहित), और सुपरएच ISAs के रूप में कई प्रकारों का समर्थन करना जारी रखता है।
पीई के अनुरूप प्रारूप ईएलएफ (लिनक्स और यूनिक्स के अधिकांश अन्य संस्करणों में प्रयुक्त) और मैक-ओ (मैकओएस और आईओएस में प्रयुक्त) हैं।
इतिहास
माइक्रोसॉफ्ट ने विंडोज़ एनटी 3.1 ऑपरेटिंग सिस्टम की शुरुआत के साथ 16-बिट एनई निष्पादन योग्य स्वरूपों से पीई प्रारूप में विस्थापित किया। विंडोज के सभी बाद के संस्करण, विंडोज 95/98/एमइ और विंडोज 3.1x में शामिल Win32s सहित, फ़ाइल संरचना का समर्थन करते हैं। प्रारूप ने डॉस-आधारित और एनटी प्रणाली के बीच की दरार को जोड़ने के लिए सीमित विरासत समर्थन को बरकरार रखा है। उदाहरण के लिए, पीई/सीओएफएफ हेडर में अभी भी डॉस निष्पादन योग्य शामिल है, जो अनुपस्थिति रूप से डॉस स्टब है जो संदेश प्रदर्शित करता है जैसे "यह प्रोग्राम डॉस मोड में नहीं चलाया जा सकता" (या इसी तरह), हालांकि यह पूर्ण रूप से डॉस कार्यक्रम का संपादन हो सकता है। ( बाद का उल्लेखनीय मामला विंडोज 98 एसई इंस्टॉलर है)।[2] यह वसा बाइनरी का रूप है। पीई भी बदलते विंडोज प्लेटफॉर्म की सेवा जारी रखता है। कुछ एक्सटेंशन में .NET पीई प्रारूप (नीचे देखें), 64-बिट एड्रेस स्पेस सपोर्ट वाला संस्करण है जिसे पीई32+ कहा जाता है,[3] और विंडोज सीई के लिए विनिर्देश शामिल है।
तकनीकी विवरण
लेआउट
पीई फाइल में कई हेडर और सेक्शन होते हैं जो गतिशील संयोजक को बताते हैं कि फाइल को मेमोरी में कैसे मैप किया जाए। निष्पादन योग्य छवि में कई अलग-अलग क्षेत्र होते हैं, जिनमें से प्रत्येक को अलग-अलग मेमोरी सुरक्षा की आवश्यकता होती है, इसलिए प्रत्येक अनुभाग की शुरुआत पृष्ठ सीमा से संरेखित होनी चाहिए।[4] उदाहरण के लिए, प्रायः .text अनुभाग (जिसमें प्रोग्राम कोड होता है) को निष्पादन/केवल-पढ़ने के लिए मैप किया जाता है, और .डेटा अनुभाग (वैश्विक चर धारण करने वाले) को निष्पादन/पढ़ने के लिए लिखने के रूप में मानचित्र किया जाता है। हालाँकि, स्थान बर्बाद करने से बचने के लिए, विभिन्न अनुभागों को डिस्क पर पृष्ठ संरेखित नहीं किया जाता है। डायनेमिक लिंकर के काम का हिस्सा प्रत्येक अनुभाग को व्यक्तिगत रूप से मेमोरी में मानचित्र करना और हेडर में मिले निर्देशों के अनुसार परिणामी क्षेत्रों को सही अनुमति देना है।[5]
आयात तालिका
नोट का एक भाग आयात पता तालिका (आईएटी) है, जिसका उपयोग लुकअप टेबल के रूप में किया जाता है जब एप्लिकेशन किसी भिन्न मॉड्यूल में फ़ंक्शन को कॉल कर रहा होता है। यह क्रमवार द्वारा आयात और नाम से आयात दोनों के रूप में हो सकता है। क्योंकि संकलित प्रोग्राम पुस्तकालयों की मेमोरी स्थिति को नहीं जान सकता है, जिस पर वह निर्भर करता है, जब भी कोई एपीआई कॉल किया जाता है तो तिरछी छलांग की आवश्यकता होती है। जैसा कि गतिशील श्रृंखलक मॉड्यूल लोड करता है और उन्हें एक साथ जोड़ता है, यह आईएटी स्थान में वास्तविक पते लिखता है, ताकि वे संबंधित पुस्तकालयों फ़ंक्शंस के मेमोरी स्थानों को इंगित करें। हालांकि यह इंट्रा-मॉड्यूल कॉल की लागत पर अतिरिक्त उछाल जोड़ता है जिसके परिणामस्वरूप प्रदर्शन जुर्माना होता है, यह महत्वपूर्ण लाभ प्रदान करता है लोडर द्वारा लिखने पर नकल बदलने की आवश्यकता वाले मेमोरी पेजों की संख्या कम हो जाती है, मेमोरी और डिस्कआई/ओ समय की बचत होती है। यदि संकलक समय से पहले जानता है कि एक कॉल इंटर-मॉड्यूल (dllimport विशेषता के माध्यम से) होगी तो यह अधिक अनुकूलित कोड का उत्पादन कर सकता है जिसके परिणामस्वरूप अप्रत्यक्ष कॉल ऑपकोड होता है।[5]
स्थानांतरण
पीई फाइलों में प्रायः स्थिति-स्वतंत्र कोड नहीं होता है। इसके जगह में उन्हें पसंदीदा आधार पते पर संकलित किया जाता है, और संकलक/श्रृंखलक द्वारा उत्सर्जित सभी पते समय से पहले तय किए जाते हैं। यदि पीई फ़ाइल को उसके पसंदीदा पते पर लोड नहीं किया जा सकता है (क्योंकि यह पहले से ही किसी और द्वारा लिया गया है), तो ऑपरेटिंग सिस्टम इसे रीबेस करेगा। इसमें प्रत्येक निरपेक्ष पते की पुनर्गणना करना और नए मानों का उपयोग करने के लिए कोड को संशोधित करना शामिल है। लोडर पसंदीदा और वास्तविक लोड पतों की तुलना करके और डेल्टा एन्कोडिंग मान की गणना करके ऐसा करता है। इसके बाद मेमोरी स्थान के नए पते के साथ आने के लिए इसे पसंदीदा पते में जोड़ा जाता है। बेस स्थानांतरण को सूची में संग्रहीत किया जाता है और आवश्यकतानुसार मौजूदा मेमोरी लोकेशन में जोड़ा जाता है। परिणामी कोड अब प्रक्रिया के लिए निजी है और अब साझा करने योग्य नहीं है, इसलिए इस परिदृश्य में डीएलएल के कई मेमोरी बचत लाभ खो गए हैं। यह मॉड्यूल के लोडिंग को भी काफी धीमा कर देता है। इस कारण जहां भी संभव हो रिबेसिंग से बचा जाना चाहिए, और माइक्रोसॉफ्ट द्वारा भेजे गए डीएलएल के आधार पते पूर्व-गणना किए गए हैं ताकि अतिव्यापन न हो। रिबेस नहीं होने की स्थिति में पीई को बहुत कुशल कोड का लाभ मिलता है, लेकिन रीबेसिंग की उपस्थिति में मेमोरी उपयोग हिट महंगा हो सकता है। यह निष्पादन योग्य और लिंक करने योग्य प्रारूप के विपरीत है जो पूरी तरह से स्थिति-स्वतंत्र कोड और वैश्विक ऑफसेट तालिका का उपयोग करता है, जो कम मेमोरी उपयोग के पक्ष में निष्पादन समय को बंद कर देता है।
.NET, मेटाडेटा, और पीई प्रारूप
.NET निष्पादन योग्य में, पीई कोड अनुभाग में एक स्टब होता है जो सीएलआर वर्चुअल मशीन स्टार्टअप प्रविष्टि को आमंत्रित करता है, _CorExeMain या _CorDllMain में mscoree.dll, बिल्कुल वैसा ही जैसा कि यह मूल दृश्य निष्पादनयोग्य में था। वर्चुअल मशीन तब मौजूद .NET मेटाडेटा का उपयोग करती है, जिसका मूल, IMAGE_COR20_HEADER (जिसे "सीएलआर हेडर" भी कहा जाता है) द्वारा इंगित किया जाता है IMAGE_DIRECTORY_ENTRY_COMHEADER[6] पीई शीर्षलेख की डेटा निर्देशिका में प्रविष्टि। IMAGE_COR20_HEADER पीई के वैकल्पिक हेडर से बहुत मिलता-जुलता है, अनिवार्य रूप से सीएलआर लोडर के लिए अपनी भूमिका निभा रहा है।[7]
सीएलआर से संबंधित डेटा, रूट संरचना सहित, प्रायः सामान्य कोड अनुभाग में निहित होता है, .text. यह कुछ निर्देशिकाओं से बना है मेटाडेटा, एम्बेडेड संसाधन, मजबूत नाम और कुछ नेटिव-कोड इंटरऑपरेबिलिटी के लिए। मेटाडेटा निर्देशिका तालिकाओं का सेट है जो सभा में सभी विशिष्ट .NET संस्थाओं को सूचीबद्ध करता है, जिसमें प्रकार, विधियाँ, फ़ील्ड, स्थिरांक, घटनाएँ, साथ ही उनके बीच और अन्य सभा के संदर्भ शामिल हैं।
अन्य ऑपरेटिंग सिस्टम पर प्रयोग करें
पीई प्रारूप का उपयोग प्रतिक्रिया द्वारा भी किया जाता है, क्योंकि प्रतिक्रिया का उद्देश्य विंडोज के साथ बाइनरी-संगत होना है। यह स्काईओएस और बीओएस आर3 सहित कई अन्य ऑपरेटिंग प्रणाली द्वारा भी ऐतिहासिक रूप से उपयोग किया गया है। हालाँकि, स्काईओएस और BeOS दोनों अंततः निष्पादन योगिनी और लिंक करने योग्य प्रारूप में चले गए।[citation needed]
जैसा कि मोनो विकास मंच माइक्रोसॉफ्ट .NET फ्रेमवर्क के साथ बाइनरी संगत होने का इरादा रखता है, यह माइक्रोसॉफ्ट कार्यान्वयन के समान पीई प्रारूप का उपयोग करता है। वही माइक्रोसॉफ्ट के अपने क्रॉस-प्लेटफ़ॉर्म .NET कोर के लिए जाता है।
x86(-64) पर यूनिक्स-जैसे ऑपरेटिंग सिस्टम, विंडोज बायनेरिज़ (पीई प्रारूप में) को वाइन के साथ निष्पादित किया जा सकता है। एचएक्स डॉस एक्सटेंडर देशी डॉस 32-बिट बायनेरिज़ के लिए पीई प्रारूप का भी उपयोग करता है, साथ ही यह कुछ हद तक, डॉस में मौजूदा विंडोज़ बायनेरिज़ को निष्पादित कर सकता है, इस प्रकार डॉस के लिए वाइन के समकक्ष कार्य करता है।
IA-32 और x86-64 लिनक्स पर कोई भी लोड पुस्तकालयों के अंतर्गत माइक्रोसॉफ्ट विंडोज़ की डीएलएल चला सकता है।[8]
मैक ओएस एक्स 10.5 में पीई फाइलों को लोड और पार्स करने की क्षमता है, लेकिन विंडोज के साथ बाइनरी संगत नहीं है।[9]
यूईएफआई और ईएफआई फर्मवेयर पोर्टेबल निष्पादन योग्य फ़ाइलों के साथ-साथ अनुप्रयोगों के लिए विंडोज एबीआईx64 कॉलिंग सम्मेलन का उपयोग करते हैं।
यह भी देखें
- प्रोग्राम फ़ाइल
- निष्पादन योग्य और लिंक करने योग्य प्रारूप
- मैक-ओ
- ए.बाहर
- निष्पादन योग्य फ़ाइल स्वरूपों की तुलना
- निष्पादन योग्य दबाव
- एआर (यूनिक्स) क्योंकि सभी सीओएफएफ पुस्तकालय उसी प्रारूप का उपयोग करते हैं
- अनुप्रयोग वर्चुअलाइजेशन
संदर्भ
- ↑ "पोर्टेबल निष्पादन योग्य (पीई) - परिभाषा - ट्रेंड माइक्रो इन". www.trendmicro.com. Retrieved 2022-11-10.
- ↑ E.g. Microsoft's linker has /STUB switch to attach one
- ↑ 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) - ↑ "पोर्टेबल निष्पादन योग्य फ़ाइल ऊपर से नीचे तक". Retrieved 2017-10-21.
- ↑ 5.0 5.1 "पीई के अंदर झाँकना: Win32 पोर्टेबल निष्पादन योग्य फ़ाइल का एक दौरा". Retrieved 2017-10-21.
- ↑ The entry was previously used for COM+ metadata in COM+ applications, hence the name
- ↑ Cite error: Invalid
<ref>tag; no text was provided for refs namedPE Format (Windows) - ↑ "गिटहब - टैविसो/लोड लाइब्रेरी: विंडोज डायनेमिक लिंक लाइब्रेरी को लिनक्स में पोर्ट करना". GitHub.
- ↑ 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)
बाहरी संबंध
- PE Format (latest online document)
- Microsoft Portable Executable and Common Object File Format Specification (revision 9.3, .docx format)
- Microsoft Portable Executable and Common Object File Format Specification (revision 6.0, .doc format)
- The original Portable Executable article by Matt Pietrek (MSDN Magazine, March 1994)
- Part I. An In-Depth Look into the Win32 Portable Executable File Format by Matt Pietrek (MSDN Magazine, February 2002)
- Part II. An In-Depth Look into the Win32 Portable Executable File Format by Matt Pietrek (MSDN Magazine, March 2002)
- The .NET File Format by Daniel Pistelli
- Ero Carrera's blog describing the PE header and how to walk through
- PE Internals provides an easy way to learn the Portable Executable File Format
- PE Explorer
