मुखपृष्ठ » कैसे » विंडोज के पुराने संस्करणों में मल्टी-टास्किंग कैसे संभव था?

    विंडोज के पुराने संस्करणों में मल्टी-टास्किंग कैसे संभव था?

    यह देखते हुए कि डॉस एक सिंगल-टास्किंग ओएस था और इसके विंडोज़ के शुरुआती संस्करणों के साथ संबंध था, ठीक उसी तरह विंडोज के पहले संस्करण मल्टी-टास्किंग को कैसे पूरा करते थे? आज का SuperUser Q & A पोस्ट इस प्रश्न के उत्तर को देखता है.

    आज का प्रश्न और उत्तर सत्र सुपरयूज़र के सौजन्य से आता है-स्टैक एक्सचेंज का एक उपखंड, क्यू एंड ए वेब साइटों का एक समुदाय-संचालित समूह है।.

    विंडोज 95 स्क्रीनशॉट विकिपीडिया के सौजन्य से.

    प्रश्न

    सुपरयूज़र रीडर LeNoob जानना चाहता है कि विंडोज के पुराने संस्करण मल्टी-टास्किंग सिस्टम के रूप में कैसे चल पाए ?:

    मैंने पढ़ा कि डॉस एक सिंगल-टास्किंग ओएस है। लेकिन अगर विंडोज के पुराने संस्करण (विंडोज 95 भी शामिल हैं?) केवल डॉस के लिए रैपर थे, तो वे मल्टी-टास्किंग ओएस के रूप में कैसे चल सकते थे?

    अच्छा प्रश्न! विंडोज के पुराने संस्करणों ने मल्टी-टास्किंग सिस्टम के रूप में चलाने का प्रबंधन कैसे किया?

    उत्तर

    सुपरयूजर योगदानकर्ताओं बॉब और पीट हमारे लिए जवाब है। पहले अप, बॉब:

    विंडोज 95 एमएस-डॉस के लिए "सिर्फ एक आवरण" से कहीं अधिक था। रायटर चेन का हवाला देते हुए:

    • MS-DOS ने विंडोज 95: 1. में दो उद्देश्य दिए हैं। यह बूट लोडर के रूप में कार्य करता है। & 2.) इसने 16-बिट लीगेसी डिवाइस ड्राइवर परत के रूप में काम किया.

    विंडोज 95 वास्तव में सभी MS-DOS के बारे में बताया गया है, जबकि इसे केवल एक भारी परत के रूप में रखते हुए, सभी भारी उठाने के दौरान हुक / ओवररोड किया गया है। इसने 32-बिट कार्यक्रमों के लिए पूर्व-खाली मल्टी-टास्किंग को भी लागू किया.

    प्री-विंडोज 95

    विंडोज 3.x और पुराने ज्यादातर 16-बिट थे (Win32s के अपवाद के साथ, एक प्रकार की संगतता परत जो पुल 16 और 32, लेकिन हम यहां पर ध्यान नहीं देंगे), DOS पर अधिक निर्भर थे, और केवल सहकारी मल्टी-टास्किंग का उपयोग करते थे - यही वह जगह है जहां वे एक चालू कार्यक्रम को बाहर स्विच करने के लिए मजबूर नहीं करते हैं; वे नियंत्रण प्राप्त करने के लिए चल रहे कार्यक्रम की प्रतीक्षा करते हैं (मूल रूप से, "मैं कर रहा हूँ" ओएस को अगले कार्यक्रम को चलाने के लिए कहकर प्रतीक्षा कर रहा है).

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

    विंडोज 3.x आर्किटेक्चर

    Windows प्रोग्रामों के आरंभिक समय से नियंत्रण कैसे होगा:

    • विंडोज 3.1 सहकारी मल्टी-टास्किंग का उपयोग करता है - जिसका अर्थ है कि प्रत्येक एप्लिकेशन जो चलने की प्रक्रिया में है, को समय-समय पर एक संदेश कतार की जांच करने का निर्देश दिया जाता है ताकि यह पता लगाया जा सके कि कोई अन्य एप्लिकेशन सीपीयू के उपयोग के लिए पूछ रहा है और, यदि हां, तो नियंत्रण प्राप्त करने के लिए वह आवेदन। हालाँकि, कई Windows 3.1 एप्लिकेशन संदेश कतार को केवल बार-बार जांचते हैं, या बिल्कुल नहीं, और सीपीयू के नियंत्रण को ज्यादा से ज्यादा समय के लिए एकाधिकार में रखते हैं। विंडोज 95 जैसी एक पूर्व-खाली मल्टी-टास्किंग प्रणाली सीपीयू को एक रनिंग एप्लिकेशन से दूर ले जाएगी और इसे उन लोगों को वितरित करेगी जिनकी प्रणाली की जरूरतों के आधार पर उच्च प्राथमिकता है।.

    स्रोत

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

    386 संवर्धित मोड?

    नोट: विंडोज 3.x के 386 वर्धित मोड पर कुछ टिप्पणियां आई हैं, जो 32-बिट की जा रही हैं और पूर्व-खाली मल्टी-टास्किंग का समर्थन कर रही हैं.

    यह एक दिलचस्प मामला है। लिंक किए गए ब्लॉग पोस्ट को सारांशित करने के लिए, 386 बढ़ाया मोड मूल रूप से एक 32-बिट हाइपरविजर था, जो आभासी मशीनों को चलाता था। उन वर्चुअल मशीनों में से एक में विंडोज 3.x मानक मोड चला, जो ऊपर सूचीबद्ध सभी सामान करता है.

    MS-DOS उन वर्चुअल मशीनों के अंदर भी चलेगा, और जाहिर तौर पर वे पूर्व-बहु-कार्य वाले थे - इसलिए ऐसा लगता है कि 386 एन्हांस्ड मोड हाइपरवाइजर वर्चुअल मशीनों के बीच सीपीयू समय के स्लाइस साझा करेगा (जिनमें से एक सामान्य 3.x भाग गया अन्य जो MS-DOS चलाते थे), और प्रत्येक VM अपना काम खुद करेगा - 3.x सहकारी बहु-कार्य, जबकि MS-DOS एकल-कार्य होगा.

    MS-DOS

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

    यह सब बिट-नेस की बात है? मैंने मल्टी टास्किंग के बारे में पूछा!

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

    इसके अलावा, चूंकि 32-बिट प्रोग्राम नए थे, इसलिए जब उन्हें जबरन बंद कर दिया गया तो उन्हें काम पर लाना आसान हो गया - जिससे शायद कुछ विरासत 16-बिट प्रोग्राम टूट गए.

    बेशक, यह सब अटकलें हैं। यदि आप वास्तव में जानना चाहते हैं कि एमएस ने विंडोज 3.x (386 एन्हांस्ड मोड के बावजूद) में पूर्व-खाली मल्टी-टास्किंग को लागू क्यों नहीं किया, तो आपको वहां काम करने वाले किसी व्यक्ति से पूछना होगा.

    इसके अलावा, मैं आपकी धारणा को सही करना चाहता था कि विंडोज 95 डॉस के लिए सिर्फ एक आवरण था.

    पीट के जवाब से पीछा किया:

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

    ओएस इस नियंत्रण को लागू कर सकता है, क्योंकि यह सीपीयू को संरक्षित मोड में प्रवेश करने के लिए मजबूर करता है.

    दूसरी ओर, डॉस कभी भी संरक्षित मोड में प्रवेश नहीं करता है, लेकिन वास्तविक मोड में रहता है (*निचे देखो)। वास्तविक मोड में, चल रहे एप्लिकेशन कुछ भी प्रदर्शन कर सकते हैं जो वह करना चाहता है, अर्थात सीधे हार्डवेयर तक पहुंच। लेकिन वास्तविक मोड में चलने वाला एप्लिकेशन सीपीयू को संरक्षित मोड में प्रवेश करने के लिए भी कह सकता है.

    और यह अंतिम भाग विंडोज 95 जैसे अनुप्रयोगों को बहु-थ्रेडेड वातावरण शुरू करने की अनुमति देता है, भले ही वे मूल रूप से डॉस से लॉन्च किए गए थे.

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

    *जब 1970 में पहली बार डॉस बनाया गया था, तो सीपीयू में संरक्षित मोड मौजूद नहीं था। 1980 के दशक के मध्य में 80286 प्रोसेसर तक यह नहीं था कि संरक्षित मोड सीपीयू का हिस्सा बन गया.

    मूल धागे पर ब्राउज़ करना सुनिश्चित करें और नीचे दिए गए लिंक का उपयोग करके इस विषय पर जीवंत चर्चा के माध्यम से पढ़ें!


    स्पष्टीकरण में कुछ जोड़ना है? टिप्पणियों में विचार व्यक्त करो। अन्य टेक-सेवी स्टैक एक्सचेंज उपयोगकर्ताओं से अधिक उत्तर पढ़ना चाहते हैं? पूरी चर्चा धागा यहाँ देखें.