रिलीज़ में BAARD को क्यों नहीं हटाया गया?

विंडोज 3.1 के बीटा संस्करणों में, छिपा हुआ और एन्क्रिप्टेड कोड था, जिसे डीआर-डॉस पर लॉन्च करने पर, एक अशुभ त्रुटि संदेश उत्पन्न होता था।



रिलीज में, उन्होंने इस तरह के ट्रिक्स से निपटने का फैसला किया, लेकिन सत्यापन कोड और संदेश को स्वयं नहीं हटाया गया: वे WIN.COM



अंदर बने रहे, और यह एक बाइट को बदलने के लिए पर्याप्त है ताकि AARD कोड को प्रत्येक शुरुआत में फिर से निष्पादित किया जाए।



उन्होंने उसे क्यों छोड़ दिया? क्या Microsoft वास्तव में भविष्य में एक दिन इन संदिग्ध जांचों को अनलॉक करने की उम्मीद कर रहा था?

बिल्कुल नहीं। यहां तक ​​कि रिलीज़ में संदेश अपरिवर्तित रहा: "कृपया विंडोज 3.1 बीटा समर्थन से संपर्क करें।" यदि संदेश वास्तव में दिखाया जाना था, तो यह बीटा परीक्षण के बाद अपडेट किया जाएगा।



तो क्यों रिलीज में व्यर्थ कोड छोड़ दें जो कभी नहीं चलता है?



लैरी ओस्टरमैन बताते हैं:

JMP



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



लेकिन क्यों पृथ्वी पर कोड में इस तरह के मामूली बदलाव से कुछ प्रभावित हो सकता है? क्रिस प्रैटली एक उदाहरण देते हैं:

यहां तक ​​कि कोड को लिंक करना, पुन: जमा करने जैसा नहीं, अप्रत्याशित बग का परिचय दे सकता है। कुछ साल पहले, जब हम Word97 की एशियाई रिलीज़ पर काम कर रहे थे और पहले से ही पूरी तरह से तैयार कोड पर विचार कर रहे थे, हमने इसका अंतिम अनुकूलन शुरू कर दिया। हमारे पास एक उपकरण है जो व्यक्तिगत कार्यों के प्रदर्शन पर आंकड़े एकत्र करता है, और उन्हें एक फ़ाइल में एक इष्टतम तरीके से पुन: व्यवस्थित करता है; फ़ंक्शन कोड नहीं बदलता है। अनुकूलन के बाद, हमने अंतिम परीक्षण के लिए कोड दिया, और - दोनों! - एक बग था। जब परीक्षकों ने कार्यक्रम के एक निश्चित कार्य का उपयोग किया, तो कुछ मशीनों पर अनुकूलित कोड दुर्घटनाग्रस्त हो गया। एक ही मशीन पर, एक ही फ़ंक्शन ने अनुकूलन से पहले ठीक काम किया।



हमने डीबग किया; लेकिन अगर हमने डिबगिंग जानकारी को अनुकूलित संस्करण में जोड़ा, तो यह अब दुर्घटनाग्रस्त नहीं हुई। हमने अतिरिक्त जानकारी के बिना इसे डीबग करने का प्रयास किया; लेकिन भले ही हम इसे डिबगर के नीचे चलाते हैं, यह अब दुर्घटनाग्रस्त नहीं हुआ। जिस तरह से हम पतन के कारण का पता लगाने की कोशिश करते हैं, उस कार्यक्रम में गिरावट नहीं हुई; लेकिन वह बिल्कुल गिर गई जब हमने उसे अकेला छोड़ दिया।



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



बाद 33 बाइट्स के बाद सशर्त कूद है, और JMP



स्वयं मेमोरी पेज की सीमा पर स्थित है। यह "अशुद्धि" पेंटियम 150MHz की रिहाई के बाद से तय किया गया है।



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



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



अब, जब कोई मुझे विश्वास दिलाता है कि उसका सुधार "बिल्कुल सुरक्षित" है, तो मैं हमेशा यह कहानी सुनाता हूं। कोई भी कोड परिवर्तन बिल्कुल सुरक्षित नहीं हो सकता।

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



इसलिए, यह आश्चर्यजनक नहीं है कि विंडोज डेवलपर्स ने रिलीज़ में AARD कोड छोड़ दिया: वे कई हफ्तों से इस कोड के साथ Windows का परीक्षण कर रहे थे, अगर महीनों नहीं, और उन्हें यह सुनिश्चित करने के लिए पता था कि जब यह कोड जगह में था, तो Windows काम करता है। चाहे विंडोज इसके बिना काम करता है, वे - रिलीज से पहले - पता लगाने की हिम्मत नहीं करते थे।

---

BAARD विंडोज 3.1 के बीटा संस्करण की एकमात्र दिलचस्प विशेषता नहीं थी।

पहली बार, विंडोज ने Ctrl-Alt-Del को दबाकर इंटरसेप्ट किया, और अपनी स्क्रीन दिखाई, "आइए मैं आपको एक जमे हुए प्रोग्राम को बंद करने में मदद करता हूं।" विंडोज 3.x का उपयोग करने वालों को याद है कि यह स्क्रीन नीले रंग की थी; बीटा में, वह सुस्त काला था।



यदि उपयोगकर्ता ने पुष्टि की कि त्रिशंकु अनुप्रयोग बंद हो गया है, लेकिन विंडोज इसे पूरा नहीं कर सकता है (उदाहरण के लिए, अगर सिस्टम में बस कोई त्रिशंकु अनुप्रयोग नहीं थे), तो केवल एक चीज जो विंडोज की पेशकश कर सकती थी वह एक रिबूट थी।



विंडोज 3.1 रिलीज में, यह विषमता तय की गई थी: अब, यदि कोई हैंगिंग एप्लिकेशन नहीं हैं, तो विंडोज सब कुछ छोड़ देने का सुझाव देता है।

---

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



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



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



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



चेन ने इस कहानी को इस स्पष्टीकरण के रूप में उद्धृत किया कि विंडोज एक्सपी में कोड के स्निपेट क्यों हैं जिन्हें विंडोज 3.0 के बाद किसी ने नहीं छुआ है। कोई नहीं जानता कि कितने अदृश्य कीड़े हैं; लेकिन हर कोई निश्चित रूप से जानता है: यह कोड काम करता है ।