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

From Vigyanwiki
No edit summary
No edit summary
Line 1: Line 1:
'''पोर्टेबल [[निष्पादन]] योग्य (पीई)''' प्रारूप निष्पादनयोग्य, [[वस्तु फ़ाइल|वस्तु कोड]], [[डायनामिक-लिंक लाइब्रेरी|डीएलएल]] और [[माइक्रोसॉफ़्ट विंडोज़|विंडोज़]] [[ऑपरेटिंग सिस्टम]] के 32-बिट और 64-बिट संस्करणों में उपयोग किए जाने वाले अन्य के लिए एक फ़ाइल प्रारूप है।<ref>{{Cite web |title=पोर्टेबल निष्पादन योग्य (पीई) - परिभाषा - ट्रेंड माइक्रो इन|url=https://www.trendmicro.com/vinfo/in/security/definition/portable-executable-pe |access-date=2022-11-10 |website=www.trendmicro.com}}</ref> जो पीई प्रारूप डेटा संरचना है लिपटे हुए निष्पादन योग्य कोड को प्रबंधित करने के लिए विंडोज ओएस लोडर के लिए आवश्यक जानकारी को समाहित करता है। इसमें लिंकिंग, एपीआई निर्यात और आयात टेबल, संसाधन प्रबंधन डेटा और [[थ्रेड-लोकल स्टोरेज]] (टीएलएस) डेटा के लिए क्रियाशील पुस्तकालय संदर्भ शामिल हैं। [[विंडोज एनटी|एनटी]] ऑपरेटिंग सिस्टम पर, EXE, DLL, SYS ([[डिवाइस ड्राइवर]]), MUI और अन्य फ़ाइल प्रकारों के लिए पीई प्रारूप का उपयोग किया जाता है। एकीकृत विस्तार योग्य फ़र्मवेयर इंटरफ़ेस (UEFI) विनिर्देश बताता है कि पीई, EFI वातावरण में सामान्य निष्पादन योग्य प्रारूप है।<ref>{{cite web|url=https://uefi.org/sites/default/files/resources/UEFI%20Spec%202.8B%20May%202020.pdf|title=UEFI विशिष्टता, संस्करण 2.8B}}, पृष्ठ 15 पर एक नोट में कहा गया है कि "इस छवि प्रकार को UEFI छवियों को अंगूठे और अंगूठे 2 निर्देशों को शामिल करने के लिए सक्षम करने के लिए चुना गया है जबकि EFI इंटरफेस को ARM मोड में होने के लिए परिभाषित किया गया है।"</रेफरी >
'''पोर्टेबल [[निष्पादन]] योग्य (पीई)''' प्रारूप निष्पादनयोग्य, [[वस्तु फ़ाइल|वस्तु कोड]], [[डायनामिक-लिंक लाइब्रेरी|डीएलएल]] और [[माइक्रोसॉफ़्ट विंडोज़|विंडोज़]] [[ऑपरेटिंग सिस्टम]] के 32-बिट और 64-बिट संस्करणों में उपयोग किए जाने वाले अन्य के लिए एक फ़ाइल प्रारूप है।<ref>{{Cite web |title=पोर्टेबल निष्पादन योग्य (पीई) - परिभाषा - ट्रेंड माइक्रो इन|url=https://www.trendmicro.com/vinfo/in/security/definition/portable-executable-pe |access-date=2022-11-10 |website=www.trendmicro.com}}</ref> जो पीई प्रारूप डेटा संरचना है लिपटे हुए निष्पादन योग्य कोड को प्रबंधित करने के लिए विंडोज ओएस लोडर के लिए आवश्यक जानकारी को समाहित करता है। इसमें लिंकिंग, एपीआई निर्यात और आयात टेबल, संसाधन प्रबंधन डेटा और [[थ्रेड-लोकल स्टोरेज]] (टीएलएस) डेटा के लिए क्रियाशील पुस्तकालय संदर्भ सम्मिलित हैं। [[विंडोज एनटी|एनटी]] ऑपरेटिंग सिस्टम पर, EXE, DLL, SYS ([[डिवाइस ड्राइवर]]), MUI और अन्य फ़ाइल प्रकारों के लिए पीई प्रारूप का उपयोग किया जाता है। एकीकृत विस्तार योग्य फ़र्मवेयर इंटरफ़ेस (UEFI) विनिर्देश बताता है कि पीई, EFI वातावरण में सामान्य निष्पादन योग्य प्रारूप है।<ref>{{cite web|url=https://uefi.org/sites/default/files/resources/UEFI%20Spec%202.8B%20May%202020.pdf|title=UEFI विशिष्टता, संस्करण 2.8B}}, पृष्ठ 15 पर एक नोट में कहा गया है कि "इस छवि प्रकार को UEFI छवियों को अंगूठे और अंगूठे 2 निर्देशों को शामिल करने के लिए सक्षम करने के लिए चुना गया है जबकि EFI इंटरफेस को ARM मोड में होने के लिए परिभाषित किया गया है।"</रेफरी >
Windows NT ऑपरेटिंग सिस्टम पर, PE वर्तमान में [[x86-32]], [[x86-64]] (AMD64/Intel 64), [[IA-64]], ARM आर्किटेक्चर और [[ARM64]] [[निर्देश सेट वास्तुकला]] (ISAs) का समर्थन करता है। [[विंडोज 2000]] से पहले, विंडोज एनटी (और इस प्रकार पीई) ने [[एमआईपीएस आर्किटेक्चर]], [[डीईसी अल्फा]] और [[पावरपीसी]] आईएसए का समर्थन किया था। क्योंकि पीई का उपयोग [[विंडोज सीई]] पर किया जाता है, यह एमआईपीएस, [[एआरएम वास्तुकला]] (एआरएम आर्किटेक्चर # थंब सहित), और सुपरएच आईएसए के कई रूपों का समर्थन करना जारी रखता है।<ref name="पीई प्रारूप (विंडोज़)">{{cite web|url=https://msdn.microsoft.com/en-us/library/windows/desktop/ms680547(v=vs.85).aspx|title=पीई प्रारूप (विंडोज़)| access-date=2017-10-21}}</ref>
Windows NT ऑपरेटिंग सिस्टम पर, PE वर्तमान में [[x86-32]], [[x86-64]] (AMD64/Intel 64), [[IA-64]], ARM आर्किटेक्चर और [[ARM64]] [[निर्देश सेट वास्तुकला]] (ISAs) का समर्थन करता है। [[विंडोज 2000]] से पहले, विंडोज एनटी (और इस प्रकार पीई) ने [[एमआईपीएस आर्किटेक्चर]], [[डीईसी अल्फा]] और [[पावरपीसी]] आईएसए का समर्थन किया था। क्योंकि पीई का उपयोग [[विंडोज सीई]] पर किया जाता है, यह एमआईपीएस, [[एआरएम वास्तुकला]] (एआरएम आर्किटेक्चर # थंब सहित), और सुपरएच आईएसए के कई रूपों का समर्थन करना जारी रखता है।<ref name="पीई प्रारूप (विंडोज़)">{{cite web|url=https://msdn.microsoft.com/en-us/library/windows/desktop/ms680547(v=vs.85).aspx|title=पीई प्रारूप (विंडोज़)| access-date=2017-10-21}}</ref>


Line 8: Line 8:
== इतिहास ==
== इतिहास ==


माइक्रोसॉफ्ट ने विंडोज़ एनटी 3.1 ऑपरेटिंग सिस्टम की शुरुआत के साथ 16-बिट एनई निष्पादन योग्य स्वरूपों [[से]] पीई प्रारूप में विस्थापित किया। विंडोज के सभी बाद के संस्करण, विंडोज 95/98/एमइ और विंडोज 3.1x में शामिल [[Win32s]] सहित, फ़ाइल संरचना का समर्थन करते हैं। प्रारूप ने डॉस-आधारित और एनटी प्रणाली के बीच की दरार को जोड़ने के लिए सीमित विरासत समर्थन को बरकरार रखा है। उदाहरण के लिए, पीई/सीओएफएफ हेडर में अभी भी [[डॉस एमजेड निष्पादन योग्य|डॉस निष्पादन योग्य]] शामिल है, जो अनुपस्थिति रूप से [[डॉस ठूंठ|डॉस स्टब]] है जो संदेश प्रदर्शित करता है जैसे "यह प्रोग्राम डॉस मोड में नहीं चलाया जा सकता" (या इसी तरह), हालांकि यह पूर्ण रूप से डॉस कार्यक्रम का संपादन हो सकता है। ( बाद का उल्लेखनीय मामला विंडोज 98 एसई इंस्टॉलर है)।<ref>E.g. Microsoft's linker has [http://msdn.microsoft.com/en-us/library/7z0585h5.aspx /STUB switch] to attach one</ref> यह वसा बाइनरी का रूप है। पीई भी बदलते विंडोज प्लेटफॉर्म की सेवा जारी रखता है। कुछ एक्सटेंशन में .NET पीई प्रारूप (नीचे देखें), 64-बिट एड्रेस स्पेस सपोर्ट वाला संस्करण है जिसे पीई32+ कहा जाता है,<ref>In order to know whether the executable code is 32- or 64-bit, check the Machine field in the IMAGE_FILE_HEADER. ([https://gdatasoftware.com/blog/pebitnesstrick PE trick explained: Telling 32 and 64 bit apart with naked eye] by Karsten Hahn)<br>To see if addresses in the executable are 32- or 64-bit, check the Magic field in the IMAGE_OPTIONAL_HEADER. 10B<sub>16</sub> indicates a PE32 file, whereas 20B<sub>16</sub> indicates a PE32+ file. ([https://docs.microsoft.com/en-us/windows/win32/debug/pe-format PE Format] at Microsoft.com)</ref> और विंडोज सीई के लिए विनिर्देश शामिल है।
माइक्रोसॉफ्ट ने विंडोज़ एनटी 3.1 ऑपरेटिंग सिस्टम के प्रारम्भ के साथ 16-बिट एनई निष्पादन योग्य स्वरूपों [[से]] पीई प्रारूप में विस्थापित किया। विंडोज के सभी बाद के संस्करण, विंडोज 95/98/एमइ और विंडोज 3.1x में सम्मिलित [[Win32s]] सहित, फ़ाइल संरचना का समर्थन करते हैं। प्रारूप ने डॉस-आधारित और एनटी प्रणाली के बीच की दरार को जोड़ने के लिए सीमित विरासत समर्थन को बरकरार रखा है। उदाहरण के लिए, पीई/सीओएफएफ हेडर में अभी भी [[डॉस एमजेड निष्पादन योग्य|डॉस निष्पादन योग्य]] सम्मिलित है, जो अनुपस्थिति रूप से [[डॉस ठूंठ|डॉस स्टब]] है जो संदेश प्रदर्शित करता है जैसे "यह प्रोग्राम डॉस मोड में नहीं चलाया जा सकता" (या इसी तरह), हालांकि यह पूर्ण रूप से डॉस कार्यक्रम का संपादन हो सकता है। ( बाद का उल्लेखनीय मामला विंडोज 98 एसई इंस्टॉलर है)।<ref>E.g. Microsoft's linker has [http://msdn.microsoft.com/en-us/library/7z0585h5.aspx /STUB switch] to attach one</ref> यह वसा बाइनरी का रूप है। पीई भी बदलते विंडोज प्लेटफॉर्म की सेवा जारी रखता है। कुछ एक्सटेंशन में .NET पीई प्रारूप (नीचे देखें), 64-बिट एड्रेस स्पेस सपोर्ट वाला संस्करण है जिसे पीई32+ कहा जाता है,<ref>In order to know whether the executable code is 32- or 64-bit, check the Machine field in the IMAGE_FILE_HEADER. ([https://gdatasoftware.com/blog/pebitnesstrick PE trick explained: Telling 32 and 64 bit apart with naked eye] by Karsten Hahn)<br>To see if addresses in the executable are 32- or 64-bit, check the Magic field in the IMAGE_OPTIONAL_HEADER. 10B<sub>16</sub> indicates a PE32 file, whereas 20B<sub>16</sub> indicates a PE32+ file. ([https://docs.microsoft.com/en-us/windows/win32/debug/pe-format PE Format] at Microsoft.com)</ref> और विंडोज सीई के लिए विनिर्देश सम्मिलित है।


== तकनीकी विवरण ==
== तकनीकी विवरण ==


=== लेआउट ===
=== लेआउट ===
[[File:Portable Executable 32 bit Structure in SVG fixed.svg|thumb|पोर्टेबल निष्पादन योग्य 32 बिट की संरचना]]पीई फाइल में कई हेडर और सेक्शन होते हैं जो [[गतिशील लिंकर|गतिशील संयोजक]] को बताते हैं कि फाइल को मेमोरी में कैसे मैप किया जाए। निष्पादन योग्य छवि में कई अलग-अलग क्षेत्र होते हैं, जिनमें से प्रत्येक को अलग-अलग मेमोरी सुरक्षा की आवश्यकता होती है, इसलिए प्रत्येक अनुभाग की शुरुआत पृष्ठ सीमा से संरेखित होनी चाहिए।<ref>{{cite web |url=http://www.csn.ul.ie/%7Ecaolan/pub/winresdump/winresdump/doc/pefile2.html |title=पोर्टेबल निष्पादन योग्य फ़ाइल ऊपर से नीचे तक|access-date=2017-10-21}}</ref> उदाहरण के लिए, प्रायः .text अनुभाग (जिसमें प्रोग्राम कोड होता है) को निष्पादन/केवल-पढ़ने के लिए मैप किया जाता है, और .डेटा अनुभाग (वैश्विक चर धारण करने वाले) को निष्पादन/पढ़ने के लिए लिखने के रूप में मानचित्र किया जाता है। हालाँकि, स्थान बर्बाद करने से बचने के लिए, विभिन्न अनुभागों को डिस्क पर पृष्ठ संरेखित नहीं किया जाता है। डायनेमिक लिंकर के काम का हिस्सा प्रत्येक अनुभाग को व्यक्तिगत रूप से मेमोरी में मानचित्र करना और हेडर में मिले निर्देशों के अनुसार परिणामी क्षेत्रों को सही अनुमति देना है।<ref name="Peering Inside">{{cite web |url=https://msdn.microsoft.com/en-us/library/ms809762.aspx |title=पीई के अंदर झाँकना: Win32 पोर्टेबल निष्पादन योग्य फ़ाइल का एक दौरा|access-date=2017-10-21}}</ref>
[[File:Portable Executable 32 bit Structure in SVG fixed.svg|thumb|पोर्टेबल निष्पादन योग्य 32 बिट की संरचना]]पीई फाइल में कई हेडर और सेक्शन होते हैं जो [[गतिशील लिंकर|गतिशील संयोजक]] को बताते हैं कि फाइल को मेमोरी में कैसे मैप किया जाए। निष्पादन योग्य छवि में कई अलग-अलग क्षेत्र होते हैं, जिनमें से प्रत्येक को अलग-अलग मेमोरी सुरक्षा की आवश्यकता होती है, इसलिए प्रत्येक अनुभाग के प्रारम्भ पृष्ठ सीमा से संरेखित होनी चाहिए।<ref>{{cite web |url=http://www.csn.ul.ie/%7Ecaolan/pub/winresdump/winresdump/doc/pefile2.html |title=पोर्टेबल निष्पादन योग्य फ़ाइल ऊपर से नीचे तक|access-date=2017-10-21}}</ref> उदाहरण के लिए, प्रायः .text अनुभाग (जिसमें प्रोग्राम कोड होता है) को निष्पादन/केवल-पढ़ने के लिए मैप किया जाता है, और .डेटा अनुभाग (वैश्विक चर धारण करने वाले) को निष्पादन/पढ़ने के लिए लिखने के रूप में मानचित्र किया जाता है। हालाँकि, स्थान बर्बाद करने से बचने के लिए, विभिन्न अनुभागों को डिस्क पर पृष्ठ संरेखित नहीं किया जाता है। डायनेमिक लिंकर के काम का हिस्सा प्रत्येक अनुभाग को व्यक्तिगत रूप से मेमोरी में मानचित्र करना और हेडर में मिले निर्देशों के अनुसार परिणामी क्षेत्रों को सही अनुमति देना है।<ref name="Peering Inside">{{cite web |url=https://msdn.microsoft.com/en-us/library/ms809762.aspx |title=पीई के अंदर झाँकना: Win32 पोर्टेबल निष्पादन योग्य फ़ाइल का एक दौरा|access-date=2017-10-21}}</ref>


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


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


==.NET, मेटाडेटा, और पीई प्रारूप ==
==.NET, मेटाडेटा, और पीई प्रारूप ==
.NET निष्पादन योग्य में, पीई कोड अनुभाग में एक स्टब होता है जो [[सामान्य भाषा रनटाइम|सीएलआर]] वर्चुअल मशीन स्टार्टअप प्रविष्टि को आमंत्रित करता है, <code>_CorExeMain</code> या <code>_CorDllMain</code> में <code>mscoree.dll</code>, बिल्कुल वैसा ही जैसा कि यह [[Visual Basic|मूल दृश्य]] निष्पादनयोग्य में था। वर्चुअल मशीन तब मौजूद .NET मेटाडेटा का उपयोग करती है, जिसका मूल, <code>IMAGE_COR20_HEADER</code> (जिसे "सीएलआर हेडर" भी कहा जाता है) द्वारा इंगित किया जाता है <code>IMAGE_DIRECTORY_ENTRY_COMHEADER</code><ref>The entry was previously used for [[COM+]] metadata in COM+ applications, hence the name</ref> पीई शीर्षलेख की डेटा निर्देशिका में प्रविष्टि। <code>IMAGE_COR20_HEADER</code> पीई के वैकल्पिक हेडर से बहुत मिलता-जुलता है, अनिवार्य रूप से सीएलआर लोडर के लिए अपनी भूमिका निभा रहा है।<ref name="PE Format (Windows)"/>
.NET निष्पादन योग्य में, पीई कोड अनुभाग में एक स्टब होता है जो [[सामान्य भाषा रनटाइम|सीएलआर]] वर्चुअल मशीन स्टार्टअप प्रविष्टि को आमंत्रित करता है, <code>_CorExeMain</code> या <code>_CorDllMain</code> में <code>mscoree.dll</code>, बिल्कुल वैसा ही जैसा कि यह [[Visual Basic|मूल दृश्य]] निष्पादनयोग्य में था। वर्चुअल मशीन तब मौजूद .NET मेटाडेटा का उपयोग करती है, जिसका मूल, <code>IMAGE_COR20_HEADER</code> (जिसे "सीएलआर हेडर" भी कहा जाता है) द्वारा इंगित किया जाता है <code>IMAGE_DIRECTORY_ENTRY_COMHEADER</code><ref>The entry was previously used for [[COM+]] metadata in COM+ applications, hence the name</ref> पीई शीर्षलेख की डेटा निर्देशिका में प्रविष्टि। <code>IMAGE_COR20_HEADER</code> पीई के वैकल्पिक हेडर से बहुत मिलता-जुलता है, अनिवार्य रूप से सीएलआर लोडर के लिए अपनी भूमिका निभा रहा है।<ref name="PE Format (Windows)"/>


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


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


जैसा कि [[मोनो (सॉफ्टवेयर)|मोनो]] विकास मंच माइक्रोसॉफ्ट .NET फ्रेमवर्क के साथ बाइनरी संगत होने का इरादा रखता है, यह माइक्रोसॉफ्ट कार्यान्वयन के समान पीई प्रारूप का उपयोग करता है। वही माइक्रोसॉफ्ट के अपने क्रॉस-प्लेटफ़ॉर्म .NET कोर के लिए जाता है।
जैसा कि [[मोनो (सॉफ्टवेयर)|मोनो]] विकास मंच माइक्रोसॉफ्ट .NET फ्रेमवर्क के साथ बाइनरी संगत होने का इरादा रखता है, यह माइक्रोसॉफ्ट कार्यान्वयन के समान पीई प्रारूप का उपयोग करता है। वही माइक्रोसॉफ्ट के अपने क्रॉस-प्लेटफ़ॉर्म .NET कोर के लिए जाता है।
Line 53: Line 53:
*
*
==बाहरी संबंध==
==बाहरी संबंध==
*[https://docs.microsoft.com/en-us/windows/desktop/Debug/pe-format PE Format] (latest online document)
*[https://docs.microsoft.com/en-us/windows/desktop/Debug/pe-format PE Format] (latest online document)
*[https://download.microsoft.com/download/9/c/5/9c5b2167-8017-4bae-9fde-d599bac8184a/pecoff_v83.docx Microsoft Portable Executable and Common Object File Format Specification] (revision 9.3, [[.docx]] format)
*[https://download.microsoft.com/download/9/c/5/9c5b2167-8017-4bae-9fde-d599bac8184a/pecoff_v83.docx Microsoft Portable Executable and Common Object File Format Specification] (revision 9.3, [[.docx]] format)
*[https://web.archive.org/web/20090126141159/http://download.microsoft.com/download/e/b/a/eba1050f-a31d-436b-9281-92cdfeae4b45/pecoff.doc Microsoft Portable Executable and Common Object File Format Specification] (revision 6.0, [[.doc]] format)
*[https://web.archive.org/web/20090126141159/http://download.microsoft.com/download/e/b/a/eba1050f-a31d-436b-9281-92cdfeae4b45/pecoff.doc Microsoft Portable Executable and Common Object File Format Specification] (revision 6.0, [[.doc]] format)
*[http://msdn2.microsoft.com/en-us/library/ms809762.aspx The original Portable Executable article] by [[Matt Pietrek]] ([[MSDN]] Magazine, March 1994)
*[http://msdn2.microsoft.com/en-us/library/ms809762.aspx The original Portable Executable article] by [[Matt Pietrek]] ([[MSDN]] Magazine, March 1994)
*[http://msdn.microsoft.com/en-us/magazine/cc301805.aspx Part I. An In-Depth Look into the Win32 Portable Executable File Format] by [[Matt Pietrek]] ([[MSDN]] Magazine, February 2002)
*[http://msdn.microsoft.com/en-us/magazine/cc301805.aspx Part I. An In-Depth Look into the Win32 Portable Executable File Format] by [[Matt Pietrek]] ([[MSDN]] Magazine, February 2002)

Revision as of 12:19, 19 January 2023

पोर्टेबल निष्पादन योग्य (पीई) प्रारूप निष्पादनयोग्य, वस्तु कोड, डीएलएल और विंडोज़ ऑपरेटिंग सिस्टम के 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] और विंडोज सीई के लिए विनिर्देश सम्मिलित है।

तकनीकी विवरण

लेआउट

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

पीई फाइल में कई हेडर और सेक्शन होते हैं जो गतिशील संयोजक को बताते हैं कि फाइल को मेमोरी में कैसे मैप किया जाए। निष्पादन योग्य छवि में कई अलग-अलग क्षेत्र होते हैं, जिनमें से प्रत्येक को अलग-अलग मेमोरी सुरक्षा की आवश्यकता होती है, इसलिए प्रत्येक अनुभाग के प्रारम्भ पृष्ठ सीमा से संरेखित होनी चाहिए।[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 कॉलिंग सम्मेलन का उपयोग करते हैं।

यह भी देखें

संदर्भ

  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)

बाहरी संबंध