|
|
Регистрация классов на уровне пользователяОбзор реестра Реестр пополнялся из целого ряда управляющих файлов и баз данных, которые имелись в предыдущих версиях 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 заставила разработчиков использовать реестр для переменных и значений и даже ее собственные программы стали поддерживать реестр. На самом деле .ini-файлы продолжают играть определенную роль в самых новых версиях Windows. Запустите поиск .ini-файлов на вашем компьютере Windows Server 2003, и вы найдете очень много таких .ini-файлов. После задания ролей компьютера, но перед установкой каких-либо приложений поиск .ini-файлов на моем компьютере Windows Server 2003 дал 228 .ini-файлов. Правила Microsoft для разработчиков включают указание, что любая программа должна записывать свои установочные настройки в раздел HKEY_LOCAL_MACHINE\Software\Имя_поставщика и все пользовательские настройки в HKEY_CURRENT_USER\Software\Имя_поставщика. Слишком многие компании, разрабатывающие ПО, игнорируют это правило или не выполняют его должным образом. Некоторые приложения создают подразделы, но не заполняют их данными. Некоторые приложения пишут данные реестра, которые очевидным образом нарушают это правило, например, регистрируя информацию командной строки, которая указывает на .ini-файл вместо исполняемого файла программы. Еще одним существенным изменением в выпуске Windows NT 3.1 было появление Regedt32. Этот новый 32-битный редактор реестра выводил каждое поддерево в его собственном окне и содержал новые мощные команды, позволяющие, например, подсоединяться к реестру на удаленном компьютере, а также защищать разделы реестра. Windows NT 4 и Windows 95 (а позже Windows 98) были выпущены с почти одинаковыми реестрами. В обоих случаях были добавлены два новых поддерева: HKEY_CURRENT_CONFIG и HKEY_DYN_DATA. Все эти изменения привели нас к реестру Windows Server 2003 (а также Windows 2000), который является темой этой лекции. Структура реестра Реестр – это иерархическая база данных, содержащая вложенные контейнеры и данные следующего типа.
Примечание. Обозначение HKEY происходит от HandleToKey (указатель к разделу). Ульи и файлы ульев Физически реестр – это набор файлов, которые называются ульями. Улей (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 не поддерживает эти платформы, любые оставшиеся элементы реестра этого типа игнорируются. HKEY_CLASSES_ROOT HKEY_CLASSES_ROOT заполняется всеми видами базовой информации. У вас редко будет повод работать интерактивно в этом поддереве; это набор "строительных блоков", с помощью которых могут работать операционная система и приложения. В этом поддереве существуют два типа данных.
Регистрация классов на уровне пользователя Наиболее интересными в этом поддереве являются изменения, появившиеся в Windows 2000. Это поддерево является алиасом (псевдонимом), и его источником в Windows NT было поддерево HKEY_LOCAL_MACHINE\Software\Classes. В Windows Server 2003/2000 это поддерево остается алиасом, но его данные извлекаются из двух источников.
Последний из этих разделов реестра не существовал в его нынешней конфигурации до Windows 2000. (Хотя такой раздел имеется в Windows 98, его содержимое отличается от одноименного раздела в Windows Server 2003/2000. В Windows 98 этот раздел содержит идентификаторы класса [ CLSID ] для используемых по умолчанию значков рабочего стола ОС.) Этот новый источник на уровне пользователя для HKEY_CLASSES_ROOT в Microsoft назвали регистрацией классов на уровне пользователя (per-user class registration). Это означает, что на компьютерах с несколькими пользователями может содержаться различная информация о классах, которая регистрируется при установке ПО каждым конкретным пользователем. Информация на уровне отдельного пользователя может включать любое количество изменений в регистрации классов, что приводит к созданию нескольких наборов уникальных записей для ПО, которое устанавливается на данном компьютере. Регистрация классов на уровне пользователя полезна для перемещающихся (блуждающих) пользователей (на многих предприятиях разделяемое использование компьютеров происходит реже, чем их использование перемещающимися пользователями). Независимо от компьютера, на котором выполняет вход пользователь, все идентификаторы классов, соответствия для типов файлов и другие связи с программным обеспечением из реестра не изменяются, поскольку информация о регистрации классов перемещается вместе с данным пользователем. Однако это средство используется, только если вы используете возможности IntelliMirror для создания профилей перемещающихся пользователей, поскольку операционная система загружает информацию регистрации классов после загрузки базового профиля пользователя, используя расширения IntelliMirror (информация регистрации классов записывается в локальную часть профиля во время процесса входа). Вы не можете выполнять запись в реестр для использования регистрации классов на уровне пользователя; это задача программирования. Инструкции и средства для записи в разделы на уровне пользователей содержатся в комплектах разработки для программистов. Данные HKEY_CLASSES_ROOT Элементы данных в поддереве HKEY_CLASSES_ROOT снабжают операционную систему информацией об устанавливаемых объектах. Просматривая это поддерево, вы увидите два набора разделов, организованных в алфавитном порядке. Первый набор разделов, содержащий все возможные расширения имен файлов от * до z*. Второй набор разделов – это идентификаторы программ и объектов. Соответствия для типов файлов. Хотя термин "соответствия для типов файлов" (file associations) использовался еще в Windows 3.1, современная реализация поддерева HKEY_CLASSES_ROOT стала намного больше как по размерам, так и функциям. Подразделы, которые имеются для любого конкретного расширения имен файлов, содержат информацию, которая используется для процессов COM, VB, автоматизации и сценарных процессов. В панели данных для раздела расширения обычно указывается тип файлов, соответствующий данному расширению имен. например, раздел .avi содержит элемент данных типа REG_SZ с именем Content Type и значением video/avi.
Для зарегистрированных типов файлов имеются подразделы, содержащие информацию, которая используется системой при работе с этими типами файлов. Например, подраздел с именем ShellNew указывает операционной системе, как создать новый экземпляр файла этого типа. Некоторые разделы для расширений имеют подразделы, связывающие данное расширение с одной или несколькими программами (и каждый из этих подразделов имеет подраздел ShellNew). Например, когда вы устанавливаете операционную систему, расширение .doc автоматически регистрируется для WordPad.exe. Если выбрать подраздел .doc в HKEY_CLASSES_ROOT, то появится элемент данных Default со значением WordPad.exe.Document.1. Если вы устанавливаете Microsoft Office, то в правой панели появится второй элемент данных с именем Content Type и значением application/msword. Дело в том, что процесс установки для Windows не перезаписывает соответствие для WordPad; он сам добавляет второе соответствие. Не все программы установки действуют таким образом, и вы можете встретить случаи, когда при установке приложения происходит запись поверх предыдущих соответствий для расширений имен файлов. Если вам нужно изменить соответствие для расширений имен файлов, не используйте реестр. Вместо этого используйте вкладку File Types (Типы файлов) диалогового окна Folder Options (Свойства папки), которое можно вызвать из панели управления или из меню Tools (Сервис) для системных папок. Вы можете добавлять соответствия, если хотите ассоциировать несколько программ с одним расширением, или можете изменить соответствие с одной программы на другую.
Идентификаторы объектов. Второй набор разделов в HKEY_CLASSES_ROOT – это в основном идентификаторы программ и объектов вместе с некоторыми родительскими разделами, которые поддерживают другие классы информации (например, CLSID ). Почти все эти разделы имеют подразделы, а количество и тип подразделов зависит от объекта и типа информации об этом объекте, которая требуется операционной системе. Для регистрируемых типов файлов часто используются один или несколько следующих подразделов.
Вы можете видеть действие данных из подраздела Shell в окне Windows Explorer или My Computer. Если щелкнуть правой кнопкой на файле с зарегистрированным расширением и выбрать пункт Open (Открыть), то система обратится к подразделу \Shell\Open\Command и выполнит команду, которая находится в этом элементе данных. Если выбрать пункт Print, то система использует команду, которая находится в подразделе \Shell\Print\Command. HKEY_CURRENT_USER HKEY_CURRENT_USER содержит профиль для текущего выполнившего вход пользователя. Это алиас для HKEY_USERS\<идентификатор безопасности выполнившего вход пользователя>. Это поддерево на самом деле не содержит никаких данных; в нем хранится только указатель на содержимое реального поддерева и выводится эта информация. Однако важно знать, что изменения, внесенные в содержимое одного из поддеревьев, приводят к изменению обоих поддеревьев. Это средство экономии времени для операционной системы и приложений, поскольку они выполняют поиск настроек пользователя, прежде чем выполнять задачи. Без поддерева-алиаса HKEY_CURRENT_USER приходилось бы направлять поиск к нужным разделам SID (идентификаторов безопасности) в HKEY_USERS, чтобы обеспечить использование подходящих настроек. Для этого требовался бы предварительный поиск, чтобы определить SID текущего пользователя. При входе пользователя HKEY_CURRENT_USER создается заново с использованием данных, которые составляют профиль выполняющего вход пользователя. Если это первый вход данного пользователя, то никакого профиля еще нет, и операционная система загружает настройки профиля Default User. При завершении сеанса этого нового пользователя его профиль сохраняется под именем этого пользователя. Сохраняются любые изменения, внесенные в конфигурацию этим пользователем. Профили пользователей Профили пользователей содержат настройки каждого пользователя, включая настройки операционной системы, настройки приложений и политики. Эти настройки содержатся в файле NTUSER.DAT, который содержится в подпапке каждого пользователя ( %SystemDrive%\Documents and Settings\<Имя-текущего-пользователя> ). Процесс создания профиля для каждого пользователя начинается с загрузки копии профиля Default User. Файл NTUSER.DAT в %SystemDrive%\Documents and Settings\Default User содержит настройки конфигурации для пользователя по умолчанию, которые хранятся в реестре в HKEY_USERS\.DEFAULT. Для профиля каждого пользователя используются также общие программные группы, которые находятся в %SystemDrive%\Documents and Settings\All Users. Соглашения по созданию папок профилей пользователей (включая профиль Default User и профиль All Users) в Windows Server 2003 отличаются от соглашений, используемых в Windows NT 4.0.
Примечание. Путь к профилю пользователя обычно представлен переменной %ProfilePath%, а имя папки для пользователя создается из идентификатора этого пользователя. Файл NTUSER.DAT содержит включаемую в реестр часть профиля для выполнившего вход пользователя (обычно в HKEY_CURRENT_USER ), и она загружается в реестр во время входа пользователя. В соответствующей подпапке профиля содержатся подпапки с дополнительными настройками.
Примечание. В дополнение к локальным профилям в Windows Server 2003, как и в Windows 2000/NT, поддерживаются два дополнительных типа профилей: перемещаемые (roaming) и обязательные (mandatory). Более подробные сведения о профилях пользователей см. в лекции 12 курса "Внедрение, управление и поддержка сетевой инфраструктуры MS Windows Server 2003". Данные HKEY_CURRENT_USER Настройки среды текущего выполнившего вход пользователя содержатся во вложенной иерархии подразделов. Почти все настройки конфигурации, которые находятся здесь, можно изменять в графическом интерфейсе, а не интерактивно в самом реестре.
AppEvents. Традиционно, начиная с Windows 9x, Microsoft выделяет целиком отдельный раздел реестра, чтобы включать в него звуки для событий. Этот раздел содержит два подраздела.
Пользователи связывают звуковые файлы с событиями в апплете Панели управления Sounds And Audio Devices (Звук и аудиоустройства). Кроме того, схемы, звуковые файлы и описания событий добавляют некоторые приложения (например, небольшая мелодия, обозначающая поступление новой почты в Eudora). Console. Раздел Console содержит настройки для подсистемы консоли Windows Server 2003, под управлением которой работают все приложения, выполняемые в текстовом режиме (включая Command Processor, который используется вами для работы в командной строке). Информацию по заданию настроек конфигурации для окна командной строки см. в лекции 7. Control Panel. Этот раздел и его подразделы содержат настройки, которые управляют внешним видом рабочего стола, вместе с определяемыми пользователем опциями для многих апплетов, вызываемых из панели управления. При раскрытии этого раздела появляются имена подразделов, соответствующие некоторым апплетам, вместе с рядом других категорий настроек. Значения этих элементов данных изменяются, когда пользователи вносят изменения в опции апплетов панели управления. Большинство этих опций действуют сразу, без необходимости перезагрузки операционной системы. Не поддавайтесь мнению, что поскольку эти настройки обычно влияют только на пользовательский интерфейс, они "безвредны". Администраторы, которые верят этому и предоставляют пользователям полную свободу в изменении настроек по умолчанию, часто раскаиваются в своем решении. Некоторые из настроек раздела Control Panel и его подразделов оказывают большее влияние, чем это кажется. Например, если неопытный пользователь существенно изменит видеонастройки, это может привести к тому, что компьютер не сможет загружаться обычным образом. Защищенная паролем экранная заставка (Screen Saver) может быть важна для клиентской машины, на экране которой могут выводиться важные данные, и если кого-то раздражает это средство, он может отключить его и уйти на обед, оставив записи платежной ведомости на экране монитора. А тут еще всякие истории о пользователях, которые защищают паролем экранную заставку, не записав или не запомнив пароль, что вынуждает их обращаться в службу поддержки. В Windows Server 2003 имеется обширный набор групповых политик, управляющих доступом к апплетам панели управления (конкретную информацию см. в лекции 13 курса "Внедрение, управление и поддержка сетевой инфраструктуры MS Windows Server 2003"). Environment. Этот раздел содержит записи данных, представляющие значения переменных среды для выполнившего вход пользователя.
Включены переменные среды Temp и Tmp, поскольку приложения могут использовать любую из этих переменных. Вместо использования редактора реестра для работы с этими настройками вы можете просматривать и изменять их в диалоговом окне System Properties (щелкните правой кнопкой на My Computer и выберите пункт Properties). Во вкладке Advanced (Дополнительно) щелкните на кнопке Environment Variables (Переменные среды), чтобы увидеть информацию, аналогичную рисунку 4.1.
Если вносятся изменения в настройки среды (через реестр или в диалоговом окне System Properties), то новые настройки начинают действовать только при следующем входе пользователя. Внимание. Элементы данных в разделе Environment должны иметь тип данных REG_SZ. Если ввести элемент другого типа или изменить существующий тип данных, то система не будет заменять переменную ее значением. Identities. Это раздел, отсутствовавший в предыдущих версиях Windows, не документирован Microsoft. Это, видимо, какой-либо идентификатор для текущего пользователя, но не основной идентификатор. В HKEY_USERS каждый пользователь имеет уникальный идентификатор. Раздел уникального идентификатора текущего пользователя имеет подраздел, значение которого совпадает со значением этого элемента данных. Keyboard Layout. В этом разделе хранится информация об установленных раскладках клавиатуры, включая настройки устройств и драйверов. Кроме того, если пользователь добавляет другие клавиатуры (файлы языков клавиатур), то информация об этих клавиатурах содержится в подразделах. Изменения по устройствам и драйверам следует вносить в апплете панели управления Keyboard. Дополнительные клавиатуры добавляются в апплете Regional and Language Options (Региональные стандарты и язык). Network. Этот раздел существует, только если текущий пользователь имеет отображенные сетевые диски. Сам этот раздел является родительским разделом и не содержит существенных данных. Для каждого постоянного отображаемого диска имеется дочерний подраздел, именем которого является буква-обозначение отображаемого сетевого диска.
Если пользователь отображает какой-либо диск и не выбирает опцию Reconnect At Logon (Снова подсоединяться при входе), то отображаемый диск не записывается в реестр. (Все текущие отображаемые диски независимо от их постоянства имеют значки в My Computer.) Примечание. По умолчанию состояние опции Reconnect At Logon определяется тем, что было выбрано на тот момент, когда пользователь отображал диск. Каждый подраздел содержит информацию о соединении.
Printers. Этот подраздел содержит информацию о принтерах, установленных на данном компьютере, включая заданные пользователем параметры конфигурации. Session Information. Этот подраздел, видимо, содержит информацию о приложениях, используемых в текущем сеансе (единственный элемент данных в моем реестре – это ProgramCount, значение которого равно количеству открытых на данный момент программ). Я использовал слово "видимо", поскольку этот подраздел не документирован. В группе по документированию реестра Windows мне сообщили, что они не документировали этот раздел, но планируют сделать это в будущей версии Windows. 
Не нашли, что искали? Воспользуйтесь поиском по сайту: ©2015 - 2024 stydopedia.ru Все материалы защищены законодательством РФ.
|
