सार:
विंडोज 11 में, एक ऐसा डिज़ाइन है जो उपयोगकर्ताओं को लंबे समय से भ्रमित कर रहा है: 64-बिट सिस्टम पर, C:WindowsSystem32 वास्तव में 64-बिट सिस्टम फ़ाइलों को संग्रहीत करता है, जबकि C:WindowsSysWOW64 निर्देशिका जिसके नाम में "64" है, इसके बजाय 32-बिट फ़ाइलों को संग्रहीत करता है। जो उपयोगकर्ता विंडोज़ का इतिहास नहीं जानते, उन्हें यह नामकरण योजना पूरी तरह उलटी लग सकती है।
Microsoft इंजीनियरों ने हाल ही में इस डिज़ाइन के पीछे के कारणों को फिर से समझाया। इसका उत्तर यह नहीं है कि Microsoft ने केवल निर्देशिका नामों को उलट दिया है, बल्कि पुराने पथों पर निर्भर बहुत सारे सॉफ़्टवेयर को तोड़ने से बचने के लिए। जब विंडोज़ 32-बिट आर्किटेक्चर से 64-बिट आर्किटेक्चर में स्थानांतरित हो गया, तो उसने पहले से ही व्यापक रूप से उपयोग किए जाने वाले System32 निर्देशिका नाम को बनाए रखना चुना, और फिर 32-बिट प्रोग्राम को सिस्टम फ़ाइलों के दूसरे सेट तक स्वचालित रूप से पहुंचने की अनुमति देने के लिए फ़ाइल सिस्टम पुनर्निर्देशन तंत्र का उपयोग किया।
विंडोज लेटेस्ट ने 20 अक्टूबर, 2026 को एक लेख प्रकाशित किया, जिसमें इस समस्या का परिचय दिया गया और माइक्रोसॉफ्ट के आधिकारिक तकनीकी दस्तावेजों के साथ प्रासंगिक तंत्र की व्याख्या की गई। रिपोर्ट में बताया गया है कि यह डिज़ाइन सॉफ़्टवेयर अनुकूलता पर विंडोज़ के दीर्घकालिक आग्रह को पूरी तरह से दर्शाता है: भले ही पुरानी नामकरण पद्धति अब सहज नहीं है, जब तक कि जल्दबाजी में किए गए संशोधनों के कारण बड़ी संख्या में प्रोग्राम चलने में असमर्थ हो सकते हैं, Microsoft मूल संरचना को बनाए रखता है और संगतता परत के माध्यम से समस्या का समाधान करता है।
इस डिज़ाइन को समझने के लिए, आपको विंडोज़ के शुरुआती दिनों में वापस जाना होगा।
16-बिट विंडोज़ युग में, सिस्टम फ़ाइलें मुख्य रूप से C:WindowsSystem निर्देशिका में संग्रहीत की जाती थीं। जब माइक्रोसॉफ्ट ने 32-बिट विंडोज़ लॉन्च किया, तो सिस्टम को 32-बिट सिस्टम फ़ाइलों को समायोजित करने के लिए एक नई निर्देशिका की आवश्यकता थी, इसलिए C:WindowsSystem32 का उपयोग किया गया था। "32" वास्तव में उस समय के 32-बिट सिस्टम आर्किटेक्चर से संबंधित है।
लेकिन जब 64-बिट विंडोज़ सामने आई, तो चीजें जटिल हो गईं। बड़ी संख्या में सॉफ़्टवेयर ने System32 को प्रोग्राम कोड में प्रोग्राम किया है और विंडोज़ द्वारा प्रदान किए गए सिस्टम इंटरफ़ेस के माध्यम से गतिशील रूप से सही सिस्टम निर्देशिका प्राप्त करने के बजाय सिस्टम फ़ाइलों तक पहुंचने के लिए सीधे इस पथ का उपयोग करते हैं।
यदि 64-बिट विंडोज़ लॉन्च करते समय Microsoft सीधे System32 का नाम बदलकर System64 कर देता है, तो कई पुराने प्रोग्राम, इंस्टॉलर और बैच स्क्रिप्ट उन सिस्टम फ़ाइलों को नहीं ढूंढ पाएंगे जिनकी उन्हें आवश्यकता है। भले ही डेवलपर्स सॉफ़्टवेयर को पुन: संकलित करें, वे समय पर सभी हार्ड-कोडित पथों को ठीक करने में सक्षम नहीं हो सकते हैं।
इससे भी अधिक परेशानी की बात यह है कि कुछ सॉफ़्टवेयर 64-बिट संस्करण में अपग्रेड होने के बाद भी डिफ़ॉल्ट रूप से System32 से संबंधित सिस्टम घटकों को पढ़ते हैं। यदि Microsoft System32 को केवल 32-बिट फ़ाइलों को संग्रहीत करने के लिए बदलता है, तो ये 64-बिट प्रोग्राम सामान्य रूप से आवश्यक डायनेमिक लिंक लाइब्रेरीज़ को लोड करने में असमर्थ होंगे।
इसलिए, Microsoft ने अंततः ऐतिहासिक नाम System32 को बनाए रखने का निर्णय लिया और इसे 64-बिट विंडोज़ में ऑपरेटिंग सिस्टम के मूल आर्किटेक्चर से मेल खाने वाली फ़ाइलों को संग्रहीत करने दिया। विंडोज 11 के मुख्यधारा x64 संस्करण के लिए, इसका मतलब है कि System32 सिस्टम घटकों के 64-बिट संस्करण को संग्रहीत करता है, जबकि 32-बिट संस्करण को किसी अन्य निर्देशिका में रखा जाता है।
यह निर्देशिका SysWOW64 है।
WOW64 "Windows 32-bit on Windows 64-bit" का संक्षिप्त रूप है, जो 64-बिट Windows पर 32-बिट Windows अनुप्रयोगों को चलाने के लिए एक अनुकूलता तंत्र है। SysWOW64 में "64" उस 64-बिट विंडोज़ वातावरण को संदर्भित करता है जिसमें यह है, न कि यह कि फ़ाइल स्वयं 64-बिट है। दूसरे शब्दों में, नाम उस प्लेटफ़ॉर्म का वर्णन करता है जिसे संगतता तंत्र लक्षित कर रहा है, न कि निर्देशिका में बाइनरी में बिट्स की संख्या।
Microsoft के वरिष्ठ इंजीनियर रेमंड चेन ने एक बार एक तकनीकी लेख में बताया था कि System32 में "32" धीरे-धीरे एक ऐतिहासिक विरासत नाम बन गया है, कुछ ब्रांड नामों की तरह, भले ही वे अब मूल अर्थ को पूरी तरह से प्रतिबिंबित नहीं करते हैं, फिर भी दीर्घकालिक उपयोग के कारण इसे बरकरार रखा जाएगा।
यदि पूरे सिस्टम को फिर से डिज़ाइन किया जा सकता है, तो उनका मानना है कि एक अधिक आदर्श निर्देशिका नाम SysExec जैसा कुछ हो सकता है, जिसका उपयोग निष्पादन योग्य फ़ाइलों को संग्रहीत करने के लिए किया जाता है जो वर्तमान सिस्टम आर्किटेक्चर से मेल खाते हैं। लेकिन विंडोज़ दशकों से मौजूद है, और System32 लंबे समय से एक निश्चित पथ रहा है जिस पर अनगिनत प्रोग्राम भरोसा करते हैं, इसलिए नाम बदलने के संभावित जोखिम नामकरण के लाभों से कहीं अधिक हैं।
निर्देशिका नामकरण के अलावा, 64-बिट विंडोज़ को एक अधिक व्यावहारिक समस्या को भी हल करने की आवश्यकता है: 32-बिट प्रोग्राम सीधे 64-बिट डायनेमिक लिंक लाइब्रेरीज़ को लोड नहीं कर सकते हैं, और 64-बिट प्रोग्राम सीधे 32-बिट डायनेमिक लिंक लाइब्रेरीज़ को लोड नहीं कर सकते हैं।
उदाहरण के लिए, कर्नेल32.dll विंडोज़ का एक महत्वपूर्ण सिस्टम घटक है। समान नाम वाली फ़ाइलें System32 और SysWOW64 में पाई जा सकती हैं, लेकिन उन्हें अलग-अलग आर्किटेक्चर के लिए संकलित किया गया है और उन्हें आसानी से आपस में बदला नहीं जा सकता है। जब विंडोज़ लेटेस्ट ने विंडोज़ 11 26H2 सिस्टम में इन दो निर्देशिकाओं की जाँच की, तो उसे संबंधित फ़ाइलों के आकार में भी अंतर मिला।
यदि कोई 32-बिट प्रोग्राम सीधे सिस्टम32 में 64-बिट संस्करण को लोड करता है, तो यह असंगत बाइनरी आर्किटेक्चर के कारण चलने में सक्षम नहीं हो सकता है। इस स्थिति से बचने के लिए, विंडोज़ ने WOW64 फ़ाइल सिस्टम रीडायरेक्टर पेश किया।
64-बिट विंडोज पर, जब 32-बिट प्रोग्राम C:WindowsSystem32 तक पहुंचने का प्रयास करता है, तो सिस्टम आमतौर पर एक्सेस अनुरोध को C:WindowsSysWOW64 पर रीडायरेक्ट कर देता है। यह प्रक्रिया मूल रूप से प्रोग्राम के लिए पारदर्शी है, यह अभी भी सोचता है कि यह System32 तक पहुंच रहा है, और ऑपरेटिंग सिस्टम पर्दे के पीछे इसके लिए सही 32-बिट फ़ाइल ढूंढता है।
Microsoft आधिकारिक दस्तावेज़ स्पष्ट रूप से बताता है कि 64-बिट विंडोज़ में System32 निर्देशिका 64-बिट अनुप्रयोगों के लिए आरक्षित है, और WOW64 32-बिट प्रोग्रामों की कुछ सिस्टम पथों तक पहुंच को संबंधित 32-बिट निर्देशिकाओं पर पुनर्निर्देशित करने के लिए ज़िम्मेदार है।
यह तंत्र न केवल सिस्टम डायनेमिक लिंक लाइब्रेरी को शामिल करता है, बल्कि कुछ सिस्टम टूल्स को भी प्रभावित करता है। उदाहरण के लिए, जब कोई 32-बिट प्रोग्राम विंडोज़ निर्देशिका में कुछ टूल तक पहुंचता है, तो इसे SysWOW64 में संबंधित संस्करण पर रीडायरेक्ट किया जा सकता है। यदि ऑपरेटिंग सिस्टम आर्किटेक्चर मेल नहीं खाता है तो यह 32-बिट प्रोग्राम को 64-बिट टूल का दुरुपयोग करने या गलत संचालन करने से रोकता है।
WOW64 रजिस्ट्री एक्सेस और प्रोग्राम इंस्टॉलेशन पथ जैसे संगतता मुद्दों को भी संभालता है। 32-बिट अनुप्रयोगों के लिए, विंडोज़ एक अलग रजिस्ट्री दृश्य प्रदान कर सकता है, एक विशिष्ट स्थान HKEY_LOCAL_MACHINESoftwareWow6432Node है। सिस्टम आमतौर पर 32-बिट प्रोग्राम के प्रोग्राम फाइल पथ को C:प्रोग्राम फाइल्स (x86) पर इंगित करता है, ताकि विभिन्न आर्किटेक्चर के सॉफ्टवेयर को यथासंभव अलग से प्रबंधित किया जा सके।
एक साथ मिलकर, ये तंत्र विंडोज संगतता प्रणाली का हिस्सा बनते हैं, जो शुरुआती 32-बिट विंडोज के लिए लिखे गए बड़ी संख्या में सॉफ़्टवेयर को अभी भी 64-बिट विंडोज 11 पर चलाने की अनुमति देते हैं, डेवलपर्स को प्रत्येक पुराने प्रोग्राम के लिए सभी कोड को फिर से लिखने की आवश्यकता के बिना।
हालाँकि, फ़ाइल सिस्टम पुनर्निर्देशन कुछ ऐसी स्थितियाँ भी ला सकता है जो डेवलपर्स को आसानी से भ्रमित कर सकती हैं।
उदाहरण के लिए, एक 32-बिट कमांड प्रॉम्प्ट और एक 64-बिट कमांड प्रॉम्प्ट, भले ही वे C:WindowsSystem32kernel32.dll तक पहुंचने के लिए समान पथ का उपयोग करते हों, प्राप्त वास्तविक फ़ाइलें भिन्न हो सकती हैं। पहले को आमतौर पर SysWOW64 पर रीडायरेक्ट किया जाता है, जबकि बाद वाला सीधे System32 तक पहुंचता है।
माइक्रोसॉफ्ट विज़ुअल स्टूडियो टीम के पूर्व सदस्य मैट पिट्रेक ने एक तकनीकी लेख में उल्लेख किया है कि उन्होंने समस्या के निवारण में भी समय बिताया क्योंकि जब 32-बिट कमांड प्रॉम्प्ट ने दो निर्देशिकाओं में एक ही नाम वाली फ़ाइलों को सूचीबद्ध किया तो उन्हें भ्रमित करने वाले परिणाम मिले। इससे पता चलता है कि यद्यपि फ़ाइल सिस्टम पुनर्निर्देशन सॉफ़्टवेयर अनुकूलता बनाए रख सकता है, यह सिस्टम डिबगिंग और विकास कार्य को और अधिक जटिल भी बनाता है।
कुछ विशेष स्थितियों को हल करने के लिए, Microsoft Sysnative नामक एक वर्चुअल पथ भी प्रदान करता है। यदि 32-बिट प्रोग्राम को वास्तव में 64-बिट विंडोज की मूल System32 निर्देशिका तक पहुंचने की आवश्यकता है, तो यह सामान्य फ़ाइल सिस्टम पुनर्निर्देशन को बायपास करने के लिए C:WindowsSysnative का उपयोग कर सकता है।
यह ध्यान दिया जाना चाहिए कि Sysnative डिस्क पर एक वास्तविक फ़ोल्डर नहीं है, बल्कि विंडोज़ द्वारा विशेष रूप से प्रदान किया गया एक पथ उपनाम है। 64-बिट एप्लिकेशन 32-बिट प्रोग्राम की तरह इस उपनाम का उपयोग नहीं कर सकते हैं, इसलिए जब उपयोगकर्ता सीधे फ़ाइल एक्सप्लोरर में सिस्नेटिव की तलाश करते हैं, तो वे पा सकते हैं कि सिस्टम संकेत देता है कि पथ मौजूद नहीं है।
Microsoft कई System32 उपनिर्देशिकाओं को भी सूचीबद्ध करता है जो नियमित फ़ाइल सिस्टम पुनर्निर्देशन से प्रभावित नहीं होती हैं, जिनमें शामिल हैं:
C:WindowsSystem32catroot
C:WindowsSystem32catroot2
C:WindowsSystem32driverstore
C:WindowsSystem32driveretc
C:WindowsSystem32logfiles
C:WindowsSystem32spool
इन निर्देशिकाओं में सिस्टम घटक निर्देशिकाएं, ड्राइवर स्टोरेज, नेटवर्क कॉन्फ़िगरेशन फ़ाइलें, लॉगिंग और प्रिंटिंग जैसे कार्य शामिल हैं। Microsoft दस्तावेज़ इन अपवाद पथों को स्पष्ट रूप से सूचीबद्ध करता है, लेकिन प्रत्येक अपवाद के लिए विशिष्ट डिज़ाइन कारणों का एकीकृत स्पष्टीकरण प्रदान नहीं करता है। विंडोज़ नवीनतम का मानना है कि इनमें से कुछ निर्देशिकाओं में डेटा हो सकता है जिसे विभिन्न आर्किटेक्चर वाले प्रोग्रामों द्वारा संयुक्त रूप से एक्सेस करने की आवश्यकता होती है, जैसे ड्राइवर आदि में होस्ट फ़ाइल।
x64 प्लेटफ़ॉर्म के अलावा, आर्म आर्किटेक्चर पर विंडोज़ के अनुकूलता तंत्र में भी एक समान मल्टी-डायरेक्टरी डिज़ाइन देखा गया है।
कुछ शुरुआती विंडोज़ ऑन आर्म सिस्टम में, 32-बिट x86 प्रोग्राम SysWOW64 का उपयोग करते हैं, जबकि 32-बिट आर्म प्रोग्राम SysArm32 के माध्यम से संबंधित सिस्टम घटकों तक पहुंच सकते हैं। चूंकि आर्म प्लेटफ़ॉर्म को विभिन्न निर्देश सेट आर्किटेक्चर के बीच संगतता मुद्दों से निपटने की आवश्यकता होती है, इसलिए विंडोज़ संबंधित सिमुलेशन और रूपांतरण तंत्र का भी उपयोग करता है।
हालांकि, माइक्रोसॉफ्ट के नवीनतम आर्म डेवलपमेंट दस्तावेज़ में कहा गया है कि विंडोज़ ऑन आर्म अब 32-बिट आर्म अनुप्रयोगों का समर्थन नहीं करेगा, और संबंधित सिस्टम बायनेरिज़ को SysArm32 निर्देशिका से भी हटा दिया जाएगा। साथ ही, सामान्य x86 एप्लिकेशन अभी भी संगतता तंत्र के माध्यम से चल सकते हैं, और कुछ x86 प्रोग्राम प्रिज्म इम्यूलेशन तकनीक द्वारा समर्थित हैं।
इससे यह भी पता चलता है कि विंडोज़ संगतता प्रणाली पूरी तरह से स्थिर नहीं है। जैसे-जैसे हार्डवेयर प्लेटफ़ॉर्म और सॉफ़्टवेयर इकोसिस्टम बदलते हैं, Microsoft अभी भी कुछ पुराने आर्किटेक्चर के लिए समर्थन बंद कर देगा, लेकिन उन अनुप्रयोगों के लिए जो अभी भी व्यापक रूप से उपयोग किए जाते हैं, कंपनी यथासंभव अनुकूलता बनाए रखने का प्रयास करेगी।
तकनीकी दृष्टिकोण से, System32 और SysWOW64 का नामकरण वास्तव में पर्याप्त सहज नहीं है। सामान्य उपयोगकर्ताओं के लिए, जब वे "64" देखते हैं तो यह सोचना स्वाभाविक समझ है कि 64-बिट फ़ाइलें निर्देशिका में संग्रहीत हैं। लेकिन विंडोज़ में, निर्देशिका नाम अंतर्ज्ञान का पालन करने के लिए शुरू से ही डिज़ाइन किए गए नियमों के एक सेट के बजाय इतिहास को दर्शाते हैं।
माइक्रोसॉफ्ट द्वारा दो निर्देशिकाओं का नाम न बदलने का मुख्य कारण संगतता था। विंडोज़ को बहुत सारे ऐतिहासिक सॉफ़्टवेयर चलाने की ज़रूरत है, और ये प्रोग्राम निश्चित पथ, लीगेसी सिस्टम इंटरफ़ेस और विशिष्ट बाइनरी फ़ाइल लेआउट पर निर्भर हो सकते हैं। इन बुनियादी ढांचे को लापरवाही से संशोधित करने से सॉफ़्टवेयर इंस्टॉलेशन विफलताएं, सिस्टम टूल असामान्यताएं हो सकती हैं, और यहां तक कि पुराने घटकों पर निर्भर व्यावसायिक प्रक्रियाएं भी प्रभावित हो सकती हैं।
इसलिए, Microsoft ने निर्देशिका नामकरण प्रणाली को पूरी तरह से पुनर्निर्मित करने के बजाय, फ़ाइल सिस्टम पुनर्निर्देशन, रजिस्ट्री पुनर्निर्देशन और वर्चुअल पथ जैसे तंत्रों के माध्यम से समस्या को हल करने का विकल्प चुना।
यह डिज़ाइन सही नहीं है, लेकिन यह विंडोज़ और अन्य ऑपरेटिंग सिस्टम के विकास पथ में एक महत्वपूर्ण अंतर को दर्शाता है: विंडोज़ को हमेशा निरंतर आधुनिकीकरण और दशकों पुराने सॉफ़्टवेयर के साथ संगतता के बीच संतुलन खोजने की आवश्यकता होती है। System32 और SysWOW64 का प्रतीत होने वाला उलटा नामकरण इस दीर्घकालिक अनुकूलता रणनीति द्वारा छोड़ा गया एक विशिष्ट निशान है।
टिप्पणियाँ