Windows 11, 30 साल पहले compile किए गए binary भी चलाता है

 (twitter.com/mikko)
1 पॉइंट द्वारा GN⁺ 2023-08-20 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • नवीनतम Windows 11 18 अगस्त 1993 को compile किए गए binary को चला देता है, जिससे Microsoft की दीर्घकालिक backward compatibility उजागर होती है
  • यह प्रोग्राम प्रकाशित होने के समय के हिसाब से 30 साल पुराना binary है, जो दिखाता है कि पुराना Windows software आज के environment में भी काम कर सकता है
  • इस मामले का मुख्य बिंदु यह है कि नए version का operating system पुराने executable files को बिना बदले स्वीकार कर लेता है — यानी backward compatibility
  • अलग conversion, recompilation, या अतिरिक्त settings की ज़रूरत थी या नहीं, यह केवल सार्वजनिक जानकारी से पुष्टि नहीं होती
  • पुराने binary चल पाने की क्षमता, लंबे समय तक संग्रहीत software को संभालने वाले enterprise और व्यक्तिगत users, दोनों के लिए एक महत्वपूर्ण stability signal है

Windows 11 में 30 साल पुराने binary चलने का मामला

  • Windows 11 18 अगस्त 1993 को compile किए गए binary को चलाता है
  • यह मामला Microsoft की backward compatibility को बेहद मजबूत बताने वाली राय के साथ साझा किया गया
  • पुष्टि की गई जानकारी केवल इसके चल पाने और compile date तक सीमित है
    • binary का नाम, development language, चलाने का तरीका, और अतिरिक्त settings की आवश्यकता शामिल नहीं है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2023-08-20
Hacker News की राय

  • संदर्भ के लिए Joel Spolsky का लेख भी है: https://www.joelonsoftware.com/2004/06/13/how-microsoft-lost...
    SimCity के developers में से एक के मुताबिक, इसमें एक गंभीर bug था जो DOS में संयोग से ठीक चलता था, लेकिन Windows में टूट जाता था। bug freed memory को फिर से इस्तेमाल करने का था, और Windows team के testers ने popular apps चलाते समय पाया कि SimCity बार-बार crash हो रहा है। कहा जाता है कि Windows developers ने SimCity को disassemble किया, debugger से trace करके bug ढूंढा, और फिर ऐसा code डाला जो SimCity चल रहा है या नहीं यह check करता था और केवल उस case में memory allocator को ऐसे special mode में चलाता था जिसमें free करने के बाद भी memory इस्तेमाल की जा सके

    • उलट उदाहरण के तौर पर Soldier of Fortune modern Windows में गलत तरीके से लागू compatibility hack की वजह से टूट जाता है। executable file का नाम बदल दें तो बिना समस्या चलता है
      इस तरह की backward compatibility implementation opaque और ad-hoc होने की वजह से खास अच्छी नहीं लगती। मिलते-जुलते tools का इस्तेमाल competitor apps को तोड़ने के लिए भी किया गया है। आमतौर पर बात इस पर आ जाती है कि एक-एक करके try करें कि किस पुराने Windows version के mode में चलाना है। Linux भी stable ABI न होने की वजह से इससे बेहतर नहीं है, और Mac में बेहतरीन Rosetta और बिना वजह apps टूटने—दोनों का मिश्रण है। सोचता हूं क्या FreeBSD ने बेहतर किया था? या VMS जैसे गायब हो चुके “mature” operating systems बेहतर थे
    • आजकल GPU driver updates भी काफी हद तक इसी तरह होते हैं। game developers द्वारा game fix करने के बजाय, Nvidia ने हिसाब लगाया कि game bugs को GPU driver level पर fix करके distribute करना उनके लिए ज्यादा फायदेमंद है
    • यह तो उल्टा backward compatibility तोड़नी चाहिए इसका अच्छा आधार लगता है। ऐसे absurd hacks किसी न किसी पर maintenance और debugging का बोझ डालते हैं, और पूरे operating system पर tax की तरह चढ़ जाते हैं। मुझे लगता है कि असल में उसके निशान काफी दिखते भी हैं
    • Raymond Chen की “The Old New Thing” के bonus chapters देखें तो ऐसे कई cases मिलते हैं जहां popular apps को एक-एक करके check करने और नए operating system पर चलाने के लिए Windows को hack करने वाली dedicated team थी
    • दूसरी तरफ Asahi Linux GPU driver process name का पहला अक्षर X है या नहीं check करता है, और अगर है तो सीधे reject कर देता है
      मतलब, अभी भी Xorg क्यों चला रहे हो? अब तक Wayland पर आ जाना चाहिए था, कुछ ऐसा
      https://social.treehouse.systems/@marcan/110904454552941656

  • Raymond Chen इस विषय पर दशकों से अंदरूनी नजरिया देते आए हैं: https://devblogs.microsoft.com/oldnewthing/

  • Windows API की कुल मिलाकर stability की वजह से यह दिलचस्प है कि Win32/DX, Wine/Proton के विशाल काम के जरिए Linux और दूसरे operating systems पर बेहद stable और भरोसेमंद “universal” API बन गया है। लगातार देखता हूं कि games Linux native release छोड़कर बस Proton के लिए release कर रहे हैं

    • Proton-aware releases कई बार Linux native version की तुलना में setup में आसान और performance में बेहतर होते हैं
    • सही है। पिछले साल किसी ने इसी विषय पर लेख लिखा था और यहां भी इस पर काफी चर्चा हुई थी
      https://sporks.space/2022/02/27/win32-is-the-stable-linux-us...

  • यह पागलपन नहीं, बल्कि किसी tool से स्वाभाविक रूप से अपेक्षित स्तर है। मेरा हथौड़ा 30 साल पहले खरीदी गई कीलों पर भी आज तक बिल्कुल ठीक काम करता है
    ऐसी डगमगाती नींव पर कुछ नहीं बनाया जा सकता जो लगातार backward compatibility तोड़ती रहे। अंत में बनाने से ज्यादा समय maintenance में चला जाता है। फिर आप wheel को दोबारा invent करते हैं, लेकिन user के नजरिए से shiny नया wheel जरूरी नहीं कि बेहतर ही हो। मेरे इस्तेमाल का ज्यादातर software 10 साल से ज्यादा पुराना है; कुछ अब भी update होते हैं, कुछ नहीं होते या cloud में चले गए, और मैं खुशी-खुशी पीछे ही रह गया

    • Milwaukee अपनी काफी पीछे छूट चुकी tools lineup के लिए NiCAD batteries अब भी बनाता है
    • इसके उलट, आप ऐसी मूर्खतापूर्ण limitations से हमेशा के लिए बंध भी सकते हैं: https://news.ycombinator.com/item?id=14286383

  • पहले मैं भी ऐसा मानता था, लेकिन अब नहीं
    Games for Windows – Live service इस्तेमाल करने वाले Steam games जो 2014 में service बंद होने के बाद update नहीं हुए, Windows 10 और उसके बाद नहीं चलते। क्योंकि उस service की DLL हटा दी गई है। कुछ समय तक लोग third-party sites से DLL डाउनलोड करके इसे solve कर लेते थे, लेकिन अब वह भी काम नहीं करता

    • DRM या network service के बिना पुराने games भी graphics compatibility की वजह से नहीं चल सकते। हालांकि cnc-ddraw उनमें से काफी को बचा लेता है: https://github.com/FunkyFr3sh/cnc-ddraw
    • फिर भी उन games के pirated versions शायद अब भी चलते होंगे ;)

  • इससे भी ज्यादा “crazy” examples हैं
    z/OS(जिसे OS360, MVS भी कहा जाता है) 1960s के programs तक support करता है, और IBM के एक DE ने कहा था कि वे Apollo 11 mission के आसपास compile किया गया program आज भी इस्तेमाल करते हैं

    • mainframe दुनिया में यह आम बात है। Unisys(पहले Univac) के पास आज भी Dorado mainframes हैं जो 1962 में आए Univac 1100 के साथ binary-compatible हैं
    • DE क्या है? और क्या उसने बताया कि वह program क्या करता है?
      30 साल से ज्यादा पुराने binaries चलाने या automatically convert करने वाले दूसरे systems भी हैं। IBM i on POWER(i5/AS400) शायद System/38(1980) दौर के programs चला सकता है, और HPE NonStop(Tandem Guardian भी कहा जाता है) on X86-64, 1970s के आखिर के original proprietary TNS system और 1991 के MIPS system के binaries चला या convert कर सकता है

  • Windows का backward compatibility को लेकर ज़िद्दी होना मशहूर है, लेकिन DOS CLI apps के मामले में DOS subsystem लगभग जड़ हो चुका है, इसलिए यह कोई बहुत बड़ी चुनौती जैसा नहीं लगता। ज़्यादा requirements वाले DOS-style programs या शुरुआती Win16 apps चलाने पर कैसा रहेगा, यह जानने की उत्सुकता है। उदाहरण के लिए, क्या 1986 का Zortech C++ और Phar Lap DOS extender, या Windows 3.1 का Minesweeper चलेंगे?

    • वह DOS app नहीं, बल्कि Win32 console app है। DOS apps (चाहे 16-bit हों या 32-bit) या Win16 apps native तौर पर execute नहीं होते
    • Zortech C++ कुछ समय तक मेरे इस्तेमाल का toolchain था और उससे अच्छी यादें जुड़ी हैं। Phar Lap बहुत deep तरीके से hook/intervene करता था, इसलिए मौजूदा Windows पर चलना मुश्किल लगता है, लेकिन experiment करने लायक है। शायद extended/expanded memory से जुड़ी features अब ज़्यादातर काम न करें

  • यह ऐसी चीज़ बिल्कुल नहीं होनी चाहिए जिसे बहुत कमाल माना जाए। इसे रोज़मर्रा और obvious चीज़ की तरह देखना चाहिए, और अगर यह न चले तो उसे बेहद शर्मनाक और अस्वीकार्य failure मानना चाहिए
    मेरा मतलब यह नहीं कि 2023 की अव्यवस्था के standards से यह impressive नहीं है। मतलब यह है कि हमें जिस norm की ओर aiming करनी चाहिए, वह ऐसा होना चाहिए

    • सहमत। ज़्यादातर statically compiled binaries के काम करना बंद कर देने की कोई वजह ही नहीं है

  • कोई कहेगा कि Linux भी ऐसा ही है, और तकनीकी तौर पर यह सही है, लेकिन व्यवहार में यह काफी मुश्किल है
    kernel ABI stable है, लेकिन बाकी सब लगभग pure chaos है, और इसकी वजह Linux पर applications की आम packaging शैली है। app खुद load हो सकता है (अगर वह a.out format में नहीं है), लेकिन ज़्यादातर library loading में fail होने की संभावना है। आखिरकार आपको जिस Linux distribution को baseline मानना है उसका पूरा chroot या कोई दूसरा runtime चाहिए होगा, और यह भी निश्चित नहीं कि 30 साल पुरानी distribution archive मिल पाएगी या नहीं। ऊपर से यह मानना पड़ेगा कि kernel ABI सच में एक bit भी नहीं बदला और /proc या /sys जैसे दूसरे interfaces भी नहीं बदले। लगता है /sys 30 साल पहले था ही नहीं। अगर यह Xorg app है, तो protocol-level compatibility पर मैं अपना lunch money दांव पर नहीं लगाऊँगा

    • Linux पर भी यह Windows जैसी ही तरह काम करता है। ज़रूरी dynamic libraries और configuration न हों तो यह नहीं चलेगा
      समझना मुश्किल है कि यह Linux के लिए minus point क्यों है और Windows के लिए नहीं

  • पुराने Mac software का यूँ ही न चलना हमेशा अफसोसजनक लगा। Apple का नए architecture पर shift करना शायद unavoidable रहा होगा। लेकिन कुछ साल बाद emulator का टूट जाना असली समस्या है
    Microsoft अपने customers के लिए जो commitment दिखाता है, वह इतनी चौंकाने वाली चीज़ नहीं होनी चाहिए। हर company को ऐसा ही व्यवहार करना चाहिए

    • Apple के पास भी एक समय ऐसा था जब वे 1st-gen iMac (300MHz?) पर भी latest Mac OS X install करने देते थे। शायद RAM को maximum तक बढ़ाना पड़ता था, लेकिन इतना काफी था और असल में वह काफी usable भी था