64-बिट विंडोज पर SysWoW64 में 64-बिट DLLs System32 और 32-बिट DLLs क्यों जाते हैं?


227

मैं जानना चाहूंगा कि हमें किसी फ़ाइल को कब स्थान देना है

C: \ Windows \ System32 या C: \ Windows \ SysWOW64, 64-बिट विंडोज़ सिस्टम पर।

मेरे पास दो डीएलएल हैं, एक 32-बिट के लिए, एक 64-बिट के लिए।

तार्किक रूप से, मैंने सोचा कि मैं C: \ Windows \ System32 के तहत 32-बिट DLL और C: \ Windows \ SysWOW64 के तहत 64-बिट DLL लगाऊंगा।

मेरे आश्चर्य के लिए, यह दूसरा तरीका है ! 32 -बिट एक सी में चला जाता है: \ Windows \ SysWOW 64 , और 64 -बिट DLL सी में चला जाता है: \ Windows \ प्रणाली 32

बहुत भ्रामक सामान। इसके पीछे क्या कारण है?


2
इसके अलावा, यह: विंडोज वर्तमान कामकाजी निर्देशिका के साथ-साथ सिस्टम पथ में भी दिखता है। अन्यथा निर्दिष्ट करने का कोई तरीका नहीं है। ओह रुको, वहाँ है। आप अपने DLL में खोज पथ को एम्बेड कर सकते हैं। यह एक क्षेत्र है जो 8 बाइट्स लंबा है। हाँ। 8 अक्षर।
जीरो बर्ट

यह विंडोज 7 पर सही नहीं लगता है। System32 फ़ाइल में DLL पर फ़ाइल चलाना C: \ Windows \ system32 \ user32.dll C: \ Windows \ system32 \ user32.dll; PE32 MS Windows (DLL) (GUI) इंटेल 80386 32-बिट के लिए निष्पादन योग्य है लेकिन 64-बिट DLL के लिए यह PE32 + MS Windows (DLL) (कंसोल) मोनो / .नेट असेंबली के लिए निष्पादन योग्य नोट करता है कि DLL एक .Net नहीं है सभा। यह एक देशी डीएलएल है।
user877329

सुपरसुसर पर इसी तरह के सवाल को जोड़ना ।
dma_k

11
एक पूर्व Microsoft के साथ साक्षात्कार । (यह कैसे हुआ, इस उत्तर को देखने के लिए एक गंभीर विवरण के लिए ।)
Tgr

superuser.com/a/157301/241386 "पश्चगामी संगतता कारण। आवेदनों की एक पूरी बहुत कुछ चीजें मानती हैं जो उन्हें नहीं
माननी

जवाबों:


225

मेरा मानना ​​है कि इरादा System32 का नाम बदलने का था, लेकिन उस रास्ते के लिए इतने सारे एप्लिकेशन हार्ड-कोड किए गए, कि इसे हटाना संभव नहीं था।

SysWoW64 64-बिट सिस्टम के dll के लिए अभिप्रेत नहीं था, यह वास्तव में "विंडोज पर विंडोज 64" की तरह है, जिसका अर्थ है कि बिट्स को आपको 64 बिट विंडो पर 32 बिट एप्लिकेशन चलाने की आवश्यकता है।

यह लेख थोड़ा समझाता है:

"Windows x64 में एक निर्देशिका System32 है जिसमें 64-बिट DLL (sic!) शामिल हैं। इस प्रकार 64 की बिटनेस के साथ देशी प्रक्रियाएं" अपने "DLL को ढूंढती हैं, जहां वे उनसे उम्मीद करते हैं: System32 फ़ोल्डर में। एक दूसरी निर्देशिका, Sysnow64 में 32 शामिल हैं। -बिट DLL। फ़ाइल सिस्टम पुनर्निर्देशक 32-बिट प्रक्रियाओं के लिए वास्तविक System32 निर्देशिका को छिपाने और SysWOW64 को System32 के नाम से दिखाने का जादू करता है। "

संपादित करें: यदि आप एक इंस्टॉलर के बारे में बात कर रहे हैं, तो आपको वास्तव में सिस्टम फ़ोल्डर में पथ को हार्ड-कोड नहीं करना चाहिए । इसके बजाय, विंडोज आपके लिए यह ध्यान रखे कि आपका इंस्टॉलर इम्यूलेशन लेयर पर चल रहा है या नहीं।


27
ऊ, मैं आज इस विचित्रता में भाग गया। उन्होंने कौन सी भ्रामक बात की है।
एंडी व्हाइट

16
आज भी इसमें भाग गया ... इतना भ्रमित - ग्लूट 32-बिट dll / SysWOW64 में जाता है, ग्लूट 64-बिट dll / System32 में जाता है। किसी को लिखना चाहिए कि नीचे। इंटरनेट पर।
जेरेन बर्ट

8
अच्छी खबर यह है कि Microsoft इंजीनियरिंग प्रतिभा के एक उदाहरण के रूप में, यह बहुत ज्यादा स्व-दस्तावेजीकरण है।
स्पाइकएक्सएक्सएफ

8
एक चीज जो मुझे नहीं मिलती है, अगर फाइल सिस्टम यह बता सकता है कि यह एक 32 बिट ऐप है और इसे SysWOW64फोल्डर में रीडायरेक्ट करता है , तो वे इसके बजाय 64 बिट ऐप का पता क्यों नहीं लगा सकते हैं और ए पर रीडायरेक्ट कर सकते हैं System64?
कोल जॉनसन

6
System32, सिस्टम DLL का विंडोज 32 बिट संस्करण है। सिस्टम 16 बिट संस्करण है। वही कंपनी जिसने हमें विंडोज 8 दिया था, 64 बिट ओएस पर चलने पर हमें 32 बिट डीएलएल के लिए सिस्कोव 64 और 64 बिट डीएलएल के लिए सिस्टम 32 दिया। 64 बिट सिस्टम में, सिस्टम फ़ोल्डर अभी भी पुराना 16 बिट जंक है, केवल सिस्टम 32 सुझाव के अनुसार 32 बिट नहीं है, और 32 बिट सामान सिस्टम निर्देशिका में नाम के साथ 64 है। मैं यह देखने में विफल हूं कि यह किसी को कैसे मदद करता है। यह चीजों को उलझा देता है, और सब कुछ तोड़ देता है। 64bit में परिवर्तित होने पर हार्ड-कोडेड "System32" को "System64" से लोगों को बचाने के लिए सभी। मुहावरे
आर्मंड

26

मुझे जोड़ना चाहिए: आपको अपने dll का \ system32 \ वैसे भी नहीं डालना चाहिए! अपने कोड को संशोधित करें, अपने इंस्टॉलर को संशोधित करें ... अपने बिट्स के लिए एक घर ढूंढें जो सी के तहत कहीं भी नहीं है: \ windows \

उदाहरण के लिए, आपका इंस्टॉलर आपके डीएलएस में डालता है:

\program files\<your app dir>\

or

\program files\common files\<your app name>\

( नोट : जिस तरह से आप वास्तव में यह करते हैं वह है पर्यावरण var का उपयोग करना:% ProgramFiles% या% ProgramFiles (x86)% जहां प्रोग्राम फ़ाइलें है खोजने के लिए .... आप यह नहीं मान रहे हैं कि यह c: \ program files \ _ है। ..)

और फिर एक रजिस्ट्री टैग सेट करता है:

HKLM\software\<your app name>
-- dllLocation

आपके dll का उपयोग करने वाला कोड रजिस्ट्री को पढ़ता है, फिर गतिशील रूप से उस स्थान के dll से लिंक करता है।

ऊपर जाने का स्मार्ट तरीका है।

आप कभी भी अपने dll, या तीसरे पक्ष के dll को \ system32 \ या \ syswow64 में स्थापित नहीं करते हैं। यदि आपको स्टैटिकली लोड करना है, तो आप अपने एक्सईएल डीआईआर (जहां वे मिल जाएंगे) में अपना डीएल लगाते हैं। यदि आप exe dir का अनुमान नहीं लगा सकते हैं (जैसे कि कुछ अन्य exe आपके dll को कॉल करने जा रहे हैं), तो आपको अपना dll dir खोज पथ में डालना पड़ सकता है (यदि सभी पर इससे बचें!)

system32 और syswow64 विंडोज प्रदान की गई फाइलों के लिए हैं ... किसी के लिए भी फाइलें नहीं हैं । लोगों को सामान रखने की बुरी आदत की वजह से एकमात्र कारण यह है कि यह हमेशा खोज पथ में है, और कई ऐप / मॉड्यूल स्टैटिक लिंकिंग का उपयोग करते हैं। (इसलिए, यदि आप वास्तव में इसके लिए नीचे आते हैं, तो असली पाप स्थिर लिंकिंग है - यह मूल कोड और प्रबंधित कोड में एक पाप है - हमेशा हमेशा गतिशील लिंक!)


9
+1 ... लेकिन मैं जोड़ना होगा कि आप% PROGRAMFILES% नहीं \ Program Files \ तरह चर का उपयोग करना चाहिए
रॉड MacPherson

XP के दिनों में, डेवलपर्स के लिए ऐसी चीजों के लिए रजिस्ट्री का उपयोग करना एक आम (और सुझाया गया) अभ्यास था। विंडोज 7 के साथ, यह अब सच नहीं है! यूएसी, कई उपयोगकर्ता सत्रों आदि के कारणों के लिए, विंडोज 7 में रजिस्ट्री को डेवलपर्स द्वारा विवेकाधीन और विवेक के साथ उपयोग किया जाना चाहिए।
राईकर

@RodMacPherson आपके सुझाव को ध्यान में रखते हुए मेरी प्रतिक्रिया बढ़ाई गई है। आप सही कह रहे हैं!
जोन्सोम ने मोनिका

कुछ विचार करने के बाद, मुझे लगता है कि यह सवाल का बेहतर जवाब देता है - "हमें% SYSTEMROOT% के तहत एक फ़ाइल रखने की आवश्यकता है"। कभी नहीँ। यह उत्तर syswow64 फ़ोल्डर के बारे में जिज्ञासा को संतुष्ट नहीं करता है, लेकिन यह एक डेवलपर्स को वास्तव में पढ़ने की आवश्यकता है।
थॉमस

7

इसी मुद्दे पर भागे और कुछ मिनटों तक इस पर शोध किया।

मुझे विंडोज 3.1 और डीओएस का उपयोग करना सिखाया गया था, उन दिनों को याद है? कुछ समय के लिए मैंने मैकिंटोश कंप्यूटरों के साथ सख्ती से काम करने के तुरंत बाद, फिर एक x64-bit मशीन खरीदने के बाद विंडोज पर वापस जाना शुरू कर दिया।

इन परिवर्तनों के पीछे वास्तविक कारण हैं (कुछ लोग ऐतिहासिक महत्व कहेंगे), जो प्रोग्रामर को अपना काम जारी रखने के लिए आवश्यक हैं।

अधिकांश परिवर्तनों का उल्लेख ऊपर किया गया है:

  • Program Files बनाम Program Files (x86)

    शुरुआत में 16/86 बिट फ़ाइलों पर लिखा था, '86' इंटेल प्रोसेसर।

  • System32वास्तव में इसका मतलब है System64(64-बिट विंडोज पर)

    जब डेवलपर्स ने पहली बार विंडोज 7 के साथ काम करना शुरू किया, तो कई संगतता मुद्दे थे जहां अन्य एप्लिकेशन जहां संग्रहीत थे।

  • SysWOW64 वास्तव में मतलब है SysWOW32

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

यहाँ सभी बुनियादी जानकारी के साथ दो लिंक दिए गए हैं:

आशा है, इससे स्थिति स्पष्ट हो जाएगी!


4
यदि आप गंभीरता से लिया जाना चाहते हैं, तो आपको संभवतः स्लैंग को कम करना चाहिए और व्याकरण में सुधार करना चाहिए। इसके अलावा, आप अपने उत्तर को थोड़ा और बढ़ाना चाहते हैं, पैराग्राफ का उपयोग कर सकते हैं।
क्लेस मेलबर्न

2
@ क्रिसली ने जवाब को साफ किया। भविष्य में, आपको विचार करना चाहिए कि क्लास क्या सुझाव देता है और अपवोट की संभावना बढ़ाने के लिए आपकी प्रतिक्रिया को प्रारूपित करता है। :)
१13:

ओपी को पूरी तरह से फिर से लिखने, या हटाए जाने की आवश्यकता है। यह भ्रामक है और वास्तव में उपयोगी नहीं है।
जोंसोम ने मोनिका

5
SysWOW64 वास्तव में इसके लिए खड़ा है: [Sys] मंदिर [W] 32-बिट [ओ] एन [W] इंडोव करता है [64] -bit इस प्रकार संक्षिप्त रूप SysWoW64 (जो वास्तव में कोई मतलब नहीं है, और Microsoft 32 बिट सामान के लिए System32 छोड़ दिया है , और एक System64 बनाया, वास्तव में संगतता के मुद्दे नहीं होंगे। Microsoft क्या करता है WoW सैंडबॉक्स में, SysWoW64 के अनुरोध के रूप में System32 में 32bit पहुंच से मेमोरी रीडायरेक्ट में बनाने के लिए है ... यह सिर्फ उजागर करने के लिए कैसे अधिक जटिल नहीं है कच्चे w / o में फ़ाइल-सिस्टम को जादुई रूप से अलग-अलग प्लेटफ़ॉर्म के लिए रीमैप करना है; जैसा कि एक पूर्व टिप्पणी में उल्लेख किया गया है - Idiocy।
आर्मंड

1
उत्तर प्रश्न पर स्पष्टता से अधिक गलतफहमी लाते हैं, आर्मंड टिप्पणी अच्छी व्याख्या है।
nahab

5

System32 वह जगह है जहां विंडोज ने ऐतिहासिक रूप से सभी 32 बिट DLL को रखा था, और सिस्टम 16bit DLL के लिए था। जब Microsoft ने 64 बिट OS बनाया, तो हर कोई जानता है कि मुझे System64 के तहत फ़ाइलों के अपेक्षित होने का पता है, लेकिन Microsoft ने फैसला किया कि उसने System32 के तहत 64 बिट फाइलें डालने का अधिक अर्थ बनाया। एकमात्र तर्क जो मैं पा सका हूं, वह यह है कि वे सब कुछ चाहते थे जो कि 64 बिट विंडोज w / o में काम करने के लिए 32 बिट था जो कि कार्यक्रमों में कुछ भी बदलने के लिए था - बस फिर से खेलना, और यह हो गया। जिस तरह से उन्होंने इसे हल किया, ताकि 32 बिट अनुप्रयोग अभी भी चल सकें, एक 32 बिट विंडोज़ सबसिस्टम बनाना था जिसे विंडोज 32 ऑन विंडोज 64 कहा जाता है। इस प्रकार, 32 बिट सबसिस्टम के सिस्टम डायरेक्टरी के लिए संक्षिप्त नाम SysWOW64 बनाया गया था। सिस्टम के लिए Sys छोटा है, और WOW64 Windows32OnWindows64 के लिए छोटा है।
चूंकि विंडोज़ 16 को विंडोज़ 32 से पहले ही अलग कर दिया गया है, इसलिए विंडोज़ 64 ऑन विंडोज 64 तुल्यता की कोई ज़रूरत नहीं थी। 32 बिट सबसिस्टम के भीतर, जब कोई प्रोग्राम सिस्टम 32 डाइरेक्टरी से फाइलों का उपयोग करने के लिए जाता है, तो वे वास्तव में SysWOWV डायरेक्टरी से फाइल प्राप्त करते हैं। लेकिन प्रक्रिया त्रुटिपूर्ण है।

यह एक भयानक डिजाइन है। और मेरे अनुभव में, मुझे 64 बिट अनुप्रयोगों को लिखने के लिए बहुत अधिक परिवर्तन करने थे, कि सिस्टम 32 को पढ़ने के लिए बस System32 निर्देशिका को बदलना एक बहुत छोटा परिवर्तन होगा, और एक कि पूर्व-संकलक निर्देशों को संभालने का इरादा है।


2

अन्य लोगों ने पहले से ही इस हास्यास्पद पहेली को समझाने का अच्छा काम किया है ... और मुझे लगता है कि क्रिस हॉफमैन ने यहां और भी बेहतर काम किया: https://www.howtogeek.com/326509/whats-the-difference-between-the- system32 और syswow64-फ़ोल्डरों में खिड़कियों /

मेरे दो विचार:

  1. हम सभी जीवन में मूर्खतापूर्ण गलतियाँ करते हैं। जब Microsoft ने (उस समय) Win32 DLL निर्देशिका "System32" का नाम दिया, तो उस समय समझ में आया ... उन्होंने इस बात पर ध्यान नहीं दिया कि 64-बिट (या 128-बिट) संस्करण क्या होगा उनके OS का विकास बाद में हुआ - और इस तरह के एक निर्देशिका नाम के कारण बड़े पैमाने पर पिछड़े संगतता समस्या पैदा होगी। Hindsight हमेशा 20-20 होती है, इसलिए मैं ऐसी गलती के लिए वास्तव में उन्हें (बहुत अधिक) दोष नहीं दे सकता। ... कैसे ... जब Microsoft ने बाद में अपने 64-बिट ऑपरेटिंग सिस्टम को विकसित किया, यहां तक ​​कि hindight के लाभ के साथ, क्यों ओह, वे न केवल सटीक समान अदूरदर्शी गलती क्यों करेंगे, लेकिन इसे पूरी तरह से खराब करके भी दे रहे हैं यह ऐसा भ्रामक नाम है ?! उन्हें शर्म आनी चाहिए!!! क्यों नहीं कम से कम वास्तव में भ्रम से बचने के लिए निर्देशिका "SysWin32OnWin64" नाम है ?! ? और क्या होता है जब वे अंततः 128-बिट ओएस का उत्पादन करते हैं ... तो वे अपने 32-बिट, 64-बिट और 128-बिट डीएलएल कहां डालने जा रहे हैं?!?

  2. यह सब तर्क मुझे अभी भी पूरी तरह से दोषपूर्ण लगता है। Windows के 32-बिट संस्करणों पर, System32 में 32-बिट DLL होते हैं; विंडोज के 64-बिट संस्करणों पर, System32 में 64-बिट DLL होते हैं ... ताकि डेवलपर्स को कोड में बदलाव करना न पड़े, सही? इस तर्क के साथ समस्या यह है कि उन डेवलपर्स या तो अब 64-बिट ऐप्स बना रहे हैं, जिन्हें 64-बिट डीएलएल की आवश्यकता है या वे 32-बिट ऐप बना रहे हैं, जिन्हें 32-बिट डीएलएल की जरूरत है ... या तो, क्या वे अभी भी खराब नहीं हुए हैं? मेरा मतलब है, अगर वे अभी भी एक 32-बिट ऐप बना रहे हैं, तो अब 64-बिट विंडोज पर चलने के लिए, उन्हें अब उसी ol '32-बिट DLL को खोजने / संदर्भ के लिए कोड परिवर्तन करने की आवश्यकता होगी। पहले (अब SysWOW64 में स्थित है) का उपयोग किया जाता है। या, यदि वे 64-बिट ऐप पर काम कर रहे हैं, तो उन्हें वैसे भी नए ओएस के लिए अपने पुराने ऐप को फिर से लिखने की आवश्यकता है ... इसलिए किसी भी तरह एक recompile / rebuild की आवश्यकता होने जा रही थी !!

Microsoft कभी-कभी मुझे चोट पहुँचाता है।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.