फ़्लॉपी डिस्क को फ़ॉर्मेट करते समय विंडोज 95 को फ्रीज क्यों किया गया?

रेमंड चेन ने एक प्रसिद्ध मजाक का जवाब दिया:
- पिताजी, मुझे दिखाओ कि कौन सा विंडोज मल्टीटास्किंग है!
- अब, बेटा, मैं सिर्फ फ्लॉपी डिस्क को प्रारूपित करूंगा ...

दिन भर डिस्कनेक्ट कौन करता है? यह पता चला है कि कई geeks केवल इसके साथ व्यस्त हैं। (वास्तव में, आप पहले से ही स्वरूपित फ्लॉपी डिस्क खरीद सकते हैं, केवल शाह!) लेकिन फ़्लॉपी डिस्क को प्रारूपित करते समय विंडोज 95 क्यों लटका हुआ था?

यह एमएस-डॉस के साथ संगतता के बारे में है।

जैसा कि हमने पहले देखा था , विंडोज 95 में एमएस-डॉस ने पुराने 16-बिट ड्राइवरों के लिए एक परत के रूप में काम किया। इस तथ्य के बावजूद कि I / O संचालन को 32-बिट फ़ाइल सबसिस्टम द्वारा संसाधित किया गया था, उन सभी को 16-बिट कोड से गुजारा गया ताकि 16-बिट ड्राइवर, TSR और इसी तरह के प्रोसेसर ने "सामान्य 16-बिट संचालन" देखा और अपने सामान्य तरीके से काम किया। से घिरा हुआ।

16-बिट दुनिया में, 13h सॉफ़्टवेयर व्यवधान प्रारूपण में शामिल था, और कई कार्यक्रमों ने इस तथ्य का उपयोग अवरोधन को रोककर किया था ताकि फ्लॉपी डिस्क को प्रारूपित करते समय नियंत्रण प्राप्त किया जा सके। कुछ टीएसआर बैकअप कार्यक्रमों ने ऐसा किया (विंडोज 3.0 के लिए विकसित बैकअप प्रोग्रामों में विंडोज 3.x के लिए 32-बिट ड्राइवर शामिल थे, जिन्हें वीएक्सडी कहा जाता है, डिस्क संचालन की निगरानी के लिए)। लेकिन यह सब कुछ नहीं समझाता है। अंत में, विंडोज 95 ने सभी डिस्क I / O को हटा दिया, न कि केवल डिस्क स्वरूपण, 16-बिट कोड के माध्यम से। क्यों फ़्लॉपी डिस्क को प्रारूपित करने से प्रणाली पर काफी असर पड़ता है?

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

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

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

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

32-बिट फ़ाइल सबसिस्टम के मामले के समान, एक 32-बिट फ़्लॉपी ड्राइवर था जो बहुत ही अंत में स्वरूपण संचालन को बाधित करने की कोशिश कर रहा था। यदि यह काम करता है, तो चालक ने BIOS के बजाय एक ट्रैक को प्रारूपित करने का काम किया। एक बहादुर प्रयास, लेकिन ड्राइवर कितना भी ऊंचा क्यों न हो, इससे कोई फर्क नहीं पड़ता; एक ट्रैक की प्रारूपण गति मुख्य रूप से फ्लॉपी डिस्क यांत्रिकी द्वारा सीमित है।

बेशक, अगर विंडोज 95 16-बिट ड्राइवरों, टीएसआर और संदिग्ध BIOS के साथ संगतता का समर्थन नहीं करता था, तो यह टाइमर और मुख्य महत्वपूर्ण अनुभाग के साथ बेतुका संचालन से विचलित हुए बिना सीधे 32-बिट फ़्लॉपी ड्राइवर को प्रारूपण अनुरोध भेज सकता था। लेकिन वास्तव में हमारे पास पहले से ही एक प्रणाली थी जो 16-बिट ड्राइवरों, टीएसआर, 16-बिट विंडोज-प्रोग्रामों के साथ अपने 32-बिट वीएक्सडी-ड्राइवरों और संदिग्ध BIOS के साथ संगतता से इनकार करती थी। इसे विंडोज एनटी कहा जाता था।

यदि आप विंडोज एनटी चाहते थे, तो आप जानते थे कि इसे कहां खोजना है।