Dlaczego 64-bitowe biblioteki DLL przechodzą do System32 i 32-bitowe biblioteki DLL do SysWoW64 w 64-bitowym systemie Windows?

227

Chciałbym wiedzieć, kiedy musimy umieścić plik

C: \ Windows \ System32 lub C: \ Windows \ SysWOW64, w 64-bitowym systemie Windows.

Miałem dwie biblioteki DLL, jedną dla wersji 32-bitowej, drugą dla wersji 64-bitowej.

Logicznie pomyślałem, że umieściłem 32-bitową bibliotekę DLL pod C: \ Windows \ System32, a 64-bitową bibliotekę DLL pod C: \ Windows \ SysWOW64.

Ku mojemu zaskoczeniu jest na odwrót ! Wersja 32- bitowa przechodzi do C: \ Windows \ SysWOW 64 , a 64- bitowa biblioteka DLL przechodzi do C: \ Windows \ System 32 .

Bardzo mylące rzeczy. Jaki jest tego powód?

Ganesh Astroved
źródło
2
Ponadto: Windows szuka w bieżącym katalogu roboczym, a także w ścieżce systemowej. Nie ma sposobu, aby określić inaczej. Och, czekaj, jest. Możesz osadzić ścieżkę wyszukiwania w swojej bibliotece DLL. Jest to pole o długości 8 bajtów. Tak. 8 znaków.
Jeroen Baert
Nie wydaje się to być prawdą w systemie Windows 7. Uruchamianie pliku w bibliotece DLL w pliku system32 C: \ Windows \ system32 \ user32.dll C: \ Windows \ system32 \ user32.dll; Plik wykonywalny PE32 dla MS Windows (DLL) (GUI) Intel 80386 32-bitowy Ale dla 64-bitowej biblioteki DLL drukuje plik wykonywalny PE32 + dla MS Windows (DLL) (konsola) Zespół Mono / .Net Uwaga: ta biblioteka DLL nie jest .Net montaż. Jest to natywna biblioteka DLL.
user877329,
11
Wywiad z byłym Microsoftiem . (Aby uzyskać poważne wyjaśnienie, jak to się stało, zobacz tę odpowiedź ).
Tgr.
superuser.com/a/157301/241386 „Przyczyny kompatybilności wstecznej. Wiele aplikacji zakłada rzeczy, których nie powinny zakładać, i ścieżki kodu”
phuclv

Odpowiedzi:

225

Wydaje mi się, że zamierzano zmienić nazwę System32, ale tak wiele aplikacji jest na stałe zakodowanych dla tej ścieżki, że jej usunięcie nie było możliwe.

SysWoW64 nie był przeznaczony do bibliotek DLL systemów 64-bitowych, w rzeczywistości przypomina coś „Windows na Windows64”, co oznacza bity potrzebne do uruchamiania aplikacji 32-bitowych w 64-bitowych oknach.

W tym artykule wyjaśniono nieco:

„Windows x64 ma katalog System32, który zawiera 64-bitowe biblioteki DLL (sic!). W ten sposób natywne procesy z bitową liczbą 64 znajdują„ swoje ”biblioteki DLL tam, gdzie ich oczekują: w folderze System32. Drugi katalog, SysWOW64, zawiera 32 -bitowe biblioteki DLL. Program przekierowujący system plików potrafi ukryć prawdziwy katalog System32 dla procesów 32-bitowych i wyświetlić SysWOW64 pod nazwą System32. ”

Edycja: Jeśli mówisz o instalatorze, naprawdę nie powinieneś na stałe wpisywać ścieżki do folderu systemowego. Zamiast tego pozwól, aby system Windows zajął się tym za Ciebie, w zależności od tego, czy instalator działa na warstwie emulacji.

Rytmis
źródło
27
Ugh, dzisiaj wpadłem na tę dziwność. Co za wprowadzająca w błąd rzecz, którą zrobili.
Andy White
16
Wpadłem na to również dzisiaj ... tak mylące - Glut 32-bit dll przechodzi do / SysWOW64, Glut 64-bit dll przechodzi do / System32. Ktoś powinien to zapisać. W Internecie.
Jeroen Baert
8
Dobrą wiadomością jest to, że jako przykład genialnego inżyniera Microsoftu jest to w dużej mierze samo-dokumentowanie.
Spike0xff 21.12.12
8
Nie rozumiem tylko, że jeśli system plików może stwierdzić, że jest to aplikacja 32-bitowa i przekierować ją do SysWOW64folderu, dlaczego nie mogliby zamiast tego wykryć aplikacji 64-bitowej i przekierować do System64?!
Cole Johnson
6
System32 to 32-bitowa wersja systemowych bibliotek DLL systemu Windows. System to wersja 16-bitowa. Ta sama firma, która dostarczyła nam system Windows 8, dostarczyła nam SysWow64 dla 32-bitowych bibliotek DLL i System32 dla 64-bitowych bibliotek DLL podczas pracy w 64-bitowym systemie operacyjnym. W systemach 64-bitowych folder System jest nadal starą 16-bitową śmiecią, tylko System32 nie jest 32-bitowy, jak sugerowano, a 32-bitowy plik znajduje się w katalogu System z nazwą 64. Nie widzę, jak to pomaga komukolwiek. komplikuje to i wszystko psuje. Wszystko po to, by uchronić ludzi przed dostosowaniem na stałe „System32” do „System64” podczas konwersji na 64-bit. Idiocy
Armand
26

Powinienem dodać: W każdym razie nie powinieneś umieszczać swojej biblioteki DLL w \ system32 \! Zmodyfikuj kod, zmodyfikuj instalator ... znajdź dom dla swoich bitów, który NIE jest nigdzie pod c: \ windows \

Na przykład instalator umieszcza pliki DLL w:

\program files\<your app dir>\

or

\program files\common files\<your app name>\

( Uwaga : Sposób, w jaki to robisz, to użycie środowiska var:% ProgramFiles% lub% ProgramFiles (x86)% w celu znalezienia plików programu .... nie zakładasz, że to c: \ program files \ .. ..)

a następnie ustawia znacznik rejestru:

HKLM\software\<your app name>
-- dllLocation

Kod korzystający z bibliotek DLL odczytuje rejestr, a następnie dynamicznie łączy się z bibliotekami DLL w tej lokalizacji.

Powyżej jest mądry sposób.

Nigdy nie instalujesz swoich bibliotek DLL ani bibliotek DLL stron trzecich w \ system32 \ lub \ syswow64. Jeśli musisz się ładować statycznie, umieścisz swoje biblioteki DLL w swoim katalogu exe (tam, gdzie je znajdziesz). Jeśli nie możesz przewidzieć exe dir (np. Jakiś inny exe wywoła twój dll), być może będziesz musiał umieścić swój dll na ścieżce wyszukiwania (unikaj tego, jeśli to w ogóle możliwe!)

System32 i syswow64 są dla plików dostarczonych z systemem Windows ... nie dla innych plików . Jedyny powód, dla którego ludzie wpadli w zły nawyk umieszczania rzeczy, ponieważ zawsze znajduje się na ścieżce wyszukiwania, a wiele aplikacji / modułów używa statycznego łączenia. (Jeśli więc naprawdę do tego dojdziecie, prawdziwym grzechem jest łączenie statyczne - jest to grzech w natywnym kodzie i kodzie zarządzanym - zawsze zawsze łączy się dynamicznie!)

Jonesome przywraca Monikę
źródło
9
+1 ... ale dodam, że powinieneś używać zmiennych takich jak% PROGRAMFILES% not \ Program Files \
Rod MacPherson
W czasach XP była to powszechna (i sugerowana) praktyka dla programistów, aby używać rejestru do takich rzeczy. W przypadku systemu Windows 7 nie jest to już prawdą! Ze względu na UAC, sesje wielu użytkowników itp. Z rejestru w systemie Windows 7 należy korzystać oszczędnie i według uznania deweloperów.
ryyker
@RodMacPherson Moja odpowiedź została ulepszona, aby uwzględnić Twoją sugestię. Masz rację!
Jonesome przywraca Monikę
Po namyśle myślę, że to lepiej odpowiada na pytanie - „Kiedy musimy umieścić plik pod% SYSTEMROOT%”. Nigdy. Ta odpowiedź nie zaspokaja ciekawości na temat folderu syswow64, ale jest to ta, którą programiści naprawdę muszą przeczytać.
Thomas
7

Natknąłem się na ten sam problem i badałem go przez kilka minut.

Nauczono mnie obsługiwać Windows 3.1 i DOS, pamiętasz te czasy? Krótko po tym, jak przez jakiś czas ściśle współpracowałem z komputerami Macintosh, zacząłem kołysać się z powrotem do systemu Windows po zakupie maszyny x64-bit.

Są rzeczywiste powody tych zmian (niektórzy powiedzieliby, że mają znaczenie historyczne), które są niezbędne dla programistów do kontynuowania pracy.

Większość zmian wspomniano powyżej:

  • Program Files vs Program Files (x86)

    Na początku zapisywano pliki 16 / 86bit, procesory Intel „86”.

  • System32naprawdę oznacza System64(w 64-bitowym systemie Windows)

    Gdy programiści po raz pierwszy rozpoczęli pracę z Windows7, pojawiło się kilka problemów ze zgodnością, w których przechowywane były inne aplikacje.

  • SysWOW64 naprawdę znaczy SysWOW32

    Zasadniczo w prostym języku angielskim oznacza „Windows w systemie Windows na komputerze 64-bitowym” . Każdy folder wskazuje, gdzie znajdują się biblioteki DLL dla aplikacji, z których chcą korzystać.

Oto dwa linki ze wszystkimi potrzebnymi podstawowymi informacjami:

Mam nadzieję, że to wszystko wyjaśni!

Chrupiący
źródło
4
Jeśli chcesz być traktowany poważnie, prawdopodobnie powinieneś stonować slang i poprawić gramatykę. Możesz także bardziej ustrukturyzować swoją odpowiedź, użyj akapitów.
Klas Mellbourn
2
@Crispy wyczyściło odpowiedź. W przyszłości powinieneś zastanowić się, co sugeruje Klas i sformatować swoją odpowiedź, aby zwiększyć szanse na pozytywne głosy. :)
RekindledPhoenix
OP musi zostać całkowicie przepisany, a nawet usunięty. Jest to mylące i niezbyt przydatne.
Jonesome przywraca Monikę
5
SysWOW64 tak naprawdę oznacza: [Sys] tem [W] indukuje 32-bitowe [o] n [W] indukuje [64] -bitowe, więc skrócona forma SysWoW64 (co naprawdę nie ma sensu, a Microsoft po prostu zostawił System32 dla rzeczy 32-bitowych i utworzył System64, naprawdę nie byłoby problemów ze zgodnością. Microsoft robi w piaskownicy WoW tworzenie przekierowania w pamięci z 32-bitowego dostępu do System32 jako żądanie do SysWoW64 ... jak to nie jest bardziej skomplikowane niż tylko ujawnienie system plików w stanie surowym bez konieczności magicznego mapowania go dla różnych platform? Jak zauważono w poprzednim komentarzu - Idiocy.
Armand
1
odpowiedź przyniesie więcej nieporozumień niż jasność pytania, komentarz Armands jest dobrym wyjaśnieniem.
nahab
5

System32 to miejsce, w którym Windows historycznie umieścił wszystkie 32-bitowe biblioteki DLL, a system był dla 16-bitowych bibliotek DLL. Kiedy Microsoft utworzył 64-bitowy system operacyjny, wszyscy, których znam, oczekiwali, że pliki będą znajdować się pod System64, ale Microsoft zdecydował, że bardziej sensowne jest umieszczenie plików 64-bitowych pod System32. Jedyne rozumowanie, jakie udało mi się znaleźć, to to, że chcieli, aby wszystko, co było 32-bitowe, działało w 64-bitowym systemie Windows bez konieczności zmiany czegokolwiek w programach - po prostu ponownie skompiluj i gotowe. Rozwiązaniem tego problemu, aby 32-bitowe aplikacje mogły nadal działać, było utworzenie 32-bitowego podsystemu Windows o nazwie Windows32 na Windows64. Jako taki utworzono akronim SysWOW64 dla katalogu System 32-bitowego podsystemu. Sys to skrót od System, a WOW64 to skrót od Windows32OnWindows64.
Ponieważ system Windows 16 jest już oddzielony od systemu Windows 32, nie było potrzeby równoważenia systemu Windows 16 w systemie Windows 64. W ramach 32-bitowego podsystemu, gdy program korzysta z plików z katalogu system32, faktycznie pobiera pliki z katalogu SysWOW64. Ale proces jest wadliwy.

To okropny projekt. Z mojego doświadczenia wynika, że ​​musiałem wprowadzić znacznie więcej zmian w pisaniu aplikacji 64-bitowych, że zwykła zmiana katalogu System32 do odczytu System64 byłaby bardzo niewielką zmianą, i którą powinny obsługiwać dyrektywy przedkompilatorowe.

Armand
źródło
2

Inni ludzie już wykonali dobrą robotę, wyjaśniając zagadkę z zagadkami ... i myślę, że Chris Hoffman wykonał jeszcze lepszą robotę tutaj: https://www.howtogeek.com/326509/whats-the-difference-between-the- system32-and-syswow64-foldery-in-windows /

Moje dwie myśli:

  1. Wszyscy popełniamy w życiu głupie krótkowzroczne błędy. Kiedy Microsoft nazwał swój (wówczas) katalog Win32 DLL „System32”, miało to wtedy sens ... po prostu nie wzięli pod uwagę, co by się stało, gdyby / kiedy wersja 64-bitowa (lub 128-bitowa) ich systemu operacyjnego opracowano później - i spowodowałoby to ogromny problem z kompatybilnością wsteczną, taki nazwa katalogu. Z perspektywy czasu zawsze jest 20-20, więc nie mogę ich winić (za dużo) za taki błąd. ... JEDNAK ... Kiedy Microsoft opracował później swój 64-bitowy system operacyjny, nawet z perspektywy czasu, dlaczego, och, dlaczego mieliby nie tylko ten sam krótkowzroczny błąd PONOWNIE, ale pogorszyliby go, CELOWO dając to takie mylące imię?!? Niech się wstydzą!!! Dlaczego nie NAJMNIEJ nazwać katalog „SysWin32OnWin64”, aby uniknąć nieporozumień ?! ? A co się stanie, gdy w końcu wyprodukują 128-bitowy system operacyjny ... to gdzie zamierzają umieścić swoje 32-bitowe, 64-bitowe i 128-bitowe biblioteki DLL?!?

  2. Cała ta logika wciąż wydaje mi się całkowicie błędna. W 32-bitowych wersjach systemu Windows System32 zawiera 32-bitowe biblioteki DLL; w 64-bitowych wersjach systemu Windows System32 zawiera 64-bitowe biblioteki DLL ... aby programiści nie musieli wprowadzać zmian w kodzie, prawda? Problem z tą logiką polega na tym, że programiści albo tworzą teraz 64-bitowe aplikacje wymagające 64-bitowych bibliotek DLL, albo tworzą 32-bitowe aplikacje wymagające 32-bitowych bibliotek DLL ... tak czy inaczej, czy nadal nie są zepsute? Mam na myśli, że jeśli nadal tworzą 32-bitową aplikację, aby działała na 64-bitowym systemie Windows, będą musieli dokonać zmiany kodu, aby znaleźć / odwołać się do tej samej 32-bitowej biblioteki DLL używany wcześniej (obecnie znajduje się w SysWOW64). Lub, jeśli pracują nad aplikacją 64-bitową, i tak będą musieli ponownie napisać starą aplikację dla nowego systemu operacyjnego ... więc i tak konieczna będzie ponowna kompilacja / przebudowa !!

Microsoft tylko czasami mnie boli.

Rich Bayless
źródło