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

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?

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.

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!)

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:

• Readresator systemu plików MSDN

• Wyjaśnienie SysWow64

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

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.

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.