रिएक्टोस न्यूज़ रिलीज़ # 89

आरपीसी

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

मेमोरी मैनेजर

कई परीक्षकों ने mshtml.dll फ़ाइल को कॉपी करने का प्रयास करते समय ReactOS स्थापना प्रक्रिया के ठंड के बारे में शिकायत की। समस्या का निदान करने के प्रयासों ने डेवलपर्स को स्मृति प्रबंधक के आंतों में गहराई से ले लिया और समस्याओं की एक विस्तृत श्रृंखला का पता चला। फ्रीज का कारण डेटा संरचनाओं की अशक्तता थी, जिसके कारण mshtml.dll फ़ाइल की प्रतिलिपि बनाते समय हीप प्रबंधक मेमोरी ब्लॉकों को ट्रैक करने की क्षमता खो देता है। इस जानकारी के बिना, ढेर प्रबंधक मेमोरी के अगले ब्लॉक को प्राप्त नहीं कर सका और एक अनंत लूप में लटका दिया गया। पहले से ही तीसरे (या शायद और भी अधिक) विकास टीम ने इस समस्या को खत्म करने में अपना हाथ आजमाया, और वे सभी एक ही निष्कर्ष पर पहुंचे: ARM3 में शुरू की गई मेमोरी मैनेजर की पुनर्लेखन को पूरा किया जाना चाहिए। थॉमस इस समस्या को ठीक करने के लिए टीम के सदस्यों में से एक थे, और पहली बार में तय किया कि त्रुटि सेटपौदी घटक के कारण हुई थी, जो ड्राइवरों, पुस्तकालयों और संबंधित फाइलों को स्थापित करता है। यह सेटटॉप कोड की बल्कि अव्यवस्थित स्थिति और जटिलता के कारण था, इसलिए थॉमस ने सुझाव दिया कि त्रुटि मेमोरी अतिप्रवाह और इसी तरह की समस्याओं के कारण होती है। इस सिद्धांत का परीक्षण करने के लिए, थॉमस ने अपना स्वयं का ढेर प्रबंधक बनाया और इसके शीर्ष पर सेतुपति को दौड़ाया। परिणामस्वरूप, सेतुपति का पुनर्वास किया गया, क्योंकि सेतुपति से संबंधित व्यवधान दिखाई देने लगे। इसका मतलब यह था कि समस्या मेमोरी मैनेजर में बहुत गहरी थी। इससे भी बड़ी निराशा यह थी कि विफलताओं को समय पर निर्भर होना प्रतीत होता था, जो अपने आप में एक संभावित संसाधन संघर्ष का कारण बनता था।

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

माइक्रोकोड प्रोसेसर

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

स्थापना

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

एस / जी डीएमए

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

फ्रीलाडर में मेमोरी ऑप्टिमाइजेशन

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

पथ तय करता है

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

पुनश्च अनुवाद में भाग लिया गया: ईविलसन , सेरोक्स , टिपिस ।

PPS परियोजना अब बिटकॉइन www.reactos.org/en/foundation_donate.html में दान स्वीकार करती है