Для чого потрібен реєстр Windows?

Оскільки я налагоджував проблеми в com, пліч-о-пліч, вирішуючи dll пекло, все, ненавиджу реєстр Windows з пристрастю, мені було цікаво, для чого це потрібно.

Я ніколи не почував себе змушеним прочитати цілу книгу про кращі практики реєстру, а потім просто "отримати це".

Однак я використовував Linux та Mac OS, і дивлюся на способи встановлення декількох версій Python та його бібліотек на одному * nix-комп'ютері.

Оскільки реєстр має дещо вільний (хоч і потворний) формат і використовується для будь-яких цілей, я ніколи не розумів, яку істотну проблему намагається вирішити.

Наприклад, Microsoft не хоче, щоб у вас були встановлені дві різні версії MS Office. Вони використовують реєстр для забезпечення цього під час встановлення. На мою думку, це обмеження є штучним. Якби вони по-справжньому дбали про те, щоб дозволити іншу поведінку, вони могли відповідно скоригувати свою архітектуру.

У Mac OS ви можете встановлювати та видаляти програми, просто опустивши їх у певну папку.

Тому,

А) Яку істотну проблему намагається вирішити? Б) Як інші операційні системи вирішують це?

Більшість інших відповідей більш-менш коректні, але (поряд із запитанням) вони начебто не вникають у суть.

Реєстр - це ієрархічний менеджер баз даних - нічого більше і нічого менше.

"Несправності", які ви віднесете до реєстру, насправді не залежать від самого реєстру. Це просто рішення, які приймають різні постачальники щодо таких речей, як встановлення своїх програм - якщо ви зберігаєте інформацію якось іншим способом / формою / контейнером, ті самі проблеми можуть залишитися.

Враховуючи філософію "все є файлом" Unix, не дивно, що Unix (і подібні, такі як Linux і MacOS) системи зберігають інформацію як окремі файли у файловій системі. Це не так вже й різно, як багато людей можуть одразу повірити, оскільки файлова система Unix сама по собі є ієрархічною базою даних (або, можливо, мережевою базою даних, якщо враховувати символічні посилання). Очевидна різниця полягає в тому, що до реєстру можна отримати доступ через окремий API, де зберігання даних конфігурації у файлах дозволяє отримувати доступ до цих файлів, редагувати їх тощо за допомогою того ж API (та інструментів), що і будь-які інші файли.

Це сховище налаштувань - централізоване і дещо стандартизоване місце для налаштувань, налаштувань, легких профілів .

Це стає легше зрозуміти, коли ви дивитесь на велику картину для всіх речей, які ОС має зберігати для своїх користувачів та додатків:

Windows

• Репозиторій налаштувань
  • Система: Реєстр Windows HKEY_LOCAL_MACHINEі, зокрема, значна частина його є\SOFTWARE\Microsoft
  • Стороння система: Реєстр WindowsHKEY_LOCAL_MACHINE
  • Система, орієнтована на користувачів: Реєстр Windows HKEY_USERS,[user]\SOFTWARE\Microsoft
  • Сторонні користувачі: Реєстр WindowsHKEY_USERS\[user]\SOFTWARE
• Файли програм, які користувач не повинен бачити C:\Users\[User]\AppData в прихованих папках
• Файли програм, які користувач може захотіти, C:\Users\[User]\ у не прихованих папках, створених додатком

Mac OS X

• Репозиторій налаштувань
  • Система та сторона: /Library/Preferences у com.apple...plistфайлах
  • Сторонні системи: /Library/Preferences у plistфайлах сторонніх розробників
  • Система, орієнтована на користувача:, /Users/[user]/Library/Preferences як і вище
  • Сторонній користувач: /Users/[user]/Library/Preferences як і вище
• Загальносистемні файли програм, які користувач не повинен бачити /Library/Application Support
• Файли програм, які користувач не повинен бачити /Users/[user]/Library/Application Support
• Файли програм, які користувач може захотіти /Users/[user]/ в не прихованих папках

По суті, реєстр ідентичний папкам Mac OS X /Library/Preferences , і не набагато більше чи менше.

Той факт, що Mac OS має майже однакову відповідність для організаційних груп системних та прикладних даних, свідчить про те, що реєстр Windows - це цілком виправдана система, яка є просто іншим способом робити

Характер реєстру, що не належить до файлових систем, ускладнює резервне копіювання, відновлення або переміщення його частин, залишаючи інші, тому я віддаю перевагу системі Mac, але мета майже однакова.

Обидві ОС мають програми, які вирішують порушувати ці структури в різній мірі, як правило, через узурпування деякого глобального контексту для створення файлів або папок, які насправді там не належать. Деякі програми фактично створюють папки прямо C:\або /без запитань. Це насправді зводить мене з розуму!

^{До речі, хоча природа перетягування (більшості) додатків Mac OS геніальна, у вас є схожа проблема з різними версіями поряд, хоча ви, мабуть, не помічаєте - оскільки ваші налаштування не зберігаються в .appсамій, але в файлі Application Supportабо Preferences, кожна версія додатка буде по- , як і раніше використовувати одні і ті ж параметри і впливають один на одного, якщо нова версія явно не вирішує використовувати папку під іншим ім'ям ( IntelliJIDEA70, IntelliJIDEA81і т.д.)}

Я ніколи не розумів, яку істотну проблему намагається вирішити.

До реєстру Windows використовували файли .INI. У публікації щоденника Чому файли INI застаріли на користь реєстру? Реймонд Чен перераховує проблеми, які існували з файлами .INI, які намагалися вирішити. Він також перераховує проблеми, якими файли конфігурації XML мають старі файли .ini. Напевно, на це варто звернути увагу, тому що саме сьогодні використовується багато програм.

... маятник повернувся до файлів конфігурації тексту, але цього разу вони XML. Це знову відкриває багато проблем, які мали файли INI, але ви маєте головну перевагу, яку ніхто не записує у файли конфігурації XML; вони читають лише з них. Файли конфігурації XML не використовуються для зберігання налаштувань користувача; вони просто містять інформацію про саму програму. Давайте розглянемо ці питання ще раз.

• Захист файлів XML недостатньо деталізований. Але оскільки файл конфігурації XML є лише для читання, основне заперечення проходить убік. (Але якщо ви хочете, щоб тільки адміністратори мали дозвіл на читання певних частин XML, тоді у вас виникли проблеми.)
• Оскільки файли конфігурації XML доступні лише для читання, вам не доведеться турбуватися про кілька записувачів.
• Файли конфігурації XML можуть зазнати відмови в обслуговуванні. Ви все одно можете відкрити їх виключно та заблокувати інші процеси.
• XML-файли містять лише рядки. Якщо ви хочете зберігати двійкові дані, вам доведеться їх якось кодувати.
• Розбір файлу XML порівняно повільний. Але оскільки вони доступні лише для читання, ви можете безпечно кешувати проаналізований результат, тому вам потрібно розібратися лише один раз.
• Програми аналізують XML-файли вручну, але формат XML уже заблокований, тому ви не можете його розширити, навіть якщо цього хочете. Сподіваємось, що ці програми використовують стандартний XML-аналізатор замість того, щоб прокручувати свій власний, але я не здивуюсь, якби люди написали власний спеціальний аналізатор XML, який задавлюється, скажімо, інструкціями з обробки або рядками довжиною більше 70 символів.
• XML-файли не мають обмеження розміру.
• Файли XML не мають місця за замовчуванням.

Все це передбачає, що програма насправді ніколи не записує у свої конфігураційні файли, про що я не згоден, але це може зробити гірше не кращим.

Моя теорія є рушійною силою нічого з перерахованого. Швидше, це був антипіратський захід. У дні перед реєстрацією ви могли просто скопіювати цілу програму з однієї машини на іншу. Знайдіть .DLL, і вам було добре. Реєстр робить це СУГО складніше.

Дуже мало, що реєстр виконує, я думаю, не було б краще обслуговувати один файл конфігурації за призначенням.

(2014) Щоб трохи розширити свої міркування тут: я бачу реєстр як об'єкт бога. Ми всі знаємо, що це антипатерн.

Моє чітке розуміння полягає в тому, що реєстр був розроблений як своєрідне сховище налаштувань, яке переповнює файли .ini, які раніше використовувалися.

(Примітка, грубе розуміння, тому це може бути неправильним).

А) Я згоден з відповіддю Тіма.

B) Інші операційні системи використовують інші методи збереження налаштувань програми, наприклад, Unix зазвичай розміщує файли в / etc (глобальних файлах) та в папці користувача у різних прихованих папках (налаштуваннях користувачів). Тому всі вони використовують якусь форму реєстру, за винятком того, що в деяких випадках вона поширюється.

Як я розумію (не обов'язково це насолоджується)

А) Надати "централізоване місце", де будь-яка програма може зберігати інформацію про її встановлення чи налаштування. Цю інформацію потім програми можуть використовувати будь-які рішення. Настроювання, антипіратство тощо.

Вся ця інформація, що перебуває в цій структурі, захищає її, подумайте про те, як тварини стикаються разом, більша безпека в чисельності. Якщо кожен біт інформації був власним ini-файлом, то якийсь користувач може потенційно видалити його за примхою. Вони все ще можуть це зробити, потрапляючи в реєстр, але багато хто розглядає це як певну чорну скриньку і не посягає на неї, боячись зламати свою систему.

B) Mac OS використовує окремі файли, подібно до вікон файлів ini, які використовувались до появи реєстру.

Очевидною метою Реєстру є діяти як єдине сховище для всіх даних конфігурації та налаштування та усунути залежність від файлів конфігурації.

В інших операційних системах modus operandi полягає у збереженні інформації, що стосується додатків (наприклад, файлів конфігурації), у прихованих специфічних каталогах додатків у домашньому каталозі користувачів. (Наприклад, гра Aquaria зберігає інформацію про конфігурацію в $HOME/.Aquaria.) Файли глобальних налаштувань зберігаються в /etc/.

Маки роблять своє: plistфайли, що стосуються додатків , зберігаються (я вважаю) в Libraryкаталозі користувача або системи .

Питання полягає не в філософії реєстру, а в його дизайні. Реєстр використовується ОС для пошуку важливої ​​інформації щодо завантажуваної програми. Хоча замість завантаження інформації як при необхідності, вона завантажує її все під час завантаження, що "може" вплинути на продуктивність системи. Система також ретельно зловживається, оскільки постачальники завантажують її купою інформації, і багато разів вони не видаляють інформацію під час видалення програмного забезпечення.

На відміну від Unix, де все зберігається n файлів і завантажується як і коли потрібно. Операційна система таким чином не покладається на навички програмування постачальника, щоб вплинути на його продуктивність ...

Хоча я не можу коментувати інші операційні системи, реєстр також допомагає підтримувати конфігурацію програми під час оновлення або видалення / перевстановлення. Якщо вся конфігурація була у файлі .ini, який потрібно було замінити через оновлення, яке додало функції, у вас можуть виникнути труднощі або доведеться створити налаштований процес, щоб об'єднати дані конфігурації у вхідний файл ini.

Однак, маючи дані в реєстрі, ви можете використовувати загальний пакет встановлення (WIX, InstallShield тощо), який буде обробляти видалення / перевстановлення файлів, не торкаючись налаштувань програми.

(усі А. Не впевнені в B)

Я вважаю, що це насправді аж до (історичного) моменту, що реєстр виступає як своєрідний загальний інтерфейс для налаштувань програми.

Маєте заявку? Хочете зберегти налаштування, що охоплюються користувачем? Закупив його в реєстр.

Не потрібно «забезпечувати профілі користувачів», взагалі немає необхідності безпосередньо отримувати доступ до файлової системи. Win32 доглядає за цим усім.

Це був спосіб створити щось нове, незнайоме та табу для більшості користувачів, тому вони залишать це в спокої. Файли .ini та autoexec.bat можна легко видалити або змінити в гірший спосіб.

Зміна налаштувань реєстрації, о, мій!

Крім простого зберігання налаштувань програми, реєстр - це засіб, за допомогою якого програми та компоненти знаходять інші програми та компоненти . Зрештою, я думаю, що саме тому його централізована в єдину базу даних, на відміну від поширення на тисячі текстових або xml-файлів.

Наприклад, компонент, який виконує, скажімо, відеоефекти «реєструє» себе в реєстрі, дозволяючи іншим програмам, пов’язаним з відео, знати про його існування та використовувати його. Маючи централізовану систему для цього, це дозволяє уникнути серйозного безладу, оскільки тисячі систем і додатків використовують різні методи для досягнення такого рівня інтеграції.