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

पोर्टेबल निष्पादन योग्य (पीई) प्रारूप निष्पादन योग्य, वस्तु फ़ाइल, डायनामिक-लिंक लाइब्रेरी और माइक्रोसॉफ़्ट विंडोज़ ऑपरेटिंग सिस्टम के 32-बिट और 64-बिट संस्करणों में उपयोग किए जाने वाले अन्य के लिए एक फ़ाइल प्रारूप है। पीई प्रारूप एक डेटा संरचना है जो लिपटे हुए निष्पादन योग्य को प्रबंधित करने के लिए विंडोज ओएस लोडर के लिए आवश्यक जानकारी को समाहित करता है। इसमें लाइब्रेरी (कंप्यूटर साइंस) # डायनेमिक लिंकिंग, अप्लिकेशन प्रोग्रामिंग अंतरफलक निर्यात और आयात टेबल, संसाधन प्रबंधन डेटा और थ्रेड-लोकल स्टोरेज (TLS) डेटा शामिल हैं। विंडोज एनटी ऑपरेटिंग सिस्टम पर, पीई प्रारूप का उपयोग EXE, डायनेमिक-लिंक लाइब्रेरी, .sys (डिवाइस ड्राइवर), .mui और अन्य फ़ाइल प्रकारों के लिए किया जाता है। एकीकृत एक्सटेंसिबल फर्मवेयर इंटरफ़ेस | यूनिफ़ाइड एक्सटेंसिबल फ़र्मवेयर इंटरफ़ेस (यूईएफआई) विनिर्देश बताता है कि पीई ईएफआई वातावरण में मानक निष्पादन योग्य प्रारूप है। पीई के अनुरूप प्रारूप निष्पादन योग्य और लिंक करने योग्य प्रारूप (लिनक्स और यूनिक्स के अधिकांश अन्य संस्करणों में प्रयुक्त) और मैक-ओ (मैकोज़ और आईओएस में प्रयुक्त) हैं।

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

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

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

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

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

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

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

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

IA-32 और x86-64 Linux पर कोई भी लोड लाइब्रेरी के तहत Microsoft Windows की डायनेमिक-लिंक लाइब्रेरी चला सकता है। मैक ओएस एक्स 10.5 में पीई फाइलों को लोड और पार्स करने की क्षमता है, लेकिन विंडोज के साथ बाइनरी संगत नहीं है। यूईएफआई और ईएफआई फर्मवेयर पोर्टेबल निष्पादन योग्य फ़ाइलों के साथ-साथ यूईएफआई # अनुप्रयोगों के लिए विंडोज एप्लिकेशन बाइनरी इंटरफ़ेस x64 कॉलिंग कन्वेंशन का उपयोग करते हैं।

यह भी देखें

 * प्रोग्राम फ़ाइल
 * निष्पादन योग्य और लिंक करने योग्य प्रारूप
 * मच-ओ
 * अ.बाहर
 * निष्पादन योग्य फ़ाइल स्वरूपों की तुलना
 * निष्पादन योग्य संपीड़न
 * ar (यूनिक्स) क्योंकि सभी COFF पुस्तकालय उसी प्रारूप का उपयोग करते हैं
 * अनुप्रयोग वर्चुअलाइजेशन

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

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

बाहरी संबंध

 * 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