Wiem, że w 64-bitowej wersji systemu Windows folder „Program Files” jest przeznaczony dla programów 64-bitowych, a folder „Program Files (x86)” dla programów 32-bitowych, ale dlaczego jest to nawet konieczne?
Przez „konieczne” nie mam na myśli „dlaczego Microsoft nie mógł podjąć żadnych innych decyzji projektowych?” bo oczywiście mogliby. Mam na myśli raczej „dlaczego, biorąc pod uwagę obecny projekt 64-bitowego systemu Windows, programy 32-bitowe muszą mieć oddzielny folder najwyższego poziomu od programów 64-bitowych?” Innymi słowy: „co poszedłoby źle, gdybym w jakiś sposób uniknął mechanizmu przekierowania i zmusiłbym wszystko do zainstalowania się w rzeczywistości C:\Program Files\?”
Super użytkownik ma wiele pytań, które mówią, że „jedno dotyczy programów 32-bitowych, jedno dotyczy programów 64-bitowych”, ale żadne z nich nie znalazło powodu. Z mojego doświadczenia wynika, że nie wydają się znaczenia, czy program 32-bitowy jest zainstalowany w odpowiednim miejscu, czy nie.
Czy system Windows w jakiś sposób prezentuje się inaczej niż program, na którym kończy się „Program Files (x86)”? Czy istnieje opis, który dokładnie pokazuje, czym różni się program zainstalowany w „Program Files (x86)” zamiast „Program Files”? Myślę, że jest mało prawdopodobne, aby Microsoft wprowadził nowy folder bez uzasadnionego powodu technicznego.
Odpowiedzi:
Krótka odpowiedź: aby zapewnić, że starsze 32-bitowe aplikacje będą działać tak samo, jak kiedyś, bez narzucania brzydkich reguł 64-bitowym aplikacjom, które spowodowałyby trwały bałagan.
To nie jest konieczne. Jest to po prostu wygodniejsze niż inne możliwe rozwiązania, takie jak wymaganie od każdej aplikacji stworzenia własnego sposobu oddzielania 32-bitowych bibliotek DLL i plików wykonywalnych od 64-bitowych bibliotek DLL i plików wykonywalnych.
Głównym powodem jest sprawienie, by 32-bitowe aplikacje, które nawet nie wiedzą, że 64-bitowe systemy istnieją, „działają”, nawet jeśli 64-bitowe biblioteki DLL są zainstalowane w miejscach, w których aplikacje mogą wyglądać. Aplikacja 32-bitowa nie będzie mogła załadować 64-bitowej biblioteki DLL, dlatego potrzebna była metoda, aby upewnić się, że aplikacja 32-bitowa (która może być wcześniejsza niż 64-bitowa, a zatem nie ma pomysłu na pliki 64-bitowe) nawet istnieje) nie znalazłby 64-bitowej biblioteki DLL, próbowałby ją załadować, zawieść, a następnie wygenerować komunikat o błędzie.
Najprostszym rozwiązaniem tego są konsekwentnie oddzielne katalogi. Naprawdę jedyną alternatywą jest wymaganie, aby każda 64-bitowa aplikacja „ukrywała” swoje pliki wykonywalne w miejscu, w którym aplikacja 32-bitowa nie wyglądałaby, na przykład
bin64katalog wewnątrz tej aplikacji. Ale to narzuciłoby stałą brzydotę 64-bitowym systemom tylko do obsługi starszych aplikacji.źródło
ProgramFiles (16)coś takiego. Poza tym, w jaki sposób 32-bitowy program „znajdzie 64-bitową bibliotekę DLL i próbuje ją załadować”? W jakich programach chodzi poszukiwanie losowych bibliotek DLL%programfiles%? Jeśli jest to współużytkowana biblioteka DLL, to jest dostępna w WinSxS; jeśli nie jest udostępniony, to do programisty należy zarządzanie własnymi bibliotekami DLL. Część tego, że jest to robione jako wygoda dla programistów, jest jednak rozsądna.Pozwala zainstalować zarówno 32-bitową, jak i 64-bitową wersję aplikacji bez zastępowania się.
Po zapoznaniu się z odpowiedzią i komentarzem następnego dnia, zdaję sobie sprawę z możliwego poważnego przeoczenia mojej odpowiedzi. Fałszywie założyłem zaplecze programistyczne i kiedy mówiłem o tobie w moich komentarzach, nie miałem na myśli użytkownika, ale programistę.
Nie pracuję dla Microsoft i nie mam pojęcia, jakie jest prawdziwe uzasadnienie tych folderów, ale myślę, że powód posiadania tych folderów jest tak oczywisty, że nie mam problemu z ich argumentowaniem.
Rozbijmy to!
Foldery są niesamowite!
Uzgodnijmy coś. Foldery są świetne! Nie potrzebujemy ich, mamy wystarczającą liczbę możliwych nazw plików, aby umieścić każdy plik w katalogu głównym dysku twardego, więc po co w ogóle mieć foldery?
Pomagają nam zamawiać nasze rzeczy. A zamawianie rzeczy jest świetne. Pomaga nam łatwiej przetwarzać rzeczy. Jest to szczególnie przydatne podczas pracy z maszyną wymagającą struktury.
Rozdzielanie danych i logiki jest świetne!
Często występującym w programowaniu paradygmatem jest oddzielanie danych od logiki. Chcesz jedną część, która wie jak coś zrobić i chcesz kolejną część, którą można zrobić coś z .
Można to również znaleźć w systemie plików.
Mamy foldery do aplikacji (logika) i foldery na nasze kosztowności (dane):
Logika
%WINDIR%%PROGRAMFILES%%PROGRAMFILES(x86)%Dane
%PROGRAMDATA%%HOMEDRIVE%%HOMEPATH%Wygląda więc na to, że foldery są niesamowite i sensowne jest umieszczanie programów w ich własnym małym folderze. Ale dlaczego mają 2? Dlaczego nie pozwolić, aby instalator sobie z tym poradził i umieścił wszystko w jednym
Programsfolderze?Instalatorzy nie są magią
Dzisiaj często używamy małych programów do instalowania naszych większych programów. Nazywamy te instalatory małych programów .
Instalatorzy nie są magią. Muszą być napisane przez programistów i są aplikacjami (z możliwymi błędami), jak każda inna aplikacja. Spójrzmy więc na sytuację, z którą wyimaginowany programista musiałby się zmierzyć z obecnym systemem i bez niego:
1 folder Program Files
Deweloper utrzymuje 2 instalatorów. Jeden dla wersji 32-bitowej i jeden dla wersji 64-bitowej jego aplikacji. Instalator 32-bitowy napisze do,
C:\Program Files\App\a instalator 64 -bitowy napisze doC:\Program Files\App\sixtyfour\.2 foldery Program Files
Deweloper utrzymuje 1 instalator. Instalator zawsze będzie pisać
%PROGRAMFILES%i zależeć od systemu operacyjnego, aby odpowiednio rozwinąć ścieżkę (w tych przypadkach nie używasz zmiennych środowiskowych, możesz użyć SHGetKnownFolderPath z,FOLDERID_ProgramFilesaby pobrać poprawną ścieżkę).Wszystko znajduje swoje miejsce automatycznie, a wzór jest identyczny z każdą instalowaną aplikacją .
Spójność ma sens
Kiedy się czegoś uczysz , zwykle oznacza to, że zaobserwowane zachowanie było spójne. W przeciwnym razie naprawdę nie ma nic do obserwowania i nauki.
To samo dotyczy naszego małego systemu plików. Sensowne jest zawsze umieszczanie tych samych rzeczy w tych samych folderach. W ten sposób będziemy wiedzieć, gdzie szukać, gdy czegoś szukamy.
System rozróżniania aplikacji 32/64 wspiera ten cel. Aplikacje są podzielone na 2 lokalizacje, aby uniknąć konfliktów nazw, zachowania ładowania binarnego i bezpieczeństwa (do pewnego stopnia).
Nadal nie rozumiem. To wydaje się bezużyteczne
Nigdy nie powinieneś zapominać o jednej rzeczy. Ludzie są niesamowicie głupi. Dotyczy to użytkowników, superużytkowników, a zwłaszcza programistów.
Dlatego potrzebujemy takich rzeczy, jak przekierowanie systemu plików, aby nawet nasze systemy były użyteczne.
Programiści po prostu tam wejdą i spróbują się załadować,
C:\Windows\system32\awesome.dllnie dbając o to, czy działają w systemie 32- lub 64-bitowym. Próbowaliby załadować 64-bitową bibliotekę DLL i po prostu zawiesić się. Niektórzy programiści chcą używać biblioteki DLL Office, nie ma problemu, wiedzą, gdzie ją znaleźć!C:\Program Files\Microsoft\Office\14.0\wizards.dll... i kolejna katastrofa!Wszystkie te żądania 32-bitowej aplikacji są przekierowywane do 32-bitowych odpowiedników, aby uniknąć awarii aplikacji.
Potrzebujemy ustalonych nazw folderów, aby zbudować taki system. Jeśli nie ma struktury folderów, która obsługiwałaby to przekierowanie, to jak sprawisz, aby działało?
Okej, teraz rozumiem. Ale dlaczego więc nie użyć
C:\Program Files\x86\?Teraz zaczynamy filozofować ...
Co pójdzie nie tak, gdybym w jakiś sposób uniknął mechanizmu przekierowania i zmusiłbym wszystko do zainstalowania się w rzeczywistości
C:\Program Files\?Najprawdopodobniej nic (o ile inne aplikacje nie zależą od stałej lokalizacji dla tej aplikacji).
W WOW64 mechanizm haki do
CreateProcessi będzie funkcjonował bardziej wyrafinowane (bardziej wyrafinowane niż sprawdzanie nazwy folderu wykonywalnego) kontrole obrazu wykonywalnego, aby ustalić, czy jest to 32 lub 64 bit.Tak, ale mam na myśli WSZYSTKIE aplikacje!
Niektóre pytania nie wymagają odpowiedzi. To nie jest przeznaczone do zrobienia, nie rób tego. Nic tu nie można zyskać. Ilość problemów, jakie taka zmiana może spowodować, zawsze przeważa nad wszelkimi możliwymi korzyściami, jakie ktoś może w tym zobaczyć.
źródło
C:\Program Files\App32iC:\Program Files\App64?SHGetSpecialFolderPathcelu ustalenia lokalizacji instalacji.%PROGRAMFILES%? Dlaczego nie umieścić wersji 32-bitowej na pulpicie użytkowników, a wersji 64-bitowej w Koszu? To, że można to zrobić, nie oznacza, że to dobry pomysł. Przepraszam, nie podążam za twoim rozumowaniem.TL; DR:
Podsumowując, nie, nie jest to konieczne ; one mogły być stosowane jeden folder, a nie, system Windows nie przedstawiać się odmiennie do programu są uruchamiane z jednego lub drugiego.
Cóż, wszyscy wydają się wypowiadać na ten temat, więc wrzucę 2 ¢. Inni już domyślili się, dlaczego Microsoft postanowił utworzyć osobne foldery najwyższego poziomu dla 32-bitowych i 64-bitowych wersji programów, więc zostawię tę część (najlepszym powodem było wyjaśnienie Davida, że jest to wygoda dla programistów). Oczywiście nawet wtedy nie odpowiada na bezpośrednie pytanie, dlaczego jest to w ogóle konieczne? , na które odpowiedź brzmi: nie .
Zamiast tego odniosę się do głównej części pytania
Nie do końca, ale lokalizacja programu może wpływać na zachowanie, ale nie w sposób, w jaki myślisz.
Kiedy uruchamiasz program, Windows konfiguruje środowisko, w którym chcesz go uruchomić (mam na myśli pamięć, adresowanie itp., Nie tylko zmienne środowiskowe). To środowisko zależy od zawartości pliku wykonywalnego (programy 32-bitowe i 64-bitowe różnią się wewnętrznie). Po uruchomieniu programu 32-bitowego w systemie 64-bitowym działa on w 32-bitowym podsystemie, który emuluje środowisko 32-bitowe. Nazywa się WoW64 (WoW64 oznacza Windows w 64-bitowym systemie Windows ) i jest podobny do tego, jak 16-bitowe aplikacje będą uruchamiane w XP za pomocą NTVDM .
Uruchamianie programu z uprawnieniami administratora lub bez niego wpływa na to, jak działa, ale lokalizacja nie powinna na niego wpływać (chociaż istnieją pewne przykłady zależności lokalizacji, na przykład niektóre sterowniki).
(Korzystam z innego komputera, więc nie mogę polegać na historii przeglądarki, aby cofnąć swoje kroki, ale pewnego dnia, odpowiadając na to pytanie SU , skończyłem na tym SO pytaniu, które spowodowało, że trafiłem do Google PROCESSOR_ARCHITEW6432, które doprowadziły do tego SO pytania i ten post na blogu Microsoft ).
Gdzieś po drodze przeczytałem post StackOverflow o tym, jak zmienna środowiskowa
%processor_architecutre%daje różne wyniki w zależności od tego, z którego miejsca uruchomiono wiersz polecenia (postaram się znaleźć dokładny cytat).Odpowiedź okazała się należna, niezależnie od tego, czy uruchomiono 32-bitową czy 64-bitową wersję wiersza polecenia (tj. Z
System32\lubSysWoW64\). Innymi słowy, chociaż lokalizacja wydaje się wpływać na zachowanie programu, dzieje się tak tylko dlatego, że istnieją różne wersje programu, a nie dlatego, że Windows traktuje folder w specjalny sposób.Ma to sens, ponieważ zawartość pliku wykonywalnego decyduje o tym, czy jest to wersja 32-bitowa, czy 64-bitowa, więc możesz umieścić zarówno 32-bitową, jak i 64-bitową kopię tego samego programu (np.
foobar32.exeIfoobar64.exe) w tym samym folderze i kiedy wykonaj je, zostaną poprawnie załadowane (wersja 64-bitowa zostanie uruchomiona natywnie, a wersja 32-bitowa będzie uruchomiona w warstwie emulacji WoW64).FreePascal umożliwia zainstalowanie zarówno wersje DOS i Windows i idą w tym samym folderze:
%programfiles%\FreePascal. Zarządza różnych architektur utrzymując pliki wykonywalne (.exe,.sys,.dll,.ovr, itd.) W oddzielnych folderach i udostępnianie plików zasobów jak zdjęcia, pliki źródłowego, itd), nie ma powodów technicznych, że to nie może być również wykonane dla 32- i 64-bitowe wersje programu. Jak powiedział David, programiście jest po prostu łatwiej, jeśli są trzymane osobno (tj. Używając zmiennych, aby wyglądać, jakby był tylko jeden zestaw plików itp.)źródło
Innym powodem jest to, że większość programów używała zmiennych środowiskowych, takich jak% PROGRAMFILES%, aby wskazać, gdzie zainstalowano ich program. W przypadku programów 64-bitowych jest to normalne miejsce. W przypadku programów 32-bitowych przekieruje to do nowego
Program Files (x86)folderu.Chociaż, przynajmniej z nowymi rzeczami .Net w Visual Studio, mają teraz zmienną App.Local, która eliminuje całą potrzebę tego.
źródło
%programfiles%,%programfiles(x86)%czy%programw6432%coś zmienić? Wszelkie współużytkowane biblioteki DLL przechodzą do pojedynczego katalogu WinSxS, a wszelkie niepodzielone biblioteki DLL znajdują się w pliku wykonywalnym. Ma to znaczenie tylko wtedy, gdy z jakiegoś powodu masz zarówno 32-bitową, jak i 64-bitową wersję tego samego programu, a nawet wtedy zachowałbyś 32-bitowe biblioteki DLL z 32-bitowym plikiem wykonywalnym i 64-bitową bibliotekę DLL z 64-bitowy plik wykonywalny. Możesz to zrobić tak:%programfiles%\CoolApp\bin\32i% programfiles% \ CoolApp \ bin \ 64`, dlaczego oddzielne foldery najwyższego poziomu?Źródło
„co poszło nie tak, gdybym w jakiś sposób uniknął mechanizmu przekierowania i zmusiłbym wszystko do zainstalowania się w prawdziwym C: \ Program Files \?”
Nic. Dwa katalogi programów służą wyłącznie do organizacji lub dla zachowania odrębności programów, które mają dwie wersje, w wersji 32-bitowej i 64-bitowej, takich jak Internet Explorer. Ale możesz zainstalować 32-bitowy program w „Program Files” i 64-bitowy program w „Program Files x86” i nic się nie stanie, program będzie działał tak samo.
Wiki mówi:
źródło
Powodem jest ułatwienie programistom uaktualnienia programu do wersji 64-bitowej. Nie muszą pisać żadnego niestandardowego kodu, aby sprawdzić program w jednym katalogu podczas kompilacji w trybie 32-bitowym oraz w innym katalogu podczas kompilacji w trybie 64-bitowym; po prostu sprawdzają
C:\Program Files, a gdy działa w trybie 32-bitowym, automatycznie zmienia sięC:\Program Files (x86)na 64-bitowy system Windows. Podobnie wpisy rejestru są izolowane między programami 32-bitowymi i 64-bitowymi.Zapobiega to nieświadomym programistom, którzy po prostu zmieniają tryb kompilacji na 64-bitowy, nie zastanawiając się nad tym, oraz zapobiega ogromnej ilości pracy dla programistów, którzy chcą, aby użytkownicy mogli instalować zarówno 32-, jak i 64-bitowe wersje swoich oprogramowanie jednocześnie.
Ale dlaczego jakikolwiek program chciałby zezwolić na instalację obu wersji jednocześnie? Jeden przykład: Photoshop i IE mają rozszerzenia, które są natywne .dll. Nie można mieszać kodu 32- i 64-bitowego w tym samym procesie, więc dodatek do wersji 32-bitowej nie może być używany z wersją 64-bitową i odwrotnie. W związku z tym Photoshop / IE musi zezwalać na instalację obu wersji, w przeciwnym razie istnieje ryzyko złamania ogromnej bazy istniejących dodatków.
źródło
Programy działające na „Program Files (x86)” korzystają z podsystemu WOW64 (Windows 32-bit na Windows 64-bit to zestaw sterowników i interfejsów API przeznaczonych do uruchamiania aplikacji x32 w systemie architektury x64):
System 64-bitowy musi „emulować” aplikacje 32-bitowe, dlatego system Windows musi „segregować” dwa foldery Program Files.
źródło
Interesujące jest to, że odpowiedzi tutaj i w Internecie są dość różne. Znalezienie dokładnej odpowiedzi na to ważne pytanie było wyzwaniem. Wydaje się, że w Internecie jest sporo fałszywych informacji, co prowadzi do zamieszania.
Przeprowadziłem znaczną liczbę badań i wyciągnąłem następujący wniosek, który moim zdaniem jest dokładny:
Dzieje się to automatycznie i jest niezależne od miejsca przechowywania aplikacji. Posiadanie osobnych folderów 32-bitowych i 64-bitowych nie ma szybkości, niezawodności ani innych korzyści funkcjonalnych.
Jedynym powodem domyślnego podziału na dwa foldery („Pliki programów” i „Pliki programów (x86)”) jest to, że jeśli masz dwie wersje tego samego programu (wersja 32-bitowa i 64-bitowa), zapewnia on prosty sposób na oddzielenie nakładających się plików. Nawet w tym przypadku, o ile wszystkie nazwy plików są unikalne, mogą faktycznie istnieć w tym samym folderze bez żadnych konsekwencji.
Powyższy wniosek zawiera zastrzeżenie, które dotyczy źle zakodowanych aplikacji. Jeśli aplikacja ma zapisane na stałe ścieżki, użyje tylko tej ścieżki. Z reguły ścieżki nie powinny być nigdy zakodowane na stałe w aplikacji, ale czasami programista popełni ten błąd. W takim przypadku program użyje zakodowanej ścieżki; katalog, w którym aplikacja jest zainstalowana, nie wpłynie na to, gdzie faktycznie szuka plików.
źródło
Konieczność oddzielenia folderów pozwala zachować natywne 64-bitowe aplikacje i te, które wymagają WoW64 oddzielnie.
Może to być przydatne - jak już wskazano @OliverSalzburg - jeśli chcesz zainstalować zarówno 64-bitową, jak i 32-bitową przeglądarkę internetową (na przykład), ponieważ niektóre wtyczki i dodatki mogą być dostępne tylko dla jednego z dwójka.
Konieczność oddzielenia folderów powoduje, że separacja ta odbywa się automatycznie , z wykorzystaniem technik takich jak przekierowanie rejestru .
Załóżmy, że instalator próbuje ustalić folder plików programu, odczytując rejestr przy użyciu np . RegQueryValueEx .
W każdym razie próbuje odczytać klucz rejestru
co zwykle wskazuje na
C:\Program Files.Jeśli jednak instalator jest aplikacją 32-bitową, przekierowanie rejestru spowoduje klucz regitry
zamiast tego należy czytać, co zwykle wskazuje
C:\Program Files (x86).Dlaczego te konkretne nazwy folderów zostały użyte, mogą odpowiedzieć tylko osoby, które dokonały tego wyboru. Zawsze możesz zmienić domyślne nazwy folderów, jeśli chcesz.
Wątpię. Większość instalatorów pozwala wybrać niestandardowy folder instalacyjny, więc tak naprawdę nie ma znaczenia, gdzie program zostanie zainstalowany.
źródło
Nie mogę uwierzyć w zamieszanie tutaj ... po pierwsze jestem programistą w pełnym wymiarze godzin.
MS zrobiło to, aby rozwiązać przypadek, w którym biblioteka DLL jest używana zarówno przez starsze aplikacje 32-bitowe, jak i nowsze aplikacje 64-bitowe. Nie można zmienić starszej metody (System32, Pliki programów itp.), Ponieważ spowodowałoby to uszkodzenie starszych programów, których nie można ponownie skompilować.
MS utworzyło folder do przechowywania 64-bitowych programów, zestawów i bibliotek, aby nowe programy mogły łączyć się z odpowiednimi bibliotekami, a starsze programy działałyby normalnie.
W obecnej formie biblioteki DLL .Net mogą współistnieć z innymi wersjami na tym samym komputerze. Na przykład możesz mieć Library.1.0.1, Library.1.0.2, Library 1.1.0 itp. A to tylko dla określonego rozmiaru bitu (32 lub 64). Jeśli nie są używane osobne foldery, każdy zestaw musi mieć wersję 32- i 64-bitową. Spowodowałoby to poważne zaśmiecenie katalogu, który zawiera już wiele wersji tego samego zestawu.
To wszystko rzeczy programistów. Jako użytkownik muszę sobie z tym poradzić tylko wtedy, gdy pracuję z 32-bitowym programem na Windows 7 64. I wolę mieć możliwość uruchamiania wersji 32-bitowej i tej samej aplikacji również w wersji 64-bitowej. Kiedy pracuję nad aplikacją 32-bitową, którą muszę skompilować w wersji 64-bitowej, wszystko, co robię, to poinstruowanie kompilatora, aby to zrobił. Nazwy dll i wszystko inne pozostaje takie samo.
Przyczyną tego nie było w Windows 95/98, ponieważ systemy te symulowały 32-bitowe środowisko uruchomieniowe; to nie był prawdziwy 32-bitowy system operacyjny. Udawało 32-bitowe wykonanie z czymś o nazwie „thunking”.
Oto dobra definicja: http://searchwinit.techtarget.com/definition/thunk
źródło
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 \ bla`` lub\blah\32; w obu przypadkach są one rozdzielone. Jeśli już, to obecny sposób oddziela komponenty aplikacji (a także niepotrzebnie kopiuje je, ponieważ niewiele aplikacji używaCommonFileszasobów itp. Poza tym sprawiasz, że brzmi to tak, jakby aplikacje wyrzucały swoje biblioteki DLL we wspólnym segmencie. Łatwo jest zachować 32-bitowe biblioteki DLL z 32-bitowymiTo wcale nie jest konieczne. Na przykład na działającym komputerze instaluję każdą aplikację w folderze
C:\MyPrograms\, aby oddzielić ją od aplikacji zainstalowanych przez nasz dział IT.Oczywiście nie pozwala mi to zainstalować obu wersji (32- i 64-bitowej) jednej aplikacji, ale w moim przypadku nie stanowi to problemu.
Za każdym razem, gdy uruchamiasz program, zawsze najpierw
C:\Windows\System32\ntdll.dlluruchamiana jest biblioteka DLL . Ta biblioteka DLL określa, czy Twój program jest aplikacją 32- czy 64-bitową. W zależności od tego następuje przekierowanie naWoW64które jest już wspomniane w kilku odpowiedziach.źródło