Наивный вопрос про Виндуза и регистри

[deim]

Почему то никто не упомянул что registry вроде защищена write-ahead journaling на случай краха. Правда в реальности вычистить программу при крахе инсталляции, если эта программа использует только .INI оказывается на два порядка проще

Вот-вот! Зачем пытаться решить проблему (защита регистри), если саму задачу можно элиминировать на корню. Нет регистри - нет риска его сломать

[Palych]

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

Eta problemma suschestvuet tol'ko v DOS i Windows 3.xx.

[lx_uk]

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

Для этого есть стандартное решение. Пользовательские настройки кладутся в отдельный файл в home directory этого пользователя (Documents and Settins/<user name>).

[Dmitry67]

На самом деле мне кажется что при проектировании registry допущена большая ошибка
Вначале для идентификации продуктов использовались каталоги
Потом ситуация усложнилась
Если бы у каждого value было бы поле InstalledBy, причем это поле нельзя было бы изменить то тогде можно было бы снести по InstalledBy
Сейчас же если аппликация чтото пихнет в хитрое место - то все, с концами

Однако мне кажется что замусоривание DLL и ActiveX является большей проблемой чем замусоривание registry (пассивное)

[VBez]

Да зачем-же в рукопашную-то?! Неужто в виндузах нет АПИ для работы с ресурсами/пропертями?!

Не знаю - не видел. Скорее всего есть.
А под НЕТ буквально в каждой книге есть примеры.

Типа - программер/архитектор изучил новый АПИ, и начинает новую игрушку пропихивать везде - где нужно и где не нужно?

Не игрушку. А технологию, которая облегчает жизнь.
Я думаю, что про джаву точно также говорили лет 10 назад

Неужто в виндузах что-то аналогичное появилось только с рождением .НЕТ?!

Конечно нет. Скорее всего есть для этого специально API, но я его не знаю. Потому как в прочитанных мною книгах я этого не видел. А на работе мы используем реджистри.

Теперь что - модно под виндуза на дельфи писать?! Куда делся софт размером 5-10-15кб и почему даже микро-тулзы измеряются мегабайтами если не их десятками!?

Все зависит от радиуса кривизны рук конкретного программера.

[Hamster]

Для этого есть стандартное решение. Пользовательские настройки кладутся в отдельный файл в home directory этого пользователя (Documents and Settins/<user name>).

Правильно. Следующий шаг - систематизировать каталог с настройками, чтобы вместо беспорядочно лежащих 5000 файлов была стройная иерархическая система. Желательно со встроенной поддержкой разных типов параметров, защитой от сбоев, и висящая постоянно в памяти для оптимизации доступа.
Что получается? ...

[lx_uk]

Для этого есть стандартное решение. Пользовательские настройки кладутся в отдельный файл в home directory этого пользователя (Documents and Settins/<user name>).

Правильно. Следующий шаг - систематизировать каталог с настройками, чтобы вместо беспорядочно лежащих 5000 файлов была стройная иерархическая система. Желательно со встроенной поддержкой разных типов параметров, защитой от сбоев, и висящая постоянно в памяти для оптимизации доступа.
Что получается? ...

Вы еще забыли security - ini файлы не всегда лежат на ntfs разделе. Сейчас это скорее исключение, но реестр создавался лет 10 назад.

Мне вот интересно другое, как с сохранением всех преимуществ реестра достичь еще одного - легкости редактирования настроек с помощью привычного редактора? Это у ini файлов не отнять. Хотя допускаю, что далеко не все согласятся, что это преимеущество.

PS. Еще одно косвенное преимущество - комментарии. В текстовом файле комментарии читать легко и удобно. В реестре их просто нет, хотя и возможо их реализовать и даже сделать удобный просмотр...

[Strannik223]

Для этого есть стандартное решение. Пользовательские настройки кладутся в отдельный файл в home directory этого пользователя (Documents and Settins/<user name>).

Правильно. Следующий шаг - систематизировать каталог с настройками, чтобы вместо беспорядочно лежащих 5000 файлов была стройная иерархическая система. Желательно со встроенной поддержкой разных типов параметров, защитой от сбоев, и висящая постоянно в памяти для оптимизации доступа.
Что получается? ...

Поддерживаю,
Если добавить еще разделение катологов на системные (те что установлены ОС) и те куда юзера инсталируют софт, то получаем Юникс :)

[Strannik223]

Таких "а почему" можно задавать много и все они называються "архитектурная ошибка"
Меня просто до бешенства доводит невозможность скопировать цветовые настройки в VisualStudio. Лезешь в регистри, а там Guid-ы в цветах

Чего еще никогда не мог понять так это какого черта было делать window handler in TLS(thread local storage), то есть имея хандлер можно им оперировать только если ты в том же потоке в котором окно создано. Я знаю как это обходить, вопрос в том какого черта это надо было!!!

[Hamster]

Таких "а почему" можно задавать много и все они называються "архитектурная ошибка"
Меня просто до бешенства доводит невозможность скопировать цветовые настройки в VisualStudio. Лезешь в регистри, а там Guid-ы в цветах

Можно просто экспортировать ключ "Format". И где там Guid-ы?

[Strannik223]

Таких "а почему" можно задавать много и все они называються "архитектурная ошибка"
Меня просто до бешенства доводит невозможность скопировать цветовые настройки в VisualStudio. Лезешь в регистри, а там Guid-ы в цветах

Можно просто экспортировать ключ "Format". И где там Guid-ы?

А я Format не нашел
Студия 2003.
local_mashine/software/microsoft/VisualStudio/FontAndColors/TextEditor/Category:
{A27B4E24-A735-4d1d-B8E7-9716E1E3D8E0}
То есть ссылка куда-то

Мне просто есть с чем сравнивать
На Юниксе по человечески почему-то все сделано. Копируешь текстовый файл с конфигурацией вот тебе и backup, или переносишь свою home directory на другую машину с таким же установленым софтом и у тебя весь твой desctop со всеми настройками. Хочеться понять каким местом проектировалось это хозяйство на Винде что без танцов с бубнами и нехилым везением настройки забекапить или перенести нельзя

[roadman]

Никогда не мог понять - почему и зачем в виндузах придумано и сделано централизованное хранилище сеттингов всех установленных программ/систем - регистри?! Какой в этом философский смысл?!

Неужели не проще хранить все сеттинги программы - локально, в пространстве этой программы? В OS/2 например все засовывали в расширенные атрибуты файловой системы. Милое дело - установленная программа легко копировалась/переносилась/бэкапилась.

А в этих идиотских виндузах все завязано на центральные регистри. Мало того, что ни перенести программу, ни забэкапить ее по человечески, так еще это регистри всяким дерьмом постоянно забивается...

Зачем?!

P.S. Эх, все-таки ИБМ - сволочи! Такую классную операционку (OS/2) загубили

Регистр выполняет ряд функций, которые трудно реализовать на базе ini файлов. Например, вся технология COM/DCOM интегрироованна с регистри, посколько не отдельная программа, а сама операционная система должна знать, где находится тот или иной COM сервер (DLL, EXE). Я так понимаю, что изначально регистр задумывалась для "внутреннего" использования. Но потом регистри API открыли и для "простых" смертных. Однако никто не мешает использовать INI файлы каждой отдельной программой для своих нужд.
Следующий пример - это безопасность (пароли там разные) и опять же это для ОС, хотя и пользовательская программа может положить в регистр зашифрованные данные.

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

Список можно продолжать...

[Strannik223]

Регистр выполняет ряд функций, которые трудно реализовать на базе ini файлов. Например, вся технология COM/DCOM интегрироованна с регистри, посколько не отдельная программа, а сама операционная система должна знать, где находится тот или иной COM сервер (DLL, EXE). Я так понимаю, что изначально регистр задумывалась для "внутреннего" использования. Но потом регистри API открыли и для "простых" смертных. Однако никто не мешает использовать INI файлы каждой отдельной программой для своих нужд.
Следующий пример - это безопасность (пароли там разные) и опять же это для ОС, хотя и пользовательская программа может положить в регистр зашифрованные данные.

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

Список можно продолжать...

С точки зрения осведомленности ОС о зарегистроированых комонентах абсолютно все равно то ли регистрационны файл будет registry.ini or registry.dat

Никто не мешает конечно использовать ini-style, но насколько я помню это нерекомендованый способ и МС его в своих продуктах не использует

Безопасность это как раз плохой пример. Права доступа на ветки регистри были приделаны намного позже чем появилось само понятие пользователей в Вин. Более того это пример того как нерационально сдублированы усилия. Были бы настройки в файлах, можно было бы просто права доступа на файлы дать, а так у файловой системы своя песня с правами доступа а у регистри своя. Имеем 2 системы каждая из который реализует разграничение доступа. С архитектурной точки зрения это явный ляп

Список драйверов: какие такие сотни мест где это инфа доступна: делается ОДИН файл с информацией необходимой ядру для загрузки и он текстовый. Мне на Юниксе достаточно любого тектового редактора что бы вырубить драйвер который шалит, и поверьте что формат там self-explained, а в винде? Зачем эту информацию о драйверах засовывать в тот же файл где лежит тысяч 200 других настроек других програм? А потом надо это дело защищать от этих самых других прграм и делать навороченую систему разграничения доступа специально для регистри. Типа создаем проблемы что бы мужественно преодолевать их

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

[Hamster]

А я Format не нашел
Студия 2003.
local_mashine/software/microsoft/VisualStudio/FontAndColors/TextEditor/Category:
{A27B4E24-A735-4d1d-B8E7-9716E1E3D8E0}
То есть ссылка куда-то

А, я думал, речь про старый ( 6.0 ).

[Sheriff]

А я Format не нашел
Студия 2003.
local_mashine/software/microsoft/VisualStudio/FontAndColors/TextEditor/Category:
{A27B4E24-A735-4d1d-B8E7-9716E1E3D8E0}
То есть ссылка куда-то

Сохранить настройки фонтов и цветов в Visual Studio .NET 2003 в файл:

regedit /ea Vc2003Colors.reg HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\7.1\FontAndColors

Восстановить настройки:

regedit -s Vc2003Colors.reg

Мне просто есть с чем сравнивать
На Юниксе по человечески почему-то все сделано. Копируешь текстовый файл с конфигурацией вот тебе и backup, или переносишь свою home directory на другую машину с таким же установленым софтом и у тебя весь твой desctop со всеми настройками.

На вкус и цвет...

Хочеться понять каким местом проектировалось это хозяйство на Винде что без танцов с бубнами и нехилым везением настройки забекапить или перенести нельзя

Везение тут не причем. Нужно знать как делать вещи.