Windows 95 में MS-DOS का उपयोग दो उद्देश्यों के लिए किया गया था:
- उसने एक बूटलोडर के रूप में कार्य किया।
- इसने 16-बिट ड्राइवरों के साथ एक संगतता परत के रूप में काम किया।
जब Windows 95 शुरू हुआ, तो MS-DOS का एक विशेष संस्करण पहले लोड किया गया था, यह वह था जिसने आपकी
CONFIG.SYS फ़ाइल को संसाधित किया,
COMMAND.COM लॉन्च किया, जिसने आपके
AUTOEXEC.BAT निष्पादित किया
AUTOEXEC.BAT और अंततः
WIN.COM निष्पादित
WIN.COM , जिसने 32 बूट प्रक्रिया शुरू की। -बिट वर्चुअल मशीन मैनेजर
VMM ।
एमएस-डॉस का यह विशेष संस्करण इस हद तक पूरी तरह कार्यात्मक था कि शब्द "पूरी तरह कार्यात्मक" आम तौर पर एमएस-डॉस पर लागू होते हैं। यह कोई अन्य तरीका नहीं हो सकता है, एमएस-डॉस इम्यूलेशन मोड में प्रवेश करने पर, केवल यह संस्करण काम कर रहा है।
WIN.COM प्रोग्राम ने डाउनलोड करना शुरू कर दिया जो ज्यादातर लोग खुद को विंडोज कहते हैं। MS-DOS की एक प्रति का उपयोग करते हुए, उसने वर्चुअल मशीन मैनेजर डाउनलोड किया,
SYSTEM.INI फ़ाइल को पढ़ा, वर्चुअल डिवाइस ड्राइवरों को लोड किया, फिर EMM386 (यदि वहाँ एक था) को बंद कर दिया और संरक्षित मोड में बदल दिया। अधिकांश लोगों के दृष्टिकोण से "रियल विंडोज" - यह एक संरक्षित मोड है।
संरक्षित मोड में, वर्चुअल डिवाइस ड्राइवरों ने अपना जादू किया। उनके कार्यों में
से MS-DOS की संपूर्ण स्थिति को
खींच रहा था, इसे 32-बिट फ़ाइल सबसिस्टम की स्थिति में स्थानांतरित कर रहा था और MS-DOS को अक्षम कर रहा था। सभी आगे की फ़ाइल संचालन को 32-बिट फ़ाइल सबसिस्टम में भेजा गया था। जब प्रोग्राम
int 21h तक पहुंच गया, तो 32-बिट फ़ाइल सबसिस्टम प्रसंस्करण के लिए जिम्मेदार निकला।
यह वह जगह है जहाँ दूसरी MS-DOS भूमिका निभाई जाती है। आप देखते हैं, MS-DOS प्रोग्राम और ड्राइवर ऑपरेटिंग सिस्टम की गहराई में एम्बेडेड होना पसंद करते थे। वे
int 25h हैंडलर की जगह ले सकते हैं, वे सिस्टम कोड को पैच कर सकते हैं, वे निचले स्तर के डिस्क हैंडलर को
int 25h और
int 26h । वे
int 13h जैसे BIOS इंटरप्ट के साथ माइंड-ब्लोइंग चीजें भी कर सकते हैं, जो डिस्क के साथ काम करने के लिए जिम्मेदार है।
जब प्रोग्राम
int 21h तक पहुंच गया, तो अनुरोध पहले 32-बिट फ़ाइल सबसिस्टम में भेजा गया था, जहां कुछ प्रीप्रोसेसिंग हुई थी। फिर, यदि फ़ाइल सबसिस्टम ने पाया कि किसी ने
int 21h वेक्टर को इंटरसेप्ट किया है, तो यह इंटरसेप्टर को निष्पादित करने की अनुमति देने के
लिए 16-बिट कोड पर
वापस आ जाएगा। वेक्टर
int 21h बदलना वैचारिक रूप से एक खिड़की को उपवर्ग के समान है। आप पुराने वेक्टर प्राप्त करें और नया वेक्टर सेट करें। जब आपके द्वारा सेट किया गया हैंडलर कहा जाता है, तो आप कुछ करते हैं, और फिर पुराने हैंडलर को कॉल करते हैं। पुराने हैंडलर से लौटने के बाद, आप नियंत्रण वापस करने से पहले कुछ और कर सकते हैं।
CONFIG.SYS से लोड किए गए 16-बिट ड्राइवरों में से एक
IFSMGR.SYS था। उनका कार्य
पहले MS-DOS को
रोकना था, इससे पहले कि अन्य सभी ड्राइवरों और कार्यक्रमों को मौका मिले! इस ड्राइवर ने 32-बिट फ़ाइल सबसिस्टम के साथ साजिश रची,
16-बिट कोड से वापस 32-बिट पर लौटा ताकि फाइल सबसिस्टम अपना काम जारी रख सके।
दूसरे शब्दों में, एमएस-डॉस सिर्फ एक असाधारण कुशल
डिकॉय बतख था । 16-बिट ड्राइवरों और कार्यक्रमों ने पैच और इंटरसेप्ट किए गए हैंडलर जो उन्हें असली एमएस-डॉस की तरह दिखते थे, लेकिन वास्तव में वे चारा थे। यदि 32-बिट फ़ाइल सबसिस्टम ने देखा कि किसी ने चारा खरीदा था, तो उसने डिकॉय बतख को शांत कर दिया।
चलो "दुर्भावनापूर्ण" ड्राइवरों और कार्यक्रमों के बिना एक प्रणाली से शुरू करते हैं जिन्हें एमएस-डॉस में पेश किया गया है।
यह एक स्वर्ग है। 32-बिट फ़ाइल सबसिस्टम कष्टप्रद ड्राइवरों के साथ बातचीत किए बिना सभी काम करने में सक्षम था जो फैंसी चीजें करते हैं। MS-DOS राज्य चर को अद्यतन करने के अतिरिक्त चरण पर ध्यान दें। यद्यपि हमने डाउनलोड के दौरान उन्हें निकाला, हम उन्हें अद्यतित रखते हैं, क्योंकि ड्राइवर और प्रोग्राम अक्सर उनके बारे में "जानते" थे, ऑपरेटिंग सिस्टम को दरकिनार कर दिया और सीधे राज्य चर के साथ काम किया। नतीजतन, फ़ाइल सबसिस्टम MS-DOS जिम्मेदारी के भ्रम का समर्थन करने वाला था (भले ही MS-DOS अब वास्तविकता में काम नहीं कर रहा था) ताकि ऐसे ड्राइवरों और कार्यक्रमों ने देखा कि वे क्या उम्मीद करते थे।
यह भी ध्यान दें कि अलग-अलग आभासी मशीनों के लिए राज्य चर अलग-अलग होते हैं। (अर्थात, प्रत्येक खुले MS-DOS सत्र को राज्य चर की अपनी प्रतिलिपि प्राप्त होती है।) अंत में,
प्रत्येक MS-DOS सत्र में एक अलग वर्तमान फ़ोल्डर , एक अलग फ़ाइल तालिका और जैसी थी। हालांकि, यह सब एक प्रदर्शन था, क्योंकि खुली फाइलों की वास्तविक सूची 32-बिट फ़ाइल सबसिस्टम में संग्रहीत की गई थी। यह अन्यथा नहीं हो सकता है, क्योंकि डिस्क कैश को लगातार होना चाहिए, और फ़ाइल साझा प्रतिबंधों को विश्व स्तर पर जांचना था। यदि एक एमएस-डॉस सत्र ने विशेष पहुंच के लिए एक फ़ाइल खोली है, तो उसी फ़ाइल को खोलने के लिए किसी अन्य एमएस-डॉस सत्र में चल रहे एक कार्यक्रम का प्रयास विफल होना चाहिए।
खैर, यह एक साधारण मामला था। मुश्किल मामला: आपके पास एक ड्राइवर था जो
int 21h इंटरसेप्ट करता था। मुझे नहीं पता कि यह ड्राइवर क्या करता है, उदाहरण के लिए, यह एक नेटवर्क ड्राइवर है जो नेटवर्क ड्राइव के लिए I / O को स्वीकार करता है और किसी विशेष रूप से इसे संसाधित करता है। यह भी मान लीजिए कि MS-DOS सत्र में चल रहे कुछ TSR प्रोग्राम ने
int 21h को स्क्रीन 1 में प्रिंट करने के लिए इंटरसेप्ट किया
जब int 21h कहा जाता है, और 2 जब int 21h समाप्त होता है । आइए हम स्थानीय ड्राइव से अपील करें (नेटवर्क एक नहीं, इसलिए नेटवर्क ड्राइवर कुछ भी नहीं करता है):
ध्यान दें कि 32-बिट फ़ाइल सबसिस्टम अभी भी सभी काम करता है। कॉल केवल 16-बिट एमएस-डॉस की जिम्मेदारी के भ्रम को बनाए रखने के लिए पूरी 16-बिट श्रृंखला के माध्यम से जाता है। 16-बिट दुनिया में, केवल TSR और ड्राइवर द्वारा स्थापित कोड को
IFSMGR गया
IFSMGR , साथ ही घटकों को जोड़ने वाला
IFSMGR का एक छोटा सा टुकड़ा। कोई 16-बिट MS-DOS कोड निष्पादित नहीं किया गया था। 32-बिट फ़ाइल सिस्टम ने MS-DOS से सभी कार्य को रोक दिया।
एक समान नृत्य "सामान्य ऑपरेशन को बाधित करने के लिए, लेकिन असामान्य क्रियाओं के लिए यदि किसी ने असामान्य कार्यों के लिए कहा है" तब होने की अनुमति दी जब I / O सबसिस्टम ने 16-बिट डिवाइस चालकों से आपकी हार्ड ड्राइव का नियंत्रण ले लिया। यदि सबसिस्टम ने ड्राइवरों को मान्यता दी है, तो उन्होंने अपनी स्थिति एकत्र की और सभी ऑपरेशनों को उसी तरह से संसाधित किया जैसे कि 16-बिट एमएस-डॉस के बजाय 32-बिट फ़ाइल सबसिस्टम संसाधित संचालन। दूसरी ओर, अगर सबसिस्टम ने किसी ड्राइवर को नहीं पहचाना, तो उसने इसे डिस्क के लिए जिम्मेदार छोड़ दिया। 32-बिट वातावरण से 16-बिट ड्राइवर पर आदेश प्रेषित करने वाले घटक को
RMM कहा जाता था।
यदि आप किसी प्रकार के डिस्क के लिए आरएमएम का उपयोग करने के लिए अशुभ हैं, तो आपने शायद देखा कि इस डिस्क के साथ संचालन का प्रदर्शन भयानक है। इसका कारण तेजी से बहु-थ्रेडेड 32-बिट के बजाय पुराने अजीब 16-बिट ड्राइवर का उपयोग है। (जब 16-बिट ड्राइवर एक I / O ऑपरेशन को संसाधित कर रहा था, तो दूसरे I / O को संसाधित करना संभव नहीं था क्योंकि 16-बिट ड्राइवर मल्टी-थ्रेडिंग के लिए डिज़ाइन नहीं किए गए थे।)
अजीब लग सकता है क्योंकि आरएमएम अपने आतंक के कारण उपयोगी साबित हुआ, क्योंकि इसका उपयोग करना आपके कंप्यूटर को संक्रमित करने वाले एमएस-डॉस वायरस का प्रारंभिक संकेत था। अंत में, एमएस-डॉस वायरस ने टीएसआर और ड्राइवरों के रूप में एक ही काम किया: उन्होंने रुकावट वाले वैक्टर को बाधित किया और आपकी हार्ड ड्राइव का नियंत्रण प्राप्त किया। I / O सबसिस्टम के दृष्टिकोण से, वे बिल्कुल 16-बिट हार्ड डिस्क ड्राइवरों की तरह दिखते थे! जब लोगों ने शिकायत की "विंडोज अचानक बहुत धीमी पड़ने लगी," हमने उन्हें नियंत्रण कक्ष में सिस्टम प्रदर्शन पृष्ठ पर निर्देशित किया और पूछा कि क्या कोई पंक्ति "एमएस-डॉस मोड में कुछ डिस्क काम करती है" या "सभी डिस्क एमएस-डॉस संगतता मोड का उपयोग करते हैं" । यदि हां, तो डिस्क के लिए आरएमएम जिम्मेदार था, और यदि आपने हार्डवेयर नहीं बदला, तो इसका मतलब वायरस था।
अंत में, MS-DOS के कुछ भाग I / O से संबंधित नहीं थे। उदाहरण के लिए, मेमोरी आवंटित
करने के लिए कार्य थे,
FCB प्रारूप में वाइल्डकार्ड के साथ तार पार्सिंग, और जैसे। ऐसे कार्यों को अभी भी MS-DOS द्वारा संसाधित किया गया था, क्योंकि ये केवल "सहायक पुस्तकालय" के कार्य थे और 32-बिट कोड में पुनर्लेखन से कोई लाभ नहीं हुआ, "हाँ, हमने किया" कहने की संभावना को छोड़कर। पुराने 16-बिट कोड ने ठीक काम किया, और तैयार कोड के उपयोग ने हमें ऐसे कार्यक्रमों के साथ संगतता बनाए रखने की अनुमति दी, जिन्होंने ऐसे कार्यों के व्यवहार को बदलने के लिए एमएस-डॉस को पैच किया।
मूल लेख पर पहली टिप्पणी: "सबसे प्रभावशाली यह है कि इस समय का अधिकांश भाग वास्तव में काम करता है (ज्यादातर)।"