Dlaczego system Windows 7 instaluje 64-bitowe aplikacje w folderze Program Files (x86)? Czy mogę zmienić zachowanie?

Korzystam z 64-bitowej wersji systemu Windows 7 od czasu CTP i napotkałem kilka problemów z aplikacjami instalowanymi w C:\Program Files (x86)folderze. Jaki jest cel posiadania 2 oddzielnych katalogów plików programu?

Każdy program, który zainstalowałem, znalazł się w C:\Program Files (x86)folderze. Nie ma znaczenia, czy aplikacja jest 32- czy 64-bitowa. Dlaczego aplikacje 64-bitowe nie są umieszczane C:\Program Files?

Czy istnieje sposób, aby C:\Program Fileszamiast tego zmienić domyślną wartość ? Czy coś by to popsuło, gdybym tylko wszystko włożył C:\Program Files?

Jeśli rzeczywiście istnieje pewna korzyść z posiadania osobnego folderu dla aplikacji 64-bitowych, wydaje się, że bardziej rozsądnym rozwiązaniem byłoby użycie C:\Program Filesaplikacji x86 i utworzenie nowego C:\Program Files (x64)folderu dla nowych aplikacji 64-bitowych. Pomogłoby to zachować zgodność wsteczną. Pracuję jako programista, a niektóre z moich projektów zawierają odwołania do ścieżek do bibliotek pod C:\Program Files. Teraz te odniesienia są zepsute na komputerze z systemem Windows 7, który je umieścił C:\Program Files (x86). Próbowałem nawet zmienić lokalizację docelową w instalatorze C:\Program Files, ale to zostało zignorowane, a aplikacja i C:\Program Files (x86)tak się zmieniła .

Jest to bardzo frustrujące, ponieważ muszę współdzielić kod źródłowy między maszynami 32- i 64-bitowymi i nie chcę bałaganu w jakimś pliku konfiguracyjnym, który inaczej ustawia ścieżkę do tych bibliotek na różnych komputerach.

Edycja dotycząca zmiennych środowiskowych: (Używając tylko domyślnych angielskich wartości zmiennych dla uproszczenia.) Na komputerze 64-bitowym %ProgramFiles%będzie, C:\Program Filespodczas gdy zupełnie nowa zmienna %ProgramFiles(x86)%będzie C:\Program Files (x86). Tak więc, jeśli masz program 32-bitowy, który musi znaleźć ścieżkę do folderu, w którym byłby zainstalowany, musiałby sprawdzić, czy działa na 32-bitowej lub 64-bitowej wersji systemu Windows w celu wiedzieć, której zmiennej środowiskowej użyć. Wszelkie 32-bitowe aplikacje, które zostały napisane bez tych uwag, muszą zostać zaktualizowane, aby działały poprawnie na komputerze 64-bitowym. Więc nawet przy użyciu zmiennych środowiskowych zgodność wsteczna jest zepsuta.

Ponadto %ProgramFiles(x86)%nie istnieje w 32-bitowych wersjach systemu Windows. Gdyby tak było, wówczas 32-bitowe aplikacje mogłyby zawsze używać tej zmiennej środowiskowej i nie potrzebowałyby żadnej logiki warunkowej w oparciu o system operacyjny, na którym działają.

Powodem tego jest po prostu wiele starszych instalatorów albo nie rozumiejących nowej struktury plików i umieszczających wszystko w standardowym katalogu plików programów, albo patrzysz na inteligentny program, który ma kilka 32-bitowych komponentów, które są tam kopiowane.

Najlepiej jest pobrać nowy program - na przykład x64 Winrar i po prostu zobaczyć, gdzie się instaluje, aby wykluczyć problem z maszyną.

Jeśli chodzi o bałagan - może, ale tak naprawdę zależy od programu, nie ma jednej odpowiedzi dla wszystkich ... niektóre mniejsze, kompaktowe programy z zaledwie kilkoma plikami nie powinny mieć problemu, jeśli tak, jeśli mówisz o pakiecie Office , Adobe lub jakikolwiek inny „pakiet” lub duży program, najprawdopodobniej zakończy się niepowodzeniem, ponieważ mają wiele współużytkowanych komponentów o architekturze krzyżowej.

Jeśli używasz czegoś innego niż %ProgramFiles%(lub CSIDL_PROGRAM_FILESw .NET Environment.GetFolderPath(Environment.SpecialFolder.ProgramFiles)) i tak masz kłopoty, ponieważ instalacje niestandardowe mogą mieć programy zainstalowane na innych woluminach (D: na przykład), a instalacje międzynarodowe często mają inne foldery domyślnie.

• Hiszpański Okna C:\Archivos de Programa,
• Francuski Okna C:\Programmes,
• Niemiecki Okna C:\Programme,
• Szwedzki system Windows: C:\Program

itp.

Należy pamiętać, że w 64-bitowych wersjach systemu Windows 7 (może to również dotyczyć innych nowszych wersji systemu operacyjnego, ale mogę to potwierdzić tylko w przypadku Win 7 w wersji 64-bitowej) istnieje różnica między widoczną lokalizacją pliku% ProgramFiles% w Eksploratorze i DOS.

W systemie Windows 7 rzeczywista lokalizacja folderu fizycznego% ProgramFiles% (i powiązanej zmiennej środowiskowej% ProgramFiles (x86)%) jest ustalona zgodnie z wersją angielską ; tzn. odpowiednio „C: \ Program Files” i „C: \ Program Files (x86)”, ale jest odpowiednio pokazany w eksploratorze .

Aby podać konkretny przykład; w szwedzkiej 64-bitowej instalacji systemu Windows 7, jeśli otworzysz Eksploratora i zajrzysz do napędu systemowego (zazwyczaj C :) zobaczysz „ Program ” i „ foldery Program (x86) ”. Wpisanie% ProgramFiles% w pasku adresu powoduje przejście do „C: \ Program”.

Jednak jeśli otworzysz okno DOS i wpiszesz SET, zobaczysz, że faktyczna wartość% ProgramFiles% to „C: \ Program Files”, a nie program do przeglądania folderów „C: \ Program”. Dalsze eksplorowanie za pomocą CD i DIR można zobaczyć fizycznie to „C: \ Program Files”

Morał jest taki, że jeśli używasz zmiennych środowiskowych lub programu za pośrednictwem interfejsu API, wszystko nadal będzie działać, ale pamiętaj o tej subtelnej zmianie podczas eksploracji systemu plików!