Реестр Windows Server 2003

В систему Windows, начиная с Windows 95, включается единое хранилище, которое называется реестром (registry) и используется для хранения информации об этой операционной системе и установленных приложениях. Реестр является базой данных, и он используется почти во всем, что вы делаете. Он содержит информацию о самом компьютере, его оборудовании, периферийных устройствах, подсоединенных к компьютеру, об установленном ПО, а также о пользователях, выполняющих вход на этот компьютер.

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

Большинство данных реестра, которые записываются в результате действий пользователей, помещаются туда из диалоговых окон, в которых работает пользователь (например, из апплетов Панели управления [Control Panel]), или из групповых политик. Предполагается, что вы вносите изменения в элементы конфигурации в окнах графического интерфейса и в диалоговых окнах.

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

Обзор реестра

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

В системе Microsoft Windows 3.1, которая была первой широко используемой версией Windows (особенно в бизнесе) использовались три типа файлов, определяющих оборудование компьютера и приложения для этой операционной системы. Два типа файлов использовались для инициализации и имели расширение имени .ini, и третий тип файлов использовался как база данных для регистрации. Среди файлов инициализации (.ini-файлов) имелись файлы, включенные в Windows, а также множество частных .ini-файлов из приложений (прикладного ПО).

В Windows 3.1 использовались шесть .ini-файлов для загрузки и управления средой Windows (control.ini, progman.ini, protocol.ini, system.ini, win.ini и winfile.ini).

Файл win.ini был основным местом хранения информации, относящейся к конфигурации ПО этой операционной системы, а также специальной информации для всей системы, добавляемой приложениями. Поскольку каждое приложение вносило изменения в файл win.ini (не принимая во внимание все остальные приложения), этот файл разрастался очень быстро. Это вызывало проблемы, когда размер файла превышал 64 Кб. В операционной системе разрешался рост этого файла сверх 64 Кб (без уведомления пользователя, что превышен этот предел), хотя любая запись, выходящая за границу 64 Кб, игнорировалась. Если приложения добавляли записи в верхние разделы файла win.ini, то информация внизу файла выталкивалась за границу инициализации, и эта информация не реализовалась. Приложения, которым требовались эти потерянные записи инициализации, переставали работать полностью или утрачивали определенные функции. Пытаясь воспрепятствовать этой проблеме, Microsoft рекомендовала разработчикам приложений сохранять информацию приложений в частных .ini-файлах, которые бы относились только к их приложению. Хотя это помогло, большинство разработчиков приложений продолжали размещать большое количество информации в файле win.ini.

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

Файл progman.ini содержал настройки инициализации для Windows Program Manager, и файл winfile.ini содержал настройки инициализации для Windows File Manager. Отсутствие этих файлов не препятствовало работе Windows (в отличие от файлов system.ini и win.ini), но загружалась конфигурация по умолчанию для приложений, которыми они управляли, без каких-либо настроек, внесенных пользователем.

Файл protocol.ini, который впервые появился для версии Windows for Workgroups в Windows 3.1x, содержал информацию инициализации для сетевой работы в Windows.

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

Файл win.ini до сих пор существует в большинстве систем Windows NT/ 2000/ Server 2003, и его роль состоит в поддержке 16-битных приложений.

И последним файлом, который использовался системой Windows 3.1x для конфигурации системы, был файл reg.dat. Это была база данных регистрации Windows 3.1 Registration Database, которая являлась непосредственным предшественником реестра. (Прошло не слишком много времени, и пользователи сократили Registration Database до registry.) Эта база данных с вложенными структурами, начиная от единственного корня ( HKEY_CLASSES_ROOT ), содержала информацию, связанную с расширениями имен файлов, а также поддержку OLE (Object Linking and Embedding) для функции drag-and-drop. В отличие от .ini-файлов, которые являлись простыми текстовыми файлами ASCII, и которые можно было редактировать в любом текстовом редакторе, файл reg.dat был двоичным файлом и поставлялся со своей собственной программой редактирования, Registration Information Editor (Regedit.exe). Этот первый реестр имел некоторые серьезные ограничения в виде единственной иерархической структуры и предельного размера в 64 Кб файла reg.dat.

Большой проблемой реестра Windows 3.1 было то, как он использовался или, скорее, не использовался этой операционной системой. Не было особого смысла в аккуратной поддержке этой базы данных регистрации на уровне текущих изменений. Приложения могли вносить в него записи, а могли и не вносить. В операционную систему не было встроено никаких стандартов, чтобы приложения записывали в реестр те же данные, что и в собственные .ini-файлы или в системные .ini-файлы. Если конфигурация программного обеспечения, .ini-файлы и база данных регистрации имели одинаковую информацию, это часто бывало просто совпадением. Кроме того, методы связи, использовавшиеся для запроса и записи в реестр, были сложны и требовали больших дополнительных затрат ресурсов, что часто замедляло работу компьютера. И, наконец, настроек отдельного пользователя не существовало, поэтому пользователи одного компьютера получали настройки, оставленные последним работавшим пользователем.

Когда Microsoft выпустила первый вариант Windows NT (NT 3.1), реестр стал намного более гибким и мощным. Ограничение в 64 Кб было снято. Иерархическая структура была расширена, включив несколько контейнеров с вложенными уровнями, а код управления реестром был переработан, чтобы поддерживать достаточно высокую производительность. Было реализовано дистанционное администрирование, что упростило жизнь сетевого администратора. Microsoft заставила разработчиков использовать реестр для переменных и значений и даже ее собственные программы стали поддерживать реестр.

Еще одним существенным изменением в выпуске Windows NT 3.1 было появление Regedt32. Этот новый 32-битный редактор реестра выводил каждое поддерево в его собственном окне и содержал новые мощные команды, позволяющие, например, подсоединяться к реестру на удаленном компьютере, а также защищать разделы реестра.

Windows NT 4 и Windows 95 (а позже Windows 98) были выпущены с почти одинаковыми реестрами. В обоих случаях были добавлены два новых поддерева: HKEY_CURRENT_CONFIG и HKEY_DYN_DATA.

Все эти изменения привели нас к реестру Windows Server 2003 (а также Windows 2000), который является темой этой лекции.

Структура реестра

Реестр – это иерархическая база данных, содержащая вложенные контейнеры и данные следующего типа.

• Поддеревья (Subtree). Корни, или основные группы этой иерархии.
• Разделы (Key). Основные контейнеры, находящиеся непосредственно в поддеревьях.
• Подразделы (Subkey). Дочерние подразделы. Подразделы могут содержать вложенные подразделы или записи.
• Записи (Entry). Реальные данные (значения), которые влияют на систему. Записи представлены в правой панели редактора реестра.

Ульи и файлы ульев

Физически реестр – это набор файлов, которые называются ульями. Улей (hive) – это определенная часть реестра (определенный набор разделов, подразделов и параметров), которая представлена файлом на вашем компьютере. Файлы ульев можно просматривать или редактировать только с помощью редактора реестра. Однако их можно копировать, что является способом их резервного копирования вручную. (Большинство программ резервного копирования, включая соответствующую встроенную программу в Windows Server 2003, позволяют выполнять резервное копирование реестра.)

Файлы ульев реестра сохраняются в виде .dat-файлов, и для каждого из этих файлов имеется соответствующий .log-файл, который действует как журнал транзакций для основного .dat-файла. Добавление .log-файла к .dat-файлу используется как средство отказоустойчивости. В случае изменений, когда требуется обновить файл определенного улья, эти изменения сначала вносятся в .log-файл, который действует как файл транзакций. (Если вы знакомы с Microsoft Exchange Server или общим подходом к использованию базы данных/файла транзакций Jet, то здесь используется тот же принцип.)

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

В самом реестре ведется запись для файлов ульев в списке HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Hive. Просматривая этот список, вы увидите пару интересных элементов.

Во-первых, здесь имеется запись для раздела Hardware, но в панели данных нет ни одного файла улья. Дело в том, что раздел Hardware формируется целиком во время загрузки. Файл ntdetect.com собирает информацию, необходимую для заполнения этого раздела, и операционная система не считывает эту информацию из какого-либо файла улья.

Второй интересный момент – это путь к файлу: \Device\HarddiskVolume1\Windows\System32\Config\<имя_файла> (вместо файлов настроек выполнившего вход пользователя, которые находятся в подпапках \Device\HarddiskVolume1\Documents and Settings). Если вы не используете Windows как "цель" для своей установки Windows Server 2003, то происходит подстановка использованного вами имени папки (на протяжении всего этого курса я использую для обозначения этой папки %SystemRoot% ). Этот формат позволяет понять, в какой момент Windows выполняет доступ к этой информации во время загрузки операционной системы. Операционная система не может читать или назначать буквы-обозначения дисков, пока не войдет в процесс запуска, то есть это единственный способ, посредством которого Windows может найти соответствующее местоположение.

В таблице 4.1 показано местоположение файлов ульев (а также их содержимое) на вашем компьютере Windows Server 2003.

Элементы данных реестра

Элементы данных реестра находятся на нижнем уровне иерархии реестра. Они содержат данные, которые определяют поведение разделов и подразделов (хотя не все разделы и подразделы содержат записи данных). Записи представлены в правой панели редактора реестра.

Любая запись содержит три элемента.

• Имя (параметр).
• Тип данных.
• Значение данных.

Имя записи

Имя записи это почти всегда (но не всегда) одно слово, даже если фактически это составное имя. Например, AutoRepeatRate – это имя записи в подразделе Keyboard Response. Во время редактирования реестра вы можете добавлять новые записи и присваивать им имя, однако это имя не должно быть произвольным. Имена должны быть известны операционной системе или приложению, которое использует данную запись, и вы должны знать это имя, прежде чем добавлять запись.

Типы данных записи

Каждая запись имеет тип данных, которые может хранить эта запись. Существуют десять типов данных, но некоторые из них не используются системой Windows Server 2003. В следующих разделах описываются типы данных, которые могут вам встретиться.

REG_DWORD. Это двойное слово – два 16-битных слова, образующих 32-битное значение. Это наиболее распространенный тип данных в реестре, и он используется для разнообразных записей. Вы можете встретить записи с информацией о драйвере устройства, булевыми значениями, такие величины, как количество секунд, которое должно пройти, прежде чем что-то произойдет или не произойдет, и другую информацию.

В редакторе Regedit записи типа REG_DWORD выводятся в шестнадцатеричном формате, но вы можете переходить в десятичный или двоичный формат (в зависимости от вида записи), если хотите выполнить редактирование. Я не могу выполнять в уме преобразование шестнадцатеричных значений в другие системы счисления, поэтому при необходимости изменения какой-либо величины, например, периода тайм-аута, я должен изменить формат представления, чтобы выполнить свою задачу. Если вы можете выполнять такие преобразования в уме, то сможете работать быстрее.

REG_BINARY. Этот тип данных используется в записях с необработанными двоичными данными. "Необработанные" означает, что нет никаких терминаторов, кроме самих двоичных данных. Этот тип данных обычно используется для информации о компонентах оборудования. Эти данные можно выводить и редактировать в двоичном или шестнадцатеричном формате в Regedit.

REG_SZ - это тип данных для текстовых строк фиксированной длины. Большинство записей, где используется этот тип, содержит булевы значения или короткие текстовые строки. Это очень распространенный тип данных, видимо, используемый почти так же часто, как и тип REG_DWORD.

Обозначение SZ означает String/Zero, поскольку в конце строки ставится нулевой байт. Regedit не показывает конечный нуль, поэтому вы можете не помнить об этом (за исключением ситуации, когда вы пишете программу, работающую с реестром, и тогда вы должны учитывать этот конечный байт).

В случае просмотра или редактирования записи этого типа в Regedit открывающееся окно озаглавлено "String Editor" (Редактор строк).

REG_MULTI_SZ. Этот тип данных используется в записях данных, содержащих несколько текстовых строк. Строки разделяются запятыми или пробелами, и запись заканчивается двумя нуль-символами (которые не видны в редакторе реестра). В окне редактирования Regedit видны двоичные данные (хотя вы можете видеть текст в правой части этого окна).

Когда приложения ищут какую-либо запись типа REG_MULTI_SZ, им отправляется вся запись; они не могут запрашивать конкретную строку (что важно знать, если вы программист).

REG_EXPAND_SZ. Этот тип используется, когда в запись включаются одна или несколько переменных, значения которых должны быть подставлены какой-либо службой операционной системы или приложением. Это те же переменные, которые вы используете в пакетных файлах и скриптах (например, %SystemRoot% или %UserName%). Я так и не смог определить, почему сам реестр не может присваивать значение такой переменной и передавать его запрашивающей службе или программе, – ведь реестру известно, где искать эту информацию.

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

REG_LINK. Этот тип данных содержит символическую ссылку между данными и каким-либо значением в реестре. Например, если приложению требуется знать уникальный идентификатор пользователя (для информации о настройках), то оно может искать идентификатор безопасности (security ID) текущего пользователя ( HKEY_CURRENT_USER ).

REG_DWORD_LITTLE_ENDIAN. Этот тип записи аналогичен типу записи REG_DWORD. Он чаще всего используется для хранения чисел. Значение данных – это 32-битное число, в котором наиболее значащий байт выводится на экран как старший (левый) байт. Этот тип записи имеется только в Windows Server 2003, Windows 2000 и Windows 98. Технически он присутствует в Windows NT, но реестр Windows NT автоматически преобразует данные, записанные в REG_DWORD_LITTLE_ENDIAN, в стандартный тип REG_DWORD.

REG_DWORD_BIG_ENDIAN. Этот тип записи противоположен типу REG_DWORD_LITTLE_ENDIAN. Наиболее значащий байт выводится на экран как младший (правый) байт, и это используется платформами, где байты следуют именно в этом порядке (PowerPC и Alpha). Поскольку Windows Server 2003 не поддерживает эти платформы, любые оставшиеся элементы реестра этого типа игнорируются.