एक निष्पादन योग्य को चलाने के लिए OS कर्नेल की आवश्यकता होगी?

53

मुझे पता है कि जब स्रोत कोड, सी ++ में, संकलित किया जाता है, तो संकलक से आउटपुट मशीन कोड (निष्पादन योग्य) है जो मुझे लगा कि सीधे सीपीयू को निर्देश थे। हाल ही में मैं गुठली पर पढ़ रहा था और मुझे पता चला कि प्रोग्राम सीधे हार्डवेयर तक नहीं पहुंच सकते हैं लेकिन कर्नेल के माध्यम से जाना है।

इसलिए जब हम कुछ सरल स्रोत कोड संकलित करते हैं, तो बस एक printf()फ़ंक्शन के साथ कहते हैं , और संकलन निष्पादन योग्य मशीन कोड का उत्पादन करता है, क्या इस मशीन कोड में प्रत्येक निर्देश सीधे मेमोरी से निष्पादित किया जाएगा (एक बार कोड ओएस द्वारा मेमोरी में लोड हो जाता है) या होगा मशीन कोड में प्रत्येक कमांड को अभी भी निष्पादित होने के लिए ओएस (कर्नेल) से गुजरना होगा?

मैंने एक ऐसा ही सवाल पढ़ा है । यह नहीं बताया कि संकलन के बाद उत्पन्न मशीन कोड सीधे सीपीयू के लिए एक निर्देश है या यदि सीपीयू के लिए सही निर्देश बनाने के लिए इसे फिर से कर्नेल के माध्यम से जाना होगा। यानी, मशीन कोड को मेमोरी में लोड करने के बाद क्या होता है? क्या यह कर्नेल के माध्यम से जाएगा या सीधे प्रोसेसर से बात करेगा?

operating-systems kernel

— GRANZER
स्रोत

29

यदि आप Arduino के लिए कोड लिख रहे हैं तो आपको OS की आवश्यकता नहीं है।

— Stib

12

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

— गाली

1

यह मौजूद है! (संबद्ध नहीं है, बस यह शांत था सोचा) erikyyy.de/invaders

— मोस

9

यह वास्तव में "निष्पादन योग्य", "कर्नेल", "रन", "आवश्यकता", "बात करें", और "से गुजरने" की आपकी सटीक परिभाषा पर निर्भर करता है। उन शर्तों की एक सटीक परिभाषा के बिना, सवाल गैर-जवाबदेह है।

— जोर्ग डब्ल्यू मित्तग

3

@ JörgWMittag - यदि आप पांडित्यपूर्ण होने जा रहे हैं, तो आप केवल उन शर्तों की ही जाँच क्यों कर रहे हैं? वास्तव में सामयिक शब्द जिसे परिभाषित करने की आवश्यकता है, "ऑपरेटिंग सिस्टम" है, जो एमएस-डॉस (और समान एकल-कार्य रनटाइम वातावरण) पर संदिग्ध रूप से लागू होता है। अगर कुछ (गलत जानकारी वाले) लोग सोचते हैं कि पीसी BIOS एक ओएस है , तो क्या सब कुछ कब्र के लिए है? मुझे नहीं लगता। ओपी उन शब्दों को एक संदर्भ में उपयोग करता है जो या तो उचित लगता है (esp। यदि गैर-देशी अंग्रेजी बोलने वाला) या गैर-तकनीकी।

— चूरा

86

जैसा कि किसी ने प्रोग्राम लिखा है जो ओएस के बिना निष्पादित होता है, मैं एक निश्चित उत्तर देता हूं।

एक निष्पादन योग्य को चलाने के लिए OS कर्नेल की आवश्यकता होगी?

यह निर्भर करता है कि उस कार्यक्रम को कैसे लिखा और बनाया गया था।
आप एक प्रोग्राम लिख सकते हैं (यह मानते हुए कि आपके पास ज्ञान है) जिसे ओएस की आवश्यकता नहीं है।
इस तरह के कार्यक्रम को स्टैंडअलोन के रूप में वर्णित किया जाता है ।
बूट लोडर और नैदानिक कार्यक्रम स्टैंडअलोन कार्यक्रमों के लिए विशिष्ट उपयोग हैं।

हालाँकि, कुछ होस्ट OS वातावरण में लिखा और बनाया गया विशिष्ट प्रोग्राम उसी होस्ट OS वातावरण में निष्पादित करने के लिए डिफ़ॉल्ट होगा।
स्टैंडअलोन प्रोग्राम लिखने और बनाने के लिए बहुत स्पष्ट निर्णय और कार्यों की आवश्यकता होती है।

... संकलक से आउटपुट मशीन कोड (निष्पादन योग्य) है जो मुझे लगा कि सीधे सीपीयू को निर्देश थे।

सही बात।

हाल ही में मैं गुठली पर पढ़ रहा था और मुझे पता चला कि प्रोग्राम सीधे हार्डवेयर तक नहीं पहुंच सकते हैं लेकिन कर्नेल के माध्यम से जाना है।

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

इसलिए जब हम कुछ सरल स्रोत कोड संकलित करते हैं, तो बस एक प्रिंटफ () फ़ंक्शन के साथ कहते हैं, और संकलन निष्पादन योग्य मशीन कोड का उत्पादन करता है, क्या इस मशीन कोड में प्रत्येक निर्देश सीधे मेमोरी से निष्पादित किया जाएगा (एक बार ओएस द्वारा मेमोरी में लोड होने के बाद) ) या मशीन कोड में प्रत्येक कमांड को अभी भी निष्पादित होने के लिए ओएस (कर्नेल) से गुजरना होगा?

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

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

ध्यान दें कि आपका प्रश्न ओएस (और एक रनटाइम लाइब्रेरी) के साथ एक वातावरण को निर्धारित करता है।
एक बार सिस्टम बूट हो जाने के बाद, और ओएस को कंप्यूटर पर नियंत्रण दिया जाता है, इस पर प्रतिबंध लगा दिया जाता है कि कोई प्रोग्राम क्या कर सकता है (जैसे कि I / O OS द्वारा निष्पादित किया जाना चाहिए)।
यदि आप एक स्टैंडअलोन प्रोग्राम (यानी ओएस के बिना) निष्पादित करने की अपेक्षा करते हैं, तो आपको ओएस चलाने के लिए कंप्यूटर को बूट नहीं करना चाहिए।

... मशीन कोड मेमोरी में लोड होने के बाद क्या होता है?

जो कि पर्यावरण पर निर्भर करता है।

एक स्टैंडअलोन कार्यक्रम के लिए, इसे निष्पादित किया जा सकता है, अर्थात कार्यक्रम के प्रारंभ पते पर कूदकर नियंत्रण सौंप दिया जाता है।

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

क्या यह कर्नेल के माध्यम से जाएगा या सीधे प्रोसेसर से बात करेगा?

सीपीयू द्वारा मशीन कोड निष्पादित किया जाता है।
वे "कर्नेल के माध्यम से नहीं जाते हैं" , लेकिन न ही वे "प्रोसेसर से बात करते हैं" ।
मशीन कोड (ऑप कोड और ऑपरेंड से मिलकर) सीपीयू को एक निर्देश है जिसे डिकोड किया जाता है और ऑपरेशन किया जाता है।

शायद अगले विषय पर आपको जांच करनी चाहिए सीपीयू मोड ।

— बुरादा
स्रोत

2

"यदि आप एक स्टैंडअलोन प्रोग्राम (यानी ओएस के बिना) निष्पादित करने की उम्मीद करते हैं, तो आपको ओएस चलाने के लिए कंप्यूटर को बूट नहीं करना चाहिए।" पूरी तरह से सही नहीं है। DOS के बाद कई DOS प्रोग्राम लोड किए गए और फिर DOS सेवाओं (पूरी तरह से बिट-बैंगिंग या शायद सीधे BIOS को कॉल करके) को अनदेखा कर दिया गया। Win3.x एक उत्कृष्ट उदाहरण है कि (कुछ दिलचस्प कोने के मामलों को छोड़कर) ने इस बात की अनदेखी की कि डॉस मौजूद था। Win95 / 98 / Me ने भी ऐसा किया। ओएस के कई उदाहरण हैं जो स्टैंडअलोन कार्यक्रमों का समर्थन करते हैं, 8- / 16-बिट युग से कई।

— एरिक टावर्स

8

@ एरिकटोर्स - "डॉस" के अनुसार, आप MS-DOS से मतलब रखते हैं (क्योंकि मैंने DOS का उपयोग MS या Intel से संबंधित नहीं है)? आप एक "OS" का हवाला दे रहे हैं जो OS अवधारणाओं और डिज़ाइन पर मेरे 1970 के कॉलेज की पाठ्यपुस्तकों के मानदंडों से भी मेल नहीं खाता है। MS-DOS की उत्पत्ति CP / M के पीछे (सिएटल कंप्यूटर उत्पाद के माध्यम से) ट्रेस होती है, जिसे स्पष्ट रूप से इसके लेखक गैरी किल्डल द्वारा ओएस नहीं कहा जाता है। एफडब्ल्यूआईडब्ल्यू एक ओएस जो सिस्टम को संभालने के लिए एक कार्यक्रम की अनुमति देता है, सिस्टम संसाधनों के प्रबंधन के अपने मूल कार्य में विफल रहा है। "ओएस के कई उदाहरण हैं जो स्टैंडअलोन कार्यक्रमों का समर्थन करते हैं" - "समर्थन" या रोकने में असमर्थ?

— चूरा

5

... या ProDOS या PC-DOS या DR-DOS या CBM DOS या TRS DOS या फ्लेक्स ...

— Eric Towers

3

मुझे जीसीसी की "फ्रीस्टैंडिंग" शब्दावली पसंद है। अंग्रेजी शब्द में कोड के लिए सभी सही अर्थ हैं जो बिना ओएस के चलता है, शायद "स्टैंडअलोन" से भी बेहतर। उदाहरण के लिए, आप gcc -O2 -ffreestanding my_kernel.c special_sauce.Sएक निष्पादन योग्य बनाने के लिए संकलन कर सकते हैं जो सामान्य पुस्तकालयों या ओएस सामानों में से कोई भी नहीं होगा। (बेशक आपको सामान्य रूप से एक फ़ाइल प्रारूप में उपयोगी लिंक प्राप्त करने के लिए एक लिंकर स्क्रिप्ट की आवश्यकता होगी जिसे बूटलोडर लोड करना चाहेगा!)

— पीटर कॉर्ड्स

4

@PeterCordes "स्टैंडअलोन" सी मानक में प्रयुक्त शब्द है जिसे IMO को कुछ आधिकारिक माना जा सकता है। वैकल्पिक रूप से एक अच्छा शब्द "नॉन-होस्टेड" (जैसा कि ओएस द्वारा होस्ट किया गया है)

— जन डोर्नियाक

38

कर्नेल "सिर्फ" अधिक कोड है। यह सिर्फ इतना है कि कोड एक परत है जो आपके सिस्टम के सबसे निचले हिस्सों और वास्तविक हार्डवेयर के बीच रहता है।

यह सब सीधे सीपीयू पर चलता है, आप बस कुछ भी करने के लिए इसकी परतों के माध्यम से संक्रमण करते हैं।

आपके प्रोग्राम को "कर्नेल" उसी तरह से कर्नेल की आवश्यकता है जैसे printfकि पहले सी कमांड का उपयोग करने के लिए मानक सी लाइब्रेरी की आवश्यकता होती है।

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

मान लें कि आपके पास एक डेस्कटॉप प्रोग्राम है जो डेस्कटॉप विंडो मैनेजर पर चल रहा है, जो आपके कर्नेल पर चल रहा है, जो आपके हार्डवेयर पर चल रहा है।

वहाँ बहुत कुछ है जो आगे बढ़ता है लेकिन इसे सरल रखने देता है ...

अपने टर्मिनल प्रोग्राम में आप अपने प्रोग्राम को प्रिंट करने के लिए चलाते हैं hello world!
टर्मिनल देखता है कि कार्यक्रम hello world!कंसोल के लिए (सी आउटपुट रूटीन के माध्यम से) लिखा गया है
टर्मिनल प्रोग्राम डेस्कटॉप विंडो मैनेजर पर जाता है और कहता है "मुझे hello world!लिखा गया है, क्या आप इसे स्थिति में रख सकते हैं x, yकृपया?"
डेस्कटॉप विंडो मैनेजर कर्नेल तक जाता है "मेरे कार्यक्रमों में से एक आपके ग्राफिक्स डिवाइस को इस स्थिति में कुछ पाठ डालना चाहता है, इसे यार!"
कर्नेल ग्राफिक्स डिवाइस ड्राइवर के लिए अनुरोध को पास करता है, जो इसे इस तरह से प्रारूपित करता है कि ग्राफिक्स कार्ड समझ सकता है
इस बात पर निर्भर करता है कि ग्राफिक्स कार्ड कैसे जुड़ा हुआ है अन्य कर्नेल डिवाइस ड्राइवरों को डेटा को बाहर निकालने के लिए बुलाया जाना चाहिए जैसे कि PCIe जैसी भौतिक डिवाइस बसों में, सही उपकरण का चयन करने जैसी चीजों को संभालना, और यह कि डेटा संबंधित पुल से गुजर सकता है या कन्वर्टर्स
हार्डवेयर सामान प्रदर्शित करता है।

_{यह केवल विवरण के लिए बड़े पैमाने पर निरीक्षण है। खतरनाक इलाके।}

प्रभावी ढंग से सब कुछ आपको लगता है कि हार्डवेयर उपयोग की जरूरत नहीं है, यह प्रदर्शित करते हैं, फाइल या कुछ भी की स्मृति के ब्लॉक, बिट्स कि तरह है कर्नेल में कुछ डिवाइस ड्राइवर के माध्यम से जाने के लिए बाहर काम करने के लिए बिल्कुल कैसे प्रासंगिक डिवाइस के लिए बात करने के लिए। यह एक SATA हार्ड डिस्क कंट्रोलर ड्राइवर के ऊपर एक फाइलसिस्टम ड्राइवर हो जो खुद एक PCIe ब्रिज डिवाइस के ऊपर बैठा हो।

कर्नेल जानता है कि इन सभी उपकरणों को एक साथ कैसे बाँधना है और कार्यक्रमों के लिए अपेक्षाकृत सरल इंटरफ़ेस प्रस्तुत करना है, बिना इन चीजों के बारे में जानने के लिए कि वे इन सभी चीजों को स्वयं कैसे करें।

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

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

यह सब कोड की परतों पर परतों द्वारा नियंत्रित किया जाता है।

— मोकूबाई
स्रोत

न केवल हार्डवेयर पहुंच, कार्यक्रमों के बीच अधिकांश संचार भी कर्नेल के माध्यम से जाता है; जो आमतौर पर कम से कम कर्नेल को शामिल नहीं करता है वह एक अधिक प्रत्यक्ष चैनल स्थापित कर रहा है। हालांकि, प्रश्न के प्रयोजनों के लिए, सभी कार्यक्रमों को एक ही कार्यक्रम में सम्मिलित करने के लिए बहुत सरल मामलों में भी संभव और अभ्यास किया जाता है।

— क्रिस स्ट्रैटन

वास्तव में, आपके टर्मिनल प्रोग्राम को उसी मशीन पर चलने की जरूरत नहीं है, जिस प्रोग्राम में वह सामान लिख रहा है।

— जम्क्सफ़

चूंकि इस प्रश्न में यह स्पष्ट रूप से कहा जा सकता है - ध्यान दें कि जब हम "एक दूसरे से बात कर रहे हैं" कार्यक्रमों के बारे में बात करते हैं, तो यह रूपक है।

— user253751

21

यह पर्यावरण पर निर्भर करता है। कई पुराने (और सरल!) कंप्यूटरों में, जैसे कि IBM 1401, का उत्तर "नहीं" होगा। आपके कंपाइलर और लिंकर ने एक स्टैंडअलोन "बाइनरी" उत्सर्जित किया जो बिना किसी ऑपरेटिंग सिस्टम के चलता था। जब आपका प्रोग्राम चलना बंद हो गया, तो आपने एक अलग लोड किया, जो बिना OS के भी चलता था।

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

इसके अलावा, आधुनिक कंप्यूटर (इसके विपरीत, कहते हैं, 1401) I / O उपकरणों की एक बहुत विस्तृत विविधता के कनेक्शन का समर्थन करते हैं, न कि केवल आईबीएम आपको पुराने दिनों में बेच देगा। आपका कंपाइलर और लिंकर संभवतः सभी संभावनाओं के बारे में नहीं जान सकता है। उदाहरण के लिए, आपके कीबोर्ड को PS / 2, या USB के माध्यम से बाधित किया जा सकता है। ओएस आपको डिवाइस-विशिष्ट "डिवाइस ड्राइवर" स्थापित करने की अनुमति देता है जो उन उपकरणों से बात करना जानता है, लेकिन ओएस के लिए डिवाइस वर्ग के लिए एक सामान्य इंटरफ़ेस प्रस्तुत करता है। तो आपका प्रोग्राम, और यहां तक कि OS, को USB बनाम PS / 2 कीबोर्ड से कीस्ट्रोक्स प्राप्त करने के लिए कुछ भी अलग करने की ज़रूरत नहीं है, या एक स्थानीय SATA डिस्क बनाम USB संग्रहण डिवाइस बनाम संग्रहण तक पहुंचने के लिए, जो कहीं बंद है। एक NAS या SAN पर। उन विवरणों को विभिन्न डिवाइस नियंत्रकों के लिए डिवाइस ड्राइवरों द्वारा नियंत्रित किया जाता है।

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

तो एक आधुनिक सामान्य प्रयोजन के वातावरण में, हाँ - आपको वास्तव में एक ओएस की आवश्यकता है। लेकिन आज भी ऐसे कंप्यूटर हैं जैसे कि वास्तविक समय के नियंत्रक जो एक की आवश्यकता के लिए पर्याप्त जटिल नहीं हैं।

उदाहरण के लिए, Arduino के वातावरण में, वास्तव में एक OS नहीं है। निश्चित रूप से, लाइब्रेरी कोड का एक गुच्छा है जो बिल्ड वातावरण हर "बाइनरी" में बनाता है। लेकिन चूँकि एक प्रोग्राम से दूसरे प्रोग्राम में उस कोड की कोई दृढ़ता नहीं है, इसलिए यह OS नहीं है।

— जेमी हनराहन
स्रोत

10

मुझे लगता है कि कई उत्तर इस प्रश्न को गलत समझते हैं, जो इस बात को उबालता है:

एक संकलक मशीन कोड आउटपुट करता है। क्या यह मशीन कोड सीपीयू द्वारा सीधे निष्पादित किया जाता है, या इसे कर्नेल द्वारा "व्याख्या" किया जाता है?

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

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

— Artelius
स्रोत

1

हालांकि जावा का बायटेकोड आमतौर पर मशीन कोड नहीं है, फिर भी जावा प्रोसेसर मौजूद हैं ।

— रुस्लान

Hypervisers हमेशा व्याख्याकार कभी नहीं रहे हैं। व्याख्या निश्चित रूप से आवश्यक है यदि वर्चुअल मशीन एक निर्देश सेट के रूप में है जो इसके होस्ट के साथ असंगत है, लेकिन समान-आर्किटेक्चर निष्पादन के लिए, यहां तक कि शुरुआती हाइपरविज़र सीधे सीपीयू पर कोड निष्पादित करते हैं (आप paravirtualized कर्नेल की आवश्यकता से भ्रमित हो सकते हैं, बिना सीपीयू के आवश्यक हाइपरविजर समर्थन)।

— टोबे स्पीट

5

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

हाल ही में मैं कर्नेल पर पढ़ रहा था और मुझे पता चला कि प्रोग्राम सीधे हार्डवेयर तक नहीं पहुंच सकते हैं लेकिन कर्नेल के माध्यम से जाना है।

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

क्या इस मशीन कोड में प्रत्येक निर्देश को सीधे मेमोरी से निष्पादित किया जाएगा (एक बार ओएस द्वारा कोड को मेमोरी में लोड किया गया है) या मशीन कोड में प्रत्येक कमांड को अभी भी ओएस (कर्नेल) से गुजरना होगा

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

यह स्पष्ट नहीं करता है कि संकलन के बाद उत्पन्न मशीन कोड सीधे सीपीयू को निर्देश है या फिर सीपीयू के लिए सही निर्देश बनाने के लिए इसे फिर से कर्नेल के माध्यम से जाना होगा?

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

मेमोरी पर लोड किए गए मशीन कोड के बाद क्या होता है? क्या यह कर्नेल के माध्यम से जाएगा या प्रोसेसर से सीधे बात करेगा।

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

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

— एलेक्स
स्रोत

3

इसलिए जब हम एक साधारण स्रोत कोड संकलित करते हैं, तो बस एक प्रिंटफ () फ़ंक्शन के साथ कहते हैं, और संकलन निष्पादन योग्य मशीन कोड का उत्पादन करता है, क्या इस मशीन कोड में प्रत्येक निर्देश सीधे मेमोरी से निष्पादित किया जाएगा (कोड को मेमोरी में लोड करने के बाद) OS द्वारा) या मशीन कोड में प्रत्येक कमांड को अभी भी निष्पादित होने के लिए OS (कर्नेल) से गुजरना होगा?

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

कर्नेल किसी प्रोग्राम में प्रत्येक निर्देश को संसाधित नहीं करता है। यह सिर्फ सीपीयू को साझा करने के लिए प्रोग्राम चलाने के बीच सिस्टम कॉल और स्विच करता है।

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

उपयोगकर्ता-मोड में (कर्नेल के बिना) I / O करना संभव नहीं है, यदि आप I / O पोर्ट या रजिस्टरों को उपकरणों के लिए एक्सेस करते हैं, या उपकरणों से जुड़े पते (किसी भी I / O को निष्पादित करने के लिए आवश्यक एक या दोनों), ये ट्रिगर एक उसी तरह से अपवाद।

एक निष्पादन योग्य को चलाने के लिए OS कर्नेल की आवश्यकता होगी?

निष्पादन योग्य के प्रकार पर निर्भर करता है।

कर्नेल, रैम और हार्डवेयर की साझा पहुंच की मध्यस्थता के अलावा, एक लोडर फ़ंक्शन भी करते हैं।

कई "निष्पादन योग्य प्रारूप", जैसे ईएलएफ या पीई, कोड के अतिरिक्त निष्पादन योग्य फ़ाइल में मेटाडेटा है, और इसे संसाधित करने के लिए लोडर का काम है। अधिक जानकारी के लिए Microsoft के PE प्रारूप के बारे में विवरण पढ़ें ।

ये निष्पादनयोग्य पुस्तकालयों को भी संदर्भित करते हैं (विंडोज .dllया लिनक्स साझा ऑब्जेक्ट .soफ़ाइलें) - उनके कोड को शामिल करना होगा।

यदि आपका कंपाइलर एक ऐसी फाइल का निर्माण करता है, जो एक ऑपरेटिंग सिस्टम लोडर द्वारा प्रोसेस की जानी है, और वह लोडर वहां नहीं है, तो यह काम नहीं करेगा।

क्या आप उस कोड को शामिल कर सकते हैं जो लोडर का काम करता है?

ज़रूर। आपको किसी भी मेटाडेटा को संसाधित किए बिना ओएस को किसी तरह अपने कच्चे कोड को चलाने के लिए मनाने की आवश्यकता है। यदि आपका कोड कर्नेल API कहता है, तो भी यह काम नहीं करेगा।

क्या होगा अगर यह कर्नेल एपीआई नहीं कहता है?

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

क्या होगा अगर आप इसे कर्नेल मोड से चलाते हैं।

तब यह काम करेगा।

— LawrenceC
स्रोत

यह पूरी तरह सही नहीं है। हार्डवेयर एक्सेस की आवश्यकता कर्नेल के माध्यम से जाती है, या कि कर्नेल भी हो सकता है, आज के कई सिस्टमों पर पुष्टिकरण में किया गया एक डिजाइन निर्णय है, लेकिन कई सरल सिस्टमों में भी यह नकारात्मक (यहां तक कि आज तक) बना है।

— क्रिस स्ट्रैटन

मैं बता रहा हूं कि अगर ए) कर्नेल और बी हैं तो चीजें कैसे होती हैं यदि आप एक सीपीयू पर उपयोगकर्ता / पर्यवेक्षक मोड के साथ कोड चला रहे हैं और इसे लागू करने में मदद करने के लिए एक एमएमयू है। हां, MMU या उपयोगकर्ता / पर्यवेक्षक मोड के बिना सीपीयू और माइक्रोकंट्रोलर हैं, और हाँ कुछ सिस्टम पूरे उपयोगकर्ता / पर्यवेक्षक बुनियादी ढांचे का उपयोग किए बिना चलते हैं। Microsoft का पहला Xbox इस तरह का था - भले ही उपयोगकर्ता / पर्यवेक्षक मोड के साथ एक मानक x86 सीपीयू, जो मैं समझता हूं कि यह कभी भी कर्नेल मोड को नहीं छोड़ता है - लोड किए गए गेम को जो कुछ भी चाहिए वह कर सकता है।

— लॉरेंस सी सी

1

MacOS X से पहले मैकिंटोश सिस्टम, एक सामान्य प्रयोजन के कंप्यूटर का एक OS था , जो सामान्य उद्देश्य CPU (68000 परिवार, PowerPC) पर दशकों से स्मृति संरक्षण के लिए समर्थन के साथ चल रहा था (पहले 68000 आधारित कंप्यूटरों को छोड़कर) मुझे लगता है कि स्मृति सुरक्षा का कभी उपयोग नहीं किया गया : कोई भी प्रोग्राम मेमोरी में कुछ भी एक्सेस कर सकता है।

— जिज्ञासु

3

टीएल; डीआर नं।

Arduino विकास एक वर्तमान वातावरण के रूप में ध्यान में आता है जहाँ कोई OS नहीं है। मेरा विश्वास करो, इन बच्चों में से एक पर आपके पास ऑपरेटिंग सिस्टम के लिए जगह नहीं है।

इसी तरह, सेगा जेनेसिस के गेम्स में सेगा द्वारा कॉल करने के लिए ओएस उपलब्ध नहीं था। आपने सिर्फ 68K असेंबलर में अपने खेल को तैयार किया है, सीधे नंगे धातु पर लिख रहे हैं।

या जहां मैंने अपने दांत काटे, इंटेल 8051 पर एम्बेडेड काम कर रहा था। फिर जब आपके पास 2k * 8 फुटप्रिंट के साथ 2716 एप्रोम है, तो आपके पास ऑपरेटिंग सिस्टम के लिए जगह नहीं है।

बेशक, यह शब्द अनुप्रयोग का एक बहुत व्यापक उपयोग मानता है। एक बयानबाजी के सवाल के रूप में, यह अपने आप से पूछने के लायक है कि क्या वास्तव में एक Arduino स्केच एक आवेदन है।

— dgnuff
स्रोत

3

जबकि मैं यह नहीं बताना चाहता हूं कि अन्य उत्तर अपने आप ठीक नहीं हैं, वे बहुत अधिक विवरण प्रदान करते हैं कि, मुझे डर है, अभी भी आप के लिए बहुत अस्पष्ट हैं।

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

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

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

— Gábor
स्रोत

2

आपके कंप्यूटर में पावर अप करने पर चलने वाला BIOS ROM में स्टोर किया गया निष्पादन योग्य कोड है। इसमें मशीन निर्देश और डेटा शामिल हैं। एक कंपाइलर (या असेंबलर) है जो इस BIOS को सोर्स कोड से असेंबल करता है। यह एक विशेष मामला है।

अन्य विशेष मामलों में बूटस्ट्रैप प्रोग्राम शामिल है जो कर्नेल और कर्नेल को स्वयं लोड करता है। इन विशेष मामलों को आम तौर पर C ++ के अलावा अन्य भाषा में कोडित किया जाता है।

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

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

— वाल्टर मिती
स्रोत

2

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

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

यह सब एक बड़ी संख्या में सहायक कोड को व्यक्तिगत कार्यक्रमों से बाहर ले जाने और "ऑपरेटिंग सिस्टम" के रूप में हुआ, जिसमें उपयोगकर्ता कार्यक्रमों से सहायक कोड को लागू करने का एक मानकीकृत तरीका था।

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

Microkernels लिखा गया है कि किसी दिए गए प्रोग्राम को पूर्ण ऑपरेटिंग सिस्टम के बिना चलाने के लिए जो आवश्यक है उसे प्रदान करें। यह अनुभवी उपयोगकर्ताओं के लिए कुछ फायदे हैं जबकि अधिकांश अन्य को दूर करते हैं। आप इसके बारे में विकिपीडिया पृष्ठ पढ़ना चाहते हैं - https://en.wikipedia.org/wiki/Microkernel - यदि आप और अधिक जानना चाहते हैं।

मैंने एक जावा वर्चुअल मशीन को चलाने में सक्षम माइक्रोकर्नल के साथ प्रयोग किया, लेकिन बाद में पाया गया कि इसके लिए मीठी जगह डोकर है।

— थोरबजोरन रावन एंडरसन
स्रोत

1

विशिष्ट डेस्कटॉप OSes में, कर्नेल अपने आप में एक निष्पादन योग्य है। (विंडोज में ntoskrnl.exeलिनक्स है vmlinux, आदि) यदि आपको चलाने के लिए निष्पादन योग्य के लिए कर्नेल की आवश्यकता है, तो वे ओएस मौजूद नहीं हो सकते हैं।

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

— चाओ
स्रोत