Чому 64-бітні DLL переходять на System32, а 32-бітні DLL - на SysWoW64 на 64-розрядної Windows?

Я хотів би знати, коли нам потрібно розмістити файл під

C: \ Windows \ System32 або C: \ Windows \ SysWOW64, у 64-бітній системі Windows.

У мене було два DLL-файли, один для 32-розрядних, один для 64-розрядних.

За логікою, я думав, що розміщу 32-бітну DLL під C: \ Windows \ System32, а 64-розрядна DLL - під C: \ Windows \ SysWOW64.

На мій подив, це навпаки ! 32 -бітовий один переходить в C: \ Windows \ SysWOW 64 , і 64 - бітний DLL входить в C: \ Windows \ System 32 .

Дуже заплутані речі. У чому причина цього?

Я вважаю, що наміром було перейменувати System32, але стільки програм жорстко закодовані для цього шляху, що видалити його було неможливо.

SysWoW64 не призначений для 64-бітних систем, це насправді щось на кшталт "Windows для Windows64", тобто біти, необхідні для запуску 32-бітних додатків на 64-бітових Windows.

Ця стаття трохи пояснює:

"У Windows x64 є каталог System32, який містить 64-бітні DLL-файли (sic!). Таким чином, власні процеси з розрядністю 64 знаходять" свої "DLL-файли там, де вони їх очікують: у папці System32. Другий каталог, SysWOW64, містить 32 -бітові DLL-файли. Редіректор файлової системи виконує магію приховування реального каталогу System32 для 32-бітних процесів та показу SysWOW64 під іменем System32. "

Редагувати: Якщо ви говорите про інсталятор, вам дійсно не слід жорстко кодувати шлях до системної папки. Натомість, дозвольте Windows подбати про це за вами на основі того, чи працює ваш інсталятор на емуляційному шарі.

Варто додати: у жодному разі не слід вводити ваші DLL в \ system32 \! Змініть свій код, модифікуйте інсталятор ... знайдіть будинок для своїх бітів, який НІСЕ під c: \ windows \

Наприклад, ваш інсталятор розміщує ваші клітини в:

\program files\<your app dir>\

or

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

( Примітка : спосіб, який ви насправді це робите, - це використовувати середовище var:% ProgramFiles% або% ProgramFiles (x86)%, щоб знайти, де файли програм .... ви не вважаєте, що це c: \ програмні файли \ .. ..)

а потім встановлює тег реєстру:

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

Код, який використовує ваші dlls, зчитує реєстр, а потім динамічно посилається на dlls у цьому місці.

Сказане вище - розумний шлях.

Ви ніколи не встановлюєте своїх dll або сторонніх dll в \ system32 \ або \ syswow64. Якщо вам доведеться статично завантажуватись, ви поміщаєте ваші коси в свій exe dir (там вони будуть знайдені). Якщо ви не можете передбачити exe dir (наприклад, якийсь інший exe зателефонує на ваш dll), можливо, вам доведеться поставити dll dir в шлях пошуку (уникайте цього, якщо це можливо!)

system32 і syswow64 призначені для файлів, що надаються Windows ... не для інших . Єдина причина, чому люди потрапили в шкідливу звичку розміщувати туди речі, це тому, що вона завжди перебуває на шляху пошуку, і багато додатків / модулів використовують статичні зв'язки. (Отже, якщо ви дійсно переходите до цього, справжній гріх - це статичне посилання - це гріх у рідному коді та керованому коді - завжди завжди завжди динамічно посилається!)

Побіг у тому ж питанні і дослідив це протягом декількох хвилин.

Мене вчили користуватися Windows 3.1 та DOS, пам'ятаєте ті дні? Незабаром я деякий час строго працював з комп’ютерами Macintosh, а потім почав перекидатися на Windows після придбання x64-бітної машини.

За цими змінами (дехто вважає історичне значення) є фактичні причини, необхідні програмістам для продовження своєї роботи.

Більшість змін згадуються вище:

• Program Files проти Program Files (x86)

  На початку 16/86-бітні файли були записані на «86» процесорах Intel.

• System32дійсно означає System64(у 64-розрядної Windows)

  Коли розробники вперше почали працювати з Windows7, виникло кілька проблем сумісності, де зберігаються інші програми.

• SysWOW64 дійсно означає SysWOW32

  По суті, простою англійською мовою це означає "Windows у Windows в межах 64-бітної машини" . Кожна папка вказує, де розташовані DLL-програми для програм, які вони хочуть використовувати.

Ось два посилання з усіма необхідними відомостями:

• Перенаправлення файлової системи MSDN

• Пояснив SysWow64

Сподіваюсь, це все прояснить!

System32 - це місце, де Windows історично розміщувала всі 32-бітні DLL, а System - для 16-бітових DLL-файлів. Коли Microsoft створила 64-бітну ОС, всі, кого я знаю, очікували, що файли будуть розміщені під System64, але Microsoft вирішила, що має більше сенсу розміщувати 64-бітні файли під System32. Єдине міркування, яке мені вдалося знайти, - це те, що вони хотіли, щоб все, що було 32-бітним, працювало в 64-бітній Windows без необхідності змінити що-небудь в програмах - просто перекомпілювати, і це зроблено. Те, як вони вирішили це, щоб 32-бітні програми все ще могли працювати, було створити 32-бітну підсистему Windows під назвою Windows32 У Windows64. Таким чином, абревіатура SysWOW64 була створена для системного каталогу 32-бітної підсистеми. Sys короткий для System, а WOW64 - для Windows32OnWindows64.
Оскільки Windows 16 вже відокремлений від Windows 32, не було потреби в еквівалентності Windows 16 для Windows 64. У 32-бітовій підсистемі, коли програма переходить на використання файлів із каталогу system32, вони фактично отримують файли з каталогу SysWOW64. Але процес є недоліком.

Це жахливий дизайн. На моєму досвіді мені довелося зробити набагато більше змін для написання 64-бітових додатків, що просто змінити каталог System32 на читання System64 було б дуже незначною зміною, і одна, з якою призначені директиви попереднього компілятора.

Інші люди вже зробили хорошу роботу, пояснивши цю головоломку ... і, я думаю, Кріс Гофман зробив ще кращу роботу тут: https://www.howtogeek.com/326509/whats-the-difference-bet between-the- system32-and-syswow64-folders-in-windows /

Мої дві думки:

1. Всі ми робимо дурні короткозорі помилки в житті. Коли Microsoft назвала свій (на той час) каталог Win32 DLL "System32", це мало сенс у той час ... вони просто не враховували, що буде, якщо / коли 64-бітна (або 128-бітна) версія їх ОС отримали розвиток пізніше - і масове питання зворотної сумісності викликало б таке ім'я каталогу. Заднім числом завжди 20-20, тому я не можу насправді звинуватити їх (занадто багато) у такій помилці. ... ЯКЩО ... Коли Microsoft пізніше розробила їх 64-бітну операційну систему, навіть з користю заднього огляду, чому б о чому вони зробили б не тільки таку ж недалекоглядну помилку ПРОСТО, але зробили її ще гірше, МОЖЛИВО надаючи це така оманлива назва?!? Сором їм !!! Чому б ЛИШЕ насправді не назвати каталог "SysWin32OnWin64", щоб уникнути плутанини ?! ? А що відбувається, коли вони зрештою виробляють 128-бітну ОС ... куди вони збираються розміщувати свої 32-бітні, 64-бітні та 128-бітні DLL-файли?!?

2. Вся ця логіка все ще здається мені повністю хибною. У 32-бітних версіях Windows System32 містить 32-бітні DLL; У 64-розрядної версії Windows System32 містить 64-бітні DLL ... так що розробникам не доведеться вносити зміни коду, правда? Проблема з цією логікою полягає в тому, що ці розробники зараз роблять 64-розрядні програми, які потребують 64-бітних DLL, або вони роблять 32-розрядні програми, що потребують 32-бітних DLL-файлів ... в будь-якому випадку, чи все ще вони не вкручені? Я маю на увазі, якщо вони все ще роблять 32-розрядний додаток, щоб він тепер працював на 64-розрядної Windows, їм тепер потрібно буде змінити код, щоб знайти / посилатися на ту саму 32-бітну DLL-програму. використовувався раніше (зараз знаходиться в SysWOW64). Або, якщо вони працюють над 64-розрядним додатком, їм все одно доведеться перезаписати свій старий додаток для нової ОС ... так що перекомпіляція / відновлення буде потрібна все одно !!

Microsoft мене просто болить іноді.