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


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

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

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

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


175
2018-06-27 17:19


मूल


अपने प्रश्न का उत्तर देने के बजाय, मैं पूछूंगा - आप \ प्रोग्राम फ़ाइलों \ सामान्य फ़ाइलों को कैसे संभालेंगे? - sgmoore
एक-लाइनर उत्तर (और इसलिए एक टिप्पणी): चूंकि आप आसानी से किसी भी फ़ोल्डर से अपने आर्किटेक्चर को जानने के बिना किसी भी एप्लिकेशन को चला सकते हैं, तो स्पष्ट रूप से कोई नहीं है अनिवार्य इस अलगाव के लिए कारण। यह सुविधा का मामला है दोनों आर्किटेक्चर के साथ अनुप्रयोगों के डबल इंस्टॉल का समर्थन करने के लिए। कुछ मामलों में यह एक फर्क पड़ता है क्योंकि वे जरूरी नहीं कि सरल रीकंपाइल हों। मुख्य समस्या यह है कि 32 बिट ऐप्स 64 बिट डीएलएस लोड नहीं कर सकते हैं, इसलिए आप आम तौर पर एक ही स्थान पर दोनों संस्करणों को स्थापित नहीं कर सकते हैं। दूसरे विकल्प में प्रत्येक एप्लिकेशन के लिए दो "बिन" फ़ोल्डर्स हैं। - Sklivvz
@Synetech I में भी x64 बाइनरी रखने के लिए प्रोग्राम (x86) के तहत स्थापित प्रोग्राम थे .. कभी-कभी यह भयानक है। - sinni800
मैंने हमेशा सोचा है कि क्यों माइक्रोसॉफ्ट ने प्रोग्राम की फाइलों (x86) में प्रोग्राम फाइल निर्देशिका को "विरासत" ले जाने के बजाय "प्रोग्राम फ़ाइलें (x64)" में 64-बिट प्रोग्राम नहीं डाले - LawrenceC
64/32 बिट भेदभाव के बारे में असली गड़बड़ यह है कि / विंडोज / सिस्टम 32 में 64 बिट सामग्री है, जबकि / विंडोज / SysWOW64 में 32 बिट सामग्री है ... - poke


जवाब:


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

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

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

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


89
2018-06-27 18:18



उन्हें एक ही सिस्टम पर 32-बिट और 16-बिट प्रोग्रामों की अनुमति देने के लिए इन हुप्स से कूदना नहीं था। मुझे कभी नहीं देख रहा है ProgramFiles (16)या कुछ ऐसे। इसके अलावा, कैसे एक 32-बिट प्रोग्राम "64-बिट डीएलएल ढूंढें और इसे लोड करने का प्रयास करें"? यादृच्छिक डीएलएल के लिए शिकार के आसपास कौन से कार्यक्रम जाते हैं %programfiles%? यदि यह एक साझा डीएलएल है, तो यह WinSxS में जाता है; अगर इसे साझा नहीं किया जाता है, तो यह प्रोग्रामर पर निर्भर करता है कि वे अपने स्वयं के डीएलएल प्रबंधित करें। हालांकि प्रोग्रामर के लिए एक सुविधा के रूप में इसे उचित के रूप में किया जा रहा है। - Synetech
आईआईआरसी विन 3.1 में प्रोग्राम फाइल निर्देशिका नहीं थी (या अधिकांश ऐप्स इसे अनदेखा करते हैं); नतीजतन कोई विरासत Win16 ऐप्स प्रोग्राम फ़ाइलों में सामान की तलाश करने के लिए शुरू नहीं होगा। इसके बजाय आईआईआरसी साझा पुस्तकालयों को अक्सर खिड़कियों के फ़ोल्डर में कहीं भी लगाया जाता था। Win32 विंडोज़ \ system और windows \ system32 है जिसमें से एक आर्टिफैक्ट है। - Dan Neely
विंडोज 3.1 ने लंबे फ़ाइल नामों का समर्थन नहीं किया, इसलिए यह 'प्रोग्राम फाइल' फ़ोल्डर नहीं हो सका। - Darth Egregious
@JarrodRoberson: काफी विपरीत, ऐसा इसलिए है क्योंकि माइक्रोसॉफ्ट मूल्य पीछे संगतता को अत्यधिक महत्व देता है। - David Schwartz
@Jarrod: दरअसल, जैसा कि प्रत्येक डेवलपर जानता है, माइक्रोसॉफ्ट पिछड़ा संगतता मानता है बहुत अत्यधिक। सचमुच उनके प्रत्येक एपीआई में विरासत विधियां हैं जिन्हें वे निकालने से इनकार करते हैं, और अक्सर गंभीर वे बग जिन्हें वे ठीक करने से इनकार करते हैं, क्योंकि वे उस एपीआई के लिए लिखे पुराने कार्यक्रमों को तोड़ने से डरते हैं। अधिकांश एपीआई के बारे में भी यही सच है, लेकिन माइक्रोसॉफ्ट के बाहर कहीं भी नहीं। - BlueRaja - Danny Pflughoeft


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


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

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

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

  1. फ़ोल्डर भयानक हैं!

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

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

  2. डेटा और तर्क अलग करना बहुत अच्छा है!

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


65
2018-06-27 17:31



क्या वह मूल कारण है, यद्यपि? क्या मैं सिर्फ ऐप इंस्टॉल नहीं कर सका C:\Program Files\App32 तथा C:\Program Files\App64? - Stephen Jennings
@ स्टीफन जेनिंग्स: लेकिन आपको निर्णय लेने के लिए मैन्युअल रूप से आवश्यकता होगी। जिस तरह से यह अब काम करता है वह यह है कि प्रक्रिया स्वचालित है, क्योंकि विंडोज जानता है कि एप्लिकेशन कॉल करते समय कौन सा फ़ोल्डर प्रदान करना है SHGetSpecialFolderPath स्थापित स्थान निर्धारित करने के लिए। - Der Hochstapler
@Synetech: क्यों स्थापित करें %PROGRAMFILES% पहली जगह में? 32 बिट संस्करण को उपयोगकर्ता डेस्कटॉप पर और 64 बिट रीसायकल बिन में क्यों न रखें? सिर्फ इसलिए कि यह किया जा सकता है, इसका मतलब यह नहीं है कि यह एक अच्छा विचार है। क्षमा करें, मैं आपके तर्क का पालन नहीं करता हूं। - Der Hochstapler
@ सिनटेक: हां, आपने यह पूरी तरह से अच्छा उदाहरण दिया है कि यह कैसे किया जा सकता है। एक और पूरी तरह से अच्छा उदाहरण यह कैसे किया जा सकता है यह तरीका है है वास्तव में अभी किया जा रहा है। बस एक फ़ाइल को% PROGRAMFILES% पर लिखना और यह सुनिश्चित करना कि यह सही फ़ोल्डर में समाप्त हो जाएगा एक बात है। अपने लिए जांच कर रहा है कि कौन सा फ़ोल्डर है सही बात एक दूसरा है। यदि आप वास्तव में पूर्व दृष्टिकोण का लाभ नहीं देखते हैं, तो मैं आपको मनाने में सक्षम नहीं हूं। सवाल यह था कि 2 फ़ोल्डर्स क्यों हैं। मुझे लगता है कि मेरा जवाब उस संबंध में पूरी तरह से उचित है। - Der Hochstapler
@ ओलिवर साल्ज़बर्ग, बिल्कुल नहीं। सवाल यह है कि दो फ़ोल्डर्स क्यों हैं अपेक्षित, क्यों नहीं कर रहे हैं। वास्तव में, उन्होंने इसे भी बोल्ड किया: यह भी जरूरी क्यों है? आपने यह समझाया नहीं कि यह क्यों है ज़रूरी और मैंने जो उदाहरण दिया (और यहां तक ​​कि आपका खुद का व्यंग्यात्मक उदाहरण) बस दिखाता है कि यह नहीं करता है है जिस तरह से किया जाना है। - Synetech


टी एल; डॉ:

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


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

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

क्या विंडोज़ किसी भी तरह से प्रोग्राम प्रोग्राम (x86) "से बाहर चल रहे प्रोग्राम के लिए अलग-अलग मौजूद है?

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

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

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

(मैं एक अलग कंप्यूटर का उपयोग कर रहा हूं, इसलिए मैं अपने ब्राउज़र इतिहास पर अपने कदमों का बैकट्रैक करने के लिए भरोसा नहीं कर सकता, लेकिन दूसरे दिन जवाब देने के दौरान यह एसयू सवाल है मैं खत्म हो गया यह SO सवाल है जिसने मुझे जन्म दिया Google PROCESSOR_ARCHITEW6432जो नेतृत्व करता है यह SO सवाल है तथा यह माइक्रोसॉफ्ट ब्लॉग पोस्टिंग।)

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

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

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

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


15
2018-06-27 19:23



बदला नीचे मतदान! Muahahaha! आह - Synetech
अजीब वोट अजीब: \। बीटीडब्ल्यू अच्छी व्याख्या +1। - avirk


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

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


11
2018-06-27 17:36



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


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

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

स्रोत 

"अगर मैं किसी भी तरह से पुनर्निर्देशन तंत्र से परहेज करता हूं और असली सी: \ प्रोग्राम फ़ाइलें \" में स्थापित करने के लिए मजबूर करता हूं तो क्या गलत होगा? 

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

विकी कहते हैं:

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


8
2018-06-28 16:28



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


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

यह अनजान डेवलपर्स से संघर्ष को रोकता है जो अपने संकलन मोड को 64-बिट में बदलकर बिना किसी विचार के बदलते हैं, और डेवलपर्स के लिए बहुत अधिक काम रोकता है जो उपयोगकर्ता चाहते हैं कि 32- और 64-बिट संस्करण दोनों इंस्टॉल करें एक साथ सॉफ्टवेयर।


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


6
2018-06-27 18:48



+1 कम से कम आपने अंतर्निहित प्रश्न को संबोधित किया कि औसत उपयोगकर्ताओं के पास दोनों संस्करण क्यों होंगे। - Synetech


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

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

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

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


5
2018-06-27 17:32



लेकिन इसे अलग फ़ोल्डर्स में क्यों रखना है? विंडोज पीई हेडर को देखकर निष्पादन योग्य के आर्किटेक्चर को निर्धारित करने में पूरी तरह से सक्षम है। यह निष्पादन योग्य लोड होने पर उपयुक्त वातावरण क्यों लोड नहीं कर सकता है? - Synetech
मुझे लगता है कि यह माइक्रोसॉफ्ट से सिर्फ एक विकल्प है जो आसानी से उपयोगकर्ताओं को दिखाता है कि वे प्रोग्राम खोलते समय दो प्रोग्राम संस्करण से आर्किटेक्चर चाहते हैं। मेरा मतलब है, अगर इन दो फ़ोल्डर्स नहीं थे और यदि यह उपयोगकर्ताओं के लिए पारदर्शी था (यदि यह स्वचालित रूप से स्विच हो जाता है), तो वे नहीं जानते होंगे कि 32 या 64 बिट्स ऐप चलाना है, भले ही वे नहीं जानते कि कौन सा प्रोग्राम खोलना है अगर 64 बिट्स पर चल रहा है .. - Diogo
आईई के 64-बिट संस्करण में भयानक होने की प्रतिष्ठा है। - Samuel Edwin Ward
एमएस Office32 का उपयोग करने की सिफारिश करता है जब तक कि आप स्मृति बाधाओं को पार करने के लिए पर्याप्त डेटासेट्स के साथ काम नहीं कर रहे हों। मुझे विश्वास है कि ऑफिस 64 के साथ काम करने के लिए बाइनरी एडॉन्स को पुन: संकलित करने की आवश्यकता है; सामान्य उपयोग मामलों में कोई लाभ नहीं देने के साथ संयुक्त निर्णय के पीछे है। - Dan Neely
मुझे लगता है कि आप पाएंगे कि प्रोग्राम फ़ाइलों (x86) फ़ोल्डर में स्पष्ट रूप से स्थापित 64-बिट प्रोग्राम सामान्य रूप से सामान्य रूप से काम करेगा (और, ज्यादातर मामलों में, इसके विपरीत)। एक्जिक्यूटिव का इलाज कैसे करें यह निर्धारित करने के लिए विंडोज फ़ोल्डर स्थान का उपयोग नहीं करता है। - Harry Johnston


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

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

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

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

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

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


5
2017-10-16 19:57





फ़ोल्डरों को अलग करने के लिए देशी 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
2018-06-27 18:40



क्षमा करें मैं "वर्जित" के साथ मिश्रित "परमिट" - Wernfried Domscheit


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

एमएस ने इस मामले को हल करने के लिए ऐसा किया जहां डीएलएल का उपयोग पुराने 32-बिट अनुप्रयोगों और नए 64-बिट अनुप्रयोगों दोनों द्वारा किया जाता है। पुरानी विधि को बदला नहीं जा सका (सिस्टम 32, प्रोग्राम फाइल्स इत्यादि) क्योंकि इससे पुराने कार्यक्रमों को तोड़ दिया जाएगा जिन्हें पुन: संकलित नहीं किया जा सकता है।

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

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

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

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

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


3
2018-06-28 14:43



कैसे 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 संसाधनों और ऐसे के लिए। इसके अलावा, आप इसे ध्वनि बनाते हैं जैसे कि ऐप्स एक आम बाल्टी में अपने डीएलएल को डंप कर रहे हैं। ऐप के 32-बिट डीएलएल को 32-बिट एक्सईएस के साथ रखना आसान है और 64-बिट एक्सएल के साथ यह 64-बिट डीएलएल है। - Synetech
ओह, और 95/98 के लिए, किसने इसके बारे में कुछ कहा? यहां तक ​​कि एक्सपी में 16-बिट सबसिस्टम (एनटीवीडीएम) था। - Synetech
मैंने सोचा कि आप एक स्पष्टीकरण चाहते थे। कुछ ऐप्स कॉमनफाइल का उपयोग करते हैं? मेरे पास 35 अलग-अलग एप्लिकेशन हैं जिनमें प्रविष्टियां हैं। System32 निर्देशिका से साझा घटकों को संग्रहीत करने के लिए यह एक सुरक्षित स्थान है। आपका बयान कि कुछ ऐप्स इसका उपयोग करते हैं, वह बहस योग्य है। आपको उद्धृत करते हुए: "उन्हें एक ही सिस्टम पर 32-बिट और 16-बिट प्रोग्रामों की अनुमति देने के लिए इन हुप्स से कूदना नहीं था। मुझे प्रोग्रामफाइल (16) या कुछ ऐसे [...] को कभी भी याद नहीं है हालांकि प्रोग्रामर के लिए एक सुविधा के रूप में इसे उचित के रूप में किया जा रहा है। " खैर, हाँ .. प्रोग्रामर करते हैं। हम सब के बाद आवेदन लिखते हैं। - Jason Locke
है ना? - Synetech
बस इसे फिर से पढ़ें .. उसने अपने उत्तरों में बेहतर कहा - superuser.com/a/442253/142951। यदि आप डेवलपर नहीं हैं तो आप उद्देश्य को नहीं देख सकते हैं। - Jason Locke


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

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

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


0
2018-05-08 08:40