Какая кодовая таблица используется в операционной системе Windows

Обновлено: 21.11.2024

В этой статье описывается, что такое библиотека динамической компоновки (DLL), и различные проблемы, которые могут возникнуть при использовании библиотек DLL. В нем также описаны некоторые дополнительные вопросы, которые следует учитывать при разработке собственных библиотек DLL.

Относится к: Windows 10 — все выпуски
Исходный номер базы знаний: 815065

Обзор

Описывая, что такое DLL, в этой статье описываются методы динамического связывания, зависимости DLL, точки входа DLL, экспорт функций DLL и средства устранения неполадок DLL.

Для операционных систем Windows большая часть функциональных возможностей операционной системы обеспечивается DLL. Кроме того, когда вы запускаете программу в одной из этих операционных систем Windows, большая часть функциональных возможностей программы может обеспечиваться библиотеками DLL. Например, некоторые программы могут содержать множество различных модулей, и каждый модуль программы содержится и распространяется в библиотеках DLL.

Использование библиотек DLL способствует модуляции кода, повторному использованию кода, эффективному использованию памяти и сокращению дискового пространства. Таким образом, операционная система и программы загружаются быстрее, работают быстрее и занимают меньше места на диске компьютера.

Когда программа использует библиотеку DLL, проблема, называемая зависимостью, может привести к тому, что программа не запустится. Когда программа использует DLL, создается зависимость. Если другая программа перезапишет и разорвет эту зависимость, исходная программа может не запуститься успешно.

Подробнее

DLL — это библиотека, содержащая код и данные, которые могут использоваться более чем одной программой одновременно. Например, в операционных системах Windows библиотека DLL Comdlg32 выполняет общие функции, связанные с диалоговыми окнами. Каждая программа может использовать функциональные возможности, содержащиеся в этой библиотеке DLL, для реализации диалогового окна «Открыть». Это способствует повторному использованию кода и эффективному использованию памяти.

С помощью библиотеки DLL программу можно разбить на отдельные компоненты. Например, бухгалтерская программа может продаваться по модулям. Каждый модуль может быть загружен в основную программу во время выполнения, если этот модуль установлен. Поскольку модули разделены, время загрузки программы сокращается. И модуль загружается только тогда, когда запрашивается эта функциональность.

Кроме того, обновления легче применять к каждому модулю, не затрагивая другие части программы. Например, у вас может быть программа расчета заработной платы, и налоговые ставки меняются каждый год. Когда эти изменения изолируются в DLL, вы можете применить обновление без повторной сборки или установки всей программы.

В следующем списке описаны некоторые файлы, реализованные в виде библиотек DLL в операционных системах Windows:

Файлы элементов управления ActiveX (.ocx)

Примером элемента управления ActiveX является элемент управления календарем, который позволяет выбрать дату из календаря.

Файлы панели управления (.cpl)

Примером файла .cpl является элемент, расположенный на панели управления. Каждый элемент представляет собой специализированную библиотеку DLL.

Файлы драйверов устройств (.drv)

Примером драйвера устройства является драйвер принтера, который управляет печатью на принтере.

Преимущества DLL

В следующем списке описаны некоторые преимущества, предоставляемые программой, использующей библиотеку DLL:

Использует меньше ресурсов

Когда несколько программ используют одну и ту же библиотеку функций, DLL может уменьшить дублирование кода, загружаемого на диск и в физическую память. Это может сильно повлиять на производительность не только программы, работающей на переднем плане, но и других программ, работающих в операционной системе Windows.

Поддерживает модульную архитектуру

Библиотека DLL помогает разрабатывать модульные программы. Он помогает разрабатывать большие программы, требующие нескольких языковых версий, или программы, требующие модульной архитектуры. Примером модульной программы является бухгалтерская программа, имеющая множество модулей, которые можно динамически загружать во время выполнения.

Упрощает развертывание и установку

Когда функция в библиотеке DLL нуждается в обновлении или исправлении, развертывание и установка библиотеки DLL не требует повторного связывания программы с библиотекой DLL. Кроме того, если несколько программ используют одну и ту же библиотеку DLL, обновление или исправление принесут пользу всем этим программам. Эта проблема может чаще возникать при использовании сторонних DLL, которые регулярно обновляются или исправляются.

DLL-зависимости

Когда программа или библиотека DLL использует функцию DLL в другой библиотеке DLL, создается зависимость. Программа больше не является автономной, и у программы могут возникнуть проблемы, если зависимость нарушена. Например, программа может не запуститься, если произойдет одно из следующих действий:

Зависимая библиотека DLL обновляется до новой версии.
Исправлена зависимая библиотека DLL.
Зависимая библиотека DLL перезаписывается более ранней версией.
Зависимая DLL удаляется с компьютера.

Эти действия называются конфликтами DLL.Если не обеспечить обратную совместимость, программа может не запуститься.

В следующем списке описаны изменения, которые были введены в Windows 2000 и более поздних операционных системах Windows, чтобы минимизировать проблемы с зависимостями:

Защита файлов Windows

При защите файлов Windows операционная система предотвращает обновление или удаление системных библиотек DLL неавторизованным агентом. Когда установка программы пытается удалить или обновить DLL, которая определена как системная DLL, защита файлов Windows будет искать действительную цифровую подпись.

Частные библиотеки DLL позволяют изолировать программу от изменений, внесенных в общие библиотеки DLL. Частные библиотеки DLL используют информацию о версии или пустой файл .local для принудительного применения версии библиотеки DLL, используемой программой. Чтобы использовать частные библиотеки DLL, найдите свои библиотеки DLL в корневой папке программы. Затем для новых программ добавьте информацию о версии в DLL. Для старых программ используйте пустой файл .local. Каждый метод указывает операционной системе использовать частные библиотеки DLL, расположенные в корневой папке программы.

Инструменты устранения неполадок с DLL

Для устранения неполадок с DLL доступно несколько инструментов. Следующие инструменты являются одними из этих инструментов.

Обходчик зависимостей

Инструмент Dependency Walker может рекурсивно сканировать все зависимые библиотеки DLL, используемые программой. Когда вы открываете программу в Dependency Walker, Dependency Walker выполняет следующие проверки:

Dependency Walker проверяет отсутствующие библиотеки DLL.
Dependency Walker проверяет наличие недопустимых программных файлов или библиотек DLL.
Dependency Walker проверяет соответствие функций импорта и экспорта.
Dependency Walker проверяет циклические ошибки зависимостей.
Dependency Walker проверяет недействительные модули, поскольку они предназначены для другой операционной системы.

С помощью Dependency Walker вы можете документировать все библиотеки DLL, используемые программой. Это может помочь предотвратить и исправить проблемы с DLL, которые могут возникнуть в будущем. Dependency Walker находится в следующем каталоге при установке Visual Studio 6.0:

диск\Program Files\Microsoft Visual Studio\Common\Tools

Универсальное средство решения проблем DLL

Универсальный инструмент решения проблем DLL (DUPS) используется для аудита, сравнения, документирования и отображения информации о DLL. В следующем списке описаны утилиты, входящие в состав инструмента DUPS:

Эта утилита перечисляет все библиотеки DLL на компьютере и записывает информацию в текстовый файл или в файл базы данных.

Эта утилита сравнивает библиотеки DLL, перечисленные в двух текстовых файлах, и создает третий текстовый файл, содержащий различия.

Эта утилита загружает текстовые файлы, созданные с помощью утилит Dlister.exe и Dcomp.exe, в базу данных dllHell.

Эта утилита представляет собой версию утилиты Dtxt2DB.exe с графическим интерфейсом пользователя (GUI).

База данных справки DLL

База данных DLL Help помогает найти определенные версии DLL, которые устанавливаются программными продуктами Microsoft.

Разработка DLL

В этом разделе описываются проблемы и требования, которые следует учитывать при разработке собственных библиотек DLL.

Типы DLL

При загрузке библиотеки DLL в приложение есть два метода связывания, позволяющие вызывать функции экспортированной библиотеки DLL. Существует два метода связывания: динамическое связывание во время загрузки и динамическое связывание во время выполнения.

Динамическое связывание во время загрузки

При динамическом связывании во время загрузки приложение делает явные вызовы экспортированных функций DLL, таких как локальные функции. Чтобы использовать динамическое связывание во время загрузки, предоставьте файл заголовка (.h) и файл библиотеки импорта (.lib) при компиляции и связывании приложения. Когда вы сделаете это, компоновщик предоставит системе информацию, необходимую для загрузки библиотеки DLL и определения местоположения функций экспортированной библиотеки DLL во время загрузки.

Динамическое связывание во время выполнения

При динамической компоновке во время выполнения приложение вызывает либо функцию LoadLibrary, либо функцию LoadLibraryEx для загрузки библиотеки DLL во время выполнения. После успешной загрузки DLL вы используете функцию GetProcAddress для получения адреса экспортированной функции DLL, которую вы хотите вызвать. При использовании динамической компоновки во время выполнения файл библиотеки импорта не требуется.

В следующем списке описаны критерии приложения, когда следует использовать динамическую компоновку во время загрузки и когда использовать динамическую компоновку во время выполнения:

Если важна начальная производительность приложения при запуске, следует использовать динамическую компоновку во время выполнения.

При динамическом связывании во время загрузки экспортированные функции DLL аналогичны локальным функциям. Это упрощает вызов этих функций.

При динамической компоновке во время выполнения приложение может разветвляться для загрузки различных модулей по мере необходимости. Это важно при разработке многоязычных версий.

Точка входа в DLL

При создании библиотеки DLL можно дополнительно указать функцию точки входа. Функция точки входа вызывается, когда процессы или потоки присоединяются к библиотеке DLL или отсоединяются от нее. Вы можете использовать функцию точки входа для инициализации структур данных или для уничтожения структур данных в соответствии с требованиями DLL. Кроме того, если приложение является многопоточным, вы можете использовать локальное хранилище потока (TLS) для выделения памяти, которая является частной для каждого потока в функции точки входа. Следующий код является примером функции точки входа DLL.

Если функция точки входа возвращает значение FALSE, приложение не запустится, если вы используете динамическую компоновку во время загрузки. Если вы используете динамическую компоновку во время выполнения, не будет загружаться только отдельная библиотека DLL.

Функция точки входа должна выполнять только простые задачи инициализации и не должна вызывать какие-либо другие функции загрузки или завершения DLL. Например, в функции точки входа не следует прямо или косвенно вызывать функцию LoadLibrary или функцию LoadLibraryEx. Кроме того, не следует вызывать функцию FreeLibrary, когда процесс завершается.

В многопоточных приложениях убедитесь, что доступ к глобальным данным DLL синхронизирован (потокобезопасный), чтобы избежать возможного повреждения данных. Для этого используйте TLS для предоставления уникальных данных для каждого потока.

Экспорт функций DLL

Чтобы экспортировать функции DLL, можно либо добавить ключевое слово функции к экспортируемым функциям DLL, либо создать файл определения модуля (.def), в котором перечислены экспортированные функции DLL.

Чтобы использовать ключевое слово функции, вы должны объявить каждую функцию, которую хотите экспортировать, следующим ключевым словом:
__declspec(dllexport)

Чтобы использовать экспортированные функции DLL в приложении, необходимо объявить каждую функцию, которую вы хотите импортировать, с помощью следующего ключевого слова: __declspec(dllimport)

Как правило, вы должны использовать один заголовочный файл с оператором определения и оператором ifdef для разделения оператора экспорта и оператора импорта.

Вы также можете использовать файл определения модуля для объявления экспортируемых функций DLL. Когда вы используете файл определения модуля, вам не нужно добавлять ключевое слово function к экспортируемым функциям DLL. В файле определения модуля вы объявляете инструкцию LIBRARY и инструкцию EXPORTS для DLL. Следующий код является примером файла определения.

Пример библиотеки DLL и приложения

В Visual C++ 6.0 можно создать библиотеку DLL, выбрав тип проекта Win32 Dynamic-Link Library или тип проекта MFC AppWizard (dll).

Следующий код является примером библиотеки DLL, созданной в Visual C++ с использованием типа проекта Win32 Dynamic-Link Library.

Следующий код является примером проекта приложения Win32, который вызывает экспортированную функцию DLL в библиотеке DLL SampleDLL.

При динамическом связывании во время загрузки необходимо связать библиотеку импорта SampleDLL.lib, которая создается при сборке проекта SampleDLL.

При динамической компоновке во время выполнения вы используете код, аналогичный приведенному ниже, для вызова экспортированной функции DLL SampleDLL.dll.

При компиляции и компоновке приложения SampleDLL операционная система Windows ищет DLL-библиотеку SampleDLL в следующих местах в указанном порядке:

Папка приложения

Текущая папка

Системная папка Windows

Функция GetSystemDirectory возвращает путь к системной папке Windows.

Папка Windows

Функция GetWindowsDirectory возвращает путь к папке Windows.

Файл сборки содержит манифест сборки, метаданные типов, код MSIL и другие ресурсы. Манифест сборки содержит метаданные сборки, содержащие всю информацию, необходимую для того, чтобы сборка имела самоописание. В манифест сборки включается следующая информация:

Название сборки
Информация о версии
Информация о культуре
Информация о сильном имени
Список файлов
Введите справочную информацию.
Информация о ссылочной и зависимой сборке

Код MSIL, содержащийся в сборке, не может выполняться напрямую. Вместо этого выполнение кода MSIL управляется через среду CLR. По умолчанию при создании сборки она является частной для приложения. Чтобы создать общую сборку, необходимо присвоить сборке строгое имя, а затем опубликовать сборку в глобальном кэше сборок.

В следующем списке описаны некоторые функции сборок по сравнению с функциями библиотек DLL Win32:

При создании сборки вся информация, необходимая среде CLR для запуска сборки, содержится в манифесте сборки. Манифест сборки содержит список зависимых сборок. Таким образом, CLR может поддерживать согласованный набор сборок, используемых в приложении.В библиотеках DLL Win32 невозможно поддерживать согласованность между набором библиотек DLL, используемых в приложении, при использовании общих библиотек DLL.

В манифесте сборки информация о версии записывается и применяется средой CLR. Кроме того, политики версий позволяют принудительно применять использование для конкретной версии. В библиотеках DLL Win32 управление версиями не может быть принудительно реализовано операционной системой. Вы должны убедиться, что библиотеки DLL обратно совместимы.

Сборки поддерживают параллельное развертывание. Одно приложение может использовать одну версию сборки, а другое приложение может использовать другую версию сборки. Начиная с Windows 2000, параллельное развертывание поддерживается путем размещения библиотек DLL в папке приложения. Кроме того, защита файлов Windows предотвращает перезапись или замену системных библиотек DLL неавторизованным агентом.

Самозащита и изоляция

Приложение, разработанное с использованием сборки, может быть автономным и изолированным от других приложений, работающих на компьютере. Эта функция помогает создавать установки с нулевым воздействием.

Сборка запускается с разрешениями безопасности, указанными в манифесте сборки и контролируемыми средой CLR.

Большинство написанных сегодня приложений обрабатывают символьные данные в основном в формате Unicode, используя кодировку UTF-16. Однако многие устаревшие приложения продолжают использовать наборы символов на основе кодовых страниц. Даже новым приложениям иногда приходится работать с кодовыми страницами, часто по одной из следующих причин:

Для связи с устаревшими приложениями.
Для связи со старыми почтовыми и новостными серверами, которые могут не всегда поддерживать Unicode.
Для связи с консолью Windows в устаревших целях. (Консоль поддерживает Unicode, но некоторые устаревшие инструменты командной строки могут не поддерживаться.)

Новые приложения Windows должны использовать Unicode, чтобы избежать несоответствий различных кодовых страниц и упростить локализацию.

Каждая кодовая страница представлена идентификатором кодовой страницы, например 1252, и обрабатывается функциями API Unicode и набора символов. Список поддерживаемых идентификаторов кодовых страниц см. в разделе Идентификаторы кодовых страниц. В справочнике "Кодовые страницы" в Центре разработчиков Microsoft Go Global Developer Center приведены полные описания многих кодовых страниц.

Кодовые страницы Windows, обычно называемые "кодовыми страницами ANSI", представляют собой кодовые страницы, для которых значения, отличные от ASCII (значения больше 127), представляют международные символы. Эти кодовые страницы изначально используются в Windows Me, а также доступны в Windows NT и более поздних версиях.

Изначально кодовая страница Windows 1252, обычно используемая для английского и других западноевропейских языков, была основана на проекте Американского национального института стандартов (ANSI). Этот проект в конечном итоге стал ISO 8859-1, но кодовая страница Windows 1252 была реализована до того, как стандарт стал окончательным, и это не совсем то же самое, что и ISO 8859-1.

Многие функции Windows API имеют версии "A" (ANSI) и "W" (широкий, Unicode). Версия «A» обрабатывает текст на основе кодовых страниц Windows, а версия «W» обрабатывает текст в формате Unicode. См. Типы данных Windows для строк и Соглашения для прототипов функций.

Кодовые страницы Windows также иногда называют "активными кодовыми страницами" или "системными активными кодовыми страницами". В операционной системе Windows всегда есть одна активная в данный момент кодовая страница Windows. Все версии функций API ANSI используют текущую активную кодовую страницу.

Кодовые страницы производителей оригинального оборудования (OEM) — это кодовые страницы, для которых значения, отличные от ASCII, представляют символы рисования линий и пунктуации. Эти кодовые страницы изначально использовались для MS-DOS и до сих пор используются для консольных приложений. Они также используются для нерасширенных имен файлов в файловых системах FAT12, FAT16 и FAT32, как описано в разделе Наборы символов, используемые в именах файлов. Обычная кодовая страница OEM для английского языка — кодовая страница 437.

Для кодовых страниц Windows и OEM кодовые значения от 0x00 до 0x7F соответствуют 7-битному набору символов ASCII. Кодовые значения от 0x00 до 0x19 и 0x7F всегда представляют собой стандартные управляющие символы, а от 0x20 до 0x7E — стандартизированные отображаемые символы. Символы, представленные остальными кодами, от 0x80 до 0xff, различаются в зависимости от набора символов. Каждый набор символов включает различные специальные символы, обычно настроенные для языка или группы языков. Кодовая страница Windows 1252 и кодовая страница OEM 437 обычно используются в США.

Помимо кодовых страниц Windows и OEM, ваши приложения могут использовать неродные кодовые страницы. Примерами являются кодовые страницы EBCDIC и Macintosh.

Две кодировки Unicode (UTF-7 и UTF-8) реализованы в виде кодовых страниц. Как и другие кодовые страницы, каждая страница известна по числовому идентификатору и может обрабатываться многими из тех же функций API Unicode и набора символов.

Кодовые страницы могут быть страницами с набором однобайтовых символов (SBCS) или страницами с набором двухбайтовых символов (DBCS).На страницах SBCS каждый байт напрямую кодирует один символ, так что можно представить ровно 256 различных символов (включая управляющие символы, буквы, цифры, знаки препинания, символы и т.п.). Кодовые страницы DBCS используются для таких языков, как японский и китайский. В такой кодовой странице некоторые символы имеют двухбайтовую кодировку с определенными значениями байтов (всегда значения больше 127), выступающими в качестве «начальных байтов». Вместо того, чтобы кодировать символы сами по себе, начальные байты могут быть сопоставлены с символом только в сочетании с «конечным байтом».

Некоторые устаревшие протоколы требуют использования кодовых страниц SBCS и DBCS. Каждая кодовая страница SBCS/DBCS поддерживает разные символы, но ни одна кодовая страница не поддерживает весь спектр символов, предоставляемых Unicode. Каждая кодовая страница SBCS/DBCS поддерживает разные подмножества, закодированные по-разному.

Данные, преобразованные из одной кодовой страницы SBCS или DBCS в другую, могут быть повреждены, поскольку одно и то же значение данных на разных кодовых страницах может кодировать разные символы. Данные, преобразованные из Unicode в SBCS или DBCS, могут быть потеряны, так как данная кодовая страница может не соответствовать каждому символу, используемому в этих конкретных данных Unicode.

Несколько функций Unicode и наборов символов позволяют вашим приложениям обрабатывать кодовые страницы. Приложение может использовать функции GetCPInfo и GetCPInfoEx для получения информации о кодовой странице. Эта информация включает символ по умолчанию, используемый, когда символ в преобразованной строке не имеет соответствующей записи на кодовой странице.

Приложение может использовать функции MultiByteToWideChar и WideCharToMultiByte для преобразования между строками на основе кодовых страниц Windows и строк Unicode. Хотя их имена относятся к MultiByte, эти функции одинаково хорошо работают с кодовыми страницами SBCS, DBCS и многобайтовыми кодовыми страницами.

WideCharToMultiByte может потерять некоторые данные, если предоставленная кодовая страница не может представлять все символы в строке Unicode.

Ваше приложение может выполнять преобразование между кодовыми страницами Windows и кодовыми страницами OEM с помощью стандартных функций библиотеки времени выполнения C. Однако использование этих функций сопряжено с риском потери данных, поскольку символы, которые могут быть представлены каждой кодовой страницей, не совпадают точно.

Ваши приложения также могут вызывать функцию GetACP. Эта функция извлекает идентификатор текущей кодовой страницы Windows (ANSI).

Вспомогательные функции API версии используются для определения текущей версии операционной системы. Дополнительные сведения см. в разделе Получение версии системы.

В следующей таблице приведены самые последние номера версий операционной системы.

Операционная система	Номер версии
Windows 11	10.0*
Windows 10	10.0*
Windows Server 2022	10.0*
Windows Server 2019	10.0*
Windows Server 2016< /td>	10.0*
Windows 8.1	6.3*
Windows Server 2012 R2	6.3*
Windows 8	6.2
Windows Server 2012	6.2
Windows 7	6.1
Windows Server 2008 R2	6.1
Windows Server 2008	6.0
Windows Vista	6.0
Windows Server 2003 R2	5.2
Windows Server 2003	5.2
Windows XP 64-разрядная версия	5.2
Windows XP	5.1
Windows 2000	5.0

* Для приложений, которые были манифестированы для Windows 8.1 или Windows 10. Приложения, не манифестированные для Windows 8.1 или Windows 10, вернут значение версии ОС Windows 8 (6.2). Чтобы манифестировать приложения для Windows 8.1 или Windows 10, см. раздел Настройка приложения для Windows.

Определение текущей операционной системы обычно не является лучшим способом определить, присутствует ли та или иная функция операционной системы. Это связано с тем, что в операционную систему могли быть добавлены новые функции в распространяемой DLL. Вместо использования вспомогательных функций API версии для определения платформы операционной системы или номера версии проверьте наличие самой функции.

Чтобы определить лучший способ тестирования функции, обратитесь к документации по интересующей функции. В следующем списке обсуждаются некоторые распространенные методы обнаружения признаков:

Вы можете проверить наличие функций, связанных с функцией. Чтобы проверить наличие функции в системной библиотеке DLL, вызовите функцию LoadLibrary для загрузки библиотеки DLL. Затем вызовите функцию GetProcAddress, чтобы определить, присутствует ли интересующая функция в DLL. Используйте указатель, возвращенный GetProcAddress, для вызова функции.Обратите внимание, что даже если функция присутствует, это может быть заглушка, которая просто возвращает код ошибки, такой как ERROR_CALL_NOT_IMPLEMENTED.
Вы можете определить наличие некоторых функций с помощью функции GetSystemMetrics. Например, вы можете обнаружить несколько мониторов, вызвав GetSystemMetrics(SM_CMONITORS).
Существует несколько версий свободно распространяемых библиотек DLL, которые реализуют функции оболочки и общие элементы управления. Сведения об определении версий, присутствующих в системе, в которой работает ваше приложение, см. в разделе Версии оболочки и общих элементов управления.

Если вам требуется определенная операционная система, обязательно используйте ее как минимальную поддерживаемую версию, а не разрабатывайте тест для одной операционной системы. Таким образом, ваш код обнаружения продолжит работать в будущих версиях Windows.

Обратите внимание, что 32-разрядное приложение может определить, работает ли оно под WOW64, вызвав функцию IsWow64Process. Он может получить дополнительную информацию о процессоре, вызвав функцию GetNativeSystemInfo.

Внедрение спецификации оборудования Advanced Configuration and Power Interface (ACPI) не требуется на платформах на основе SoC, но большая часть спецификации программного обеспечения ACPI требуется (или может потребоваться). ACPI определяет общий, расширяемый механизм передачи таблиц, а также специальные таблицы для описания платформы в операционной системе.

Структура и заголовки таблиц, включая поля идентификатора и контрольной суммы, определены в спецификации ACPI 5.0. Windows использует этот механизм передачи таблиц в дополнение к конкретным таблицам, описанным в этой статье.

Идея, стоящая за этими таблицами, заключается в том, чтобы универсальное программное обеспечение могло поддерживать стандартные блоки интеллектуальной собственности (IP), которые можно различными способами интегрировать в различные платформы. При табличной стратегии переменные атрибуты конкретной платформы предоставляются в виде таблицы и используются общим программным обеспечением для адаптации к определенному набору IP-блоков, интегрированных в платформу. Таким образом, это программное обеспечение можно написать один раз, тщательно протестировать, а затем оптимизировать с течением времени.

Указатель описания корневой системы (RSDP)

Windows использует прошивку UEFI для загрузки аппаратной платформы. Следовательно, Windows будет использовать системную таблицу EFI для поиска RSDP, как описано в разделе 5.2.5.2 «Поиск RSDP в системах с поддержкой UEFI» спецификации ACPI 5.0. Микропрограмма платформы заполняет адрес RSDT или XSDT в RSDP. (Если указаны оба адреса таблицы, Windows предпочтет XSDT.)

Таблица описания корневой системы (RSDT)

RSDT (или XSDT) включает указатели на любые другие таблицы описания системы, имеющиеся на платформе. В частности, эта таблица содержит указатели на следующее:

Таблица фиксированного оборудования ACPI (FADT)

Таблица контроллеров множественных прерываний (MADT)

Необязательно, основная таблица системных ресурсов (CSRT)

Таблица портов отладки 2 (DBG2)

Таблица ресурсов загрузочной графики (BGRT)

Таблица данных о производительности встроенного ПО (FPDT)

Таблица описания базовой системы (DSDT)

Необязательно, дополнительные таблицы описания системы (SSDT)

Фиксированная таблица описания ACPI (FADT)

Таблица фиксированного оборудования ACPI (FADT) содержит важную информацию о различных функциях фиксированного оборудования, доступных на платформе. Для поддержки аппаратных платформ ACPI ACPI 5.0 расширяет определение таблицы FADT следующим образом:

Поле Flags в FADT (смещение 112) имеет два новых флага:

HARDWARE_REDUCED_ACPI Битовое смещение 20. Указывает, что оборудование ACPI недоступно на этой платформе. Этот флаг должен быть установлен, если модель программирования фиксированного оборудования ACPI не реализована.

LOW_POWER_S0_IDLE_CAPABLE Битовое смещение 21. Указывает, что платформа поддерживает состояния простоя с низким энергопотреблением в состоянии питания системы ACPI S0, которые более энергоэффективны, чем любое состояние сна Sx. Если этот флаг установлен, Windows не будет пытаться переходить в спящий режим и возобновлять работу, а вместо этого будет использовать состояния простоя платформы и режим ожидания с подключением.

Поле FADT Preferred_PM_Profile (смещение 45 байт) содержит новую запись роли "Планшет". Эта роль влияет на политику управления питанием дисплея и ввода, а также на отображение экранных клавиатур.

Поле «Флаги архитектуры загрузки IA-PC» (смещение 109) содержит новый флаг «CMOS RTC Not Present» (битовое смещение 5), указывающий, что CMOS RTC ПК либо не реализован, либо не существует на данный момент. устаревшие адреса. Если этот флаг установлен, платформа должна реализовать устройство ACPI Time and Alarm Control Method. Дополнительную информацию см. в разделе «Метод управления временем и устройством будильника» в разделе, посвященном устройствам, определенным ACPI.

Добавлены новые поля для поддержки традиционного режима сна/возобновления ПК на платформах ACPI с уменьшенным аппаратным обеспечением. Эти поля игнорируются Windows, но должны присутствовать в таблице для соответствия требованиям.

Если установлен флаг HARDWARE_REDUCED_ACPI, все поля, относящиеся к спецификации оборудования ACPI, игнорируются операционной системой.

Все остальные настройки FADT сохраняют свои значения из предыдущей версии ACPI 4.0. Дополнительные сведения см. в разделе 5.2.9 «Таблица фиксированного описания ACPI (FADT)» спецификации ACPI 5.0.

Таблица описания нескольких APIC (MADT)

В реализациях ACPI для ПК для описания модели системных прерываний используется таблица описания множественных APIC (MADT) и дескрипторы контроллера прерываний для ПК. Для платформ SoC на базе ARM ACPI 5.0 добавляет дескрипторы для универсального контроллера прерываний (GIC) и распределителя GIC от ARM Holdings. Windows включает поддержку входящих сообщений для GIC и GIC Distributor. Дополнительные сведения об этих дескрипторах см. в разделах 5.2.12.14, «Структура GIC» и 5.2.12.15, «Структура распространителя GIC» спецификации ACPI 5.0.

Структуры дескрипторов контроллера прерываний перечислены сразу после поля Flags в MADT. Для платформ ARM один дескриптор указан для каждого GIC, а затем один для каждого распространителя GIC. GIC, соответствующий загрузочному процессору, должен быть первой записью в списке дескрипторов контроллера прерываний.

Общая таблица описания таймера (GTDT)

Как и в случае с контроллером прерываний, в ACPI существует стандартная таблица описания таймера. Для систем ARM, в которых используется таймер GIT, можно использовать ACPI GTDT для использования встроенной поддержки GIT в Windows.

Таблица основных системных ресурсов (CSRT)

Основные системные ресурсы (CSR) — это общие аппаратные функции, такие как контроллеры прерываний, таймеры и контроллеры прямого доступа к памяти, к которым операционная система должна сериализовать доступ. Там, где существуют отраслевые стандарты для таких функций, как таймеры и контроллеры прерываний (как для архитектуры x86, так и для ARM), Windows встраивает поддержку этих функций на основе стандартных таблиц, описанных в ACPI (например, MADT и GTDT). Однако до тех пор, пока отрасль не примет стандарты интерфейсов контроллеров прямого доступа к памяти, в операционной системе необходимо будет поддерживать некоторые нестандартные устройства.

Windows поддерживает концепцию расширений HAL для решения этой проблемы. Расширения HAL — это специфичные для SoC модули, реализованные в виде библиотек DLL, которые адаптируют Windows HAL к определенному аппаратному интерфейсу определенного класса CSR, необходимого для Windows. Чтобы идентифицировать и загружать эти нестандартные модули CSR, Microsoft определила новую таблицу ACPI. Эта таблица, которая имеет зарезервированную подпись "CSRT" в спецификации ACPI, должна быть включена в RSDT, если на платформе используются нестандартные CSR.

CSRT описывает группы ресурсов CSR, где каждая группа ресурсов идентифицирует оборудование определенного типа. Windows использует идентификатор, предоставленный группе ресурсов, чтобы найти и загрузить необходимое расширение HAL для этой группы. Группы ресурсов в CSRT также могут содержать отдельные дескрипторы ресурсов, в зависимости от типа CSR и потребностей расширения HAL. Формат и использование этих дескрипторов ресурсов определяются автором расширения HAL, который может сделать расширение намного более переносимым и, таким образом, поддерживать множество различных платформ SoC, просто изменив дескрипторы ресурсов, содержащиеся в CSRT.

Для поддержки поддержки расширений HAL и управления системными ресурсами, используемыми этими расширениями, каждая группа ресурсов, описанная в CSRT, также должна быть представлена как устройство в пространстве имен ACPI платформы. Дополнительные сведения см. в следующем разделе «Таблица описания дифференцированной системы (DSDT)». Идентификаторы устройств, используемые в заголовке группы ресурсов, должны совпадать с идентификаторами, используемыми в узле пространства имен устройства. Дополнительные сведения см. в разделе «Идентификация устройства в ACPI» раздела «Объекты пространства имен управления устройствами». Существование этих устройств пространства имен группы ресурсов позволяет службе обновления Windows обслуживать расширение HAL.

Таблица портов отладки 2 (DBG2)

Microsoft требуется порт отладки на всех системах. Для описания портов отладки, встроенных в платформу, Microsoft определяет таблицу портов отладки 2 (DBG2) для ACPI. В этой таблице указан один или несколько независимых портов для целей отладки. Наличие таблицы DBG2 указывает на то, что платформа включает по крайней мере один порт отладки. Эта таблица включает информацию об идентификаторе и конфигурации порта(ов) отладки. Эта таблица находится в системной памяти вместе с другими таблицами ACPI, и на нее должна быть ссылка в таблице ACPI RSDT.

Windows использует значение типа порта в таблице DBG2 для определения и загрузки транспорта отладчика ядра (KD) (например, USB или последовательного порта), который требуется системе. Затем транспорт KD использует значение подтипа порта в таблице DBG2 для идентификации аппаратного интерфейса, используемого портом.Другая информация в таблице DBG2 указывает системный адрес регистров порта, который используется модулем аппаратного интерфейса для указанного подтипа. Наконец, таблица DBG2 должна включать ссылку на узел устройства в пространстве имен ACPI, который соответствует порту отладки. Эта ссылка позволяет Windows управлять конфликтами между использованием отладки и обычным использованием устройства, если таковые имеются, а также интегрировать отладчик с переключением питания.

Таблица описания дифференцированной системы (DSDT)

В ACPI периферийные устройства и функции системного оборудования на платформе описываются в таблице дифференцированного описания системы (DSDT), которая загружается при загрузке, или во вторичных таблицах описания системы (SSDT), которые загружаются при загрузке или загружаются динамически во время выполнения. Для SoC конфигурация платформы обычно является статической, поэтому DSDT может быть достаточно, хотя SSDT также можно использовать для повышения модульности описания платформы.

ACPI определяет интерпретируемый язык (исходный язык ACPI или ASL) и среду выполнения (виртуальную машину ACPI) для описания системных устройств и функций, а также их элементов управления для конкретных платформ, независимо от ОС. ASL используется для определения именованных объектов в пространстве имен ACPI, а компилятор Microsoft ASL используется для создания байт-кода машинного языка ACPI (AML) для передачи в операционную систему в DSDT. Входящий драйвер Windows ACPI, Acpi.sys, реализует виртуальную машину ACPI и интерпретирует байт-код AML. Объект AML может просто возвращать информацию описания. Или объект AML может быть методом, выполняющим вычисления или операции ввода-вывода. Метод управления — это исполняемый объект AML, который использует драйверы устройств операционной системы для выполнения операций ввода-вывода на оборудовании платформы. ASL использует OpRegions для абстрагирования различных адресных пространств, доступных в операционной системе. Методы управления выполняют операции ввода-вывода в виде серии передач в именованные поля, объявленные в OpRegions, и из них.

Дополнительную информацию об OpRegions см. в разделе 5.5.2.4 «Доступ к операционным регионам» спецификации ACPI 5.0. Дополнительные сведения о ASL и методах управления см. в разделе 5.5 «Пространство имен ACPI» спецификации ACPI 5.0.

Windows поддерживает разработку и отладку кода ASL. Компилятор ASL включает в себя дизассемблер, позволяющий разработчику загружать пространство имен из цели отладки. Затем компилятор ASL можно использовать для повторного применения пространства имен к целевому объекту для быстрого прототипирования и тестирования без необходимости прошивки системной прошивки. Кроме того, отладчик ядра Windows в сочетании с проверенной (CHK) версией драйвера Acpi.sys поддерживает отслеживание и анализ выполнения AML. Дополнительные сведения см. в разделе Отладчик AMLI.

Таблица мер безопасности Windows SMM (WSMT)

Спецификация Windows SMM Security Mitigations Table (WSMT) содержит сведения о таблице Advanced Configuration and Power Interface (ACPI), которая была создана для использования с операционными системами Windows, поддерживающими функции безопасности на основе виртуализации Windows (VBS).

Эта информация относится к следующим операционным системам:

Windows Server 2016

Windows 10, версия 1607

Таблица микрокода загрузки iSCSI (iBFT)

Таблица iSCSI Boot Firmware (iBF) (iBFT) — это блок данных, содержащий различные параметры, полезные для процесса загрузки iSCSI. iBFT — это механизм, с помощью которого значения параметров iBF передаются в операционную систему. iBF строит и заполняет iBFT. iBFT доступен для операционной системы Windows, чтобы обеспечить согласованный поток процесса загрузки.

В этой статье описывается реестр Windows и содержится информация о том, как его редактировать и создавать резервные копии.

Относится к: Windows 10 — все выпуски, Windows Server 2012 R2
Исходный номер базы знаний: 256986

Описание реестра

В пятом издании Microsoft Computer Dictionary реестр определяется как:

Центральная иерархическая база данных, используемая в Windows 98, Windows CE, Windows NT и Windows 2000 для хранения информации, необходимой для настройки системы для одного или нескольких пользователей, приложений и аппаратных устройств.

Реестр содержит информацию, на которую Windows постоянно ссылается во время работы, например, профили для каждого пользователя, приложения, установленные на компьютере, и типы документов, которые каждый из них может создавать, настройки листа свойств для папок и значков приложений, какое аппаратное обеспечение установлено на компьютере. система и используемые порты.

Реестр заменяет большинство текстовых файлов .ini, которые используются в Windows 3.x и файлах конфигурации MS-DOS, таких как Autoexec.bat и Config.sys. Хотя реестр является общим для нескольких операционных систем Windows, между ними есть некоторые различия.Куст реестра — это группа ключей, подразделов и значений в реестре, которая имеет набор вспомогательных файлов, содержащих резервные копии своих данных. Вспомогательные файлы для всех кустов, кроме HKEY_CURRENT_USER, находятся в папке % SystemRoot%\System32\Config в Windows NT 4.0, Windows 2000, Windows XP, Windows Server 2003 и Windows Vista. Вспомогательные файлы для HKEY_CURRENT_USER находятся в папке %SystemRoot%\Profiles\Username. Расширения имен файлов в этих папках указывают тип содержащихся в них данных. Кроме того, отсутствие расширения может иногда указывать на тип данных, которые они содержат.

куст реестра	Поддерживаемые файлы
HKEY_LOCAL_MACHINE\SAM	Sam, Sam.log, Sam.sav
HKEY_LOCAL_MACHINE\Security	Security, Security.log, Security.sav
HKEY_LOCAL_MACHINE\Software	Software, Software.log, Software.sav
HKEY_LOCAL_MACHINE\System	System, System.alt, System.log, System.sav
HKEY_CURRENT_CONFIG	System, System.alt, System.log, System. sav, Ntuser.dat, Ntuser.dat.log
HKEY_USERS\DEFAULT	Default, Default.log, Default.sav

В Windows 98 файлы реестра называются User.dat и System.dat. В Windows Millennium Edition файлы реестра называются Classes.dat, User.dat и System.dat.

Функции безопасности в Windows позволяют администратору контролировать доступ к разделам реестра.

В следующей таблице перечислены предопределенные клавиши, используемые системой. Максимальный размер имени ключа — 255 символов.

< td>HKEY_CURRENT_CONFIG

Папка/предопределенный ключ	Описание
HKEY_CURRENT_USER	Содержит корневую информацию о конфигурации для пользователя, который в данный момент находится в системе. Здесь хранятся папки пользователя, цвета экрана и настройки панели управления. Эта информация связана с профилем пользователя. Этот ключ иногда обозначается как HKCU.
HKEY_USERS	Содержит все активно загруженные профили пользователей на компьютере. HKEY_CURRENT_USER является подразделом HKEY_USERS. HKEY_USERS иногда обозначается как HKU.
HKEY_LOCAL_MACHINE	Содержит информацию о конфигурации, относящуюся к компьютеру (для любого пользователя). Этот ключ иногда обозначается как HKLM.
HKEY_CLASSES_ROOT	Является подразделом HKEY_LOCAL_MACHINE\Software . Информация, хранящаяся здесь, гарантирует, что при открытии файла с помощью проводника Windows откроется нужная программа. Этот ключ иногда обозначается как HKCR. Начиная с Windows 2000, эта информация хранится в ключах HKEY_LOCAL_MACHINE и HKEY_CURRENT_USER. Раздел HKEY_LOCAL_MACHINE\Software\Classes содержит настройки по умолчанию, которые могут применяться ко всем пользователям на локальном компьютере. Раздел HKEY_CURRENT_USER\Software\Classes содержит параметры, которые переопределяют параметры по умолчанию и применяются только к интерактивному пользователю. Раздел HKEY_CLASSES_ROOT предоставляет представление реестра, объединяющее информацию из этих двух источников. HKEY_CLASSES_ROOT также обеспечивает это объединенное представление для программ, разработанных для более ранних версий Windows. Чтобы изменить настройки интерактивного пользователя, необходимо внести изменения в HKEY_CURRENT_USER\Software\Classes, а не в HKEY_CLASSES_ROOT. Чтобы изменить настройки по умолчанию, необходимо внести изменения в разделе HKEY_LOCAL_MACHINE\Software\Classes. Если вы записываете ключи в раздел HKEY_CLASSES_ROOT, система сохраняет информацию в разделе HKEY_LOCAL_MACHINE\Software\Classes. Если вы записываете значения в ключ в HKEY_CLASSES_ROOT, а ключ уже существует в HKEY_CURRENT_USER\Software\Classes, система сохранит информацию там, а не в HKEY_LOCAL_MACHINE\Software\Classes.
Содержит информацию о профиле оборудования, который используется локальным компьютером при запуске системы.

Реестр в 64-разрядных версиях Windows XP, Windows Server 2003 и Windows Vista разделен на 32-разрядные и 64-разрядные ключи. Многие из 32-битных ключей имеют те же имена, что и их 64-битные аналоги, и наоборот. 64-разрядная версия редактора реестра по умолчанию, входящая в состав 64-разрядных версий Windows XP, Windows Server 2003 и Windows Vista, отображает 32-разрядные ключи в узле HKEY_LOCAL_MACHINE\Software\WOW6432Node. Дополнительные сведения о том, как просматривать реестр в 64-разрядных версиях Windows, см. в разделе Как просмотреть системный реестр в 64-разрядных версиях Windows.

В следующей таблице перечислены типы данных, которые в настоящее время определены и используются Windows. Максимальный размер имени значения следующий:

Windows Server 2003, Windows XP и Windows Vista: 16 383 символа.
Windows 2000: 260 символов ANSI или 16 383 символа Unicode.
Windows Millennium Edition/Windows 98/Windows 95: 255 символов.

Длинные значения (более 2048 байт) должны храниться в виде файлов с именами файлов, сохраненными в реестре. Это помогает реестру работать эффективно. Максимальный размер значения следующий:

Windows NT 4.0/Windows 2000/Windows XP/Windows Server 2003/Windows Vista: Доступная память
Windows Millennium Edition/Windows 98/Windows 95: 16 300 байт.

Существует ограничение в 64 КБ на общий размер всех значений ключа.

< td> Ряд вложенных массивов, предназначенных для хранения списка ресурсов, используемых физическим аппаратным устройством. Эти данные обнаруживаются и записываются системой в дерево \HardwareDescription и отображаются в редакторе реестра в шестнадцатеричном формате в виде двоичного значения.

Имя	Тип данных	Описание
Двоичное значение	REG_BINARY	Необработанные двоичные данные. Большая часть информации о компонентах оборудования хранится в виде двоичных данных и отображается в редакторе реестра в шестнадцатеричном формате.
Значение DWORD	REG_DWORD	Данные, представленные числом длиной 4 байта (32-разрядное целое число). Многие параметры драйверов устройств и служб относятся к этому типу и отображаются в редакторе реестра в двоичном, шестнадцатеричном или десятичном формате. Связанные значения: DWORD_LITTLE_ENDIAN (младший байт находится по младшему адресу) и REG_DWORD_BIG_ENDIAN (младший значащий байт находится по старшему адресу).
Расширяемое строковое значение	REG_EXPAND_SZ	Строка данных переменной длины. Этот тип данных включает переменные, которые разрешаются, когда программа или служба использует данные.
Многострочное значение	REG_MULTI_SZ	Многократная строка. К этому типу обычно относятся значения, содержащие списки или несколько значений в удобной для чтения форме. Записи разделяются пробелами, запятыми или другими знаками.
String Value	REG_SZ	Текстовая строка фиксированной длины.
Двоичное значение	REG_RESOURCE_LIST	Серия вложенных массивов, предназначенных для хранения списка ресурсов, используемых оборудованием. драйвер устройства или одно из физических устройств, которыми он управляет. Эти данные обнаруживаются и записываются системой в дерево \ResourceMap и отображаются в редакторе реестра в шестнадцатеричном формате в виде двоичного значения.
Двоичное значение	REG_RESOURCE_REQUIREMENTS_LIST	Серия вложенных массивов, предназначенных для хранения списка возможных аппаратных ресурсов драйвера устройства, которые может использовать драйвер или одно из контролируемых им физических устройств. Система записывает часть этого списка в дерево \ResourceMap. Эти данные обнаруживаются системой и отображаются в редакторе реестра в шестнадцатеричном формате в виде двоичного значения.
Двоичное значение	REG_FULL_RESOURCE_DESCRIPTOR
Нет	REG_NONE	Данные без определенного типа. Эти данные записываются в реестр системой или приложениями и отображаются в редакторе реестра в шестнадцатеричном формате в виде двоичного значения
Link	REG_LINK	Строка Unicode, обозначающая символическую ссылку.
Значение QWORD	REG_QWORD	Данные, представленные числом, которое представляет собой 64-битное целое число. Эти данные отображаются в редакторе реестра как двоичное значение и впервые появились в Windows 2000.

Создать резервную копию реестра

Перед редактированием реестра экспортируйте разделы реестра, которые вы планируете редактировать, или создайте резервную копию всего реестра. В случае возникновения проблемы вы можете выполнить действия, описанные в разделе «Восстановление реестра», чтобы восстановить реестр в его предыдущее состояние. Для резервного копирования всего реестра используйте утилиту резервного копирования для резервного копирования состояния системы. Состояние системы включает реестр, регистрационную базу данных классов COM+ и загрузочные файлы. Дополнительные сведения об использовании утилиты резервного копирования для резервного копирования состояния системы см. в следующих статьях:

Редактировать реестр

Чтобы изменить данные реестра, программа должна использовать функции реестра, определенные в функциях реестра.

Администраторы могут изменять реестр с помощью редактора реестра (Regedit.exe или Regedt32.exe), групповой политики, системной политики, файлов реестра (.reg) или запуская сценарии, такие как файлы сценариев VisualBasic.

Использовать пользовательский интерфейс Windows

Мы рекомендуем использовать пользовательский интерфейс Windows для изменения настроек системы, а не редактировать реестр вручную. Однако иногда редактирование реестра может быть лучшим способом решения проблемы с продуктом. Если проблема задокументирована в базе знаний Майкрософт, будет доступна статья с пошаговыми инструкциями по редактированию реестра для этой проблемы. Мы рекомендуем точно следовать этим инструкциям.

Использовать редактор реестра

При неправильном изменении реестра с помощью редактора реестра или другого метода могут возникнуть серьезные проблемы. Эти проблемы могут потребовать переустановки операционной системы. Майкрософт не может гарантировать, что эти проблемы могут быть решены. Вносите изменения в реестр на свой страх и риск.

Вы можете использовать редактор реестра для выполнения следующих действий:

Найти поддерево, ключ, подраздел или значение
Добавить подраздел или значение
Изменить значение
Удалить подраздел или значение
Переименовать подраздел или значение

В области навигации редактора реестра отображаются папки. Каждая папка представляет собой предопределенный ключ на локальном компьютере. При доступе к реестру удаленного компьютера отображаются только два предопределенных ключа: HKEY_USERS и HKEY_LOCAL_MACHINE.

Использовать групповую политику

Консоль управления Microsoft (MMC) содержит инструменты администрирования, которые можно использовать для администрирования сетей, компьютеров, служб и других системных компонентов. Оснастка MMC групповой политики позволяет администраторам определять параметры политики, которые применяются к компьютерам или пользователям. Вы можете реализовать групповую политику на локальных компьютерах с помощью оснастки локальной групповой политики MMC, Gpedit.msc. Вы можете реализовать групповую политику в Active Directory с помощью оснастки MMC «Пользователи и компьютеры Active Directory». Дополнительные сведения об использовании групповой политики см. в разделах справки соответствующей оснастки MMC групповой политики.

Использовать файл регистрационных записей (.reg)

Создайте файл регистрационных записей (.reg), содержащий изменения реестра, а затем запустите файл .reg на компьютере, на котором вы хотите внести изменения. Вы можете запустить файл .reg вручную или с помощью сценария входа в систему. Дополнительные сведения см. в разделе Добавление, изменение или удаление подразделов и значений реестра с помощью файла регистрационных записей (.reg).

Использовать хост сценариев Windows

Узел сценариев Windows позволяет запускать сценарии VBScript и JScript непосредственно в операционной системе. Вы можете создавать файлы VBScript и JScript, которые используют методы Windows Script Host для удаления, чтения и записи ключей и значений реестра. Дополнительные сведения об этих методах см. на следующих веб-сайтах Microsoft:

Использовать инструментарий управления Windows

Инструментарий управления Windows (WMI) является компонентом операционной системы Microsoft Windows и реализацией Microsoft управления предприятием через Интернет (WBEM). WBEM — это отраслевая инициатива по разработке стандартной технологии доступа к управленческой информации в корпоративной среде. Вы можете использовать WMI для автоматизации административных задач (таких как редактирование реестра) в корпоративной среде. Вы можете использовать WMI в языках сценариев, которые имеют движок в Windows и обрабатывают объекты Microsoft ActiveX. Вы также можете использовать утилиту командной строки WMI (Wmic.exe) для изменения реестра Windows.

Использовать консольный инструмент реестра для Windows

Для редактирования реестра можно использовать утилиту Console Registry Tool для Windows (Reg.exe). Чтобы получить справку по инструменту Reg.exe, введите reg /? в командной строке и нажмите кнопку ОК.

Восстановить реестр

Чтобы восстановить реестр, используйте соответствующий метод.

Способ 1. Восстановите ключи реестра

Чтобы восстановить экспортированные подразделы реестра, дважды щелкните файл Registration Entries (.reg), который вы сохранили в разделе Экспорт подразделов реестра. Или вы можете восстановить весь реестр из резервной копии. Дополнительные сведения о том, как восстановить весь реестр, см. в разделе Способ 2. Восстановление всего реестра далее в этой статье.

Способ 2: восстановить весь реестр

Чтобы восстановить весь реестр, восстановите состояние системы из резервной копии. Дополнительные сведения о том, как восстановить состояние системы из резервной копии, см. в разделе Как использовать резервное копирование для защиты данных и восстановления файлов и папок на компьютере в Windows XP и Windows Vista.

При резервном копировании состояния системы также создаются обновленные копии файлов реестра в папке %SystemRoot%\Repair.

Ссылки

Для получения дополнительной информации посетите следующие веб-сайты:

Каталог протестированных продуктов Windows Server — это справочник по продуктам, которые были протестированы на совместимость с Windows Server.

Диспетчер защиты данных (DPM) — это ключевой член семейства продуктов управления Microsoft System Center, который помогает ИТ-специалистам управлять своей средой Windows. DPM — это новый стандарт резервного копирования и восстановления Windows, который обеспечивает непрерывную защиту данных для приложений и файловых серверов Microsoft, использующих интегрированные диски и ленточные носители. Дополнительные сведения о резервном копировании и восстановлении реестра см. в разделе Резервное копирование и восстановление реестра в Windows XP и Windows Vista.

Читайте также: