Разница в реестре 64 битной версии Windows
64-битное программное обеспечение с трудом удается совместить с 32-битным; это вызывает необходимость существования двух реестров, чтобы эти биты находились подальше друг от друга. Поскольку иметь два независимых реестра непрактично, разделяются лишь некоторые разделы и ветви.
Сопоставления типов файлов, например, общие для обоих слоев поэтому вы можете один раз связать .txt-документы с любимым текстовым редактором, и эти связи будут работать и в 32-битной, и в 64-битной версиях Windows.
Но в то же время 64-битная программа не может обратиться к 32-битной DLL. Часть реестра, управляющая DLL и другими компонентами, будет для каждого слоя Windows отдельной. Таким образом, например, 64-битные версии Проводника и Internet Explorer недоступны для 32-битных DLL, и наоборот.
Как правило, такой раздвоенный дизайн не требует от вас дополнительных усилий. Каждое из 32-битных приложений видит только те разделы реестра, которые оно должно видеть, а все 64-битные приложения видят только 64-битный реестр.
Как восстановить ️ реестр операционной системы Windows☑️
Дополнительные усилия понадобятся только в тех случаях, когда двойственность реестра становится помехой для ежедневного неавторизованного доступа или вас начинают раздражать надоедливые предупреждения.
Редактор реестра включает специальную ветвь Wow6432Node, позволяющую получить доступ к 32-битным записям из того же окна, что и к 64-битным. В Windows 7 по умолчанию существует три таких «узла»:
- HKEY_CLASSES_R0OTWow6432Node
- HKEY_CURRENT_USERSoftwareWow6432Node
- HKEY_L0CAL_MACHINES0FTWAREWow6432Node
Рекомендуем для просмотра:
- Запрет изменений в разделе реестра — 26/11/2012 09:10
- Экспорт и импорт файлов реестра — 26/11/2012 09:02
- Поиск в реестре — 26/11/2012 07:07
Источник: cmd4win.ru
Вы используете «Wow6432Node» в своем коде? Немедленно прекратите!
Я уже упоминал несколько раз, что 64-х разрядные версии Windows используют два раздельных представления реестра – одно для 32-х разрядных приложений, а другое для 64-х разрядных. Как-то, я даже писал о том, как это делается. Ключевых моментов там всего ничего:
- Разделён не весь реестр, а лишь некоторые из ключей;
- Физически 32-х разрядные ключи помещаются в ветки с именем «Wow6432Node»;
- Приложения могут выбирать представление реестра с которым они хотят работать с помощью флагов KEY_WOW64_32KEY и KEY_WOW64_64KEY (см. Accessing an Alternate Registry View).
Проблема, однако, заключается в том, что многие приложения имею тенденцию явно использовать «Wow6432Node», чтобы получить доступ к 32-х битным ключам реестра. Похоже, что всё происходит по такому сценарию:
- Разработчики пробуют перевести приложение на 64-х битную платформу и натыкаются на проблему с реестром;
- В процессе решения они узнают о разделении реестра и о том, что 32-х разрядные ключи расположены под «Wow6432Node»;
- На коленке разрабатывается заплатка, которая, да, просто добавляет в путь «Wow6432Node», если программа выполняется под Wow64;
- Ура! Всё работает, проблема решена, программисты идут пить пиво…
Что не тут так? «Wow6432Node» не документирована, как способ доступа к 32-х битному представлению реестра. Если поискать «Wow6432Node» на msdn.microoft.com, то в результате будет найдено довольно много статей упоминающих «Wow6432Node», однако все они либо описывают особенности организации реестра на 64-х разрядных версиях системы, либо описывают временные решения для проблем, возникающих с 32-х разрядными приложениями на 64-х битных системах. Поиск по KEY_WOW64_32KEY возвращает гораздо меньше статей, но первые же четыре ссылки ведут на статьи, описывающие рекомендованный способ работы реестром на 64-х разрядных OS.
Где находится автозагрузка в Windows 10
Впрочем, я прекрасно понимаю, почему так происходит. Дизайн Wow64 – не самая прозрачная часть системы. Это скорее проэволюционировавший хак, чем хорошо продуманный компонент системы. В частности разделение реестра на два виртуальных представления – не самое очевидное архитектурное решения для разработчиков приложений. Тем не менее, код, использующий «Wow6432Node», — это очень плохое решение. По нескольким причинам:
- Структура реестра может поменяться с выходом следующей версией операционной системы либо даже с выходом нового сервис пака. Иными словами время жизни такого решения (фактически — заплатки) — пара лет;
- Как правило, используя подобную заплатку разработчики не понимают, что стоит за разделением реестра. В такой ситуации высока вероятность того, что в другие местах продукта имеется аналогичная или похожая проблема, связанная с особенностями 64-х разрядного реестра. В результате рождаются уродцы вроде принудительной синхронизации синхронизация 32-х и 64-х битных версий ключа (AKA закат солнца вручную). Частенько 32-х и 64-х разрядные компоненты приложения ведут себя по-разному;
- Такая заплатка создаёт иллюзию правильности – ведь работает же! Она имеет все шансы попасть в финальную версию продукта и разойтись по тысячам пользователей. Соответственно, распространение исправленной версии встанет в копеечку;
- Высокая стоимость исправления подобной заплатки может стать причиной того, что оно будет отложено до выхода следующей версии продукта, а пользователям будет рекомендовано не обновлять операционную систему. Фактически, повториться история с выходом Vista – относительно много приложений не будет совместимо со следующей версией системы. А на кого посыпятся все шишки? Именно!
В общем, вы всё еще используете «Wow6432Node» в своем коде? Немедленно прекратите!
Источник: blog.not-a-kernel-guy.com
Проверка ключей реестра на подверженность перенаправлению Wow6432 (redirected, shared, reflected)
Привет!
Для тех, кому все это в новинку поясню, что для 64-разрядных ОС некоторые ключи в реестре существуют в двух представлениях:
— для х64 битных приложений.
— для х32 битных приложений.
1. Ключ HKEY_LOCAL_MACHINESOFTWAREClassesCLSID (и все его подразделы) — является 64-битным
2. Ключ HKEY_LOCAL_MACHINESOFTWAREClassesWow6432NodeCLSID (и все его подразделы) — 32-битным.
Если вы попытаетесь в 64-битной ОС с помощью 32-разрядного приложения прочитать/записать/удалить и.т.п. ключ № 1, произойдет перенаправление, и действие выполнится с ключем № 2.
Это пример обычного перенаправления (redirected).
Виды перенаправлений
В плане переадресации существуют такие виды ключей реестра:
1. Перенаправляемые (redirected)
2. Общие (shared)
3. Отраженные (reflected)
4. Также выделю отдельной группой симлинки (symlink), связанные с механизмом registry redirector.
1. Перенаправляемые (redirected).
Пример таких ключей описан выше (см. Введение).
Возьмем для примера такие ключи:
а) HKLMSoftwareWow6432NodeMicrosoftWindowsCurrentVersionPolicies (32-битное представление)
б) HKLMSoftwareMicrosoftWindowsCurrentVersionPolicies (64-битное представление)
В виду особой важности, некоторые ключи в обеих представлениях (64 и 32) физически ссылаются на один и тот же ключ. Это означает, что если Вы измените ключ под Wow6432Node (ключ а.), то изменения будут видны и в ключе б. И наоборот.
Такие ключи использовались в ОС Windows Server 2008 / Vista / Server 2003 / XP.
Начиная с Windows 7 они были заменены на Shared (общие ключи, см. выше).
Отличием от Shared ключей является то, что физически — это 2 разных ключа. Но, как только программа завершает запись в любой из этих ключей, он автоматически копируется в другое представление. Таким образом, их состояние синхронизируется между собой.
4. Симлинки, связанные с переадресацией под Wow64.
Microsoft не рекомендует использовать для доступа к 32-разрядным ключам жестко закодированные строки, проходящие через имя Wow6432Node. Вместо этого есть цивилизованные способы.
Однако, некоторые программисты все же используют такие пути. И это могло бы плохо закончится, потому что, начиная с Windows 7 (?) путь к Wow6432Node для некоторых ключей изменился, а для других было вообще отключено 32-битное представление.
- HKEY_LOCAL_MACHINESOFTWAREWow6432NodeClasses указывает на HKEY_LOCAL_MACHINESOFTWAREClassesWow6432Node
- HKEY_LOCAL_MACHINESOFTWAREClassesWow6432NodeAppId указывает на HKEY_LOCAL_MACHINESOFTWAREClassesAppId
- HKEY_LOCAL_MACHINESOFTWAREClassesWow6432NodePROTOCOLS указывает на HKEY_LOCAL_MACHINESOFTWAREClassesPROTOCOLS
- HKEY_LOCAL_MACHINESOFTWAREClassesWow6432NodeTypelib указывает на HKEY_LOCAL_MACHINESOFTWAREClassesTypelib
- HKEY_LOCAL_MACHINESOFTWAREWow6432NodeClasses указывает на HKEY_LOCAL_MACHINESOFTWAREClassesWow6432Node (для ОС Windows Server 2008 / Vista / Server 2003 / XP)
Возьмем замечательную утилиту ListRegistryLinks от Helge Klein, и выполним в командной строке, например, такое для улья HKLM:
ListRegistryLinks-x64.exe HKLM | find /i «Wow6432Node»
Спойлер: Итог для Windows 7 x64
«HKLMSOFTWAREClassesWow6432NodeAppID» -> «HKLMSOFTWAREClassesAppID» (заметьте, что ключ больше не указывает на Wow6432Node, а значит в этой версии ОС просто отказались от 32-битного представления этого ключа и некоторых других (см. ниже аналогичные))
«HKLMSOFTWAREClassesWow6432NodePROTOCOLS» -> «HKLMSOFTWAREClassesPROTOCOLS»
«HKLMSOFTWAREClassesWow6432NodeTypeLib» -> «HKLMSOFTWAREClassesTypeLib»
«HKLMSOFTWAREWow6432NodeMicrosoftCryptographyCalaisCurrent» -> «HKLMSOFTWAREMicrosoftCryptographyCalaisCurrent»
«HKLMSOFTWAREWow6432NodeMicrosoftCryptographyCalaisReaders» -> «HKLMSOFTWAREMicrosoftCryptographyCalaisReaders»
«HKLMSOFTWAREWow6432NodeMicrosoftCryptographyServices» -> «HKLMSOFTWAREMicrosoftCryptographyServices»
«HKLMSOFTWAREWow6432NodeMicrosoftCTFSystemShared» -> «HKLMSOFTWAREMicrosoftCTFSystemShared»
«HKLMSOFTWAREWow6432NodeMicrosoftCTFTIP» -> «HKLMSOFTWAREMicrosoftCTFTIP»
«HKLMSOFTWAREWow6432NodeMicrosoftNotepadDefaultFonts» -> «HKLMSOFTWAREMicrosoftNotepadDefaultFonts»
«HKLMSOFTWAREWow6432NodeMicrosoftSoftwareMicrosoftShared ToolsMsinfo» -> «HKLMSOFTWAREMicrosoftSoftwareMicrosoftShared ToolsMsinfo»
«HKLMSOFTWAREWow6432NodeMicrosoftWindowsCurrentVersionControl PanelCursorsSchemes» -> «HKLMSOFTWAREMicrosoftWindowsCurrentVersionControl PanelCursorsSchemes»
«HKLMSOFTWAREWow6432NodeMicrosoftWindowsCurrentVersionexplorerAutoplayHandlers» -> «HKLMSOFTWAREMicrosoftWindowsCurrentVersionExplorerAutoplayHandlers»
«HKLMSOFTWAREWow6432NodeMicrosoftWindowsCurrentVersionexplorerDriveIcons» -> «HKLMSOFTWAREMicrosoftWindowsCurrentVersionExplorerDriveIcons»
«HKLMSOFTWAREWow6432NodeMicrosoftWindowsCurrentVersionexplorerKindMap» -> «HKLMSOFTWAREMicrosoftWindowsCurrentVersionExplorerKindMap»
«HKLMSOFTWAREWow6432NodeMicrosoftWindowsCurrentVersionTelephonyLocations» -> «HKLMSOFTWAREMicrosoftWindowsCurrentVersionTelephonyLocations»
«HKLMSOFTWAREWow6432NodeMicrosoftWindowsCurrentVersionApp Paths» -> «HKLMSOFTWAREMicrosoftWindowsCurrentVersionApp Paths»
«HKLMSOFTWAREWow6432NodeMicrosoftWindowsCurrentVersionGroup Policy» -> «HKLMSOFTWAREMicrosoftWindowsCurrentVersionGroup Policy»
«HKLMSOFTWAREWow6432NodeMicrosoftWindowsCurrentVersionPolicies» -> «HKLMSOFTWAREMicrosoftWindowsCurrentVersionPolicies»
«HKLMSOFTWAREWow6432NodeMicrosoftWindowsCurrentVersionPreviewHandlers» -> «HKLMSOFTWAREMicrosoftWindowsCurrentVersionPreviewHandlers»
«HKLMSOFTWAREWow6432NodeMicrosoftWindowsCurrentVersionSetup» -> «HKLMSOFTWAREMicrosoftWindowsCurrentVersionSetup»
«HKLMSOFTWAREWow6432NodeMicrosoftWindows NTCurrentVersionConsole» -> «HKLMSOFTWAREMicrosoftWindows NTCurrentVersionConsole»
«HKLMSOFTWAREWow6432NodeMicrosoftWindows NTCurrentVersionFontDPI» -> «HKLMSOFTWAREMicrosoftWindows NTCurrentVersionFontDPI»
«HKLMSOFTWAREWow6432NodeMicrosoftWindows NTCurrentVersionFontLink» -> «HKLMSOFTWAREMicrosoftWindows NTCurrentVersionFontLink»
«HKLMSOFTWAREWow6432NodeMicrosoftWindows NTCurrentVersionFontMapper» -> «HKLMSOFTWAREMicrosoftWindows NTCurrentVersionFontMapper»
«HKLMSOFTWAREWow6432NodeMicrosoftWindows NTCurrentVersionFonts» -> «HKLMSOFTWAREMicrosoftWindows NTCurrentVersionFonts»
«HKLMSOFTWAREWow6432NodeMicrosoftWindows NTCurrentVersionFontSubstitutes» -> «HKLMSOFTWAREMicrosoftWindows NTCurrentVersionFontSubstitutes»
«HKLMSOFTWAREWow6432NodeMicrosoftWindows NTCurrentVersionGRE_Initialize» -> «HKLMSOFTWAREMicrosoftWindows NTCurrentVersionGRE_Initialize»
«HKLMSOFTWAREWow6432NodeMicrosoftWindows NTCurrentVersionImage File Execution Options» -> «HKLMSOFTWAREMicrosoftWindows NTCurrentVersionImage File Execution Options»
«HKLMSOFTWAREWow6432NodeMicrosoftWindows NTCurrentVersionLanguagePack» -> «HKLMSOFTWAREMicrosoftWindows NTCurrentVersionLanguagePack»
«HKLMSOFTWAREWow6432NodeMicrosoftWindows NTCurrentVersionNetworkCards» -> «HKLMSOFTWAREMicrosoftWindows NTCurrentVersionNetworkCards»
«HKLMSOFTWAREWow6432NodeMicrosoftWindows NTCurrentVersionPerflib» -> «HKLMSOFTWAREMicrosoftWindows NTCurrentVersionPerflib»
«HKLMSOFTWAREWow6432NodeMicrosoftWindows NTCurrentVersionPorts» -> «HKLMSOFTWAREMicrosoftWindows NTCurrentVersionPorts»
«HKLMSOFTWAREWow6432NodeMicrosoftWindows NTCurrentVersionPrint» -> «HKLMSOFTWAREMicrosoftWindows NTCurrentVersionPrint»
«HKLMSOFTWAREWow6432NodeMicrosoftWindows NTCurrentVersionProfileList» -> «HKLMSOFTWAREMicrosoftWindows NTCurrentVersionProfileList»
«HKLMSOFTWAREWow6432NodeMicrosoftWindows NTCurrentVersionTime Zones» -> «HKLMSOFTWAREMicrosoftWindows NTCurrentVersionTime Zones»
«HKLMSOFTWAREWow6432NodeMicrosoftCOM3» -> «HKLMSOFTWAREMicrosoftCOM3»
«HKLMSOFTWAREWow6432NodeMicrosoftDFS» -> «HKLMSOFTWAREMicrosoftDFS»
«HKLMSOFTWAREWow6432NodeMicrosoftDriver Signing» -> «HKLMSOFTWAREMicrosoftDriver Signing»
«HKLMSOFTWAREWow6432NodeMicrosoftEnterpriseCertificates» -> «HKLMSOFTWAREMicrosoftEnterpriseCertificates»
«HKLMSOFTWAREWow6432NodeMicrosoftEventSystem» -> «HKLMSOFTWAREMicrosoftEventSystem»
«HKLMSOFTWAREWow6432NodeMicrosoftMSMQ» -> «HKLMSOFTWAREMicrosoftMSMQ»
«HKLMSOFTWAREWow6432NodeMicrosoftNon-Driver Signing» -> «HKLMSOFTWAREMicrosoftNon-Driver Signing»
«HKLMSOFTWAREWow6432NodeMicrosoftOle» -> «HKLMSOFTWAREMicrosoftOle»
«HKLMSOFTWAREWow6432NodeMicrosoftRas» -> «HKLMSOFTWAREMicrosoftRas»
«HKLMSOFTWAREWow6432NodeMicrosoftRpc» -> «HKLMSOFTWAREMicrosoftRpc»
«HKLMSOFTWAREWow6432NodeMicrosoftSystemCertificates» -> «HKLMSOFTWAREMicrosoftSystemCertificates»
«HKLMSOFTWAREWow6432NodeMicrosoftTermServLicensing» -> «HKLMSOFTWAREMicrosoftTermServLicensing»
«HKLMSOFTWAREWow6432NodeMicrosoftTransaction Server» -> «HKLMSOFTWAREMicrosoftTransaction Server»
«HKLMSOFTWAREWow6432NodeClasses» -> «HKLMSOFTWAREClassesWow6432Node»
«HKLMSOFTWAREWow6432NodeClients» -> «HKLMSOFTWAREClients»
«HKLMSOFTWAREWow6432NodePolicies» -> «HKLMSOFTWAREPolicies»
«HKLMSOFTWAREWow6432NodeRegisteredApplications» -> «HKLMSOFTWARERegisteredApplications»
Перечень ключей реестра, подверженных переадресации
Такой перечень присутствует на сайте Microsoft, но он давно не обновлялся.
Я написал скрипт (батник), который позволяет проверить индивидуальный (введенный вами) ключ на предмет его перенаправления таких видов:
1) Shared
2) Redirected
Если ключ обычный — батник ничего не выведет.
Рекомендуется пользоваться батником на виртуальной машине , т.к. он оставляет мусор в виде пустых ключей в 32-битном представлении. Они специально не удаляются в целях безопасности (чтобы ничего лишнего не наудалять).
Также он не особо хорошо тестировался. Я на 100% не гарантирую, что он все правильно определит.
Тем не менее, по моим ручным тестам (с подтверждением) уже нашлись расхождения даже с официальной информацией, например, на Windows 7 ключ
Источник: www.safezone.cc
Как быть с реестром (пишет в WOW64)?
Записываю данные сюда: «Software\my-firm». Раньше так и писало. Теперь пишет в «SOFTWAREWow6432Nodemy-firm». Это перенаправление WOW64.
Что произошло — не пойму даже. Ничего такого не делал. Как это отключить?
- Вопрос задан более трёх лет назад
- 558 просмотров
Комментировать
Решения вопроса 0
Ответы на вопрос 4
Собирать 64битное приложение а не 32. Wow6432Node это виртуальный реестр для 32битных приложений.
Ответ написан более трёх лет назад
Комментировать
Нравится 1 Комментировать
Программист на «си с крестами» и не только
Так надо, у W32 и W64 разные места в реестре. И в 90% случаев ничего не надо делать.
Но иногда всё-таки приходится, например:
• Есть проги для W32 и W64, и хотелось бы иметь общие настройки.
• Прога для W32 читает чужие настройки от проги для W64, и наоборот.
• У вас программа, оперирующая реестром: редактор, чистильщик, архиватор…
Тогда вот дока от M$, объясняющая всё это.
https://msdn.microsoft.com/en-us/library/windows/d.
P.S. «Работает с реестром» — это пишет свои настройки в реестр или действительно оперирует реестром, типа редактора или чистильщика реестра?
Ответ написан более трёх лет назад
Нравится 1 2 комментария
https://msdn.microsoft.com/en-us/library/windows/d. — эта ссылка лучше) По той Вистовский механизм больше описан, он вроде сейчас не используется.
Нужны обе сцылки. Первая показывает, что писать программисту. Вторая — что конкретно делает виртуализация в W10.
MiiNiPaa прав, вы и не должны ничего особенного делать. Знакомьтесь, это виндовая подсистема для 32-битных приложений. Между прочим, system32 в 32-х битах тоже не system32, а SysWow64. Отключать это не надо, из 32-битного приложения всё должно быть как и раньше видно. Если хотите без виртуализации, соберите 64-битное приложение.
И вообще, опишите лучше реальную проблему, потому что сейчас вы говорите об эстетической стороне вопроса.
Источник: qna.habr.com