Ответ на »сообщение 389« (Александр Алексеев)
___________________________
Вы удивитесь изобретательности криворуких программистов. В одной и той же программе вполне может быть ситуация, когда она читает настройки из 'MySettings.ini', но пишет в '%windir%\MySettings.ini'. Ну дык может там еще и вариант c:\windows\MySettings.ini. Да, в некоторых организациях есть указание, ставить ОС только на диск C, т.к. некоторые проги иначе не работают. А что мы имеем в сухом остатке: из двух зол выбрали обе, перестали работать и криворукие и пряморукие.
>>> в файле надо заменить один текст на другой, и не ошибиться, и выяснить что на что заменять копаясть не в папке с парой десятков файлов
Чем это отличается от ini-файлов? Тем, что в ini нет необходимости хранить информацию о версии и о его местоположении. В reg-файле зашита вся информация о путях, которая меняется от версии к версии. Рассмотрите еще вариант замены одних настроек другими. Надо сначала удалить всю ветку в regedit (не дай бог не ту), потом запустить соответствующий файл.

Ответ на »сообщение 389« (Александр Алексеев)
___________________________
>>> Вы удивитесь изобретательности криворуких программистов...
... особенно тех, которые могут обрушить реестр.

>>> мне было бы удобнее, если бы я просто сбрасывал с дистрибутивного диска нужный набор файлов в выбранный мной каталог и сразу запускал выполняемый файл
Угу, а кое-кому было бы удобнее иметь прямой доступ к аппаратуре (и зачем вообще эта ОС мне палки в колёса вставляет?!). Играть по правилам - всегда тяжелее, но это не значит, что так не нужно делать.

>>> Объясните мне, может я чего не догоняю, как на работу приложений повлияет: если без указания пути раньше писалось в [x]:\windows, а теперь [x]:\Application Data????
Вы удивитесь изобретательности криворуких программистов. В одной и той же программе вполне может быть ситуация, когда она читает настройки из 'MySettings.ini', но пишет в '%windir%\MySettings.ini'.
Нет смысла исправлять старые баги, исправления которых потенциально могут поломать программы, если у нас есть новая возможность без багов.

>>> в файле надо заменить один текст на другой, и не ошибиться, и выяснить что на что заменять копаясть не в папке с парой десятков файлов
Чем это отличается от ini-файлов?

Ответ на »сообщение 384« (Geo)
___________________________
Про главное преимущество файла настроек, расположенного рядом с EXE, я уже писал: перенос программы на другой компьютер выполняется простым копированием каталога с программой.
Так-то оно, конечно, так...
Но как быть с "персональным компьютером коллективного пользования"?
Каждый пользователь по своему настроил программу и, соответственно, необходимо хранить несколько экземпляров файла и выбирать при запуске нужный.
Кроме того, в заботе о безопасности, модификация файлов в "program files" ограничена.
Значит, либо соответствующая ветка реестра, либо C:\Documents and Settings\Петя\Application Data

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

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

Не все еще написано. Если бы было все написано, некоторые из участников дискуссии уже дважды бы переквалифицировались в управдомы :)

И еще я не понимаю разработчиков программ. Они не только какие-то свои форматы используют. Они еще зачем-то интерфейс прорабатывают, алгоритмы какие-то хитрые. Зачем. Сейчас в MS Visual Studio можно создать формочку, подключить нужный класс и получить готовое приложение. И чего это люди корячатся с какими-то собственными разработками.

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

>>>  Текстовый файл настроек всегда можно отредактировать любым редактором, без запуска особенной программы и многочисленных щелчков мышью :)
У нас, вроде бы, существуют не только консольные приложения, некоторые разрабатывают программы с GUI. Зачем же для таких программ настройки выносить в файл, который потом править в блокноте? Или еще более многочисленные щелчки по клавиатуре -- это удобнее чем настроить все парой кликов мышкой?

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

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

Ответ на »сообщение 382« (Cepгей Poщин)
___________________________
>>> Кстати говоря при сносе содержимого диска админиы могут ...
Да ничего они не могут.
Просто поменять XP на висту и опять на XP.
Без объявления войны и сохранения чего-либо.
Упала винда - пострадали "папки с пробелами".
Установили по новой - все выдуманные папки пострадали.
Это реальность данная в ощущениях.

Объясню свой контекст.
Я ставлю программы по городам России.
Сопровождаю удалённо.
Поэтому резервирование настроек и данных на флешку клиентами.
Флешка прилагается к софту и не отчуждается (типа ключ активации).

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

Ответ на »сообщение 384« (Geo)
___________________________
Неужели никаких других вариантов не может быть в принципе? Я уже насвистел вариант, когда, допустим, есть бинарный файл настроек Другие варианты это ДРУГИЕ варианты, а ini/reg почти одно и тоже, некоторые даже не понимают, какая разница :) Кстати бинарный файл настроек точно также можно запихнуть в реестр, а можно писать отдельным файлом и тут опять всплывает вопрос, где он должен находиться, так чтобы было удобно и конечному пользователю и операционной системе.
Ответ на »сообщение 383« А никто не задал себе вопрос: зачем конечному пользователю GUI приложения изменять настройки в ini-файлах, реестре и других? Для этого и создается GUI приложение. В нем и должно быть все для этого необходимое. Там могут находится какие-нибудь "секретные" настройки, доступные только кругу посвященных. Кроме того, как я уже писал програмы бывают и мелкие, там создание нормального GUI для настроек может по трудоёмкости превысить всё остальное, и не факт, что кто-то хоть раз воспользуется подобным сервисом.

Ответ на »сообщение 381« (Игорь Шевченко)
___________________________
>>> Не понимаю я изобретателей своих форматов и гуевых интерфейсов к ним. Это же лишняя работа, во имя чего ?
А я вообще не понимаю разработчиков программ: зачем они еще что-то разрабатывают, ведь все уже написано :)

И еще я не понимаю разработчиков программ. Они не только какие-то свои форматы используют. Они еще зачем-то интерфейс прорабатывают, алгоритмы какие-то хитрые. Зачем. Сейчас в MS Visual Studio можно создать формочку, подключить нужный класс и получить готовое приложение. И чего это люди корячатся с какими-то собственными разработками.

>>>  Текстовый файл настроек всегда можно отредактировать любым редактором, без запуска особенной программы и многочисленных щелчков мышью :)
У нас, вроде бы, существуют не только консольные приложения, некоторые разрабатывают программы с GUI. Зачем же для таких программ настройки выносить в файл, который потом править в блокноте? Или еще более многочисленные щелчки по клавиатуре -- это удобнее чем настроить все парой кликов мышкой?

По поводу моих наездов на реестр. Похоже, что люди вообще зациклились на двух возможных вариантах: либо реестр, либо ini-файл (как вариант -- xml). Неужели никаких других вариантов не может быть в принципе? Я уже насвистел вариант, когда, допустим, есть бинарный файл настроек, представляющий собой образ памяти, содержащей данные для работы программы. Такой файл грузится при старте программы целиком в память, создавая сразу готовую структуру данных для работы программы. Без какого-либо дополнительного ползания по ключам с их последующей обработкой. А все возражения касались именно сравнения реестра и стандартного ini-файла.

Про главное преимущество файла настроек, расположенного рядом с EXE, я уже писал: перенос программы на другой компьютер выполняется простым копированием каталога с программой. Такой простоты ни один из предложенных здесь альтернативных способов. А такая вещь как инсталляция с прописыванием всего и вся -- это вещь для разработчика, но не для пользователя. Пользователю от этого лишняя головная боль (к которой мы уже привыкли, считая ее неизбежным злом). Иногда (для больших и сложных программных комплексов) инсталляция является вещью необходимой для разработчика, потому что не получив от пользователя ответы на некоторые вопросы, невозможно правильно настроить работу комплекса. Для маленьких программок в процессе инсталляции всего лишь указывается каталог для размещения программы (ну, и еще что-то по поводу ярлыков). И я не вижу смысла писать отдельную программу, которая будет копировать EXE из дистрибутива в выбранные каталог, потому что любой файл-менеджер справится с этой работой ничуть не хуже. Тут уже действуют какие-то другие принципы: от "чтобы выглядело круто" до "по правилам хорошего тона у любой программы должен быть инсталлятор".

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

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

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

В пример той же IDE Delphi - зачем возникает необходимость лезть в реестр для изменения цветовой схемы от версии Delphi. А потому что разработчики инструмента не позаботились о конечных пользователях. Достаточно было добавить две кнопки "Импорт-Экспорт" в соответствующем месте IDE.

В противоположный пример многие дополнения для Firefox, например Tab Mix Plus или Mr Tech Toolkit, в которых можно "оттюнинговать" firefox под свои потребности, с их гигантским количеством настроек. В случае перестановки-переноса firefox не придется лезть и вспоминать где-что стояло. Там есть кнопки импорт,экспорт и даже умолчания.

И еще про папки из Documents and Settings, но тут необходимо, наверно, MSDN читать и делать выводы. Например, папка Local Settings не перемещается, в случае перемещаемого профиля в домене. А от этого многие программы страдают. Даже в сложном AutoCAD это починили где-то с версии 2007.

А вообще многие просчеты и тонкости программ начинаешь понимать, когда после того как был программистом становишься системным администратором. И видишь, как необходимо было проектировать то или иное приложение с этой точки зрения. А если пойти еще дальше - то стать пользователем программы.

Ответ на »сообщение 377« (Александр Алексеев)
___________________________
>>> Если с выходом NT4, по умолчанию, ini-файлы начали записываться в Application Data
Вы не можете изменить существующее поведение, потому что это поломает существующие программы. Оставим 1985 вместе с перестройкой, тем более windows тогда принадлежал не микрософт, перейдём в более поздние века. Объясните мне, может я чего не догоняю, как на работу приложений повлияет: если без указания пути раньше писалось в [x]:\windows, а теперь [x]:\Application Data???? А вот решение с борбой с безопастностью как раз повлияло на работу многих программ.
Чем это принципиально отличается от ini-файлов? Хранила бы Delphi настройки в ini-шниках - они точно так же прыгали бы по диску.
Чем так сложно выполнение нескольких щелчков мыши: "Экспорт"/"Импорт"? В файле reg имеется такой текст если его открыть текстовым редактором:

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\Borland\BDS\5.0\Editor]

[HKEY_CURRENT_USER\Software\Borland\BDS\5.0\Editor\Highlight]

[HKEY_CURRENT_USER\Software\Borland\BDS\5.0\Editor\Highlight\Assembler]

В зависимости от версии возможны варианты:

[HKEY_CURRENT_USER\Software\CodeGear\BDS\6.0\Editor\Highlight\Assembler]
[HKEY_CURRENT_USER\Software\Embarcadero\BDS\7.0\Editor\Highlight\Assembler]
[HKEY_CURRENT_USER\Software\Borland\Delphi\7.0\Editor\Highlight\Assembler]

Т.е. в файле надо заменить один текст на другой, и не ошибиться, и выяснить что на что заменять копаясть не в папке с парой десятков файлов, а во всёмчтоможетсистемепонадобиться. Чтобы не быть голословным попробуйте скопировать настройки цветовой схемы из одной версии Delphi в другую.
___________________________
Ответ на »сообщение 379« (Как слышно? Приём!)
>>> А если завтра война?
Вы имеете в виду переход на Red Flag Linux? :) Нет, я имею в виду судный день. Исчо раз:
А если винда грохнется или айтишники переставят её в очередной раз? Поэтому правило - ничего не храните в каталогах с пробелами.
А если завтра война?
Как на это могут повлиять каталоги с пробелами? Разбиритесь с причинно следственными связями.
Кстати говоря при сносе содержимого диска админиы могут пощадить содержимое популярных папок типа "Мои документы", а вот папка с непопятным названием без пробелов, может после очередной чистки рядов партии, подвергнуться репрессиям минуя корзину.