Запускайте Regedt32.exe, а для пошуку — Regedit.exe і відкривайте розділ за розділом. Подорож у безоднях реєстру дуже цікава і... дуже небезпечна. Удосталь поекспериментував з ним, навчилися відновлювати систему навіть після її повного руйнування.
Для повноти опису визначимо фізичне положення файлів реєстру. Як Ви розумієте, реєстр не існує десь у просторі, а фізично розташований на диску, але не одним великим файлом , а розбитий на декілька частин:
Галузь Файл
HKEY_LOCAL_
MACHINENSYSTEM
HKEY_LOCAL_
MACHINEXSAM
HKEY LOCAL
MACHINEXSECURITY
HKEY_LOCAL_
MACHINEXSOFTWARE
HKEYJJSERSVDEFAULT
HKEY_USERS\
<UserSID>
%SystemRoot%\system32\config\SYSTEM %SystemRoot%\system32\config\SAM
%SystemRoot%\systera32\config\
SECURITY
%SystemRoot%\system32\config\
SOFTWARE
%SystemRoot%\proffles\Default
User\ntuser.dat
%SystemRoot%\profiles\%user%\ntuser.dat
Інформацію про відповідність галузей реєстру і файлів можна одержати з розділу: HKEY_LOCAL_MACHINE\System\CunentControlSet\hiveUst. Дуже важлива для процедури завантаження системи галузь HKEY_LOCAL_MACHINE\SYSTEM. Вона містить сукупність розділів реєстру — control set — необхідних для процедури завантаження. HKEY_LOCAL_MACHINE\SYSTEM\Clone — копія control set, створена ядром на етапі ініціалізації.
HKEY_LOCAL_MACHINE\SYSTEM\ControlSetOO1 — основна сукупність control set, що використовуна за замовчуванням при завантаженні Windows NT. HKEY_LOCAL_MACHINE\SYSTEM\ControlSet002 — резервна копія control set, що використовується при невдалому завантаженні Windows NT. HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet — це control set з якого завантажилася дана копія Windows NT. Звичайно це символічне посилання HaHKEY_LOCAL_MACHINE\SYSTEM\ConttolSet001. Тепер розглянемо склад control set докладніше: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control — цей розділ містить підрозділи, необхідні для завантаження WindowsNT. Наведено деякі з них:
...\ServiceGroupOrder — описує послідовність завантаження груп служб. Необхідний щоб служби мережних протоколів завантажувалися після того, як завантажилися драйвера мережної плати.
\BootVerlficationProgramm — це значення визначає нестандартну програму, що підтверджує вдале завантаження. Як правило, це програма від виробника апаратури, що перевіряє параметри нестандартного устаткування.
...\ComputerName — містить два параметри: ComputerName (ім'я, яке буде присвоєно комп'ютеру на етапі завантаження) і ActiveComputerName (активне ім'я комп'ютера, що при завантаженні заміняється на ComputerName).
..\hivelist — ключ, що вказує фізичне розташування файлів реєстру.
...\Keyboard Layout — містить ключ DOSKeybCodes, у якому описані всі доступні системі коди клавіатурних розкладок.
...\Keyboard Layouts — описує DLL-файли клавіатурних розкладок.
...ALSA— описує доступні пакети ідентифікації. Ці значення варто змінювати тільки у випадку системних помилок!
...\Prlnt — інформація про встановлені принтери, їх параметри і порти друку (print/port monitors).
...\PriorityControl — встановлення пріоритетів процесорного часу. Для зміни цього підрозділу краще скористатися системними параметрами з Control Panel (Панель керування). ...\Session Manager — містить кілька важливих значень і розділів:
• BootExecute — визначає програми, що виконуються на етапі завантаження ядра. Наприклад, chkdsk.
• DOSDevices — визначає відповідність DOS-пристроїв (PRN, AUX, UNC і т.п.) пристроям Windows NT.
• Environment — визначає системні змінні оточення.
• FileRenameOperation — визначає які файли будуть перейменовані на етапі завантаження. Часто застосовується програма установки, у випадку якщо потрібно «змінити» якийсь з компонентів, що використовувався .
• Subsystems — визначає «підсистеми», встановлені в Windows NT, наприклад, Posix чи OS/2.
Розглянемо основну гілку реєстру, що описує усі драйвера пристроїв, драйвера файлових систем і системні служби Windows NT. Кожен розділ визначає чи службу драйвер і його (її) ім'я. HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\<HMH чи служби драйвера>
Даний параметр визначає тип служби (драйвера).
Параметр: Турі Тип даних: REG_DWORD
Можливі значення: 0x1—драйвер ядра;
0x2 — драйвер файлової системи;
0x4 — пристрою (у цьому випадку підгілки містять опис елементів апаратури);
0x10 — служба (неподільні процеси);
0x20 — служба (подільні процеси).
Даний параметр визначає, на якому етапі буде запускатися дана служба (драйвер). Параметр: Start
Тип даних: REG_DWORD
Можливі значення: 0x0 — на етапі завантаження ядра (boot);
0x1—на етапі ініціалізації ядра (start);
0x2 — автоматично, на етапі старту Win32 підсистеми (automatic);
0x3 — може бути завантажена при запиті чи користувача іншої служби (manual);
0x4 — завантаження заборонене (disabled).
Даний параметр визначає реакцію системи, якщо драйвер чи служба, почала завантажуватися, не змогли цього зробити чи неправильно иніціалізувались.
Параметр: ErrorControl Тип даних: REG_DWORD
Можливі значення:
0 х 1 — нормальний режим: помилка ігнорується і продовжується завантаження;
0x2 — небезпечний режим: якщо відбулася помилка і система завантажиться в
нормальному режимі, то процес завантаження припиняється, і ви
полняется перезавантаження в режимі LastKnownGood. Якщо помилка виникла в режимі завантаження LastKnownGood, то помилка ігнорується
і продовжується процес завантаження;
0x3 — критичний режим: якщо відбулася помилка і система завантажується в нормальному режимі, то процес завантаження припиняєся, і виконується перезавантаження в режимі LastKnownGood. Якщо помилка відбулася в режимі завантаження LastKnownGood, то процес завантаження припиняється, і видається повідомлення про помилку.
Даний параметр визначає групу, в яку входить конкретний драйвер (служба).
Параметр: Group Тип даних: REG_SZ
Даний параметр визначає послідовність завантаження в середині групи.
Параметр: Tag Тип даних: REG_DWORD,
Даний параметр визначає програму, що відіграє роль чи служби драйвера.
Параметр: ImagePath
Тип даних: REG_SZ
Даний параметр визначає ім'я об'єкта завантаження. Якщо це служба, то ObjeclName визначає ім'я користувача.
Утилити операційної системи
Системні утиліти надають набір загальних послуг для плавних підсистем операційної системи і практично коли не використовуються останнім користувачем. Часто утиліти наділяються спеціальними привілеями, щоб збільшити їх ефективність і продуктивність. Звичайно, існує компроміс між виконанням добре визначених модулів утиліт і безпекою і цілісністю системи.
Цей розділ здивує вас трохи еклектичним підходом. Порозумівається це тим, що утиліти, здається, ніколи не складають інтегровану підсистему. Проектувальник звичайно «запихає» їх туди, куди вони більше всього підходять. В дійсності те, що є утилітою в одній операційної системі, може так само бути і в іншій. З іншого боку, хоча модулі утиліт не зібрані в одному місці, вони все-таки служать інтегруючим чи єднальним агентом операційної системи, оскільки всі інші модулі виявляються залежними від них.
Концепція утиліт
Вступ роздягнув стосувалося того, що ми вважаємо природою системних утиліт. Корисно прояснити цей підхід, у співвідношенні його з іншими поняттями, збереженими від систем другого і третього поколінь. Класично утиліта була системно-незалежною програмою, що завантажується користувачем для виконання специфічних функцій, Наприклад, у багатьох системах для міні-ЄВМ діагностичні програми усе ще розглядаються як системно-незалежні утиліти. Чому? Тому, що вони виконують функцію, що користувач звичайно воліє не робити сам. В міру розвитку операційної системи утиліти ставали тією «усякою всячиною», що виробник надавав безкоштовно разом з обчислювальною системою. Надзвичайно популярною була утиліта сортування/ злиття— окрема програма, запускається окремо користувачем для спеціально підготовленого файлу. Настільки ж популярною була програма, називана текстовим редактором, що давала користувачу можливість вводити і змінювати вихідні тексти програмних модулів. В інших варіантах уключалися такі речі, як засобу розробки програм, засоби керування файлами і «купа» інших додаткових модулів, що розширювали можливості «голої» операційної системи.
У загальному утилітою вважалася будь-яка загальцільова програма, що виконує розповсюджені функцій. Визначальні слова — «загальцільова» і «розповсюджені». Недалекий проектувальник системи часто інтерпретував слово «утиліти» як «те, що раніш не спало на думку». Не було нічого чаруючого чи зухвалого інтересу у проектуванні і написань утиліт; насправді вони часто розглядалися як стомлююча рутинна робота, що відволікає від задачі побудови складних і «тонких» програм, що складають ядро ОС.
Наша точка зору на утиліти відрізняється від класичної. Для нас утиліти —це єднальний компонент, «клей», що з'єднує базисні підсистеми операційної системи в єдине ціле. Такі засоби, як текстовий редактор і сортування, — це усього лише програми, часто неважливо ким доставлені: чи користувачем виробником, тому що вони виповнюються однаково. Тоді, який же наш підхід до концепції утиліт? І, що більш важливо, які базові утиліти повинні бути включені в ядро будь-якої операційної системи. Цим питанням присвячена даний розділ.
Утиліти : розширення фізичної машини.
Визначальні слова, що ми підкреслювали при визначенні утиліти, були «загальцільова» і «розповсюджена». Задумаємся на хвилину над цими словами: «загальцільова» означає корисність у різних ситуаціях; «розповсюджена» включає характеристики, що часто й усіма використовуються.
Як ці концепції співвідносяться із системою команд ЕОМ? З центральним процесором? У загальному і цілому система команд
ЦП складається з таких операцій, що вважаються найбільш корисними при обчисленнях. Стандартний набір команд мало розрізняється для різних ЕОМ. Крім цього, більшість виробників ЕОМ додає для своєї архітектури ЕОМ ряд спеціальних команд, що дозволяє швидше виконувати визначені типи обчислень.
Схожим способом реалізації майже кожної операційної системи заснована на точно визначеній підмножині операцій. Можна думати про ці операції як про розширення фізичної архітектури ЕОМ. У загальному дешевше реалізувати ці операцій програмно, чим апаратно, особливо якщо вони потребують для виконання операнди різної чи довжини сильно відрізняються для визначених додатків формату. У будь-якому випадку майже кожен модуль операційної системи залежить від цих розширених команд — особливої групи. Таким чином, модулі нижнього рівня, що служать для багатьох цілей і використовувана багатьма підсистемами, суть утиліти. Вони в дійсності є розширеннями фізичної архітектури ЕОМ, щоб зробити її більш придатною для реалізації операційної системи.