64-बिट विंडोज को एक अलग "प्रोग्राम फाइल्स (x86)" फोल्डर की आवश्यकता क्यों है?

178

मुझे पता है कि विंडोज के 64-बिट संस्करण पर "प्रोग्राम फाइल्स" फोल्डर 64-बिट प्रोग्राम्स के लिए है और "प्रोग्राम फाइल्स (x86)" फोल्डर 32-बिट प्रोग्राम्स के लिए है, लेकिन यह क्यों जरूरी है?

"आवश्यक" से मेरा मतलब यह नहीं है कि "Microsoft कोई अन्य डिज़ाइन निर्णय क्यों नहीं कर सकता था?" क्योंकि वे कर सकते थे। बल्कि, मेरा मतलब है, "क्यों, 64-बिट विंडोज के वर्तमान डिज़ाइन को देखते हुए, 32-बिट प्रोग्राम में 64-बिट प्रोग्राम से एक अलग शीर्ष-स्तरीय फ़ोल्डर होना चाहिए?" एक और तरीका रखो, "क्या गलत होगा अगर मैं किसी तरह पुनर्निर्देशन तंत्र से बचता हूं और सब कुछ वास्तविक स्थापित करने के लिए मजबूर करता हूं C:\Program Files\?"

सुपर यूजर और अन्य जगहों पर बहुत सारे प्रश्न हैं जो "32-बिट प्रोग्राम के लिए है, एक 64-बिट प्रोग्राम के लिए है" पर जोर देता है, लेकिन कोई भी जिसे मैं कारण नहीं दे सकता हूं। मेरे अनुभव से, यह नहीं करता है लगता है कोई फर्क करने के लिए एक 32-बिट प्रोग्राम या नहीं सही जगह में स्थापित किया गया है या नहीं।

क्या विंडोज़ किसी तरह खुद को "प्रोग्राम फाइल्स (x86)" से बाहर चलने वाले प्रोग्राम में अलग से पेश करता है? क्या कोई विवरण है जो दिखाता है कि "प्रोग्राम फाइल्स" के बजाय "प्रोग्राम फाइल्स (x86)" में स्थापित प्रोग्राम के लिए क्या अलग है? मुझे लगता है कि यह संभावना नहीं है कि Microsoft एक वैध तकनीकी कारण के बिना एक नया फ़ोल्डर पेश करेगा।

windows  64-bit 
— स्टीफन जेनिंग्स
स्रोत
13
आपके प्रश्न का उत्तर देने के बजाय, मैं पूछता हूँ - आप \ program files \ common फ़ाइलों को कैसे संभालेंगे?
— sgmoore
8
वन-लाइनर उत्तर (और इसलिए एक टिप्पणी): चूंकि आप इसकी वास्तुकला को जाने बिना किसी भी फ़ोल्डर से किसी भी एप्लिकेशन को आसानी से चला सकते हैं, तो इस अलगाव के लिए स्पष्ट रूप से कोई अनिवार्य कारण नहीं है । दोनों आर्किटेक्चर के साथ एप्लिकेशन की दोहरी इंस्टॉल का समर्थन करना सुविधा की बात है । कुछ मामलों में इससे फर्क पड़ता है क्योंकि वे आवश्यक रूप से सरल रेपसीले नहीं हैं। मुख्य समस्या यह है कि 32 बिट ऐप्स 64 बिट dll को लोड नहीं कर सकते हैं, इसलिए आप आम तौर पर एक ही स्थान पर दोनों संस्करणों को स्थापित नहीं कर सकते हैं। अन्य विकल्प में प्रत्येक अनुप्रयोग के लिए दो "बिन" फ़ोल्डर हैं।
— स्किलिव्ज
1
@Synetech मैं भी x64 बायनेरिज़ (x86) के तहत प्रोग्राम इंस्टॉल कर रहा था .. यह कभी-कभी भयानक होता है।
— sinni800
10
मैंने हमेशा सोचा है कि Microsoft ने "विरासत" प्रोग्राम फ़ाइलें निर्देशिका को प्रोग्राम फ़ाइलों (x86) में "बढ़ने" के बजाय "प्रोग्राम फाइल्स (x64)" में 64-बिट प्रोग्राम क्यों नहीं रखा
— लॉरेंससी
30
64 / 32bit भेदभाव के बारे में असली गड़बड़ है कि / विंडोज / System32, 64 बिट सामग्री शामिल है, जबकि / विंडोज / SysWOW64 32 बिट सामान शामिल हैं ...
— प्रहार

जवाबों:

92

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

यह आवश्यक नहीं है। यह अन्य संभावित समाधानों की तुलना में अधिक सुविधाजनक है जैसे कि 32-बिट डीएलएल और निष्पादन योग्य 64-बिट डीएलएल और निष्पादन योग्य से अलग करने के लिए हर एप्लिकेशन को अपना रास्ता बनाने की आवश्यकता होती है।

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

इसका सबसे सरल समाधान लगातार अलग-अलग निर्देशिकाएं हैं। वास्तव में एकमात्र विकल्प यह है कि हर 64-बिट एप्लिकेशन को अपनी निष्पादन योग्य फ़ाइलों को "छिपाने" के लिए कहीं न कहीं एक 32-बिट एप्लिकेशन की आवश्यकता नहीं होगी, जैसे bin64कि उस एप्लिकेशन के अंदर एक निर्देशिका। लेकिन यह केवल विरासत अनुप्रयोगों का समर्थन करने के लिए 64-बिट सिस्टम पर स्थायी कुरूपता लागू करेगा।

— डेविड श्वार्ट्ज
स्रोत
52
उन्हें एक ही सिस्टम पर 32-बिट और 16-बिट प्रोग्राम के लिए अनुमति देने के लिए इन हुप्स के माध्यम से कूदना नहीं था। मुझे याद नहीं है कभी एक ProgramFiles (16)या कुछ ऐसे देखकर । इसके अलावा, 32-बिट प्रोग्राम "64-बिट DLL को खोजने और इसे लोड करने का प्रयास कैसे करेगा"? यादृच्छिक DLL में शिकार के लिए कौन से कार्यक्रम चलते हैं %programfiles%? यदि यह एक साझा DLL है, तो यह WinSxS में जाता है; यदि इसे साझा नहीं किया जाता है, तो यह प्रोग्रामर पर निर्भर है कि वे अपने खुद के DLL को प्रबंधित करें। हालांकि इसके बारे में यह कार्यक्रम उचित प्रोग्रामर के लिए एक सुविधा के रूप में किया जा रहा है।
— सिंटेक
30
IIRC Win3.1 के पास प्रोग्राम फाइल्स डायरेक्टरी नहीं थी (या ज्यादातर ऐप्स इसे अनदेखा करते थे); एक परिणाम के रूप में वहाँ कोई विरासत win16 क्षुधा के साथ शुरू करने के लिए प्रोग्राम फ़ाइलों में सामान की तलाश नहीं होगी। इसके बजाय IIRC साझा पुस्तकालयों को अक्सर विंडोज़ के फ़ोल्डर में ही कहीं न कहीं रखा गया था। Win32 विन्डोज़ सिस्टम और windows \ system32 उस की एक कलाकृति है।
— दान नीली
15
Windows 3.1 ने लंबी फ़ाइल नामों का समर्थन नहीं किया है, इसलिए यह 'प्रोग्राम फाइल्स' फ़ोल्डर में सक्षम नहीं होगा।
— डेथ एग्रिअस
14
@JarrodRoberson: काफी उल्टा, यह इसलिए है क्योंकि Microsoft पीछे की ओर संगतता को अत्यधिक महत्व देता है।
— डेविड श्वार्ट्ज
24
@ जारोड: वास्तव में, जैसा कि प्रत्येक डेवलपर जानता है, Microsoft बहुत अधिक अनुकूलता के पीछे पीछे है । वस्तुतः हर एपीआई में उनके पास विरासत के तरीके हैं जिन्हें वे हटाने से इनकार करते हैं, और अक्सर गंभीर कीड़े वे ठीक करने से इनकार करते हैं, क्योंकि वे पुराने कार्यक्रमों को तोड़ने से डरते हैं जो उस एपीआई के लिए लिखे गए थे। वही सबसे एपीआई का सच है, लेकिन माइक्रोसॉफ्ट के विस्तार के पास कहीं भी नहीं है।
— ब्लूराजा - डैनी पफ्लुगुफ्ट
65

यह आपको 32 बिट और 64 बिट के 64 बिट संस्करण को स्थापित करने की अनुमति देता है।

इस उत्तर और टिप्पणी को अगले दिन देखने के बाद, मुझे अपने उत्तर में एक प्रमुख प्रमुख निरीक्षण का एहसास हुआ। मैंने एक प्रोग्रामिंग पृष्ठभूमि को गलत तरीके से ग्रहण किया और जब मैं अपनी टिप्पणियों में आपके बारे में बात कर रहा था , तो मुझे उपयोगकर्ता का मतलब नहीं था, लेकिन प्रोग्रामर।

मैं Microsoft के लिए काम नहीं करता हूं और मुझे कोई सुराग नहीं है कि इन फ़ोल्डरों के पीछे का वास्तविक कारण क्या है, लेकिन मुझे लगता है कि इन फ़ोल्डरों के होने का कारण इतना स्पष्ट है कि मुझे इसे बहस करने में कोई समस्या नहीं है।

तो चलो इसे तोड़ दो!

  1. फोल्डर कमाल के हैं!

    चलो कुछ पर सहमत हैं। फोल्डर महान हैं! हमें उनकी आवश्यकता नहीं है, आपके पास हर एक फ़ाइल को आपकी हार्ड ड्राइव के रूट पर रखने के लिए पर्याप्त संभव फ़ाइल नाम हैं, इसलिए फ़ोल्डर बिल्कुल क्यों हैं?

    खैर, वे हमें अपना सामान ऑर्डर करने में मदद करते हैं। और सामान ऑर्डर करना बहुत अच्छा है। यह हमें चीजों को आसानी से संसाधित करने में मदद करता है। यह विशेष रूप से उपयोगी है जब एक मशीन के साथ काम करना होता है जिसमें संरचना की आवश्यकता होती है।

  2. अलग डेटा और तर्क महान है!

    प्रोग्रामिंग में अक्सर पाया जाने वाला एक प्रतिमान तर्क से डेटा को अलग करना है। आप एक हिस्सा चाहते हैं जो जानता है कि कुछ कैसे करना है और आप एक और हिस्सा चाहते हैं जिसके साथ आप कुछ कर सकते हैं ।

    यह फ़ाइल सिस्टम में भी पाया जाता है।

    हमारे पास एप्लिकेशन (तर्क) के लिए फ़ोल्डर हैं और हमारे कीमती सामान (डेटा) के लिए फ़ोल्डर हैं:

    तर्क

    • %WINDIR%
    • %PROGRAMFILES%
    • %PROGRAMFILES(x86)%

    डेटा

    • %PROGRAMDATA%
    • %HOMEDRIVE%%HOMEPATH%

    तो, ऐसा लगता है जैसे फ़ोल्डर कमाल के हैं और यह अपने छोटे फ़ोल्डर में प्रोग्राम डालने के लिए समझ में आता है। लेकिन 2 क्यों है? क्यों नहीं इंस्टॉलर को संभालना चाहिए और सब कुछ एक Programsफ़ोल्डर में डाल देना चाहिए ?

  3. इंस्टॉलर जादू नहीं हैं

    आज, हम अक्सर अपने बड़े कार्यक्रमों को स्थापित करने के लिए छोटे कार्यक्रमों का उपयोग करते हैं। हम इन छोटे कार्यक्रमों को इंस्टॉलर कहते हैं ।

    इंस्टॉलर जादू नहीं हैं। उन्हें प्रोग्रामर द्वारा लिखा जाना है और वहां किसी भी अन्य एप्लिकेशन की तरह एप्लिकेशन (संभावित बग्स के साथ) हैं। तो आइए उस स्थिति को देखें जो एक काल्पनिक प्रोग्रामर को मौजूदा प्रणाली के साथ और उसके बिना सामना करना होगा :

    1 प्रोग्राम फ़ाइलें फ़ोल्डर

    डेवलपर 2 इंस्टॉलर रखता है। एक 32 बिट के लिए और एक अपने आवेदन के 64 बिट संस्करण के लिए। 32 बिट इंस्टॉलर को लिखेगा C:\Program Files\App\और 64 बिट इंस्टॉलर को लिखेगा C:\Program Files\App\sixtyfour\।

    2 प्रोग्राम फाइल्स फोल्डर

    डेवलपर 1 इंस्टॉलर रखता है। इंस्टॉलर हमेशा %PROGRAMFILES%पथ के विस्तार के लिए ऑपरेटिंग सिस्टम पर लिखेगा और उस पर निर्भर करेगा (आप वास्तव में इन मामलों के लिए पर्यावरण चर का उपयोग नहीं करते हैं, आप सही पथ को पुनः प्राप्त करने के साथ SHGetKnownFolderPath का उपयोग करेंगेFOLDERID_ProgramFiles )।
    सब कुछ पाता है कि यह स्वचालित रूप से है और पैटर्न आपके द्वारा इंस्टॉल किए गए हर एप्लिकेशन के साथ समान है ।

  4. संगति समझ में आती है

    जब आप कुछ सीखते हैं, तो आमतौर पर इसका अर्थ है कि एक मनाया गया व्यवहार सुसंगत था। अन्यथा वास्तव में निरीक्षण करने और सीखने के लिए कुछ भी नहीं है।

    हमारी छोटी फ़ाइल प्रणाली के लिए भी यही सच है। यह हमेशा एक ही सामान एक ही फ़ोल्डर में डाल करने के लिए समझ में आता है । इस तरह, हमें पता चल जाएगा कि जब हम किसी चीज़ की तलाश कर रहे हैं तो कहाँ देखना है।

    32/64 अनुप्रयोग भेद के लिए सिस्टम इस लक्ष्य को पूरा करता है। नामों, बाइनरी लोडिंग व्यवहार और सुरक्षा (कुछ हद तक) में संघर्ष से बचने के लिए अनुप्रयोगों को 2 स्थानों में विभाजित किया गया है।

मैं अभी भी नहीं मिला। यह बेकार लगता है

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

यही कारण है कि हमें अपने सिस्टम को उपयोगी बनाने के लिए फ़ाइल सिस्टम पुनर्निर्देशन जैसे सामान की आवश्यकता होती है ।

प्रोग्रामर बस वहां जाएंगे और लोड करने की कोशिश करेंगे C:\Windows\system32\awesome.dllऔर परवाह नहीं करेंगे कि क्या वे 32 या 64 बिट सिस्टम पर चल रहे हैं। वे 64 बिट DLL को लोड करने और बस दुर्घटना करने की कोशिश करेंगे। कुछ प्रोग्रामर कुछ Office DLL का उपयोग करना चाहते हैं, कोई समस्या नहीं, वे जानते हैं कि इसे कहां खोजना है! C:\Program Files\Microsoft\Office\14.0\wizards.dll... और एक और दुर्घटना!

32 बिट अनुप्रयोग द्वारा इन सभी अनुरोधों को 32 बिट समकक्षों में अनुप्रयोग क्रैश से बचने के लिए पुनर्निर्देशित किया गया है।

ऐसी प्रणाली बनाने के लिए हमें कुछ निश्चित फ़ोल्डर नामों की आवश्यकता होती है। यदि इस पुनर्निर्देशन का समर्थन करने के लिए कोई फ़ोल्डर संरचना नहीं है, तो आप इसे कैसे काम करने जा रहे हैं?

ठीक है, अब मैं इसे प्राप्त करता हूं। लेकिन C:\Program Files\x86\तब उपयोग क्यों नहीं ?

अब हम दार्शनिक हो रहे हैं ...

अगर मैं किसी तरह पुनर्निर्देशन तंत्र से बचता हूं और सब कुछ वास्तविक स्थापित करने के लिए मजबूर करता हूं तो क्या गलत होगा C:\Program Files\?

सबसे अधिक संभावना कुछ भी नहीं (जब तक कि अन्य अनुप्रयोग उस एप्लिकेशन के लिए निश्चित स्थान पर निर्भर न हों)।

WOW64 तंत्र हुक में CreateProcessऔर अधिक परिष्कृत प्रदर्शन करेंगे (निष्पादन के फ़ोल्डर नाम की जाँच की तुलना में और अधिक परिष्कृत) निष्पादन योग्य छवि पर जाँच करता है निर्धारित करने के लिए अगर यह 32 या 64 बिट है।

हाँ, लेकिन मेरा मतलब है, जैसे, सभी अनुप्रयोग!

  • अगर मैं अपनी कार में डीजल और गैस दोनों डालूं तो क्या होगा ?
  • यदि मैं एक ही लाइन पर वैकल्पिक और प्रत्यक्ष धारा दोनों का उपयोग करने की कोशिश करूं तो क्या होगा ?
  • अगर मैं अपनी बिल्ली और मछली दोनों को एक ही मछलीघर में रखूं तो क्या होगा ?

कुछ सवालों के जवाब की आवश्यकता नहीं है। यह करने का इरादा नहीं है, यह मत करो। यहां कुछ हासिल होने वाला नहीं है। इस तरह के बदलाव के कारण होने वाली समस्याओं की मात्रा हमेशा किसी भी संभावित लाभ से आगे निकल जाएगी जो किसी को इसमें दिखाई दे सकती है।

— डेर होकस्टाप्लर
स्रोत
3
हालांकि यह मूल कारण है? मैं बस करने के लिए एप्लिकेशन इंस्टॉल नहीं कर सका C:\Program Files\App32और C:\Program Files\App64?
— स्टीफन जेनिंग्स ने
4
@StephenJennings: लेकिन आपको मैन्युअल रूप से निर्णय लेने की आवश्यकता होगी। अब यह जिस तरह से काम करता है वह यह है कि यह प्रक्रिया स्वचालित है, क्योंकि विंडोज को पता है कि जब कोई एप्लिकेशन SHGetSpecialFolderPathइंस्टॉल लोकेशन निर्धारित करने के लिए कॉल करता है तो उसे कौन सा फोल्डर उपलब्ध कराना है ।
— डेर होकस्टाप्लर
6
@ सिंथेटेक: %PROGRAMFILES%पहली जगह में क्यों स्थापित करें ? यूज़र्स डेस्कटॉप पर 32 बिट संस्करण और रीसायकल बिन में 64 बिट क्यों नहीं डालते हैं? सिर्फ इसलिए कि यह किया जा सकता है, इसका मतलब यह नहीं है कि यह एक अच्छा विचार है। क्षमा करें, मैं आपके तर्क का पालन नहीं करता।
— डेर होकस्टाप्लर
4
@ सिनटेक: हां, आपने पूरी तरह से अच्छा उदाहरण दिया कि यह कैसे किया जा सकता है। यह कैसे किया जा सकता है की एक और पूरी तरह से अच्छा उदाहरण जिस तरह से यह है है वास्तव में अभी किया जा रहा है। बस% PROGRAMFILES% के लिए एक फ़ाइल लिखना और यह निश्चित है कि यह सही फ़ोल्डर में समाप्त हो जाएगा एक बात है। अपने लिए जाँच करना कि कौन सा फ़ोल्डर सही है दूसरा है। यदि आप वास्तव में पूर्व दृष्टिकोण का लाभ नहीं देखते हैं, तो मैं आपको मना नहीं कर पाऊंगा। सवाल यह था कि 2 फोल्डर क्यों थे। मुझे लगता है कि मेरा जवाब उस संबंध में पूरी तरह से उचित है।
— डेर होकेस्टाप्लर
3
@ ऑलिवरसालबर्ग, काफी नहीं। सवाल यह है कि दो फ़ोल्डरों की आवश्यकता क्यों है, क्यों नहीं हैं । वास्तव में, उन्होंने इसे बोल्ड भी किया: यह आवश्यक क्यों है? आपने यह नहीं बताया कि यह आवश्यक क्यों है और मैंने जो उदाहरण दिया है (और यहां तक ​​कि आपके खुद के व्यंग्यात्मक उदाहरण) सिर्फ यह दर्शाता है कि इसे उस तरह से करने की ज़रूरत नहीं है जैसे यह है।
— सिंटेक
14

टी एल; डॉ:

संक्षेप में, नहीं, यह आवश्यक नहीं है ; वे एक एकल फ़ोल्डर का उपयोग कर सकते थे , और नहीं, विंडोज एक स्थान या किसी अन्य से चलाए जा रहे कार्यक्रम के लिए खुद को अलग ढंग से पेश नहीं करता है।

खैर, हर कोई इस पर अपनी राय देने में लगा हुआ है, इसलिए मैं अपने 2 be में टॉस करूंगा। अन्य लोगों ने पहले ही कारणों पर अनुमान लगा लिया है कि Microsoft ने 32-बिट और 64-बिट संस्करणों के लिए अलग-अलग शीर्ष-स्तरीय फ़ोल्डर बनाने के लिए क्यों चुना, इसलिए मैं वह हिस्सा छोड़ दूंगा (सबसे अच्छा कारण डेविड का स्पष्टीकरण था कि यह एक के रूप में है प्रोग्रामर को सुविधा)। निश्चित रूप से तब भी, यह प्रत्यक्ष प्रश्न को संबोधित नहीं करता है कि यह आवश्यक क्यों है? , जिसका उत्तर संभवतः है: यह नहीं है ।

इसके बजाय, मैं प्रश्न के मुख्य निकाय को संबोधित करूंगा

क्या विंडोज़ किसी तरह खुद को "प्रोग्राम फाइल्स (x86)" से बाहर चलने वाले प्रोग्राम में अलग से पेश करता है?

वास्तव में नहीं, लेकिन कार्यक्रम का स्थान व्यवहार को प्रभावित कर सकता है, लेकिन उस तरीके से नहीं जैसा आप सोचते हैं।

जब आप कोई प्रोग्राम चलाते हैं, तो विंडोज एक ऐसा वातावरण तैयार करता है, जिसमें इसे चलाने के लिए (मेरा मतलब मेमोरी, एड्रेसिंग आदि के संदर्भ में है, न कि सिर्फ पर्यावरण चर)। यह वातावरण निष्पादन योग्य की सामग्री पर निर्भर करता है (32-बिट और 64-बिट प्रोग्राम आंतरिक रूप से भिन्न होते हैं)। जब आप 64-बिट सिस्टम पर 32-बिट प्रोग्राम चलाते हैं, तो यह 32-बिट सबसिस्टम में चलता है जो 32-बिट वातावरण का अनुकरण करता है। इसे WoW64 कहा जाता है (WoW64 का अर्थ है विंडोज पर विंडोज 64-बिट ) और यह उसी तरह है जैसे कि NTVDM का उपयोग करके XP में 16-बिट ऐप्स चलाए जाएंगे ।

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

(मैं एक अलग कंप्यूटर का उपयोग कर रहा हूं, इसलिए मैं अपने कदमों को पीछे हटाने के लिए अपने ब्राउज़र के इतिहास पर भरोसा नहीं कर सकता, लेकिन दूसरे दिन इस एसयू प्रश्न का उत्तर देते समय मैं इस एसओ प्रश्न पर समाप्त हो गया, जिसके कारण मुझे Google PROCESSOR_ARCHITEW6432 मिला, जिससे इस एसओ प्रश्न और यह Microsoft ब्लॉग पोस्टिंग ।)

रास्ते में कहीं, मैंने एक StackOverflow पोस्ट के बारे में पढ़ा कि कैसे envirnoment वैरिएबल %processor_architecutre% अलग-अलग परिणाम देता है जिसके आधार पर आप कमांड-प्रॉम्प्ट से चलाते हैं (मैं सटीक उद्धरण खोजने की कोशिश करूँगा)।

उत्तर यह निकला कि क्या कमांड प्रॉम्प्ट का 32-बिट या 64-बिट संस्करण चलाया गया था (यानी, से System32\या SysWoW64\)। दूसरे शब्दों में, जबकि स्थान प्रोग्राम के व्यवहार को प्रभावित करता है, यह केवल इसलिए है क्योंकि प्रोग्राम के विभिन्न संस्करण हैं, इसलिए नहीं कि विंडोज फ़ोल्डर को एक विशेष तरीके से व्यवहार करता है।

यह समझ में आता है क्योंकि निष्पादन योग्य फ़ाइल की सामग्री 32-बिट या 64-बिट निर्धारित करती है, इसलिए आप एक ही प्रोग्राम में (जैसे, foobar32.exeऔर foobar64.exe) दोनों 32-बिट और 64-बिट कॉपी एक ही फ़ोल्डर में रख सकते हैं और जब आप उन्हें निष्पादित करें, उन्हें सही तरीके से लोड किया जाएगा (64-बिट संस्करण को मूल रूप से चलाया जाएगा और 32-बिट वाले को WoW64 अनुकरण परत में चलाया जाएगा)।

FreePascal आपको DOS और Windows दोनों संस्करणों को स्थापित करने की अनुमति देता है और वे एक ही फ़ोल्डर में जाते हैं %programfiles%\FreePascal:। यह निष्पादन योग्य फ़ाइलों (रखकर विभिन्न आर्किटेक्चर का प्रबंधन करता है .exe, .sys, .dll, .ovr, आदि) अलग फ़ोल्डर में और, स्रोत फ़ाइलें, आदि) कोई तकनीकी कारण यह है कि यह भी 32- और के लिए नहीं किया जा सकता है है चित्रों की तरह संसाधन फ़ाइलें साझा एक कार्यक्रम के 64-बिट संस्करण। जैसे डेविड ने कहा, प्रोग्रामर के लिए यह आसान है अगर उन्हें अलग रखा जाए (जैसे, चर का उपयोग करके यह देखना कि यह फाइलों का एक सेट है, आदि)

— Synetech
स्रोत
वोटिंग का बदला! Muahahaha! sigh
— सिनटेक
डाउन-वोट अजीब: \। BTW अच्छा समझा +1।
— १०:३१ बजे १२
11

एक और कारण यह है कि अधिकांश प्रोग्राम पर्यावरण वेरिएबल्स जैसे% PROGRAMFILES% का उपयोग करने के लिए करते थे, जहां उनका प्रोग्राम स्थापित किया गया था। 64 बिट कार्यक्रमों के लिए, यह सामान्य स्थान पर जाता है। 32 बिट प्रोग्राम के लिए, यह नए Program Files (x86)फ़ोल्डर में रीडायरेक्ट करेगा ।

हालांकि, विज़ुअल स्टूडियो में कम से कम नए .Net सामान के साथ, अब उनके पास App.Local चर है जो इसके लिए संपूर्ण आवश्यकता को समाप्त करता है।

— कैनेडियन ल्यूक
स्रोत
4
वह इसकी व्याख्या नहीं करता है। कौन वास्तव में पर्यावरण चर का उपयोग कर रहा है और यह क्यों ध्यान रखेगा कि क्या कार्यक्रम 32-बिट या 64-बिट है?
— सिनिटेक
4
@Synetech - कार्यक्रमों के लेखक पर्यावरण चर का उपयोग करते हैं। कारण यह है कि यह dlls के संदर्भ के कारण देखभाल करेगा। आप 64-बिट प्रक्रिया के भीतर 32-बिट dll लोड नहीं कर सकते हैं और इसके विपरीत।
— रामहुंड
1
और कैसे करना है %programfiles%, %programfiles(x86)%या %programw6432%वहाँ एक फर्क? कोई भी साझा DLL एकल WinSxS निर्देशिका में जाता है, और कोई भी गैर-साझा DLL निष्पादन योग्य के साथ वहीं होता है। यह केवल तभी होगा जब किसी कारण से आपके पास एक ही प्रोग्राम के 32-बिट और 64-बिट संस्करण दोनों स्थापित हों, और तब भी, आप 32-बिट DLL को 32-बिट निष्पादन योग्य और 64-बिट DLL के साथ रखेंगे। 64-बिट निष्पादन योग्य। आप ऐसा कर सकते हैं: %programfiles%\CoolApp\bin\32और% प्रोग्रामफाइल्स% \ CoolApp \ bin \ 64`, अलग-अलग शीर्ष-स्तरीय फ़ोल्डर्स क्यों?
— सिंटेक
@ सिंथेट ज़रूर करता है; % प्रोग्रामफाइल% थोड़ी देर के आसपास रहा है। यदि आप 64 बिट कंप्यूटर पर 32 बिट प्रोग्राम स्थापित करते हैं, तो एक जगह होने से उस 32 बिट ऐप के लिए समस्याएं पैदा होंगी। वाह हालांकि 32 बिट ऐप्स के लिए (x86) संस्करण के लिए% programfile% और 64 के लिए गैर- x86 संस्करण को पुनर्निर्देशित कर सकते हैं।
— एंडी
मुझे लगता है कि लोग इतने भ्रमित नहीं होंगे, अगर कोई निहित पुनर्निर्देशन नहीं था
— kommradHomer
8

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

संक्रमण को आसान बनाने में मदद करने के लिए, Microsoft ने यह निर्धारित किया है कि सभी 32-बिट एप्लिकेशन को डिफ़ॉल्ट रूप से प्रोग्राम फाइल (x86) फ़ोल्डर में लोड किया जाना चाहिए, बजाय नियमित प्रोग्राम फाइल फ़ोल्डर में सही 64-बिट अनुप्रयोगों के साथ मिश्रित होने के।

स्रोत

"क्या गलत होगा अगर मैं किसी तरह पुनर्निर्देशन तंत्र से बचता हूं और असली C: \ Program Files \" पर स्थापित होने के लिए सब कुछ मजबूर कर देता हूं? "

कुछ भी तो नहीं। दो प्रोग्राम निर्देशिकाएं केवल संगठन के लिए हैं, या उन प्रोग्रामों को रखने के लिए जिनके पास दो संस्करण 32-बिट और 64-बिट संस्करण अलग-अलग हैं, जैसे कि इंटरनेट एक्सप्लोरर। लेकिन आप "प्रोग्राम फाइल्स" में 32-बिट प्रोग्राम और "प्रोग्राम फाइल्स x86" में 64-बिट प्रोग्राम इंस्टॉल कर सकते हैं और ऐसा कुछ भी नहीं होगा कि प्रोग्राम वही चलेगा।

विकी कहता है:

कुछ एप्लिकेशन इंस्टॉलर्स इंस्टॉल पथ स्थान के भीतर रिक्त स्थान को अस्वीकार करते हैं। 32-बिट सिस्टम के लिए, प्रोग्राम फ़ाइल फ़ोल्डर का संक्षिप्त नाम प्रोग्रा ~ 1 है । 64-बिट सिस्टम के लिए, 64-बिट प्रोग्राम फाइल्स फोल्डर का संक्षिप्त नाम प्रोग्रा ~ 1 (32-बिट सिस्टम पर समान) है; जबकि 32-बिट प्रोग्राम फाइल्स (x86) फोल्डर का संक्षिप्त नाम अब Progra ~ 2 है ।

— avirk
स्रोत
1
हेहे। अच्छा लेख। उस लेख की टिप्पणियाँ यहाँ के लोगों की तरह लगती हैं। इससे भी बदतर, वह लेख दो साल से अधिक समय से था, जो यह दर्शाता है कि यह प्रश्न नया नहीं है और यदि इसे अभी भी आधिकारिक रूप से उत्तर नहीं दिया जा सकता है, तो मुझे लगता है कि यह कभी भी नहीं होगा (जब तक कि विंडोज टीम के किसी व्यक्ति ने झंकार नहीं किया हो)। ओह ठीक है, मुझे लगता है कि हम सभी को चिंता करना छोड़ देना चाहिए और बम से प्यार करना सीखना चाहिए, उह, मेरा मतलब इसके साथ रहना है। +1 लेख को इंगित करने और यह दिखाने के लिए कि यह प्रश्न इतने लंबे समय से था।
— सिंटेक
1
@Synetech धन्यवाद! हाँ, लेख लिंक लगाने के पीछे विचार वही है जो आपको मिला था। यह एक बहुत पुराना समय है, लेकिन IDK क्यों लोग इसे अभी तक प्राप्त नहीं कर सके। हालाँकि, MS को इस समस्या के लिए KB या दस्तावेज़ीकरण लिखना चाहिए :)
— avrik
हाँ, उन्हें विशेष रूप से यह सिर्फ डेवलपर्स के लिए ही नहीं पूछना चाहिए, यहाँ तक कि सामान्य उपयोगकर्ता भी इसके बारे में आश्चर्य करते हैं। दुर्भाग्य से Microsoft का प्रलेखन अक्सर बहुत अच्छा नहीं होता है।
— Synetech
@ सिंथ यूप! एमएस प्रलेखन ज्यादातर समय बेकार है। ); लेकिन हाँ वे भी कुछ अच्छा लेख लिखा था और मुझे यकीन है कि वे गणनीय हैं हूँ
— avirk
6

इसका कारण डेवलपर्स के लिए एक प्रोग्राम को 64-बिट में अपग्रेड करना है। उन्हें 32-बिट मोड में और दूसरी निर्देशिका में 64-बिट मोड में संकलन करते समय प्रोग्राम के लिए एक कस्टम कोड लिखने के लिए कोई कस्टम कोड लिखने की आवश्यकता नहीं है; वे सिर्फ जांच करते हैं C:\Program Files, और 32-बिट मोड के तहत चलने पर, यह स्वचालित रूप C:\Program Files (x86)से 64-बिट विंडोज द्वारा बदल जाता है । इसी तरह, रजिस्ट्री प्रविष्टियों को 32-बिट और 64-बिट प्रोग्राम के बीच अलग किया जाता है।

यह अनजाने डेवलपर्स से टकराव को रोकता है जो सिर्फ अपने संकलन मोड को 64-बिट में बदल देते हैं, इसके बारे में ज्यादा विचार किए बिना एक साथ सॉफ्टवेयर।

लेकिन कोई भी प्रोग्राम दोनों वर्जन को एक साथ इंस्टॉल करने की अनुमति क्यों देना चाहेगा? एक उदाहरण: फ़ोटोशॉप और IE में ऐसे एक्सटेंशन हैं जो देशी हैं। आपके पास एक ही प्रक्रिया में 32- और 64-बिट कोड मिश्रित नहीं हो सकते हैं, इसलिए 32-बिट संस्करण के लिए एक ऐडऑन का उपयोग 64-बिट संस्करण और इसके विपरीत नहीं किया जा सकता है। इस प्रकार, फ़ोटोशॉप / IE को दोनों संस्करणों को स्थापित करने की अनुमति देनी होगी, या मौजूदा एडोनों के अपने विशाल आधार को तोड़ने का जोखिम उठाना होगा।

— ब्लूराजा - डैनी पफ्लुघोफ़्ट
स्रोत
2
+1 कम से कम आपने अंतर्निहित प्रश्न को संबोधित किया कि औसत उपयोगकर्ताओं के पास दोनों संस्करण क्यों होंगे।
— Syntech
5

प्रोग्राम जो "प्रोग्राम फाइल्स (x86)" पर चलते हैं, WOW64 सबसिस्टम का उपयोग करते हैं (विंडोज 64-बिट पर विंडोज 32-बिट ड्राइवरों का एक सेट है और एपीआई एक x64 आर्किटेक्चर सिस्टम पर x32 एप्लिकेशन को चलाने के लिए इरादा है):

WoW64 सबसिस्टम में एक हल्की संगतता परत शामिल होती है जिसमें विंडोज के सभी 64-बिट संस्करणों पर समान इंटरफेस होता है। इसका उद्देश्य 32-बिट वातावरण बनाना है जो 64-बिट सिस्टम पर अनमॉडिफाइड 32-बिट विंडोज अनुप्रयोगों को चलाने के लिए आवश्यक इंटरफेस प्रदान करता है। तकनीकी रूप से, WoW64 को तीन डायनेमिक-लिंक लाइब्रेरी (DLL) का उपयोग करके लागू किया गया है:

  • Wow64.dll, Windows NT कर्नेल के लिए मुख्य इंटरफ़ेस जो कि सूचक और कॉल स्टैक जोड़तोड़ सहित 32-बिट और 64-बिट कॉल के बीच अनुवाद करता है।
  • Wow64win.dll, जो 32-बिट अनुप्रयोगों के लिए उचित प्रवेश-बिंदु प्रदान करता है
  • Wow64cpu.dll, जो 32-बिट से 64-बिट मोड में प्रोसेसर को स्विच करने का ख्याल रखता है

64 बिट सिस्टम को 32 बिट्स एप्लिकेशन को "इम्यूलेट" करने की आवश्यकता है, यही कारण है कि विंडोज को दो प्रोग्राम फाइल्स फ़ोल्डर्स को "अलग" करने की आवश्यकता है।

— डियोगो
स्रोत
7
लेकिन इसे अलग-अलग फ़ोल्डरों में क्यों रखना पड़ता है? विंडोज पीई हेडर को देखते हुए पहले से ही एक निष्पादन योग्य की वास्तुकला का निर्धारण करने में पूरी तरह से सक्षम है। जब निष्पादन योग्य लोड होता है तो वह उपयुक्त वातावरण क्यों नहीं लोड कर सकता है?
— सिनटेक
1
मुझे लगता है कि माइक्रोसॉफ्ट से यह केवल एक विकल्प है कि उपयोगकर्ताओं को आसानी से दिखाया जा सके कि प्रोग्राम खोलते समय वे दो प्रोग्राम संस्करण से कौन सा आर्किटेक्चर चाहते हैं। मेरा मतलब है, अगर ये दो फ़ोल्डर्स नहीं थे और अगर यह उपयोगकर्ताओं के लिए पारदर्शी था (यदि यह स्वचालित रूप से स्विच होता है), तो उन्हें पता नहीं चलता कि क्या 32 या 64 बिट्स ऐप चल रहा है, यहां तक ​​कि, उन्हें पता नहीं होगा कि कौन सा प्रोग्राम खोलना है अगर 64 बिट्स पर चल रहा है ..
— डियागो
1
IE के 64-बिट संस्करण में भयानक होने के लिए एक प्रतिष्ठा है।
— शमूएल एडविन वार्ड
1
MS Office32 का उपयोग करने की अनुशंसा करता है जब तक कि आप मेमोरी बाधाओं को पार करने के लिए डेटासेट के साथ पर्याप्त रूप से काम नहीं कर रहे हैं। मेरा मानना ​​है कि कार्यालय के साथ काम करने के लिए द्विआधारी योजक को फिर से जोड़ने की आवश्यकता है; सामान्य उपयोग के मामलों में कोई लाभ नहीं देने के साथ संयुक्त निर्णय के पीछे है।
— दान नीली
1
मुझे लगता है कि आप पाएंगे कि 64-बिट प्रोग्राम स्पष्ट रूप से प्रोग्राम फाइल्स (x86) फ़ोल्डर में स्थापित है, पूरी तरह से सामान्य रूप से काम करेगा (और, ज्यादातर मामलों में, इसके विपरीत)। निष्पादन योग्य का इलाज कैसे करें, यह निर्धारित करने के लिए Windows फ़ोल्डर स्थान का उपयोग नहीं करता है।
— हैरी जॉनसन
5

यह दिलचस्प है कि यहां और इंटरनेट पर उत्तर काफी भिन्न हैं। इस महत्वपूर्ण प्रश्न का सटीक उत्तर खोजना एक चुनौती रही है। प्रतीत होता है कि इंटरनेट पर काफी गलत जानकारी प्रस्तुत की गई है, जिससे भ्रम पैदा होता है।

मैंने एक महत्वपूर्ण मात्रा में अनुसंधान किया है, और निम्नलिखित निष्कर्ष निकाला है, जो मुझे लगता है कि सटीक है:

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

यह स्वचालित रूप से होता है, और जहां आवेदन संग्रहीत होता है, वहां से स्वतंत्र होता है। अलग-अलग 32-बिट और 64-बिट फ़ोल्डर्स होने की कोई गति, विश्वसनीयता या अन्य कार्यात्मक लाभ नहीं है।

दो फोल्डर ('प्रोग्राम फाइल्स' और 'प्रोग्राम फाइल्स (x86)' में डिफॉल्ट से अलग होने का एकमात्र कारण यह है कि यदि आपके पास एक ही प्रोग्राम के दो वर्जन (32-बिट और 64-बिट वर्जन) हैं, तो यह एक प्रदान करता है। ओवरलैपिंग फ़ाइलों को अलग रखने का सरल तरीका। इस मामले में भी, जब तक सभी फ़ाइलनाम अद्वितीय हैं, वे वास्तव में बिना किसी परिणाम के एक ही फ़ोल्डर में मौजूद हो सकते हैं।

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

— RockPaperLizard
स्रोत
3

अलग-अलग फ़ोल्डरों के होने से देशी 64-बिट एप्लिकेशन और थॉस को अलग रखने की आवश्यकता होती है, जिसके लिए WoW64 की आवश्यकता होती है ।

यह उपयोगी हो सकता है - जैसा कि @OliverSalzburg पहले ही इंगित कर चुका है - यदि आप चाहें तो 64-बिट और 32-बिट एक वेब ब्राउज़र (उदाहरण के लिए) स्थापित करना चाहते हैं, क्योंकि कुछ प्लग-इन और ऐड-ऑन केवल एक के लिए उपलब्ध हो सकते हैं दो।

अलग फ़ोल्डरों के होने से रजिस्ट्री पुनर्निर्देशन जैसी तकनीकों का उपयोग करके इस पृथक्करण को स्वचालित बना दिया जाता है ।

मान लीजिए कि कोई इंस्टॉलर प्रोग्राम फाइल फोल्डर का उपयोग करके रजिस्ट्री को पढ़ने की कोशिश करता है, जैसे, RegQueryValueEx ।

किसी भी स्थिति में, यह रजिस्ट्री कुंजी को पढ़ने की कोशिश करता है

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion

जो आम तौर पर इंगित करता है C:\Program Files।

हालाँकि, यदि इंस्टॉलर 32-बिट अनुप्रयोग है, तो रजिस्ट्री पुनर्निर्देशन regitry कुंजी का कारण होगा

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion

इसके बजाय पढ़ा जाना चाहिए, जो सामान्य रूप से इंगित करता है C:\Program Files (x86)।

इन विशेष फ़ोल्डर नामों का उपयोग क्यों किया गया है यह केवल उन लोगों द्वारा उत्तर दिया जा सकता है जिन्होंने यह विकल्प बनाया है। यदि आप चाहते हैं तो आप हमेशा डिफ़ॉल्ट फ़ोल्डर के नाम बदल सकते हैं।

क्या विंडोज़ किसी तरह खुद को "प्रोग्राम फाइल्स (x86)" से बाहर चलने वाले प्रोग्राम में अलग से पेश करता है?

मुझे शक है। अधिकांश इंस्टॉलर आपको एक कस्टम इंस्टॉलेशन फ़ोल्डर चुनने की अनुमति देते हैं, इसलिए यह वास्तव में मायने नहीं रखता कि कोई प्रोग्राम कहाँ स्थापित होता है।

— डेनिस
स्रोत
क्षमा करें मैंने "परमिट" को "
— निषिद्ध
3

मैं यहाँ भ्रम नहीं मान सकता .. सबसे पहले मैं एक पूर्णकालिक डेवलपर हूँ।

एमएस ने यह मामला सुलझाने के लिए किया था जहां एक DLL का उपयोग पुराने 32-बिट अनुप्रयोगों और नए 64-बिट अनुप्रयोगों द्वारा किया जाता है। पुराने तरीके को बदला नहीं जा सकता था (System32, प्रोग्राम फाइल्स इत्यादि) क्योंकि इससे पुराने प्रोग्राम टूट जाएंगे जिन्हें दोबारा नहीं बनाया जा सकता है।

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

जैसा कि यह खड़ा है, .Net DLL एक ही मशीन पर अन्य संस्करणों के साथ सह-अस्तित्व में आ सकता है। उदाहरण के लिए, आपके पास लाइब्रेरी.1.0.1, लाइब्रेरी.1.0.2, लाइब्रेरी 1.1.0 आदि हो सकते हैं और यह केवल एक विशिष्ट बिट आकार (32 या 64) के लिए है। यदि अलग-अलग फ़ोल्डरों का उपयोग नहीं किया जाता है, तो हर विधानसभा में 32 और 64 बिट संस्करण होना चाहिए। यह गंभीर रूप से एक निर्देशिका को अव्यवस्थित कर देगा जिसमें पहले से ही एक ही विधानसभा के कई संस्करण शामिल हैं।

यह सभी डेवलपर सामान है। एक उपयोगकर्ता के रूप में मुझे केवल इससे निपटना होगा जब मैं विंडोज 7 64 पर 32-बिट प्रोग्राम के साथ काम कर रहा हूं। और मैं 32-बिट संस्करण और 64-बिट में भी समान एप्लिकेशन चलाने की क्षमता रखना पसंद करता हूं। जब मैं एक 32-बिट एप्लिकेशन पर काम कर रहा हूं, जिसे मुझे 64-बिट में संकलित करने की आवश्यकता है, तो मैं केवल ऐसा करने के लिए कंपाइलर को बताता हूं। Dll के नाम और बाकी सभी चीजें समान हैं।

विंडोज 95/98 के साथ मौजूद नहीं होने का कारण यह है कि सिस्टम ने 32-बिट रनटाइम की नकल की है; यह वास्तविक 32-बिट ऑपरेटिंग सिस्टम नहीं था। इसने "थुंकिंग" नाम की चीज़ के साथ 32-बिट निष्पादन को रोक दिया।

यहाँ एक अच्छी परिभाषा है: http://searchwinit.techtarget.com/definition/thunk

— जेसन लोके
स्रोत
1
कैसे करता है ProgramFiles(x86)` avoid clutter? There are still both 32- and 64-bit versions of files, so avoiding clutter doesn't make sense. There is no difference between putting them in \ 32 \ blah` या \blah\32; किसी भी तरह से, वे अलग हो जाते हैं। यदि कुछ भी हो, तो वर्तमान तरीका ऐप के घटकों को अलग करता है (और CommonFilesसंसाधनों के लिए उपयोग किए जाने वाले कुछ ऐप के बाद से उन्हें अनावश्यक रूप से डुप्लिकेट भी करता है। इसके अलावा, आप इसे ध्वनि बनाते हैं जैसे कि ऐप अपने DLL को एक आम बकेट में डंप कर रहे हैं। यह ऐप के ऐप को रखना काफी आसान है। 32-बिट डीएलएल इसके 32-बिट एक्सेस के साथ है और यह 64-बिट
— डीएलएस है
ओह, और 95/98 के लिए, किसने उस बारे में कुछ कहा? यहां तक ​​कि XP ​​में 16-बिट सबसिस्टम (NTVDM) था।
— सिंटेक
मुझे लगा कि आप एक स्पष्टीकरण चाहते हैं। कुछ ऐप कॉमनफाइल्स का उपयोग करते हैं? मेरे पास 35 अलग-अलग एप्लिकेशन हैं जिनकी वहां प्रविष्टियां हैं। यह System32 निर्देशिका की तुलना में साझा घटकों को संग्रहीत करने के लिए एक सुरक्षित स्थान है। आपका कथन कि कुछ एप्लिकेशन इसका उपयोग करते हैं, यह बहस का विषय है। आपको उद्धृत करते हुए: "उन्हें एक ही सिस्टम पर 32-बिट और 16-बिट कार्यक्रमों की अनुमति देने के लिए इन हुप्स के माध्यम से कूदने की ज़रूरत नहीं थी। मुझे याद नहीं है कि कभी भी एक ProgramFiles (16) या कुछ ऐसे देखकर [...] हालांकि इसके बारे में यह कार्यक्रम उचित रूप से प्रोग्रामर के लिए एक सुविधा के रूप में किया जा रहा है। " खैर, हाँ .. प्रोग्रामर करते हैं। हम आवेदन आखिरकार लिखते हैं।
— जेसन लोके
है ना?
— Synetech
बस इसे फिर से पढ़ें .. उन्होंने अपने उत्तरों में इसे बेहतर बताया - superuser.com/a/442253/142951 । यदि आप एक डेवलपर नहीं हैं तो आप उद्देश्य को नहीं देख सकते हैं।
— जेसन लोके
0

यह बिल्कुल भी जरूरी नहीं है। मेरे काम करने वाले कंप्यूटर पर उदाहरण के लिए मैं प्रत्येक एप्लिकेशन को फ़ोल्डर C:\MyPrograms\में स्थापित करता हूं ताकि उन्हें हमारे आईटी विभाग द्वारा स्थापित अनुप्रयोगों से अलग किया जा सके।

बेशक, यह मुझे एक आवेदन के दोनों संस्करणों (32 और 64 बिट) को स्थापित करने से रोकता है, लेकिन यह मेरे मामले में कोई समस्या नहीं है।

जब भी आप कोई प्रोग्राम लॉन्च करते हैं, तो हमेशा पहले DLL C:\Windows\System32\ntdll.dllको निष्पादित किया जाता है। यह DLL निर्धारित करता है कि आपका प्रोग्राम 32 या 64 बिट अनुप्रयोग है। इसके आधार पर आपको पुनर्निर्देशित किया जाता है WoW64जिसका उल्लेख पहले से ही कई उत्तरों में किया गया है।

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