विंडोज 7 प्रोग्राम फाइलों (x86) फ़ोल्डर में 64 बिट ऐप्स को क्यों स्थापित करता है? क्या मैं व्यवहार बदल सकता हूं?


12

मैं CTP के बाद से विंडोज 7 के 64-बिट संस्करण का उपयोग कर रहा हूं और उन अनुप्रयोगों में कुछ समस्याओं में चला गया है जो C:\Program Files (x86)फ़ोल्डर में स्थापित होते हैं । वैसे भी 2 अलग-अलग प्रोग्राम फ़ाइल निर्देशिकाओं का उद्देश्य क्या है?

मेरे द्वारा इंस्टॉल किया गया प्रत्येक प्रोग्राम C:\Program Files (x86)फ़ोल्डर में चला गया है । ऐसा लगता नहीं है कि ऐप 32 या 64 बिट का है। 64-बिट ऐप्स को क्यों नहीं रखा गया C:\Program Files?

क्या C:\Program Filesइसके बजाय डिफ़ॉल्ट को बदलने का एक तरीका है ? अगर मैं अभी सबकुछ डालूं तो क्या यह कुछ भी गड़बड़ करेगा C:\Program Files?

अगर वास्तव में 64 बिट ऐप्स के लिए एक अलग फ़ोल्डर होने का कुछ लाभ है, तो ऐसा लगता है कि अधिक समझदार डिफ़ॉल्ट C:\Program Filesx86 एप्लिकेशन के लिए उपयोग करना होगा और C:\Program Files (x64)नए 64-बिट एप्लिकेशन के लिए एक नया फ़ोल्डर बनाना होगा । यह पीछे की संगतता को बनाए रखने में मदद करेगा। मैं एक सॉफ्टवेयर डेवलपर के रूप में काम करता हूं और मेरी कुछ परियोजनाओं में पुस्तकालयों के तहत पथ संदर्भ शामिल हैं C:\Program Files। अब उन संदर्भों को विंडोज 7 मशीन पर तोड़ दिया गया है जिन्होंने उन्हें अंदर रखा है C:\Program Files (x86)। मैंने भी इंस्टॉलर में लक्ष्य स्थान को बदलने की कोशिश की C:\Program Files, लेकिन इसे नजरअंदाज कर दिया गया और ऐप C:\Program Files (x86)वैसे भी चला गया ।

यह बहुत निराशाजनक है क्योंकि मुझे 32 और 64 बिट मशीनों के बीच स्रोत कोड साझा करने की आवश्यकता है और मैं कुछ कॉन्फ़िगरेशन फ़ाइल के साथ गड़बड़ नहीं करना चाहता जो इन पुस्तकालयों के लिए अलग-अलग मशीनों पर अलग-अलग तरीके से रास्ता तय करता है।

पर्यावरण चर के बारे में संपादित करें: (सरलता के लिए चर के केवल डिफ़ॉल्ट अंग्रेजी मूल्यों का उपयोग करना।) 64-बिट मशीन पर %ProgramFiles%होगा C:\Program Filesजबकि ब्रांड नया चर %ProgramFiles(x86)%होगा C:\Program Files (x86)। इसलिए, यदि आपके पास एक 32-बिट प्रोग्राम है जिसे उस फ़ोल्डर पथ को खोजने की आवश्यकता है जिसे इसके तहत स्थापित किया जाएगा, तो यह देखने के लिए जांचना होगा कि क्या यह 32-बिट या विंडोज के 64-बिट संस्करण में चल रहा था। जो पर्यावरण चर का उपयोग करने के लिए पता करने के लिए। इस विचार के बिना लिखे गए किसी भी 32-बिट ऐप को 64-बिट मशीन पर सही ढंग से काम करने के लिए अपडेट करने की आवश्यकता होगी। तो यहां तक ​​कि पर्यावरण चर का उपयोग करते हुए, पीछे की संगतता टूट गई है।

इसके अलावा, %ProgramFiles(x86)%विंडोज के 32-बिट संस्करणों पर मौजूद नहीं है। यदि ऐसा होता है, तो 32-बिट ऐप्स हमेशा उस पर्यावरण चर का उपयोग कर सकते हैं और जिस ओएस पर वे चल रहे हैं उसके आधार पर किसी भी सशर्त तर्क की आवश्यकता नहीं होगी।


6
क्या आप सकारात्मक हैं ये ऐप वास्तव में 64-बिट हैं? ज्यादातर मामलों में आपको ऐसे प्रोग्राम मिलेंगे जो सिर्फ 64-बिट संगत हैं, लेकिन वास्तव में 32-बिट अनुप्रयोग हैं।
जॉन टी

मुझे आश्चर्य है कि अगर %ProgramFiles%पर्यावरण चर का उपयोग करने से यह हल हो जाएगा। सुनिश्चित नहीं है कि यह x86 / 64bit अंतर को कैसे संभालता है।
ceejayoz

जवाबों:


7

इसका कारण बस कई पुराने इंस्टॉलर हैं या तो नई फ़ाइल संरचना को नहीं समझते हैं और मानक प्रोग्राम फ़ाइलों की निर्देशिका में सब कुछ प्लैंक करते हैं या आप एक स्मार्ट प्रोग्राम देख रहे हैं जिसमें कुछ 32-बिट घटक हैं जो वहां कॉपी किए जा रहे हैं।

आपका सबसे अच्छा दांव एक नया प्रोग्राम डाउनलोड करना है - जैसे कि x64 विनर और बस यह देखें कि यह आपकी मशीन के साथ किसी समस्या से निपटने के लिए कहां स्थापित होता है।

सामान को गड़बड़ाने के लिए - यह कर सकते हैं, लेकिन यह वास्तव में कार्यक्रम पर निर्भर करता है, कोई भी जवाब नहीं है सभी फिट बैठता है ... बस कुछ फ़ाइलों के साथ कुछ छोटे, कॉम्पैक्ट कार्यक्रमों में कोई समस्या नहीं होनी चाहिए, जहां, यदि आप कार्यालय के बारे में बात करते हैं , Adobe या किसी भी अन्य "सूट" या बड़े कार्यक्रम, यह सबसे अधिक संभावना विफल हो जाएगा क्योंकि उनके पास कई साझा घटक हैं जो क्रॉस आर्किटेक्चर हैं।


इसलिए, Microsoft ने 32-बिट ऐप्स के लिए "C: \ Program Files" स्थान क्यों नहीं बनाया ताकि उन पुराने इंस्टॉलरों को समस्या न हो। इसके अलावा, मुझे वास्तव में समझ में नहीं आता है कि अलग होने की आवश्यकता क्यों है। वे सभी सिर्फ "C: \ Program Files" में क्यों नहीं जा सकते?
कोडरडेन 16

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

4

यदि आप वैसे भी %ProgramFiles%(या CSIDL_PROGRAM_FILES, या .NET के तहत Environment.GetFolderPath(Environment.SpecialFolder.ProgramFiles)) के अलावा किसी भी चीज़ का उपयोग करते हैं, तो आप किसी भी समस्या में हैं, क्योंकि कस्टम इंस्टॉलेशन में अन्य वॉल्यूम (D: उदाहरण के लिए) के तहत प्रोग्राम इंस्टॉल हो सकते हैं और अंतर्राष्ट्रीय इंस्टॉलेशन में अक्सर डिफ़ॉल्ट रूप से अन्य फ़ोल्डर होते हैं।

  • स्पेनिश विंडोज: C:\Archivos de Programa,
  • फ्रेंच विंडोज: C:\Programmes,
  • जर्मन विंडोज: C:\Programme,
  • स्वीडिश विंडोज: C:\Program

आदि।


मैंने अपने मूल प्रश्न में पर्यावरण चर का उल्लेख नहीं किया, इसे सरल रखने के लिए। मैंने अभी एक एड किया है जो बताता है कि कैसे उपयोग %ProgramFiles%करना वास्तव में समस्या का कारण बनता है।
कोडरडैनी

3

कृपया ध्यान दें कि विंडोज 7 के 64-बिट संस्करणों के तहत (यह अन्य नए ओएस संस्करणों पर भी लागू हो सकता है, लेकिन मैं केवल विन 7 64-बिट के लिए इसकी पुष्टि कर सकता हूं) आपके% ProgramFiles% के अपरेंट स्थान में अंतर है एक्सप्लोरर में और डॉस में।

विंडोज 7 के तहत अंग्रेजी संस्करण के अनुसार % ProgramFiles% (और संबंधित% ProgramFiles (x86)% environemnt चर) का वास्तविक भौतिक फ़ोल्डर स्थान ; यानी "C: \ Program Files" और "C: \ Program Files (x86)" respivley , लेकिन उचित रूप में स्थानीयकृत शोषक में दिखाया गया है

एक विशिष्ट उदाहरण प्रदान करने के लिए; यदि आप एक्सप्लोरर खोलते हैं और सिस्टम ड्राइव (आमतौर पर C :) आप " प्रोग्राम " और " प्रोग्राम (x86) " फ़ोल्डर देखते हैं, तो एक स्वीडिश विंडोज 7 64-बिट इंस्टॉल पर । एड्रेस बार में% ProgramFiles% टाइप करना आपको "C: \ Program" में ले जाता है।

हालाँकि, यदि आप एक DOS बॉक्स खोलते हैं और SET टाइप करते हैं, तो आप देखेंगे कि% ProgramFiles% का वास्तविक मान "C: \ Program Files" है न कि "C: \ Program" फ़ोल्डर का शोषक आपको दिखाता है। सीडी और डीआईआर के साथ आगे की खोज आप इसे भौतिक रूप से देख सकते हैं "C: \ Program Files"

नैतिक है यदि आप एपीआई के माध्यम से पर्यावरण के varaibles या प्रोग्राम का उपयोग करते हैं, तो सब कुछ अभी भी काम करेगा, लेकिन फ़ाइल सिस्टम की खोज करते समय इस सूक्ष्म परिवर्तन से अवगत रहें!


पोलिश संस्करण में "प्रोग्राम फाइल्स (x86)" "प्लिकी प्रोग्रामो (x86)" है, जबकि "प्रोग्राम फाइल्स" अच्छी तरह से ... "प्रोग्राम फाइल्स" है। पोलिश में अजीब व्याकरण है। इसके अलावा, कृपया इसे DOS बॉक्स न कहें। वहां कोई डॉस नहीं है।
किनोकिजुफ
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.