Ответ на »сообщение 380« (Geo)
___________________________

И под все эти ОС пользовательские приложения от Микрсофт не только настройки сохраняли рядом с EXE

Дабы быть ближе к истине, настройки они сохраняли в каталоге Windows (это до Win95) или в реестре (это во время Win95 и после).


И-мен-но! Поэтому я предпочитаю предоставить пользователю необходимый инструмент для настроек, а сами данные хранить там и в том виде, где это удобнее мне. Если лениво, то можно и ini-файлом ограничиться. Если не лень, то можно продумать формат, удобный для данной конкретной программы (допустим, бинарник, который целиком загружается в память).


Не понимаю я изобретателей своих форматов и гуевых интерфейсов к ним. Это же лишняя работа, во имя чего ? Текстовый файл настроек всегда можно отредактировать любым редактором, без запуска особенной программы и многочисленных щелчков мышью :)


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

1. Реестр не работает медленнее (или медленнее чего имеется в виду ?)
2. Александр Алексеев в [370] дал хорошую ссылку, где написано, чем реестр отличается от файлов для хранения конфигурации.
3. Мне видится недостаток реестра в том, что набор конфигурационных параметров нельзя окинуть взглядом. Бывает полезно.
4. Да, реестр большой и толстый. С другой стороны, в каждой новой версии системы размер максимально допустимого объема реестра только растет :)
5. В приложениях на .Net, насколько мне известно, использовать реестр считается дурным тоном. Поэтому они могут наплодить вокруг себя множество конфигурационных файлов. Не всегда удобно потом с этим зоопарком иметь дело.
6. Каждый все-таки сам выбирает доступный способ хранения конфигурации, в зависимости от задачи, личных предпочтений, корпоративных стандартов и т.п.

С наилучшими,

>>> Не очень понятно, о каких 15-ти годах идёт речь, если это было так ещё в WinNT (1996-й).
А WinNT была шибко распространена среди простых обычных пользователей, когда не было сетей? Что-то не помню. Были ДОС, Win 3.1, Win 95. И под все эти ОС пользовательские приложения от Микрсофт не только настройки сохраняли рядом с EXE, но и результаты работы программы (те же вордовские докумены) по умолчанию предлагалось сохранять рядом EXE. Я так и не смог до конца забороть наших тупых юзеров, хотя применял жестокие меры: вплоть до самостоятельной реализации физического запрета записи на диск C:

>>> При этои место хранения настроек значения не имеет (что позволяет нам свободно им распоряжаться).
>>> Потому что реестр - это аналог private-полей объекта. Вам незачем туда лазить - никто не лезет в реестр просто так, за посмотреть.
И-мен-но! Поэтому я предпочитаю предоставить пользователю необходимый инструмент для настроек, а сами данные хранить там и в том виде, где это удобнее мне. Если лениво, то можно и ini-файлом ограничиться. Если не лень, то можно продумать формат, удобный для данной конкретной программы (допустим, бинарник, который целиком загружается в память).

Реестр же -- эта некая монструозная конструкция, которая требует дополнительных телодвижений (в виде вызовов дополнительных функций), которая медленнее работает (пусть и ненамного), которая навязывает свой формат хранения данных по ключам (исключаем вырожденныый случай, когда заводим один единственный ключ и в него запихиваем весь наш бинарник), но при всем этом не дает никаких значимых преимуществ. Ну, или (правильнее сказать) я не вижу преимуществ реестра перед файловой системой (с учетом неких предопределенных каталогов файловой системы, пути которых получаем через API). Кстати, боюсь что с закрытием Program Files на запись появятся программы (хранящие настройки в файле рядом с EXE), в redme которых будет написано, что данную программу не надо размещать в Program Files. И я эту инициативу поддержу если что: на Program Files свет клином не сошелся, а копировать на другой компьютер удобнее не ветку реестра или Application Data, а папку с EXE-шником.

Ответ на »сообщение 372« (Cepгей Poщин)
___________________________
>>> А если завтра война?
Вы имеете в виду переход на Red Flag Linux? :)
Вот уж где реестр, Program Files, Рабочий Стол, Documents and Settings, Application Data, Главное Меню - не пришей кобыле хвост.

Интересно, такой вой о кроссплатформенности, а решения - под винду.

Реестр - временное решение, когда количество особенностей уже требовало централизованной обработки,
но ещё было достаточно малым, чтобы не превратиться в неуклюжего монстра, как сейчас.
Жаль, что умные люди ещё тратят время на поддержку этого пережитка - прекрасно можно и без него обойтись.

Ответ на »сообщение 377« (Александр Алексеев)
___________________________


>>> Насколько я понял, предлагается использовать (Default) для хранения комментариев, верно ?
Нет, имеется ввиду, что значение хранится в (Default), а в дополнительных параметрах хранится что угодно. В том числе - комментарий. Пример: http://dl.dropbox.com/u/201788/Web/OracleInRegistry.png

Тоже подход. Хотя непривычный. И читать не так удобно, как в случае файла


>>> в котором "все ясно и понятно" из чтения самого файла
Угу, обратите внимание, на какие уловки в вашем примере приходится идти, чтобы эмулировать древовидные настройки в плоском ini-файле (постфикс у многих опций, указывающий на её отношение к узлу дерева). Насколько проще и нагляднее это выглядело бы в реестре. (P.S. есть мнение, что Oracle хранит всё в ini, чтобы было единообразно на всех платформах, где нет реестра)


Есть мнение, что это было сделано задолго до реестра :) Кстати, приведенный файл далеко не ini.


Окей, как насчёт написать скрипт "все ли пользователи в сети используют последнюю версию моей программы"? Это важно для системных администраторов. Как насчёт "установить для всех пользователей домена настройку XXX в YYY и запретить всем её менять"? Покажите мне, как вы сделаете это на ini-файлах.

У нас подобная проблема решена иначе - часть настроек (в том числе и версия программы) хранится в базе данных.
То есть, не ini и не реестр, а централизованно. И это оправдано, так как версия программы связана с версией структуры данных, с которой приходится работать.
Все это лишняя иллюстрация того, что не стоит применять единственное решение на все случаи жизни.

С наилучшими,

>>> Вина M$ в том, что если не указывать путь, то ini-файл создаётся в папке Windows.
Сергей, вы меня извините, но вы говорите о 1985-м - задолго до времени когда люди начали волноваться из-за таких "пустяков", как unicode или безопасность.

>>> Если с выходом NT4, по умолчанию, ini-файлы начали записываться в Application Data
Вы не можете изменить существующее поведение, потому что это поломает существующие программы.
А в Win95/WinNT появляется реестр и, между прочим, нормальное разделение и "умолчательное" место хранения.
Это один из примеров, когда введение новой возможности позволяет исправить старые косяки. Другое дело, что не все его используют.

>>> Но в Delphi чуть ли c каждым выходом новой версии меняется название фирмы и путь к ключу
Чем это принципиально отличается от ini-файлов? Хранила бы Delphi настройки в ini-шниках - они точно так же прыгали бы по диску.

>>> С реестром это уже высший пилотаж :)
Чем так сложно выполнение нескольких щелчков мыши: "Экспорт"/"Импорт"?

>>> Насколько я понял, предлагается использовать (Default) для хранения комментариев, верно ?
Нет, имеется ввиду, что значение хранится в (Default), а в дополнительных параметрах хранится что угодно. В том числе - комментарий. Пример: http://dl.dropbox.com/u/201788/Web/OracleInRegistry.png

>>> в котором "все ясно и понятно" из чтения самого файла
Угу, обратите внимание, на какие уловки в вашем примере приходится идти, чтобы эмулировать древовидные настройки в плоском ini-файле (постфикс у многих опций, указывающий на её отношение к узлу дерева). Насколько проще и нагляднее это выглядело бы в реестре. (P.S. есть мнение, что Oracle хранит всё в ini, чтобы было единообразно на всех платформах, где нет реестра)

>>> Я все пытаюсь сказать, что не существует единственного верного решения на все случаи жизни, все решения хороши, каждое к своей задаче.
Да с этим я и не спорю. Просто указываю на некоторые дополнительные соображения по выбору места/способа хранения.

>>> Когда можно преспокойно использовать в ряде случаев тот самый ini-файл, для которого не надо писать ничего дополнительного, который может быть документирован, который легко и удобно переносится вместе с программой, который легко и просто переименовать для проверки разных конфигураций.
Окей, как насчёт написать скрипт "все ли пользователи в сети используют последнюю версию моей программы"? Это важно для системных администраторов. Как насчёт "установить для всех пользователей домена настройку XXX в YYY и запретить всем её менять"? Покажите мне, как вы сделаете это на ini-файлах.

Ответ на »сообщение 370« (Александр Алексеев)
___________________________
Это вина Microsoft, что ленивые разработчики всегда работают под админом и даже не задумываются о запуске программ из под обычного пользователя? Вина M$ в том, что если не указывать путь, то ini-файл создаётся в папке Windows. Т.е. умолчательный каталог с самого начала был не самый подходящий, что и вынудело большинство разработчиков записывать данные в папку с программой. Если с выходом NT4, по умолчанию, ini-файлы начали записываться в Application Data (»сообщение 367«), то ни кто бы не выдумывал куда записывать настройки приложения и переход под висту оказался бы гораздо проще.
Никто не запрещает делать поиск по реестру (и это проще, чем поиск по всему диску) Кстати количество ключей реестра больше чем 65535 (максимального количества узлов TreeView), так что при неудачном стечении обстоятельств в RegEdit вы не сможете попасть в искомую ветку реестра. Это я так..., ибо M$ :o)
Чем для меня лично выгоднее хранение настроек в ini? Как продвинутый пользователь, я могу скопировать настройки с другого компьютера, могу удалить их вовсе. С реестром это уже высший пилотаж :) Можно найти нужный ключ реестра, и сохранить его (если повезет). Но в Delphi чуть ли c каждым выходом новой версии меняется название фирмы и путь к ключу, т.е. что бы к примеру скопировать цвета из Delphi2006 в Delphi2010, надо еще плотно поработать с reg-файлом. Если не дай бог удалишь что лишнее, вообще можно заново занятся установкой...
Конечно можно бы ло бы сделать специальный сервис по переносу настроек с одной версии на другую. Только это лишняя работа (кто его знает будет ли вообще версия X + 1), лишний повод напрягать мосх у пользователя (куда я скопировал год назад настройки, какое у них расширение вообще), лишний источник глюков, которые всплывут не сразу после начала работы, а после сноса ОС, или переезде на другой комп, т.е. очень не скоро. Для небольших прог. это не пренебрежимомалые величины.

Ответ на »сообщение 373« (Александр Алексеев)
___________________________

>>> В реестре такое не получится.
Это не так. Посмотрите пример в конце моего предыдущего сообщения.

Насколько я понял, предлагается использовать (Default) для хранения комментариев, верно ?

Я приведу пример файла с конфигурацией:

# copyright (c) 1997 by the Oracle Corporation
#
# NAME
#  listener.ora
# FUNCTION
#  Network Listener startup parameter file example
# NOTES
#  This file contains all the parameters for listener.ora,
#  and could be used to configure the listener by uncommenting
#  and changing values.  Multiple listeners can be configured
#  in one listener.ora, so listener.ora parameters take the form
#  of SID_LIST_<lsnr>, where <lsnr> is the name of the listener
#  this parameter refers to.  All parameters and values are
#  case-insensitive.

# <lsnr>
#  This parameter specifies both the name of the listener, and
#  it listening address(es). Other parameters for this listener
#  us this name in place of <lsnr>.  When not specified,
#  the name for <lsnr> defaults to "LISTENER", with the default
#  address value as shown below.
#
# LISTENER =
#  (ADDRESS_LIST=
# (ADDRESS=(PROTOCOL=tcp)(HOST=localhost)(PORT=1521))
# (ADDRESS=(PROTOCOL=ipc)(KEY=PNPKEY)))

# SID_LIST_<lsnr>
#  List of services the listener knows about and can connect
#  clients to.  There is no default.  See the Net8 Administrator's
#  Guide for more information.
#
# SID_LIST_LISTENER=
#  (SID_LIST=
# (SID_DESC=
# #BEQUEATH CONFIG
#          (GLOBAL_DBNAME=salesdb.mycompany)
#          (SID_NAME=sid1)
#          (ORACLE_HOME=/private/app/oracle/product/8.0.3)
# #PRESPAWN CONFIG
#        (PRESPAWN_MAX=20)
#   (PRESPAWN_LIST=
#          (PRESPAWN_DESC=(PROTOCOL=tcp)(POOL_SIZE=2)(TIMEOUT=1))
#        )
#        )
#      )

# PASSWORDS_<lsnr>
#  Specifies a password to authenticate stopping the listener.
#  Both encrypted and plain-text values can be set.  Encrypted passwords
#  can be set and stored using lsnrctl. 
#    LSNRCTL> change_password
#      Will prompt for old and new passwords, and use encryption both
#      to match the old password and to set the new one.
#    LSNRCTL> set password
# Will prompt for the new password, for authentication with
#      the listener. The password must be set before running the next
#      command.
#    LSNRCTL> save_config
#      Will save the changed password to listener.ora. These last two
#      steps are not necessary if SAVE_CONFIG_ON_STOP_<lsnr> is ON.
#      See below.
#
# Default: NONE
#
# PASSWORDS_LISTENER = 20A22647832FB454      # "foobar"

# SAVE_CONFIG_ON_STOP_<lsnr>
#  Tells the listener to save configuration changes to listener.ora when
#  it shuts down.  Changed parameter values will be written to the file,
#  while preserving formatting and comments.
# Default: OFF
# Values: ON/OFF
#
# SAVE_CONFIG_ON_STOP_LISTENER = ON

# USE_PLUG_AND_PLAY_<lsnr>
#  Tells the listener to contact an Onames server and register itself
#  and its services with Onames.
# Values: ON/OFF
# Default: OFF
#
# USE_PLUG_AND_PLAY_LISTENER = ON

# LOG_FILE_<lsnr>
#  Sets the name of the listener's log file.  The .log extension
#  is added automatically.
# Default=<lsnr>
#
# LOG_FILE_LISTENER = lsnr

# LOG_DIRECTORY_<lsnr>
#  Sets the directory for the listener's log file.
# Default: <oracle_home>/network/log
#
# LOG_DIRECTORY_LISTENER = /private/app/oracle/product/8.0.3/network/log

# TRACE_LEVEL_<lsnr>
#  Specifies desired tracing level.
# Default: OFF
# Values: OFF/USER/ADMIN/SUPPORT/0-16
#
# TRACE_LEVEL_LISTENER = SUPPORT

# TRACE_FILE_<lsnr>
#  Sets the name of the listener's trace file. The .trc extension
#  is added automatically.
# Default: <lsnr>
#
# TRACE_FILE_LISTENER = lsnr

# TRACE_DIRECTORY_<lsnr>
#  Sets the directory for the listener's trace file.
# Default: <oracle_home>/network/trace
#
# TRACE_DIRECTORY_LISTENER=/private/app/oracle/product/8.0.3/network/trace
# CONNECT_TIMEOUT_<lsnr>
#  Sets the number of seconds that the listener waits to get a
#  valid database query after it has been started.
# Default: 10
#
# CONNECT_TIMEOUT_LISTENER=10

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

>>> Кстати, бесплатным, что тоже немаловажно.
Извините, не понял, о чём речь.

Речь о том, что можно искать/ждать "нормальную" программу, в которой для загруженных файлов есть N удобств, а можно пользоваться бесплатной, но, возможно, с неудобствами.


>>> Нормальную надо писать. В смысле вносить лишний код, тестировать этот код, возможно, документировать.
Так ли сложно сделать два батника с вызовом из GUI? (простейший случай)

А зачем ? :) Когда можно преспокойно использовать в ряде случаев тот самый ini-файл, для которого не надо писать ничего дополнительного, который может быть документирован, который легко и удобно переносится вместе с программой, который легко и просто переименовать для проверки разных конфигураций.

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

С наилучшими,

P.S.
>>> Но я описал несколько иную ситуацию - когда другая программа что-то сохраняет в AppData, а мне это что-то желательно найти и перенести (ну хотя бы на другой носитель в целях резервного копирования).
Как же удобен в этом плане реестр с его HKLM/HKCU\Software\TheirCompany\TheirProduct\1.0 :D

>>> В реестре такое не получится.
Это не так. Посмотрите пример в конце моего предыдущего сообщения.

>>> Кстати, бесплатным, что тоже немаловажно.
Извините, не понял, о чём речь.

>>> Нормальную надо писать. В смысле вносить лишний код, тестировать этот код, возможно, документировать.
Так ли сложно сделать два батника с вызовом из GUI? (простейший случай)

Ответ на »сообщение 368« (Как слышно? Приём!)
___________________________
А если винда грохнется или айтишники переставят её в очередной раз?
Поэтому правило - ничего не храните в каталогах с пробелами. А если завтра война? Как на это могут повлиять каталоги с пробелами? :))) Короче нету такого правила.