कैसे शुरू करें और ओएस लिखना बंद न करें

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

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

कैसे शुरू न करें

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

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

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

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

ट्रेनिंग

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

प्रारंभिक शैक्षिक कार्यक्रम के बाद, आपको मुख्य प्रश्नों पर निर्णय लेने की आवश्यकता है:

• लक्ष्य वास्तुकला - x86 (वास्तविक / संरक्षित / लंबी मोड), PowerPC, ARM, ...
• कर्नेल / OS आर्किटेक्चर - मोनोलिथ, मॉड्यूलर मोनोलिथ, माइक्रो कर्नेल, एक्सो-कोर, विभिन्न संकर
• भाषा और इसके संकलक - C, C ++, ...
• कर्नेल फ़ाइल प्रारूप - योगिनी, a.out, कॉफ़, बाइनरी, ...
• विकास का माहौल (हाँ, यह भी एक महत्वपूर्ण भूमिका निभाता है) - IDE, vim, emacs, ...

इसके अलावा, चयनित और निम्नलिखित क्षेत्रों के अनुसार ज्ञान को गहरा करना आवश्यक है:

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

उपकरण

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

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

नमस्ते विश्व!

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

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

इस चरण के सफल होने के बाद, वास्तविक विकास शुरू होता है।

रन-टाइम समर्थन प्रदान करना

चूंकि यह उच्च-स्तरीय भाषाओं में लिखने का प्रस्ताव है, इसलिए संकलक पैकेज के लेखकों द्वारा लागू किए जाने वाले भाषा उपकरणों के हिस्से के लिए समर्थन सुनिश्चित करने के लिए ध्यान रखा जाना चाहिए। उदाहरण के लिए, C ++ के लिए, इसमें शामिल हैं:

• स्टैक पर डेटा ब्लॉक को गतिशील रूप से आवंटित करने के लिए कार्य करता है
• ढेर के साथ काम करें
• कॉपी डेटा ब्लॉक फ़ंक्शन (मेमसीपी)
• कार्यक्रम प्रवेश बिंदु समारोह
• वैश्विक वस्तुओं के डिजाइनरों और विध्वंसक को कॉल करता है
• अपवादों के साथ काम करने के लिए कई कार्य
• अवास्तविक शुद्ध आभासी कार्यों के लिए ठूंठ
• ...

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

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

डिबगिंग

लेख के अंत में डिबगिंग को न देखें। वास्तव में, यह ओएस के विकास में एक बहुत ही गंभीर और कठिन मुद्दा है, क्योंकि सामान्य उपकरण यहां (कुछ अपवादों के साथ) लागू नहीं होते हैं।

आप निम्नलिखित की सलाह दे सकते हैं:

• डिबगिंग निष्कर्ष दिया
• "डीबगर" से तत्काल बाहर निकलने का दावा करें (अगला पैराग्राफ देखें)
• किसी प्रकार का कंसोल डीबगर
• जांचें कि क्या एमुलेटर आपको डिबगर, प्रतीक तालिकाओं या कुछ और कनेक्ट करने की अनुमति देता है

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

• मानक डिबगिंग ऑपरेशन का हिस्सा: ब्रेकप्वाइंट, कॉल स्टैक, मूल्य आउटपुट, डंप डंप, ...
• शेड्यूलर निष्पादन कतार या विभिन्न आँकड़ों के रूप में विभिन्न उपयोगी जानकारी के उत्पादन के लिए कमांड (यह उतना बेकार नहीं है जितना कि यह पहले हो सकता है)
• विभिन्न संरचनाओं की स्थिरता की स्थिति की जाँच करने के लिए आदेश: खाली / व्यस्त मेमोरी सूचियाँ, ढेर या संदेश कतार

विकास

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

इसी तरह के एस.डी.के.

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

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

आगे की कार्रवाई

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

उपयोगी लिंक

हेबेरा पर:
हम अपना OS: अंक 1 लिखते हैं
हम अपना OS: अंक 2 लिखते हैं
हम OSes लिखना जारी रखते हैं। कदम से कदम
संरक्षित मोड क्या है और यह क्या खाता है
पेजिंग और इंटरप्ट हैंडलिंग सीखना
एक मल्टीटास्किंग बातचीत शुरू करना
स्मृति और कार्य

ओएस विकास पर बहुत सारी जानकारी के साथ अन्य स्रोत:
wasm.ru
sysbin.com
osdev.org पर विकि
iakovlev.org
बोना फाइड ओएस