सॉफ्टवेयर OS विशिष्ट क्यों है?

Question

मैं कुछ तकनीकी प्रणालियों के लिए प्रोग्रामिंग भाषाओं का उपयोग करके उत्पादित सॉफ्टवेयर का तकनीकी विवरण निर्धारित करने की कोशिश कर रहा हूं, केवल उनके साथ काम करता हूं।

यह मेरी समझ है कि बायनेरिज़ कुछ विशेष प्रोसेसर के लिए विशिष्ट होते हैं क्योंकि प्रोसेसर विशिष्ट मशीन भाषा जो वे समझते हैं और विभिन्न प्रोसेसर के बीच अलग-अलग निर्देश सेट करते हैं। लेकिन ऑपरेटिंग सिस्टम की विशिष्टता कहां से आती है? मैं यह मानता था कि यह OS द्वारा प्रदान किया गया API था, लेकिन फिर मैंने इस चित्र को एक पुस्तक में देखा:

ऑपरेटिंग सिस्टम - आंतरिक और डिज़ाइन सिद्धांत 7 वें संस्करण - डब्ल्यू स्टालिंग्स (पियर्सन, 2012)

जैसा कि आप देख सकते हैं, एपीआई को ऑपरेटिंग सिस्टम के एक भाग के रूप में संकेत नहीं दिया गया है।

यदि उदाहरण के लिए मैं निम्नलिखित कोड का उपयोग करके C में एक सरल प्रोग्राम बनाता हूं:

#include<stdio.h>

main()
{
    printf("Hello World");

}

क्या संकलक OS को संकलित करते समय कुछ भी विशिष्ट कर रहा है?

Comments

क्या आप एक विंडो पर प्रिंट करते हैं? या एक सांत्वना? या ग्राफिक्स मेमोरी के लिए? आप वहां डेटा कैसे डालते हैं? Apple के लिए प्रिंटफ को देखते हुए] [+ एक मैक ओएस 7 के लिए अलग और फिर से मैक ओएस एक्स (कंप्यूटर की एक 'लाइन के साथ चिपके हुए) की तुलना में काफी अलग होगा।

क्योंकि अगर आपने मैक ओएस 7 के लिए वह कोड लिखा है, तो यह एक नई विंडो में टेक्स्ट में दिखाई देगा। यदि आप इसे Apple पर करते हैं] [+, तो यह मेमोरी के कुछ सेगमेंट को सीधे लिख रहा होगा। मैक ओएस एक्स पर, यह इसे कंसोल पर लिखता है। इस प्रकार, लाइब्रेरी की परत द्वारा नियंत्रित निष्पादन हार्डवेयर के आधार पर कोड को लिखने के तीन अलग-अलग तरीके हैं।

@StevenBurnap yep - en.wikipedia.org/wiki/Aztec_C

आपका एफएफटी फ़ंक्शन खुशी से विंडोज या लिनक्स (उसी सीपीयू पर) के तहत चलेगा, यहां तक ​​कि फिर से काम किए बिना। लेकिन फिर आप परिणाम कैसे प्रदर्शित करने जा रहे हैं? ऑपरेटिंग सिस्टम एपीआई का उपयोग करना, बिल्कुल। ( printfmsvcr90.dll से libc.so.6 के समान नहीं है printf)

— इबिसिस

यहां तक ​​कि अगर एपीआई "ऑपरेटिंग सिस्टम का हिस्सा नहीं" हैं, तो वे अभी भी अलग हैं यदि आप एक ओएस से दूसरे में जाते हैं। (जो, निश्चित रूप से, इस सवाल को उठाता है कि वाक्यांश "ऑपरेटिंग सिस्टम का हिस्सा नहीं है" वास्तव में, आरेख के अनुसार इसका मतलब है।)

— थियोडोरोस चैट्ज़िग्नानकिस

Answer 1

आप इस बात का उल्लेख करते हैं कि यदि कोड सीपीयू के लिए विशिष्ट है, तो यह ओएस के लिए भी विशिष्ट क्यों होना चाहिए। यह वास्तव में एक दिलचस्प सवाल है जो यहां के कई उत्तरों ने ग्रहण किया है।

सीपीयू सुरक्षा मॉडल

सबसे सीपीयू आर्किटेक्चर पर चलने वाला पहला प्रोग्राम इनर रिंग या रिंग 0 के अंदर चलता है । एक विशिष्ट सीपीयू आर्क इम्प्लीमेंट रिंग कैसे बदलता है, लेकिन यह खड़ा है कि लगभग हर आधुनिक सीपीयू में ऑपरेशन के कम से कम 2 मोड हैं, एक जो विशेषाधिकार प्राप्त है और 'नंगे मेटल' कोड चलाता है जो सीपीयू प्रदर्शन कर सकता है और कोई भी कानूनी कार्रवाई कर सकता है। अविश्वसनीय और संरक्षित कोड चलाता है जो केवल क्षमताओं के एक निर्धारित सुरक्षित सेट को निष्पादित कर सकता है। हालांकि कुछ सीपीयू में ग्रैन्युलैरिटी अधिक होती है और वीएम को सुरक्षित रूप से उपयोग करने के लिए कम से कम 1 या 2 अतिरिक्त रिंग्स की आवश्यकता होती है (अक्सर इसे नकारात्मक संख्याओं के साथ लेबल किया जाता है) हालांकि यह इस उत्तर के दायरे से परे है।

जहां OS आता है

अर्ली सिंगल टास्किंग ओएस

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

यह कोड वास्तव में काफी हद तक OS अज्ञेयवादी था, जब तक कि आपके पास लोडर था जो प्रोग्राम को मेमोरी में लोड करने में सक्षम था (शुरुआती बाइनरी प्रारूपों के लिए बहुत सरल) और कोड किसी भी ड्राइवर पर भरोसा नहीं करता था, सभी हार्डवेयर एक्सेस को लागू करने के तहत इसे चलाना चाहिए कोई भी OS जब तक वह रिंग 0. में चलाया जाता है, तो नोट, इस तरह का एक बहुत ही सरल ओएस आमतौर पर एक मॉनिटर कहलाता है यदि इसका उपयोग केवल अन्य प्रोग्राम चलाने के लिए किया जाता है और कोई अतिरिक्त कार्यक्षमता प्रदान नहीं करता है।

आधुनिक मल्टी टास्किंग ओएस

UNIX सहित अधिक आधुनिक ऑपरेटिंग सिस्टम , NT के साथ शुरू होने वाले विंडोज के संस्करण और अन्य विभिन्न अब अस्पष्ट OSes ने इस स्थिति में सुधार करने का निर्णय लिया, उपयोगकर्ता मल्टीटास्किंग जैसी अतिरिक्त सुविधाएँ चाहते थे ताकि वे एक बार में एक से अधिक एप्लिकेशन चला सकें और सुरक्षा हो, इसलिए बग ( या दुर्भावनापूर्ण कोड) किसी एप्लिकेशन में अब मशीन और डेटा को असीमित नुकसान नहीं पहुंचा सकता है।

यह ऊपर उल्लिखित रिंगों का उपयोग करके किया गया था, ओएस रिंग 0 में चलने वाली एकमात्र जगह लेगा और अनुप्रयोग बाहरी अविश्वसनीय रिंगों में चलेगा, केवल संचालन के एक सीमित सेट को निष्पादित करने में सक्षम होगा जिसे ओएस ने अनुमति दी थी।

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

प्रत्येक OS ने इन सुरक्षा के लिए एक अलग कार्यान्वयन का फैसला किया, आंशिक रूप से वास्तुकला के आधार पर ओएस को डिजाइन किया गया था और आंशिक रूप से ओएस के डिजाइन और सिद्धांतों के आधार पर प्रश्न में, UNIX उदाहरण के लिए बहु उपयोगकर्ता उपयोग और केंद्रित होने वाली मशीनों पर ध्यान केंद्रित किया। एक उपयोगकर्ता के साथ धीमे हार्डवेयर पर चलने के लिए, विंडोज़ के लिए उपलब्ध सुविधाओं को सरल बनाने के लिए डिज़ाइन किया गया था। जिस तरह से उपयोगकर्ता-स्पेस प्रोग्राम भी ओएस पर बात करते हैं, वह X86 पर पूरी तरह से अलग है क्योंकि यह ARM या MIPS पर होगा, उदाहरण के लिए हार्डवेयर पर काम करने की आवश्यकता के आधार पर निर्णय लेने के लिए एक मल्टी-प्लेटफ़ॉर्म OS को मजबूर करना।

इन ओएस विशिष्ट इंटरैक्शन को आमतौर पर "सिस्टम कॉल" कहा जाता है और इसमें शामिल होता है कि कैसे एक यूजर स्पेस प्रोग्राम पूरी तरह से ओएस के माध्यम से हार्डवेयर के साथ इंटरैक्ट करता है, वे मूल रूप से ओएस के फ़ंक्शन के आधार पर भिन्न होते हैं और इस प्रकार एक प्रोग्राम जो सिस्टम कॉल के माध्यम से अपना काम करता है, को उसकी जरूरत होती है ओएस विशिष्ट हो।

कार्यक्रम लोडर

सिस्टम कॉल के अलावा, प्रत्येक OS एक प्रोग्राम को द्वितीयक भंडारण माध्यम से और मेमोरी में लोड करने के लिए एक अलग विधि प्रदान करता है , एक विशिष्ट ओएस द्वारा लोड करने योग्य होने के लिए प्रोग्राम में एक विशेष हेडर होना चाहिए जिसमें ओएस का वर्णन हो कि यह कैसे हो सकता है। लोड किया गया और चला।

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

पुस्तकालय

प्रोग्राम शायद ही कभी सिस्टम कॉल का सीधे उपयोग करते हैं, हालांकि, वे लगभग विशेष रूप से अपनी कार्यक्षमता प्राप्त करते हैं, हालांकि लाइब्रेरी जो सिस्टम कॉलिंग को प्रोग्रामिंग भाषा के लिए थोड़े मैत्रीपूर्ण प्रारूप में लपेटते हैं, उदाहरण के लिए, सी में सी मानक लाइब्रेरी है और लिनक्स के तहत glibc और इसी तरह और win32 lib के तहत विंडोज एनटी और इसके बाद के संस्करण, अधिकांश अन्य प्रोग्रामिंग भाषाओं में भी समान पुस्तकालय हैं जो एक उपयुक्त तरीके से सिस्टम कार्यक्षमता को लपेटते हैं।

ये लाइब्रेरी कुछ हद तक ऊपर बताए गए क्रॉस प्लेटफॉर्म के मुद्दों को भी दूर कर सकती हैं, पुस्तकालयों की एक श्रृंखला है जो अनुप्रयोगों के लिए एक समान मंच प्रदान करने के लिए डिज़ाइन की गई हैं, जबकि आंतरिक रूप से एसडीएल जैसे ओएस की एक विस्तृत श्रृंखला के लिए कॉल का प्रबंधन करते हैं , इसका मतलब यह है कि हालांकि प्रोग्राम बाइनरी संगत नहीं हो सकते हैं, जो प्रोग्राम इन पुस्तकालयों का उपयोग करते हैं वे प्लेटफार्मों के बीच आम स्रोत हो सकते हैं, जिससे पोर्टिंग को सरल बनाने के साथ-साथ पुन: उपयोग में लाया जा सकता है।

इसके बाद के संस्करण के अपवाद

यहां तक ​​कि सभी के बावजूद, मैंने कहा है कि एक से अधिक ऑपरेटिंग सिस्टम पर प्रोग्राम चलाने में सक्षम नहीं होने की सीमाओं को दूर करने का प्रयास किया गया है। कुछ अच्छे उदाहरण वाइन प्रोजेक्ट हैं, जिन्होंने सफलतापूर्वक विंड ३२ प्रोग्राम को विभिन्न यूनिक्स पर चलाने के लिए विंड ३२ प्रोग्राम लोडर, बाइनरी फॉर्मेट और सिस्टम लाइब्रेरी दोनों का अनुकरण किया है। लिनक्स सॉफ्टवेयर चलाने के लिए कई BSD UNIX ऑपरेटिंग सिस्टम को अनुमति देने वाली एक संगतता परत भी है और निश्चित रूप से Apple के अपने शिम को MacOS X के तहत पुराने MacOS सॉफ़्टवेयर को चलाने की अनुमति देता है।

हालाँकि ये परियोजनाएँ मैन्युअल विकास प्रयास के विशाल स्तरों के माध्यम से काम करती हैं। इस बात पर निर्भर करता है कि दोनों ओएस अलग-अलग हैं, कठिनाई एक छोटे से छोटे शिम से दूसरे ओएस के पूर्ण अनुकरण के करीब है जो अक्सर अपने आप में एक संपूर्ण ऑपरेटिंग सिस्टम लिखने की तुलना में अधिक जटिल होती है और इसलिए यह अपवाद है और नियम नहीं।

Comments

+1 "सॉफ़्टवेयर OS विशिष्ट क्यों है?" क्योंकि इतिहास।

— पॉल ड्रेपर

CPU सुरक्षा मॉडल x86- उत्पन्न है? मॉडल का आविष्कार क्यों और कब किया गया था?

— n611x007

@naxa नहीं, यह लंबे समय से x86 से पहले है, इसे पहली बार 1969 में मल्टिक्स के लिए आंशिक रूप से लागू किया गया था, जो कि जीई -645 कंप्यूटर में इस मॉडल की आवश्यकता वाले उपयोगी बहु-उपयोगकर्ता समय-साझाकरण सुविधाओं वाला पहला ओएस है , हालांकि यह कार्यान्वयन अधूरा था और इस पर निर्भर था सॉफ्टवेयर का समर्थन, हार्डवेयर में पहला पूर्ण और सुरक्षित कार्यान्वयन इसके उत्तराधिकारी, हनीवेल 6180 में था । यह पूरी तरह से हार्डवेयर आधारित था और मल्टीिक्स को क्रॉस-हस्तक्षेप करने के अवसर के बिना कई उपयोगकर्ताओं से कोड चलाने की अनुमति दी।

— वैलिट

@Vality इसके अलावा, IBM LPAR ~ 1972 है।

— इलियट फ्रिस्क

@ElliottFrisch वाह, यह प्रभावशाली है। मुझे एहसास नहीं था कि यह बहुत जल्दी था। उस जानकारी के लिए धन्यवाद।

— वैलिटी

Answer 2

जैसा कि आप देख सकते हैं, एपीआई को ऑपरेटिंग सिस्टम के एक भाग के रूप में संकेत नहीं दिया गया है।

मुझे लगता है कि आप आरेख में बहुत अधिक पढ़ रहे हैं। हां, एक ओएस एक बाइनरी इंटरफेस को निर्दिष्ट करेगा कि ऑपरेटिंग सिस्टम फ़ंक्शन को कैसे बुलाया जाता है, और यह निष्पादनयोग्य के लिए एक फ़ाइल प्रारूप भी परिभाषित करेगा, लेकिन यह एक एपीआई भी प्रदान करेगा, जो कि फ़ंक्शन के कैटलॉग प्रदान करने के अर्थ में है ओएस सेवाओं को लागू करने के लिए एक आवेदन।

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

Printf C रन टाइम लाइब्रेरी से एक फ़ंक्शन है और एक सामान्य कार्यान्वयन में एक काफी जटिल फ़ंक्शन है। यदि आप गूगल करते हैं तो आप ऑनलाइन कई संस्करणों के लिए स्रोत पा सकते हैं। एक के निर्देशित दौरे के लिए इस पृष्ठ को देखें । घास में नीचे हालांकि यह एक या एक से अधिक सिस्टम कॉल करता है, और उनमें से प्रत्येक सिस्टम कॉल होस्ट ऑपरेटिंग सिस्टम के लिए विशिष्ट है।

Comments

क्या होगा यदि सभी कार्यक्रम दो नंबर जोड़ने के लिए थे, जिसमें कोई इनपुट या आउटपुट नहीं था। क्या वह कार्यक्रम अभी भी ओएस विशिष्ट होगा?

— पॉल

OS'es का अभिप्राय अधिकतर हार्डवेयर विशिष्ट सामान को पीछे की ओर / एक अमूर्त परत में रखना है। हालांकि, ओएस खुद (अमूर्त) कार्यान्वयन से कार्यान्वयन तक भिन्न हो सकता है। वहाँ कुछ OS'es (अधिक या कम) का पालन करना है और शायद कुछ अन्य लेकिन समग्र OS'es अमूर्त के उनके "दृश्यमान" भाग में बहुत अधिक भिन्न होते हैं। जैसा कि पहले कहा गया था: आप खिड़कियों पर / घर / उपयोगकर्ता नहीं खोल सकते हैं और आप * N * X सिस्टम पर HKEY_LOCAL_MACHINE \ ... का उपयोग नहीं कर सकते। आप इसके लिए वर्चुअल ("एमुलेशन") सॉफ़्टवेयर लिख सकते हैं ताकि इन सिस्टमों को एक साथ पास लाने में मदद मिल सके लेकिन यह हमेशा "3rd पार्टी" (OS POV से) होगा।

— RobIII

@Paul हाँ। विशेष रूप से, जिस तरह से इसे एक निष्पादन योग्य में पैक किया जाता है वह ओएस-विशिष्ट होगा।

— ऑरेंजडॉग

@TimSeguine मैं आपके एक्सपी बनाम 7 के उदाहरण से असहमत हूं। माइक्रोसॉफ्ट द्वारा यह सुनिश्चित करने के लिए बहुत काम किया जाता है कि एक ही एपीआई 7 में मौजूद है जैसा कि एक्सपी में था। स्पष्ट रूप से यहां क्या हुआ है कि कार्यक्रम एक निश्चित एपीआई या अनुबंध के खिलाफ चलाने के लिए डिज़ाइन किया गया था। नया OS बस उसी API / अनुबंध का पालन करता है। विंडोज़ के मामले में हालांकि एपीआई बहुत अधिक मालिकाना है, यही वजह है कि कोई अन्य ओएस विक्रेता इसका समर्थन नहीं करता है। फिर भी बहुत सारे कार्यक्रमों के उदाहरण हैं जो 7. पर नहीं चलते हैं

— ArTs

@Paul: कोई प्रोग्राम जो कोई इनपुट / आउटपुट नहीं करता है, वह खाली प्रोग्राम है , जिसे किसी भी ऑप को संकलित करना चाहिए।

— बर्गी

Answer 3

क्या संकलक OS को संकलित करते समय कुछ भी विशिष्ट कर रहा है?

शायद। संकलन और लिंकिंग प्रक्रिया के दौरान कुछ बिंदु पर, आपका कोड ओएस-विशिष्ट बाइनरी में बदल जाता है और किसी भी आवश्यक लाइब्रेरी से जुड़ा होता है। आपके प्रोग्राम को एक प्रारूप में सहेजा जाना है कि ऑपरेटिंग सिस्टम को उम्मीद है कि ओएस प्रोग्राम को लोड कर सकता है और इसे निष्पादित करना शुरू कर सकता है। इसके अलावा, आप मानक लाइब्रेरी फ़ंक्शन को कॉल कर रहे हैं printf(), जो कुछ स्तर पर उन सेवाओं के संदर्भ में लागू किया जाता है जो ऑपरेटिंग सिस्टम प्रदान करता है।

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

Answer 4

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

इसके बाद, प्रत्येक OS हार्डवेयर परत से बात करने के लिए पुस्तकालयों का एक अलग सेट प्रदान करता है। ये आपके द्वारा उल्लिखित एपीआई हैं, और वे आमतौर पर पुस्तकालय होते हैं जो डेवलपर को सरल इंटरफ़ेस प्रस्तुत करते हैं, इसे अधिक जटिल, अधिक विशिष्ट कॉल ओएस के स्वयं में अनुवाद करते हुए, ये कॉल अक्सर अनजाने या सुरक्षित होते हैं। यह परत अक्सर काफी ग्रे होती है, नए "OS" API के साथ आंशिक रूप से या पूरी तरह से पुराने APIs पर बनाए जाते हैं। उदाहरण के लिए, विंडोज में, पिछले कुछ वर्षों में Microsoft द्वारा बनाए गए कई नए APIs मूल Win32 API के शीर्ष पर अनिवार्य रूप से परतें हैं।

एक मुद्दा जो आपके उदाहरण में नहीं उठता है, लेकिन यह उन बड़े लोगों में से एक है जो डेवलपर्स का सामना करते हैं, एक GUI को पेश करने के लिए विंडो मैनेजर के साथ इंटरफेस है। चाहे विंडो मैनेजर "OS" का हिस्सा हो, कभी-कभी आपके दृष्टिकोण पर निर्भर करता है, साथ ही साथ OS भी, Windows में GUI के साथ OS को एक गहरे स्तर पर एकीकृत किया जा रहा है, जबकि Linux और OS X पर GUI अधिक सीधे अलग हो गए। यह बहुत महत्वपूर्ण है क्योंकि आज लोग जिसे आमतौर पर "द ऑपरेटिंग सिस्टम" कहते हैं, पाठ्यपुस्तकों का वर्णन करने की तुलना में बहुत बड़ा जानवर है, क्योंकि इसमें कई, कई एप्लिकेशन स्तर के घटक शामिल हैं।

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

Comments

यह ध्यान देने योग्य हो सकता है कि लोड किए गए कोड को रखने के लिए सरल निष्पादन योग्य प्रारूपों को केवल थोड़ी मात्रा में रैम (यदि कोई हो) का उपयोग करके लोड किया जा सकता है, जबकि अधिक जटिल प्रारूपों के दौरान और कुछ मामलों में अधिक बड़े रैम पदचिह्न की आवश्यकता हो सकती है। लोडिंग के बाद भी। MS-DOS COM फ़ाइलों को 63.75K तक लोड करेगा, केवल अनुक्रमिक बाइट्स को RAM पढ़कर एक मनमाने खंड के 0x100 पर शुरू होने वाले, अंत पते के साथ CX लोड करें, और उस पर कूदें। सिंगल-पास संकलन बिना बैक-पैचिंग (

— फ्लॉपीज़ के

... संकलक में प्रत्येक रूटीन के साथ सभी पैच-पॉइंट की एक सूची शामिल होती है, जिनमें से प्रत्येक में पिछली ऐसी सूची का पता शामिल होता है, और कोड के अंत में अंतिम सूची का पता लगाना होता है। OS कोड को कच्चे बाइट्स के रूप में लोड करेगा, लेकिन कोड के भीतर एक छोटी दिनचर्या कोड के मुख्य भाग को चलाने से पहले सभी आवश्यक पता पैच लागू कर सकती है।

— सुपरकैट

Answer 5

से एक और उत्तर मेरा:

प्रारंभिक डॉस मशीनों पर विचार करें, और दुनिया के लिए Microsoft का वास्तविक योगदान क्या था:

ऑटोकैड को प्रत्येक प्रिंटर के लिए ड्राइवरों को लिखना पड़ता था जिसे वे प्रिंट कर सकते थे। तो 1-2-3 से कमल किया। वास्तव में, यदि आप अपने सॉफ़्टवेयर को प्रिंट करना चाहते थे, तो आपको अपने ड्राइवरों को लिखना होगा। यदि 10 प्रिंटर और 10 प्रोग्राम थे, तो अनिवार्य रूप से एक ही कोड के 100 अलग-अलग टुकड़ों को अलग-अलग और स्वतंत्र रूप से लिखना पड़ता था।

विंडोज़ 3.1 ने (जीईएम के साथ, और कई अन्य अमूर्त परतों के साथ) को पूरा करने की कोशिश की, जिससे प्रिंटर निर्माता ने अपने प्रिंटर के लिए एक ड्राइवर लिखा और प्रोग्रामर ने विंडोज़ प्रिंटर वर्ग के लिए एक ड्राइवर लिखा।

अब 10 कार्यक्रमों और 10 प्रिंटरों के साथ, कोड के केवल 20 टुकड़ों को लिखना होगा, और चूंकि कोड का माइक्रोसॉफ़्ट पक्ष सभी के लिए समान था, तो एमएस से उदाहरणों का मतलब था कि आपके पास काम करने के लिए बहुत कम काम था।

अब एक कार्यक्रम केवल 10 प्रिंटर तक ही सीमित नहीं था जिसे उन्होंने समर्थन करने के लिए चुना था, लेकिन वे सभी प्रिंटर जिनके निर्माताओं ने विंडोज़ में ड्राइवरों को प्रदान किया था।

इसलिए OS अनुप्रयोगों को सेवाएं प्रदान करता है ताकि अनुप्रयोगों को निरर्थक काम न करना पड़े।

आपका उदाहरण सी प्रोग्राम प्रिंटफ का उपयोग करता है, जो पात्रों को stdout में भेजता है - एक OS विशिष्ट संसाधन जो उपयोगकर्ता इंटरफ़ेस पर वर्ण प्रदर्शित करेगा। प्रोग्राम को यह जानने की आवश्यकता नहीं है कि उपयोगकर्ता इंटरफ़ेस कहाँ है - यह डॉस में हो सकता है, यह एक ग्राफिकल विंडो में हो सकता है, इसे दूसरे प्रोग्राम में पाइप किया जा सकता है और दूसरी प्रक्रिया में इनपुट के रूप में उपयोग किया जा सकता है।

क्योंकि OS इन संसाधनों को प्रदान करता है, प्रोग्रामर बहुत कम काम कर सकते हैं।

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

इसलिए, भले ही निष्पादन योग्य मशीन कोड समान है, और ओएस के संसाधनों की आवश्यकता नहीं है, विंडोज के लिए संकलित एक प्रोग्राम एक अतिरिक्त अनुकरण या अनुवाद परत के बिना, एक ही सटीक हार्डवेयर पर भी ओएस एक्स ऑपरेटिंग सिस्टम पर नहीं चलेगा।

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

Answer 6

वास्तव में, वास्तविक उत्तर यह है कि यदि प्रत्येक OS ने एक ही निष्पादन योग्य बाइनरी फ़ाइल लेआउट को समझ लिया है, और आपने केवल अपने आप को मानकीकृत कार्यों (जैसे सी मानक पुस्तकालय) में सीमित कर दिया है जो कि ओएस प्रदान करता है (जो कि ओएसई प्रदान करते हैं), तो आपका सॉफ्टवेयर होगा वास्तव में, किसी भी OS पर चलते हैं।

बेशक, वास्तविकता यह नहीं है। किसी EXEफ़ाइल में फ़ाइल के समान प्रारूप नहीं है ELF, भले ही दोनों में एक ही CPU के लिए बाइनरी कोड हो। * इसलिए प्रत्येक ऑपरेटिंग सिस्टम को सभी फ़ाइल स्वरूपों की व्याख्या करने में सक्षम होने की आवश्यकता होगी, और उन्होंने बस इसमें ऐसा नहीं किया। शुरुआत, और बाद में ऐसा करने का कोई कारण नहीं था (लगभग निश्चित रूप से तकनीकी कारणों के बजाय व्यावसायिक कारणों से)।

इसके अलावा, आपके कार्यक्रम को संभवतः उन चीजों को करने की ज़रूरत है जो सी लाइब्रेरी परिभाषित नहीं करती हैं कि कैसे करना है (यहां तक ​​कि साधारण चीजों के लिए भी जैसे किसी निर्देशिका की सामग्री को सूचीबद्ध करना), और उन मामलों में हर ओएस आपको अपना स्वयं का फ़ंक्शन प्रदान करता है। कार्य, स्वाभाविक रूप से अर्थ है कि आपके लिए उपयोग करने के लिए एक न्यूनतम सामान्य भाजक नहीं होगा (जब तक कि आप स्वयं उस भाजक को नहीं बनाते )।

तो प्रिंसिपल में, यह पूरी तरह से संभव है। वास्तव में, वाइन लिनक्स पर सीधे विंडोज निष्पादन योग्य चलाता है ।
लेकिन यह काम का एक टन है और (आमतौर पर) व्यावसायिक रूप से अनुचित है।

* नोट: सिर्फ बाइनरी कोड की तुलना में निष्पादन योग्य फ़ाइल के लिए बहुत कुछ है। एक टन जानकारी है जो ऑपरेटिंग सिस्टम को बताती है कि फ़ाइल किस लाइब्रेरी पर निर्भर करती है, उसे कितनी स्टैक मेमोरी की आवश्यकता होती है, यह अन्य लाइब्रेरीज़ को क्या फ़ंक्शंस देता है जो उस पर निर्भर हो सकता है, जहाँ ऑपरेटिंग सिस्टम को प्रासंगिक डीबग जानकारी मिल सकती है, कैसे " "फ़ाइल को फिर से याद रखें" यदि आवश्यक हो, तो अपवाद हैंडलिंग कार्य को सही तरीके से कैसे करें, आदि आदि .... फिर, इसके लिए एक ही प्रारूप हो सकता है जो हर किसी पर सहमत हो, लेकिन बस नहीं है।

Comments

मजेदार तथ्य: एक मानकीकृत पॉज़िज़ बाइनरी प्रारूप है, जिसे ओएसिस के पार चलाया जा सकता है। यह आमतौर पर इस्तेमाल नहीं किया जाता है।

— मार्सिन

@ मार्सिन: लगता है कि आप विंडोज को ओएस नहीं मानते हैं। (या आप कह रहे हैं कि विंडोज POSIX बायनेरिज़ चला सकते हैं?) मेरे जवाब के प्रयोजनों के लिए POSIX उस तरह का मानक नहीं है जिसका मैं उल्लेख कर रहा हूं। POSIX में X, यूनिक्स के लिए है। उदाहरण के लिए विंडोज का उपयोग करने का इरादा कभी नहीं किया गया था, भले ही विंडोज में पॉसिक्स सबसिस्टम हो।

— मेहरदाद

1. कुछ सभी ओएस के बिना कई ओएस पर चल सकता है; 2. Windows चूंकि NT पॉज़िक्स बायनेरिज़ को चलाने में सक्षम है।

— मार्सिन

@ मार्सिन: (1) जैसा मैंने कहा, POSIX में X UNIX के लिए है । यह एक मानक नहीं है जो अन्य OSes द्वारा पालन किया जाना था, यह सिर्फ विभिन्न यूनिक्स के बीच एक आम भाजक तक पहुंचने का एक प्रयास था, जो महान है, लेकिन यह आश्चर्यजनक नहीं है। तथ्य यह है कि वहाँ यूनिक्स OSes के कई स्वाद हैं बाहर बात करने के लिए पूरी तरह से अप्रासंगिक है मैं यूनिक्स की तुलना में अन्य ऑपरेटिंग सिस्टम में संगतता के बारे में बनाने की कोशिश कर रहा हूँ । (२) क्या आप # २ के लिए एक संदर्भ प्रदान कर सकते हैं?

— मेहरदाद

@ मेहरदाद: मार्सिन सही है; विंडोज SUA (यूनिक्स अनुप्रयोगों के लिए सबसिस्टम) POSIX अनुरूप है

— MSalters

Answer 7

आरेख में "एप्लिकेशन" परत (अधिकतर) "लाइब्रेरी" द्वारा "ऑपरेटिंग सिस्टम" परत से अलग होती है, और इसका मतलब है कि "एप्लिकेशन" और "ओएस" को एक दूसरे के बारे में जानने की आवश्यकता नहीं है। यह आरेख में एक सरलीकरण है, लेकिन यह बिल्कुल सच नहीं है।

समस्या यह है कि "लाइब्रेरी" में वास्तव में इसके तीन भाग हैं: कार्यान्वयन, अनुप्रयोग के लिए इंटरफ़ेस, और ओएस के लिए इंटरफ़ेस। सिद्धांत रूप में, पहले दो को "सार्वभौमिक" बनाया जा सकता है जहां तक ​​ओएस का संबंध है (यह उस पर निर्भर करता है जहां आप इसे स्लाइस करते हैं), लेकिन तीसरा भाग - ओएस के लिए इंटरफ़ेस - आमतौर पर नहीं हो सकता। ओएस के लिए इंटरफ़ेस आवश्यक रूप से ओएस, यह प्रदान करने वाले एपीआई, पैकेजिंग तंत्र (जैसे विंडोज डीएलएल द्वारा उपयोग की जाने वाली फ़ाइल प्रारूप, आदि) पर निर्भर करेगा।

क्योंकि "लाइब्रेरी" को आम तौर पर एकल पैकेज के रूप में उपलब्ध कराया जाता है, इसका मतलब है कि एक बार प्रोग्राम का उपयोग करने के लिए "लाइब्रेरी" चुनने के बाद, यह एक विशिष्ट ओएस के लिए होता है। यह दो तरीकों में से एक होता है: ए) प्रोग्रामर पहले से पूरी तरह से चुनता है, और फिर लाइब्रेरी और एप्लिकेशन के बीच बंधन सार्वभौमिक हो सकता है, लेकिन लाइब्रेरी खुद ओएस के लिए बाध्य है; या b) प्रोग्रामर चीजों को सेट करता है इसलिए जब आप प्रोग्राम चलाते हैं तो लाइब्रेरी का चयन किया जाता है, लेकिन फिर प्रोग्राम और लाइब्रेरी के बीच में बाइंडिंग मैकेनिज्म ओएस पर निर्भर होता है (जैसे विंडोज में DLL मैकेनिज्म)। प्रत्येक के पास इसके फायदे और नुकसान हैं, लेकिन किसी भी तरह से आपको पहले से चुनाव करना होगा।

अब, इसका मतलब यह नहीं है कि ऐसा करना असंभव है, लेकिन आपको बहुत चालाक होना चाहिए। समस्या को दूर करने के लिए, आपको रन-टाइम पर लाइब्रेरी को चुनने के मार्ग पर जाना होगा, और आपको एक सार्वभौमिक बाध्यकारी तंत्र के साथ आना होगा जो ओएस पर निर्भर नहीं करता है (इसलिए आप इसे बनाए रखने के लिए जिम्मेदार हैं, बहुत अधिक काम)। कुछ समय के लायक है।

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

अब तक आपने देखा होगा कि मैं कहां जा रहा हूं। जावा जैसे भाषा-मंच बिल्कुल वैसा ही करते हैं। जावा रनटाइम (लाइब्रेरी) आपके जावा प्रोग्राम और लाइब्रेरी (जावा रनटाइम कैसे खुलता है और आपके प्रोग्राम को कैसे चलाता है) के बीच ओएस-न्यूट्रल बाइंडिंग को परिभाषित करता है, और यह वर्तमान ओएस के लिए एक कार्यान्वयन प्रदान करता है। .NET एक हद तक एक ही काम करता है, सिवाय इसके कि Microsoft किसी भी चीज़ के लिए "पुस्तकालय" (रनटाइम) प्रदान नहीं करता है, लेकिन विंडोज (लेकिन अन्य करते हैं - मोनो देखें)। और, वास्तव में, फ्लैश भी यही काम करता है, हालांकि यह ब्राउज़र के दायरे में अधिक सीमित है।

अंत में, कस्टम बंधन तंत्र के बिना एक ही काम करने के तरीके हैं। आप पारंपरिक साधनों का उपयोग कर सकते हैं, लेकिन जब तक उपयोगकर्ता ओएस नहीं उठाता तब तक पुस्तकालय में बाध्यकारी कदम को स्थगित कर दें। जब आप स्रोत कोड वितरित करते हैं तो वास्तव में यही होता है। उपयोगकर्ता आपके कार्यक्रम को लेता है और इसे प्रोसेसर (इसे संकलित करता है) और ओएस (लिंक) को बांधता है जब उपयोगकर्ता इसे चलाने के लिए तैयार होता है।

यह सब इस बात पर निर्भर करता है कि आप परतों को कैसे काटते हैं। दिन के अंत में, आपके पास हमेशा एक कंप्यूटिंग डिवाइस होता है जो विशिष्ट हार्डवेयर के साथ विशिष्ट मशीन कोड चलाता है। परतें काफी हद तक एक वैचारिक ढांचे के रूप में हैं।

Answer 8

सॉफ्टवेयर हमेशा ओएस विशिष्ट नहीं है। दोनों जावा और पहले पी कोड प्रणाली (और यहां तक कि ScummVM) सॉफ्टवेयर है कि ऑपरेटिंग सिस्टम के बीच पोर्टेबल है के लिए अनुमति देते हैं। Infocom ( Zork और Z- मशीन के निर्माता ), एक अन्य वर्चुअल मशीन पर आधारित एक रिलेशनल डेटाबेस भी था । हालाँकि, कुछ स्तर पर कुछ एब्स्ट्रैक्ट को कंप्यूटर पर निष्पादित करने के लिए वास्तविक निर्देशों में भी अनुवाद करना पड़ता है।

Comments

जावा एक आभासी मशीन पर चलता है, हालांकि, जो क्रॉस-ओएस नहीं है। आपको प्रत्येक ओएस के लिए एक अलग JVM बाइनरी का उपयोग करना होगा

— इज़काता 5

@Izkata सच है, लेकिन आप सॉफ्टवेयर (सिर्फ JVM) को फिर से जमा नहीं करते हैं। इसके अलावा, मेरा अंतिम वाक्य देखें। लेकिन मैं इंगित करूंगा कि सूर्य में एक माइक्रो-प्रोसेसर था जो सीधे बाइट-कोड निष्पादित कर सकता था।

— इलियट फ्रिस्क

जावा एक ओएस है, हालांकि यह आमतौर पर एक के रूप में नहीं सोचा जाता है। जावा सॉफ्टवेयर जावा ओएस के लिए विशिष्ट है, और अधिकांश "वास्तविक" ओएस के लिए जावा ओएस एमुलेटर हैं। लेकिन आप किसी भी होस्ट और लक्ष्य OS के साथ एक ही काम कर सकते हैं - जैसे कि WINE का उपयोग करके लिनक्स पर विंडोज सॉफ्टवेयर चलाना।

— इम्बिसिस

@ मिनीबिस मैं और अधिक विशिष्ट होगा। जावा फाउंडेशन क्लासेस (जेएफसी, जावा का मानक पुस्तकालय) एक ढांचा है। जावा अपने आप में एक भाषा है। जेवीएम एक ओएस के समान है: इसके नाम में "वर्चुअल मशीन" है, और इसमें चलने वाले कोड के परिप्रेक्ष्य से ओएस के समान कार्य करता है।

Answer 9

तुम कहो

कुछ ऑपरेटिंग सिस्टम के लिए प्रोग्रामिंग भाषाओं का उपयोग करके उत्पादित सॉफ्टवेयर केवल उनके साथ काम करते हैं

लेकिन आपके द्वारा एक उदाहरण के रूप में दिया जाने वाला कार्यक्रम कई ऑपरेटिंग सिस्टम और यहां तक ​​कि कुछ नंगे-धातु वातावरणों पर भी काम करेगा।

यहाँ महत्वपूर्ण बात स्रोत कोड और संकलित बाइनरी के बीच का अंतर है। सी प्रोग्रामिंग भाषा विशेष रूप से स्रोत रूप में ओएस स्वतंत्र होने के लिए डिज़ाइन की गई है। यह "प्रिंट टू कंसोल" जैसी चीजों की व्याख्या को लागू करने वाले तक छोड़ देता है। लेकिन सी कुछ के लिए अनुपालन किया जा सकता है जो ओएस विशिष्ट है (कारणों के लिए अन्य उत्तर देखें)। उदाहरण के लिए, पीई या ईएलएफ निष्पादन योग्य प्रारूप।

Comments

यह बिल्कुल स्पष्ट है कि ओपी बायनेरिज़ के बारे में पूछ रहा है, न कि सोर्स कोड।

— कालेब

Answer 10

अन्य लोगों ने तकनीकी विवरणों को अच्छी तरह से कवर किया है, मैं कम तकनीकी कारण, यूएक्स / यूआई चीजों का उल्लेख करना चाहता हूं:

एक बार लिखें, हर जगह अजीब महसूस करें

हर ऑपरेटिंग सिस्टम में उपयोगकर्ता इंटरफ़ेस API और डिज़ाइन मानक होते हैं। एक कार्यक्रम के लिए एक उपयोगकर्ता इंटरफ़ेस लिखना संभव है और इसे कई ऑपरेटिंग सिस्टम पर चलाया जाता है, हालांकि ऐसा सभी करते हैं लेकिन गारंटी देते हैं कि कार्यक्रम हर जगह से बाहर महसूस होगा। एक अच्छा उपयोगकर्ता इंटरफ़ेस बनाने के लिए प्रत्येक समर्थित प्लेटफॉर्म के लिए विवरण को ट्विक करने की आवश्यकता होती है।

इनमें से बहुत से छोटे विवरण हैं, लेकिन उन्हें गलत करें और आप अपने उपयोगकर्ताओं को निराश करेंगे:

• Windows और OSX में अलग-अलग क्रम में संवाद की पुष्टि करें; यह गलत है और उपयोगकर्ता मांसपेशियों की मेमोरी द्वारा गलत बटन पर क्लिक करेंगे। विंडोज में उस क्रम में "ओके", "रद्द" है। OSX में ऑर्डर स्वैप किया गया है और डू-इट बटन का पाठ प्रदर्शन की जाने वाली क्रिया का संक्षिप्त विवरण है: "रद्द करें", "चाल में जाएँ"।
• आईओएस और एंड्रॉइड के लिए "गो बैक" व्यवहार अलग है। iOS एप्लिकेशन अपने स्वयं के बैक बटन को आवश्यकतानुसार खींचते हैं, आमतौर पर टॉप-लेफ्ट में। एंड्रॉइड में स्क्रीन रोटेशन के आधार पर निचले-बाएं या निचले-दाएं में एक समर्पित बटन है। एंड्रॉइड के त्वरित पोर्ट गलत तरीके से व्यवहार करेंगे यदि ओएस बैक बटन को अनदेखा किया गया है।
• आईओएस, ओएसएक्स और एंड्रॉइड के बीच मोमेंटम स्क्रॉलिंग अलग है। अफसोस की बात है, यदि आप देशी यूआई कोड नहीं लिख रहे हैं, तो आपको अपने स्वयं के स्क्रॉलिंग व्यवहार को लिखने की संभावना है।

यहां तक ​​कि जब तकनीकी रूप से एक यूआई कोडबेस लिखना संभव होता है जो हर जगह चलता है, तो प्रत्येक समर्थित ऑपरेटिंग सिस्टम के लिए समायोजन करना सबसे अच्छा है।

Answer 11

इस बिंदु पर एक महत्वपूर्ण अंतर संकलक को लिंकर से अलग कर रहा है। संकलक सबसे अधिक संभावना कमोबेश एक ही आउटपुट (विभिन्न #if WINDOWSएस के कारण भिन्नता ) पैदा करता है। दूसरी ओर लिंकर, को सभी प्लेटफ़ॉर्म विशिष्ट सामान को संभालना पड़ता है - पुस्तकालयों को जोड़ना, निष्पादन योग्य फ़ाइल का निर्माण करना आदि।

दूसरे शब्दों में, कंपाइलर ज्यादातर सीपीयू आर्किटेक्चर के बारे में परवाह करता है, क्योंकि यह वास्तविक रन करने योग्य कोड का उत्पादन कर रहा है, और सीपीयू के निर्देशों और संसाधनों का उपयोग करना है (ध्यान दें कि .NET का IL या JVM का बायटेकोड एक वर्चुअल सीपीयू का निर्देश सेट माना जाएगा। इस दृश्य में)। यही कारण है कि आप के लिए अलग से कोड संकलन चाहिए x86और ARMउदाहरण के लिए,।

दूसरी ओर, लिंकर को यह सभी कच्चे डेटा और निर्देश लेने होंगे, और इसे एक प्रारूप में रखना होगा कि लोडर (इन दिनों, यह लगभग हमेशा ओएस होगा), साथ ही किसी भी सांख्यिकीय रूप से जुड़े पुस्तकालयों को जोड़ने के लिए समझ सकता है। (जिसमें डायनेमिक लिंकिंग, मेमोरी आवंटन आदि के लिए आवश्यक कोड भी शामिल है)।

दूसरे शब्दों में, आप केवल एक बार कोड को संकलित करने में सक्षम हो सकते हैं और यह लिनक्स और विंडोज दोनों पर चल सकता है - लेकिन आपको इसे दो बार लिंक करना होगा, दो अलग-अलग निष्पादनयोग्य का उत्पादन करना होगा। अब, व्यवहार में, आपको अक्सर कोड में भी भत्ते बनाने पड़ते हैं (यही वह जगह है जहाँ (पूर्व-) संकलक निर्देश आते हैं), इसलिए एक बार लिंक को दो बार भी उपयोग नहीं किया जाता है। यह उल्लेख नहीं करने के लिए कि लोग निर्माण के दौरान संकलन और लिंकिंग को एक ही चरण के रूप में मान रहे हैं (जैसे आप अब संकलक के अंगों की परवाह नहीं करते हैं)।

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

Comments

इस महज में विस्तार से बताया अंक दोहराने के लिए लगता है इस और इस से पहले जवाब है कि पोस्ट किए गए थे कल

— कुटकी