निष्पादक OS पर क्यों नहीं बल्कि CPU पर निर्भर करते हैं?

16

अगर मैं एक C प्रोग्राम लिखता हूं और उसे फाइल में संकलित करता हूं .exe, तो .exeफाइल में सीपीयू के लिए कच्चे मशीन के निर्देश होते हैं। (मुझे लगता है)।

यदि हां, तो विंडोज के आधुनिक संस्करण को चलाने वाले किसी भी कंप्यूटर पर संकलित फ़ाइल को चलाना मेरे लिए कैसे संभव है? सीपीयू के प्रत्येक परिवार का एक अलग निर्देश सेट है। तो कोई भी कंप्यूटर कैसे आता है जो उपयुक्त OS को चलाता है वह मेरी .exeफ़ाइल के निर्देशों को समझ सकता है , चाहे वह भौतिक CPU हो?

इसके अलावा, अक्सर कुछ एप्लिकेशन के "डाउनलोड" पृष्ठ में वेबसाइटों में, आपके पास विंडोज के लिए एक लिनक्स, और मैक के लिए (अक्सर दो ओएस के लिए दो डाउनलोड, 86 और 64 बिट कंप्यूटर के लिए) डाउनलोड होता है। CPU के प्रत्येक परिवार के लिए कई और डाउनलोड क्यों नहीं हैं?

low-level cpu machine-code

— अवीव कोहन
स्रोत

4

CPU में x86, 64b आदि जैसे मानक होते हैं। निष्पादनयोग्य CPU पर निर्भर करते हैं। आप कुछ विशेष सीपीयू जैसे RISC पर उल्लिखित अपने exe को नहीं चला सकते हैं, विशेष प्रयोजन सीपीयू के बहुतायत हैं

— InformedA

OS निष्पादक से बने होते हैं, और वे CPU पर निर्भर करते हैं, OS पर नहीं, क्योंकि वे OS हैं।

— ट्यूलेंस कोर्डोवा

पिछड़े अनुकूलता के कारण।

— MiKL

2

86 और 64 बिट कंप्यूटरों के लिए प्रत्येक ओएस के लिए अक्सर दो डाउनलोड : मैं व्याख्या करता हूं कि सीपीयू पर निष्पादनयोग्य की निर्भरता के रूप में।

— मौवीसिकल

37

निष्पादनकर्ता OS और CPU दोनों पर निर्भर करते हैं:

निर्देश सेट: निष्पादन योग्य में बाइनरी निर्देश कुछ निर्देश सेट के अनुसार सीपीयू द्वारा डिकोड किए जाते हैं। अधिकांश उपभोक्ता CPU x86 ("32 बिट") और / या AMD64 ("64 बिट") निर्देश सेट का समर्थन करते हैं। इन अनुदेश सेटों में से किसी एक के लिए एक कार्यक्रम संकलित किया जा सकता है, लेकिन दोनों में नहीं। इन अनुदेश सेटों के विस्तार हैं; इनका समर्थन रनटाइम पर किया जा सकता है। उदाहरण के लिए ऐसे एक्सटेंशन SIMD सपोर्ट प्रदान करते हैं। ऑप्टिमाइज़िंग कंपाइलर इन एक्सटेंशनों का लाभ उठाने की कोशिश कर सकते हैं यदि वे मौजूद हैं, लेकिन आमतौर पर एक कोड पथ भी प्रदान करता है जो बिना किसी एक्सटेंशन के काम करता है।
बाइनरी प्रारूप: निष्पादन योग्य को एक निश्चित बाइनरी प्रारूप के अनुरूप होना है, जो ऑपरेटिंग सिस्टम को प्रोग्राम को सही ढंग से लोड करने, आरंभ करने और शुरू करने की अनुमति देता है। विंडोज मुख्य रूप से पोर्टेबल निष्पादन योग्य प्रारूप का उपयोग करता है, जबकि लिनक्स ईएलएफ का उपयोग करता है।
सिस्टम एपीआई: कार्यक्रम पुस्तकालयों का उपयोग कर सकता है, जिसे निष्पादन प्रणाली पर उपस्थित होना होगा। यदि कोई प्रोग्राम विंडोज एपीआई से कार्यों का उपयोग करता है, तो इसे लिनक्स पर नहीं चलाया जा सकता है। यूनिक्स दुनिया में, केंद्रीय ऑपरेटिंग सिस्टम API को POSIX में मानकीकृत किया गया है: केवल POSIX फ़ंक्शन का उपयोग करने वाला एक प्रोग्राम मैक ओएस एक्स और सोलारिस जैसे किसी भी अनुरूप यूनिक्स प्रणाली पर चलने में सक्षम होगा।

इसलिए अगर दो सिस्टम समान सिस्टम API और लाइब्रेरी प्रदान करते हैं, एक ही इंस्ट्रक्शन सेट पर चलते हैं, और एक ही बाइनरी प्रारूप का उपयोग करते हैं, तो एक सिस्टम के लिए संकलित एक प्रोग्राम दूसरे पर भी चलेगा।

हालाँकि, अधिक अनुकूलता प्राप्त करने के तरीके हैं:

AMD64 इंस्ट्रक्शन सेट पर चलने वाले सिस्टम आमतौर पर x86 एक्जीक्यूटिव भी चलाएंगे। बाइनरी प्रारूप इंगित करता है कि किस मोड को चलाना है। 32 बिट और 64 बिट दोनों कार्यक्रमों को संभालने के लिए ऑपरेटिंग सिस्टम द्वारा अतिरिक्त प्रयास की आवश्यकता होती है।
कुछ द्विआधारी प्रारूप एक फ़ाइल को एक प्रोग्राम के कई संस्करणों को रखने की अनुमति देते हैं, विभिन्न निर्देश सेटों के लिए संकलित। ऐसे "वसा बायनेरिज़" को Apple द्वारा प्रोत्साहित किया गया था, जबकि वे PowerPC आर्किटेक्चर से x86 में संक्रमण कर रहे थे।
कुछ कार्यक्रमों को मशीन कोड के लिए संकलित नहीं किया जाता है, लेकिन कुछ मध्यवर्ती प्रतिनिधित्व के लिए। इसके बाद वास्तविक निर्देशों के अनुसार इसका अनुवाद किया जाता है, या इसकी व्याख्या की जा सकती है। यह एक कार्यक्रम को विशिष्ट वास्तुकला से स्वतंत्र बनाता है। ऐसी रणनीति का उपयोग यूसीएसडी पी-सिस्टम पर किया गया था।
एक ऑपरेटिंग सिस्टम कई बाइनरी प्रारूपों का समर्थन कर सकता है। विंडोज़ काफी पीछे संगत है और अभी भी डॉस युग के प्रारूपों का समर्थन करता है। लिनक्स पर, शराब विंडोज प्रारूपों को लोड करने की अनुमति देती है।
एक ऑपरेटिंग सिस्टम के एपीआई को दूसरे होस्ट ओएस के लिए फिर से लागू किया जा सकता है। विंडोज पर, Cygwin और POSIX सबसिस्टम का उपयोग (ज्यादातर) POSIX- अनुरूप वातावरण प्राप्त करने के लिए किया जा सकता है। लिनक्स पर, वाइन कई विंडोज एपीआई को पुन: लागू करता है।
क्रॉस-प्लेटफ़ॉर्म लाइब्रेरी एक प्रोग्राम को ओएस एपीआई से स्वतंत्र होने की अनुमति देती है। कई प्रोग्रामिंग भाषाओं में मानक पुस्तकालय हैं जो इसे प्राप्त करने की कोशिश करते हैं, जैसे जावा और सी।
एक एमुलेटर विदेशी बाइनरी प्रारूप को पार्स करके, निर्देशों की व्याख्या करके, और सभी आवश्यक एपीआई के पुन: कार्यान्वयन की पेशकश करके एक अलग प्रणाली का अनुकरण करता है। आमतौर पर आधुनिक पीसी पर पुराने नितोन्डो गेम्स चलाने के लिए एमुलेटर का उपयोग किया जाता है।

— आमोन
स्रोत

10

आपको यह उल्लेख करना चाहिए कि जावा और .net दोनों एक मध्यवर्ती प्रारूप का उपयोग करने के उदाहरण हैं - मध्यवर्ती प्रारूप आज बहुत लोकप्रिय हैं, और केवल 1970 की प्रणाली का अवशेष नहीं है जो 5 1/4 फ्लॉपी से भाग गया।

— jmoreno

@AKoscianski आपके सुझाए गए संपादन के लिए धन्यवाद । हालाँकि, मुझे लगता है कि सुरक्षा डिजाइन यही कारण नहीं है कि निष्पादक OS-निर्भर हैं, बल्कि यही कारण है कि हमारे पास OS बनाम यूजरलैंड पहले स्थान पर विभाजित है। इस तरह के संरक्षित ऑपरेटिंग सिस्टम की कार्यक्षमता के लिए विभिन्न एपीआई पहले से ही इस जवाब के "सिस्टम एपीआई" अनुभाग द्वारा संबोधित किया गया था।

— आमोन

2

विंडोज चलाने वाले 99% वर्तमान पीसी में 64 बिट प्रोसेसर है, जो 32 बिट सॉफ्टवेयर चलाने में भी सक्षम है। अन्य एक प्रतिशत में 32 बिट प्रोसेसर हैं। इसलिए 32 बिट प्रोसेसर के लिए बनाया गया सॉफ्टवेयर हर जगह चलता है। 64 बिट प्रोसेसर के लिए बनाया गया सॉफ्टवेयर हर उस पीसी पर चलता है, जिसके बारे में सॉफ्टवेयर का निर्माता परवाह करता है।

मैकओएस एक्स और आईओएस "वसा बायनेरिज़" का समर्थन करते हैं - जो आप डाउनलोड करते हैं वह वास्तव में विभिन्न प्रोसेसर के लिए संस्करण हो सकते हैं। कोई भी अब पावरपीसी प्रोसेसर के लिए एप्लिकेशन नहीं बनाता है, लेकिन कुछ साल पहले एक निष्पादन योग्य में एक पावरपीसी, 32 बिट इंटेल, और 64 बिट इंटेल संस्करण हो सकते हैं, और सही एक को निष्पादित किया जाएगा। IOS पर आजकल, जब आप कोई ऐप डाउनलोड करते हैं, तो आपको अपने डिवाइस पर प्रोसेसर के लिए उपयुक्त संस्करण मिलेगा। एक अलग डिवाइस पर डाउनलोड करें, और आपको एक अलग संस्करण मिलता है। पूरी तरह से उपयोगकर्ता के लिए अदृश्य।

— gnasher729
स्रोत

-1

एक exe में सिर्फ कच्चे मशीन कोड की तुलना में अधिक जानकारी होती है। ओएस इसे लोड करते समय पढ़ता है और यह पता लगा सकता है कि इसे कैसे चलाना चाहिए।

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

— जेम्स
स्रोत