जवाबों:
साधारण संकलित कार्यक्रम सीपीयू पर "सीधे चलते हैं", लेकिन एक कार्यक्रम वैक्यूम में नहीं चलता है:
कई कार्यक्रम बाहरी, गतिशील रूप से भरी हुई पुस्तकालयों ( DLLsया .soपुस्तकालयों) पर निर्भर करते हैं । उन्हें लिंक करने का तरीका कंपाइलर / लिंकर तक है, और प्रत्येक ओएस के अलग-अलग मानक हैं। हालांकि, "स्टैटिकली लिंक्ड" प्रोग्राम भी हैं जो अपने सभी कोड प्रदान करते हैं।
एक आधुनिक ओएस एक चल रहे कार्यक्रम के लिए कंप्यूटर का पूर्ण नियंत्रण नहीं देता है। कार्यक्रम i / o के लिए "सिस्टम कॉल" पर भरोसा करते हैं, हार्डवेयर तक पहुंच, और सिग्नल जैसी चीजें और एक नींद की स्थिति में प्रवेश करते हैं। उपलब्ध सेवाएं और इंटरफ़ेस ओएस द्वारा परिभाषित किए गए हैं। ओएस भी नियंत्रित करता है कि सिस्टम के किन हिस्सों (मेमोरी, रजिस्टर, इंटरप्ट) को प्रोग्राम का उपयोग करने की अनुमति है।
GUI प्रोग्राम को स्क्रीन पर खुद को खींचने के लिए ग्राफिकल यूजर वातावरण के माध्यम से भी काम करना चाहिए। लेकिन आपने शायद इस बारे में पहले ही सोच लिया है।
इन कारणों से, ओएस-स्वतंत्र अनुप्रयोगों को किसी प्रकार की "वर्चुअल मशीन" पर भरोसा करना चाहिए, जैसे जावा रनटाइम द्वारा प्रदान किया गया। महत्वपूर्ण रूप से, एक VM ओएस संसाधनों (i / o, सिग्नल, आदि) के लिए एक मानक इंटरफ़ेस प्रदान करता है। बेशक, जावा या अजगर भी इंटेल के इंस्ट्रक्शन सेट की विचित्रताओं से निपटने के बजाय "बायटेकोड" की व्याख्या करते हैं; लेकिन यह एक अलग कहानी है।
अलग-अलग OSes की अलग-अलग कार्यक्षमता होती है। विंडोज में I / O पूर्ण पोर्ट हैं, लिनक्स नहीं है। FreeBSD में kqueue, Linux नहीं है। लिनक्स में futexes है, विंडोज नहीं है। उनके पास एक ही काम करने के अलग-अलग तरीके भी हैं - एक फ़ाइल खोलने के लिए आप कौन से पैरामीटर पास करते हैं? वे किस क्रम में जाते हैं? आप विशेष रूप से ऑपरेटिंग सिस्टम के "एक फ़ाइल खोलें" फ़ंक्शन को कैसे लागू करते हैं?
सामान्य तौर पर, प्रोग्राम उनके एप्लिकेशन बाइनरी इंटरफ़ेस (ABI) में अंतर के कारण संगत नहीं होते हैं ।
क्या प्रोग्राम सीधे सीपीयू पर नहीं चलता है?
नहीं ! यह ऑपरेटिंग सिस्टम का काम है, अनुप्रयोगों को सीपीयू पर "सीधे" चलाने से रोकने के लिए । आमतौर पर, सबसे निचले स्तर पर (यानी एक ओएस एपीआई पर बनाया गया है), एक आवेदन ऑपरेटिंग सिस्टम के कर्नेल के साथ इंटरफेस करता है ।
क्या यह इसलिए है क्योंकि संकलित कार्यक्रम को ओएस विशिष्ट पुस्तकालयों को संदर्भित करने की आवश्यकता है?
जी हां । कई ओएस पुस्तकालयों को स्वयं ऑपरेटिंग सिस्टम के साथ इंटरफेस की सुविधा के लिए लिखा जाता है, लेकिन क्रॉस-प्लेटफ़ॉर्म के लिए लिखे गए हैं। ये डेवलपर से निम्न-स्तरीय ओएस इंटरफेसिंग को छिपाते हैं, और मान लेते हैं कि ओएस के लिए संकलित संस्करण रनटाइम पर उपलब्ध होगा (नीचे देखें)।
हालाँकि पुस्तकालयों को क्रॉस-प्लेटफ़ॉर्म तरीके से लिखा जा सकता है , जब संकलित किया जाता है तो उन्हें क्रॉस-प्लेटफ़ॉर्म नहीं चलाया जा सकता है। उन्हें अभी भी विशिष्ट लक्ष्य ऑपरेटिंग सिस्टम के लिए पुन: संकलित करने की आवश्यकता है, फिर से ऑपरेटिंग सिस्टम (कर्नेल) के विशेष अंतर्निहित घटकों का उपयोग करने के लिए।
एक ओएस बनाम दूसरे के लिए संकलित कार्यक्रम के बीच अंतर क्या है?
अंत में, निष्पादन योग्य फ़ाइलों में अक्सर बहुत विशिष्ट बाइनरी लोडिंग हेडर और आगे-आगे होते हैं (उदाहरण के लिए PE निष्पादन योग्य फ़ाइल प्रारूप .exe, .dll, आदि ...) विंडोज के लिए, या लिनक्स के लिए ELF [कोई नहीं, .o, .o] , आदि...])। इनमें किसी विशेष सॉफ़्टवेयर लाइब्रेरी के लिए संकलित OS- विशिष्ट बायनेरिज़ को लोड करने के लिए कोड भी शामिल हो सकता है।
अंत में, एक प्रोग्रामर के दृष्टिकोण से: सम्मेलन बुलाना । संकलित कोड एक विशेष तरीके से (निश्चित रूप से, रजिस्टरों के माध्यम से, या स्टैक पर) कार्यों के चर को पास करता है। फिर भी, इस बात पर भी सहमति होनी चाहिए कि फ़ंक्शन कॉल (कॉल करने वाले या कॉलली) को "क्लीन अप" करने के लिए कौन जिम्मेदार है। यद्यपि कई मानक और व्यापक रूप से उपयोग किए जाने वाले x86 कॉलिंग कन्वेंशन हैं , कुछ को कुछ ऑपरेटिंग सिस्टमों द्वारा समर्थित नहीं किया जा सकता है (यह एबीपी का हिस्सा है)।