पोर्टेबल निष्पादन योग्य

From alpha
Jump to navigation Jump to search
Portable Executable
Filename extension
.acm, .ax, .cpl, .dll, .drv, .efi, .exe, .mui, .ocx, .scr, .sys, .tsp
Internet media type
application/vnd.microsoft.portable-executable[1]
Developed byCurrently: Microsoft
Type of formatBinary, executable, object, shared libraries
Extended fromDOS MZ executable
COFF

पोर्टेबल निष्पादन योग्य (पीई) प्रारूप निष्पादन योग्य, वस्तु फ़ाइल, डायनामिक-लिंक लाइब्रेरी और माइक्रोसॉफ़्ट विंडोज़ ऑपरेटिंग सिस्टम के 32-बिट और 64-बिट संस्करणों में उपयोग किए जाने वाले अन्य के लिए एक फ़ाइल प्रारूप है।[2] पीई प्रारूप एक डेटा संरचना है जो लिपटे हुए निष्पादन योग्य को प्रबंधित करने के लिए विंडोज ओएस लोडर के लिए आवश्यक जानकारी को समाहित करता है। इसमें लाइब्रेरी (कंप्यूटर साइंस) # डायनेमिक लिंकिंग, अप्लिकेशन प्रोग्रामिंग अंतरफलक निर्यात और आयात टेबल, संसाधन प्रबंधन डेटा और थ्रेड-लोकल स्टोरेज (TLS) डेटा शामिल हैं। विंडोज एनटी ऑपरेटिंग सिस्टम पर, पीई प्रारूप का उपयोग EXE, डायनेमिक-लिंक लाइब्रेरी, .sys (डिवाइस ड्राइवर), .mui और अन्य फ़ाइल प्रकारों के लिए किया जाता है। एकीकृत एक्सटेंसिबल फर्मवेयर इंटरफ़ेस | यूनिफ़ाइड एक्सटेंसिबल फ़र्मवेयर इंटरफ़ेस (यूईएफआई) विनिर्देश बताता है कि पीई ईएफआई वातावरण में मानक निष्पादन योग्य प्रारूप है।[3] Windows NT ऑपरेटिंग सिस्टम पर, PE वर्तमान में x86-32, x86-64 (AMD64/Intel 64), IA-64, ARM आर्किटेक्चर और ARM64 निर्देश सेट वास्तुकला (ISAs) का समर्थन करता है। विंडोज 2000 से पहले, विंडोज एनटी (और इस प्रकार पीई) ने एमआईपीएस आर्किटेक्चर, डीईसी अल्फा और पावरपीसी आईएसए का समर्थन किया था। क्योंकि पीई का उपयोग विंडोज सीई पर किया जाता है, यह एमआईपीएस, एआरएम वास्तुकला (एआरएम आर्किटेक्चर # थंब सहित), और सुपरएच आईएसए के कई रूपों का समर्थन करना जारी रखता है।[4] पीई के अनुरूप प्रारूप निष्पादन योग्य और लिंक करने योग्य प्रारूप (लिनक्स और यूनिक्स के अधिकांश अन्य संस्करणों में प्रयुक्त) और मैक-ओ (मैकोज़ और आईओएस में प्रयुक्त) हैं।

इतिहास

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

तकनीकी विवरण

लेआउट

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

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


आयात तालिका

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


स्थानांतरण

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

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

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

सीएलआर से संबंधित डेटा, रूट संरचना सहित, आम तौर पर सामान्य कोड अनुभाग में निहित होता है, .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 की डायनेमिक-लिंक लाइब्रेरी चला सकता है।[10] मैक ओएस एक्स 10.5 में पीई फाइलों को लोड और पार्स करने की क्षमता है, लेकिन विंडोज के साथ बाइनरी संगत नहीं है।[11] यूईएफआई और ईएफआई फर्मवेयर पोर्टेबल निष्पादन योग्य फ़ाइलों के साथ-साथ यूईएफआई # अनुप्रयोगों के लिए विंडोज एप्लिकेशन बाइनरी इंटरफ़ेस x64 कॉलिंग कन्वेंशन का उपयोग करते हैं।

यह भी देखें

संदर्भ

  1. Andersson, Henrik (2015-04-23). "application/vnd.microsoft.portable-executable". IANA. Retrieved 2017-03-26.
  2. "Portable executable (PE) - Definition - Trend Micro IN". www.trendmicro.com. Retrieved 2022-11-10.
  3. "UEFI Specification, version 2.8B" (PDF)., a note on p.15, states that "this image type is chosen to enable UEFI images to contain Thumb and Thumb2 instructions while defining the EFI interfaces themselves to be in ARM mode."
  4. 4.0 4.1 "PE Format (Windows)". Retrieved 2017-10-21.
  5. E.g. Microsoft's linker has /STUB switch to attach one
  6. 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)
  7. "The Portable Executable File From Top to Bottom". Retrieved 2017-10-21.
  8. 8.0 8.1 "Peering Inside the PE: A Tour of the Win32 Portable Executable File". Retrieved 2017-10-21.
  9. The entry was previously used for COM+ metadata in COM+ applications, hence the name
  10. "GitHub - taviso/Loadlibrary: Porting Windows Dynamic Link Libraries to Linux". GitHub.
  11. Chartier, David (2007-11-30). "Uncovered: Evidence that Mac OS X could run Windows apps soon". Ars Technica. Retrieved 2007-12-03. ... Steven Edwards describes the discovery that Leopard apparently contains an undocumented loader for Portable Executables, a type of file used in 32-bit and 64-bit versions of Windows. More poking around revealed that Leopard's own loader tries to find Windows DLL files when attempting to load a Windows binary.


बाहरी संबंध