Добро пожаловать, читатели Slashdot. Напоминаю, что этот web-сайт предназначен только для развлечения.
Почему INI-файлы устарели и их заменил реестр? Потому что у INI-файлов было много проблем.
- INI-файлы не поддерживают Unicode. Даже хотя у вас есть Unicode-варианты функций по работе с INI-файлами, они всё равно пишут всё в ANSI по соображениям совместимости (у вас есть кривой способ создать Unicode-ный INI-файл, но вам придётся выйти за API, чтобы сделать это). Это не было проблемой в Win16, потому что Win16 тоже не поддерживала Unicode!
- INI-файлы не поддерживают точную настройку доступа. Поскольку это просто текстовый файл, то любые настройки безопасности возможны только на файловом уровне, а не уровне отдельных ключей. Вы не можете сказать "кто угодно может изменять эту секцию, а вот этот раздел может изменяться только админами". Это также не было проблемой в Win16, потому что в Win16 не было безопасности.
- Если у вас есть два записывающих потока, то это может привести к потере данных. Рассмотрим два потока, которые пытаются обновить INI-файл. Если они работают одновременно, то вы можете получить такой сценарий:
Обратите внимание, что второй поток, обновляющий INI, случайно может затереть обновление от первого потока. И снова: это не было проблемой в Win16, потому что она была системой с кооперативной многозадачностью. Что означало, что пока вы явно не захотели отдать процессор другому потоку, никакой поток не мог вас прервать.Thread 1 Thread 2 Читает INI файл Читает INI файл Записывает в INI файл + X Записывает в INI файл + Y - INI-файлы подвержены атакам отказа в обслуживании. Программа может открыть INI-файл в эксклюзивном режиме и заблокировать всех. Это было бы просто ужасно, если бы в ini-файлах хранились бы настройки по безопасности, потому что это не дало бы никому узнать, какие же вообще у нас настройки безопасности. Это было также проблемой и в Win16, но поскольку у нас не было безопасности вообще, то плохая программа могла просто удалить файл!
- INI-файлы содержат только строки. Если вам нужно хранить двоичные данные, то вам нужно как-то закодировать их в строку.
- Парсинг INI-файла - это относительно медленная операция. Каждый раз, когда вы читаете или пишете значение в INI-файл, файл должен быть целиком загружен в память и распарсен. Если вы записываете в INI-файл три строки, то этот INI-файл загружается и парсится три раза, а также три раза записывается на диск. В Win16 несколько последовательных операций с INI файлами не приводили к записи, чтению или парсингу, потому что операционная система была с кооперативной многозадачностью. Когда вы в первый раз обращались к INI-файлу, он читался, парсился и кэшировался. Все ваши дальнейшие обращения приводили к работе с кэшем. Кэш выгружался на диск, когда вы передавали процессор другому потоку.
- Многие программы открывают и работают с INI-файлами напрямую, минуя официальный API. Это означает, что теперь формат INI-файлов фиксирован и мы не можем его поменять. Даже если бы мы захотели добавить что-то (безопасность на ключи или вложенность) - мы не смогли бы этого сделать. Что ещё хуже, многие программы содержат ошибки или ограничения в своих парсерах INI-файлов, так что на практике вы можете столкнуться с ситуацией, когда вы не можете хранить строку длиннее 70 символов, иначе вылетит другая программа, которая читает этот файл.
- INI-файлы имеют ограничение в максимальный размер - не более 32 Кб.
- Каталог по-умолчанию для INI-файлов - это папка Windows! Это однозначно очень плохо для всех систем на базе Windows NT, потому что на них только администраторы имеют туда доступ.
- INI-файлы имеют только два уровня структуры. Любой INI-файл состоит из секций, а каждая секция состоит из пары ключ=значение. Вы не можете вносить секции внутрь других секций.
- Централизованное управление INI-файлами тяжело. Поскольку они могут быть где угодно в системе, то системный администратор не может написать скрипт, узнающий "все ли используют последнюю версию FireFox?". А поскольку INI-файлы не поддерживают безопасность, то они также не могут сделать скрипт, который говорит "Установить всем настройки FireFox в XYZ и не давать пользователям их менять" (например, настройки прокси).
Комментатор TC отметил, что маятник качнулся в другую сторону к текстовым файлам конфигурации, но на этот раз это уже XML. Это возвращает нам много проблем, которые были у INI-файлов, но у файлов конфигурации XML есть значительное преимущество: никто не пишет в файлы XML, а только читают их. XML файлы не используются для хранения пользовательских настроек программы, они просто содержат информацию о самой программе. Давайте посмотрим на проблемы INI-файлов, применительно к XML-файлам.
- XML-файлы поддерживают Unicode.
- Безопасность XML-файлов не обладает достаточной гранулярностью. Но поскольку XML файлы только читают, то это уже не так уж и необходимо (однако, если вы захотите, чтобы только админы читали бы определённые части конфигурации, то у вас появляются проблемы).
- Поскольку XML-файлы только для чтения, вам не нужно волноваться о нескольких одновременных писателях.
- XML-файлы конфигурации также подвержены атакам отказа в обслуживании. Вы всё ещё можете открыть их в эксклюзивном режиме и заблокировать другие процессы.
- XML-файлы содержат только строки. Если вы хотите хранить любые другие данные, то вам нужно как-то их кодировать.
- Парсинг XML-файла ещё более медленное занятие, чем парсинг INI-файла. Но поскольку они только для чтения, то вы можете парсить их только один раз и закэшировать результат.
- Программы также читают и парсят XML файлы напрямую, но даже если бы это было не так, то стандарт XML всё равно фиксирован, так что вы не можете его расширить, даже если бы захотели. Я надеюсь, что эти программы используют XML-парсер, соответствующий стандартам, вместо того, чтобы писать свой собственный, но я не удивлюсь, если в мире есть люди, которые написали свой собственный парсер, который встаёт на строках длиннее 70-ти символов.
- XML-файлы не имеют ограничения на размер.
- XML-файлы не имеют места по-умолчанию.
- XML-файлы имеют сложную структуру. Элементы могут содержать другие элементы.
*ехидно* Введение реестра создаёт единую точку отказа. Помнится у меня однажды бед-блок прошёлся как раз поверх ветви HKEY_LOCAL_MACHINE, угадаете, как я "повеселился" пытаясь оживить компьютер?
ОтветитьУдалитьИ что?
ОтветитьУдалитьЧем это отличается от порчи любого другого критического для системы файла?
А для реестра у вас есть бэкап предыдущего состояния реестра - "загрузка последней удачной конфигурации", равно как и точки восстановления, создаваемые либо автоматически, либо вручную, не говоря уже о возможности ручного бэкапа реестра.
Если вы всё это поотключали - ну тогда и сами себе буратино.
Это ничем не отличается от случая порчи любого другого критического для системы файла.
Хранилась бы необходимая для работы ОС конфигурация в ini-файле, я бы ровно так же мог бы сказать по отношению к ini-файлу: "вот, смотрите, я его удалил/испортил,сбой диска, а система не загружается, какая она кривая!".
А вы вспомните статистику появления бед-блоков (не доводилось видеть?). Я вот не помню, чтобы они приходились на ядро или загрузчик. Потому что это очень редко меняющиеся файлы. А в реестр постоянно кто-нибудь да и пишет. Получается у нас критический для системы файл постоянно кем-то меняется. И тут отказы могут быть не только по железу уже. Сбой питания, кривой драйвер...
ОтветитьУдалитьПлюсуя то, что написано в статье, думаю %APPDATA% + JSON(или XML) - вполне приемлемый вариант без реестра.
ОтветитьУдалитьВ очередной раз спасибо за перевод.
ОтветитьУдалитьНепонятен один момент, Рэймонд не один раз упоминает, что XML-файлы конфигурации предназначены только для чтения, надо понимать, в отличие от ini-файлов. А кто же их, XML-файлы, записывает, и почему нельзя аналогичный механизм применить к ini-файлам ?
По поводу бэкапа реестра - последняя удачная конфигурация относится только к HKLM\System\ControlSetxxx, то есть не совсем "последнее удачное состояние реестра", скорее "последнее удачное состояние конфигурации".
К чему пишу - тоже пришлось столкнуться с нечитаемостью реестра из-за бэдблока в HKLM, и восстановление работоспособности системы в этом случае занятие не такое тривиальное, как может показаться.
Спасибо за перевод.
ОтветитьУдалитьУтверждение о том, что XML-файлы нужно только читать, конечно сильное. Непонятно, откуда оно взялось - вроде и читается и пишется без проблем.
По поводу read-only: вспомните, где в основном применяют XML. Это может быть конфигурация чего-либо, это может быть документ (CSS, XSLT, etc) и т.д.
ОтветитьУдалитьВсе эти сценарии предполагают, что XML записывается один раз (читай: редко), а читается постоянно (читай: много). Именно это подразумевается под "XML - это read-only". Не надо понимать это буквально, что XML появляются из воздуха и их никто не создаёт.
Использование же XML как замены ini или реестру для хранения пользовательских настроек программы будет подразумевать постоянные записи. Read-only не будет.
Так вот, смысл этого поста в том, чтобы указать, что XML имеет преимущества, если вы из него в основном читаете, но если вам нужно много писать, то XML - не самый удачный выбор. Его преимущества перед ini не окупаются его недостатками (тяжеловесность и необходимость таскать с собой парсер).
реестр отстой (все уже в него пишут, хлам один и ось тупить начинает)
ОтветитьУдалитьини рулит (простота использования)
xml сложно (ну просто жесть и документации на русском по нему нормальной не нашел пришлось из того что было ваять)))
По поводу применения XML: Delphi и Visual Studio применяют его для хранения настроек проекта, при этом, при изменениях в этих настройках, XML преспокойно переписывается :)
ОтветитьУдалитьSkype хранит настройки в XML и перезаписывает их. Если поискать, наверняка еще не одна программа найдется.
Ini-файлы, могут поддерживать Юникод, например, в Utf8.
Реестр безусловно удобен в части хранения часто меняющейся информации, но переносить настройки из реестра с компьютера на компьютер, все-таки не самое очевидное для пользователя занятие. Файл скопировать проще.
Перенос настроек вообще дело особенное, оно всегда тянет за собой проблемы переноса настроек, и пользователь решившийся на это понимает предстоящую сложность.
ОтветитьУдалитьВ последнее время множество программ обретают Portable версии для легкого переноса с места на место.
Стационарные программы, например как MS Office вряд ли нуждаются в частом переносе настроек, впрочем в Windows есть средства переноса настроек.
>>> Delphi и Visual Studio применяют его для хранения настроек проекта
ОтветитьУдалитьНастройки проекта - это и есть документ. Это не настройки программы.
Для настроек программы нет смысла использовать XML. Вы не получаете никаких преимуществ.
>>> Файл скопировать проще
Никто не запрещает кинуть в папку программы файлики BackupSettings.bat и RestoreSettings.bat
Ссылка в тему.
>>> Никто не запрещает кинуть в папку программы файлики BackupSettings.bat и RestoreSettings.bat
ОтветитьУдалитьЭто сродни тому, чтобы написать "открыть regedit, выбрать export, сохранить, скопировать, потом сделать двойной щелчок на файле". Тоже никто не запрещает и главное, это не так сложно. Но необходимость выполнять какие-то дополнительные действия при переносе программы, она, знаете ли, напрягает.
Может, мне пользователи такие ленивые попадаются :)
Тоже согласен, бат файлы это уже далеко не уровень домохозяек, если конечно вы не пишите софт для программистов.
УдалитьОчень интересный перевод, спасибо!
ОтветитьУдалитьПо поводу тормознутости работы с ini-файлами - у меня был случай, когда настройки окон (положение и размеры) сохранялись в ini при закрытии окна и считывались при создании. Так вот пройдясь по программе профайлером, выяснилось, что Api-функции чтения и записи Ini работают довольно медленно. Переписал код сохранения/загрузки этих данных с TIniFile на TMemIniFile удалось ускорить открытие каждой формы, где-то на 1/3 секунды. Дело было давно и точных цифр и названий я не помню, но помню, что выигрыш производительности был довольно заметным.
>>> Никто не запрещает кинуть в папку программы файлики BackupSettings.bat и RestoreSettings.bat
ОтветитьУдалить>> Это сродни тому, чтобы написать "открыть regedit, выбрать export, сохранить, скопировать, потом сделать двойной щелчок на файле". Тоже никто не запрещает и главное, это не так сложно. Но необходимость выполнять какие-то дополнительные действия при переносе программы, она, знаете ли, напрягает.
Лучший вариант, как мне кажется, это предусмотреть в самой программе кнопки: Export config, Import Config.
Export config, Import Config
УдалитьЭто точно, вот если бы во ВСЕХ приложениях были такие кнопочки и после переустановок винды или миграции на другой компьютер не надо было бы часами настраивать всё под себя как мы к этому привыкли на другой машине.
Читаю и плачу... :), бред сивой кобылы...
ОтветитьУдалитьini файлы, xml файлы, binary реестр.
Медленный парсинг. (Ужастно! Как будто ini и xml файлы размером с гигабайт).
ini файлы не поддерживают unicode (так это мои проблемы или операционной системы?!)
ini файл "слишком прост" а ну-ка признатесь кто делал секции [Common] [Common-Editors] [Common-Editors-Text] ведь делали же.
binary информацию в ini файл не положить, ага Base64 неподходит.
Ой-ой второй поток может перезаписать результаты первого. (Ужастно! Про блокировки никто не знает).
Программа может "эксклюзивно" открыть ini файл и заблокировать всех. (Без комментариев.)
xml файлы только для чтения, не надо туда ничего писать. (Без комментариев)
Реестр это худшее что они придумали, и совсем не для замены ini-files.
Чем текстовые конфиги плохи, понять не могу, им сто лет в обед, и на MS платформе прекрасно живут.
Если "сегодняшнее" приложение нельзя перенести с компьютера на компьютер простым copy deployment - хрош цена этому приложению.
>>> Ужастно! Как будто ini и xml файлы размером с гигабайт
ОтветитьУдалитьмой дорогой мальчик, это был 1995-й год ;)
>>> binary информацию в ini файл не положить, ага Base64 неподходит
Что характерно, реестру в недостатки пару кликов мышью записывают, а на поиск, прикручивание и накладные расходы реализации Base64 закрывают глаза.
>>> Чем текстовые конфиги плохи, понять не могу
Как вы планируете централизовано управлять настройками в домене? Как насчёт заблокировать некоторые настройки администратором, потому что пользователям не следует своими шаловливыми ручками их трогать? Это же не из воздуха берётся, а по отзывам и просьбам администратооров в реальных организациях.
Ах, да:
ОтветитьУдалить>>> xml файлы только для чтения, не надо туда ничего писать. (Без комментариев)
Не волнуйтесь, 8000 быдлокодеров по всему миру активно работают над устранением этой проблемы ;)
Проблема переносимости настроек, хранимых в реестре, с компа на комп - отнюдь не в том, что это сложно. Она в том, что если "винда" померла и загрузить ее не получается - из реестра настроек уже не вытащить никакими "официальными" способами. А ini-файл - без проблем.
ОтветитьУдалитьregedit.exe, File/Load hive, ткнули на улей с другой машины. Дальше - импорт, экспорт, что угодно.
ОтветитьУдалитьИли даже с консоли reg load.
Это можно сделать с WinPE или консоли восстановления дистрибутивного диска.
Это я для справки. Вообще, много интересного можно узнать, если иногда листать справку :)
Очень сомневаюсь, чтобы данные манипуляции освоил конечный пользователь.
ОтветитьУдалитьТоже согласен, гунсмокер очевидно пишет софт для людей которым не надо пережёвывать пищу перед тем как её положить в рот, одни спорят о софте для домохозяек, где нет всяких администраторов и прочего, а другие про какой-то специфический софт, где ещё над одним администратор, другой администратор а над ним главный администратор уровня БОГА где закопаешься в разделении прав, так для такого софта надо уже базы данных делать и в них хранить, а не в реестре и файлах.
УдалитьПо поводу решения проблем с загрузкой Windows - у тебя есть куча способов для этого:
ОтветитьУдалить- повреждение MBR ("Error loading operating system" или "Invalid partition table") - загружай консоль восстановления с дистрибутивного диска и давай команду fixmbr.
- повреждение загрузочного сектора ("NTLDR is missing" или "A disk error occurred") - загружай консоль восстановления с дистрибутивного диска и давай команду fixboot.
- повреждение конфигурации загрузки в boot.ini ("Windows could not start because of a computer disk hardware configuration problem", "Could not read from selected boot disk" или "Check boot path and disk hardware") - загружай консоль восстановления с дистрибутивного диска и давай команду bootcfg /rebuild.
- повреждение системных файлов ("Windows could not start because the following file is missed or corrupt" или "Unable to locate component") - загружай консоль восстановления с дистрибутивного диска и давай команду chkdsk. Если удаётся запустить машину в SafeMode, то можно дать команду sfc /scannow. В любом случае, можно поискать копии проблемных файлов в Windows\System32\DllCache или Windows\Repair.
- если ты создавал бэкап системы или он был создан автоматически (ASR) - жми F2 при загрузке с дистрибутивного диска.
- если проверки не помогли и бэкапа нет - запускай установку Windows в режиме исправления ("поверх").
- если был поверждён реестр - делай также, как и при поверждение системных файлов: сначала проверки, потом восстановление из бэкапа, потом ручной поиск файлов или установка поверх. Только для реестра копирование из Windows\Repair - это самый последний вариант, потому что там копия реестра, как она была после установки.
- также можно воспользоваться точками восстановления, которые создаются автоматически. Просто возьмите нужные файлы из \System Volume Information.
- также для реестра можно запустить chkreg, но её нужно брать отдельно.
- в любых случаях нужно пробовать last known good конфигурацию и безопасный режим. Причём, если вы не отключали точки восстановления, то будет доступна ещё и опция отката системы к последней точке восстановления.
Так что решаемо всё, просто KB надо полистать.
Кста, вот только сейчас ставил на Win7 покрытую мхом прогу. После перезагрузки комп напроч отказался грузится. Просто тупо вис.
ОтветитьУдалитьНе проблема, вставил дистрибутивный диск, выбрал восстановление системы, а потом - откат к чекпоинту.
К счастью, эта прога хоть и динозаврическая, была упакована в столь нелюбимый многими MSI-инсталлер, а не использовала самописные говно-установщики типа Inno Setup. Поэтому точка восстановления была создана автоматически.
Щёлкаем далее-далее-далее и получаем работающую систему!
"Введение реестра создаёт единую точку отказа" - у меня, кстати, на старой машине примерно раза два в год слетал реестр именно из-за повреждения куста при записи на диск. Причина оказалась в некачественном RAID-контроллере, бажная прошивка которого приводила к случайной порче данных на диске! Когда я это узнал, сказать, что я охуел - это ничего не сказать. Просто так оказалось, что порча данных, попадавшая на реестр, оказалась самой видимой для меня. Потом, я ещё обнаружил кучу других испорченных файлов. К счастью, повреждены оказались только такие вещи, которые можно было восстановить. Так что для меня "единая точка отказа" стала, скорее, благом - потому что я обратил внимание на своё железо. А то так бы и сидел, пока повреждение не пришлось бы на ценные данные. Как тут уже выше до меня говорили - в точках восстановления создаются резервные копии. А у меня вообще стоял Акронис, я просто откатывал систему. Понятно, что когда обнаружил такой косяк с RAID-контроллером - пришлось от него отказаться и систему всё же переустановить.
ОтветитьУдалитьДополню начавшийся оффтопик в комментах.
ОтветитьУдалитьВот статья из KB, которая описывает, что делать при повреждении реестра.
И хватит уже на эту тему. Пост был про другое.
"Ой-ой второй поток может перезаписать результаты первого. (Ужастно! Про блокировки никто не знает)." - отличный сценарий для отказа в обслуживании
ОтветитьУдалитьОчень спорная\навязчивая\заказная\провокационная статья.
ОтветитьУдалитьПродвинутые юзеры уже давно поняли всю прелесть портебельных програм, сохраняющих все настройки у себя в папки(своя рубашка ближе к телу)(и это логично\понятно\безопасно, чтобы там не утверждали).
Продвинутых же юзеров с из года в год становиться больше - это тоже доказанные факт, что поколение школьников умнее предыдущего поколения.
Отсюда логический вывод - в будущем, реестр будет нужен только самой ОS, и не кому более - будет по сути тот же файл настроек, лежащий под боком у ОS.
Точка.
Скажите, пожалуйста, а почему именно так? Откуда это? Где про это написано?
ОтветитьУдалить"INI-файлы имеют ограничение в максимальный размер - не более 32 Кб"
Почему именно 32 Кб? Что будет если размер будет больше? Беда?
> Скажите, пожалуйста, а почему именно так? Откуда это? Где про это написано?
ОтветитьУдалить> Почему именно 32 Кб? Что будет если размер будет больше? Беда?
Написано об этом в KB78346. Функции GetPrivateProfileString/WriteProfileString начали свою жизнь в Windows 3.x, были 16-битными, счётчик длины был 16-битным целым со знаком, что даём максимум 32kb длины. В Windows 9x эти функции были расширены до 32-битных, но из-за введения реестра остались лишь для совместимости и возможности быстрой перекомпиляции старых 16-битных приложений. Их внутренняя реализация по прежнему была ограничена. Данные за пределом границы не считывались, а при записи - усекались.
Системы на базе Windows NT (включая современные XP и выше) не имеют подобного ограничения.
В Delphi классы модуля IniFiles имеют различную реализацию. TIniFile является обёрткой над Win32 API и будет иметь все ограничения на Win9x (если вы где-нибудь найдёте сегодня такую систему). Класс TMemIniFile содержит собственную реализацию парсера и не подвержен ограничениям ни на каких системах.
Предлагаю (как пример) мою потоко-безопасную поделку
ОтветитьУдалитьна основе TMemIniFile, с дополнительными возможностями...
https://yadi.sk/d/6EVk5-JsdBwAg
И никаких проблем с сохранением\чтением.
Сегодня большинство юзеров просто совершенно не понимают,
ОтветитьУдалитьгде/в каком месте хранятся их (важные) данные\настройки, и даже, если этим
и озабочиваются - просто тупо не могут разобраться.
А когда все данные\настройки программы лежат в папке самой программы - вот это
прозрачно\понятно и безопасно для простого юзера более чем. А права\шифрование
в ini файле вполне возможно, просто всё зависит от желания\квалификации\ленивости
самого программера - которому проще всю безопасность отдать непонятно куда\
на растерзание реестрам\(вражеским)чужим дядям из мелкософта.
Реестр - это по сути, база данных. Что как бы намекает на SQLite в папке самой программы, со всеми бонусами не уступая реестру Винды.
ОтветитьУдалитьВообще то реестр Windows и есть иерархически построенная база данных параметров системы. Вот только SQL там никаким боком.
ОтветитьУдалитьВот Михаил писал (всех рьяных сторонников INI касается), что, дескать, "HKLM упал - и ничем его не поднять, а вот INI - это дааааа!". А какая, нафиг, разница, если HKLM и придуманный HKLM.ini одну и ту же информацию содержат, и одинаково дербанятся и системой, и программистами? Мне думается, у вас просто нет статистики падения INI такого размера и нагрузки, а для себя Вы придумали что это будет лучше, чем реестр. Но почему? Подтвердите, чем это лучше?
ОтветитьУдалитьА вообще, INI справедливо использовать для "своих местных" настроек, а в реестр лазить только по делу. Почему-то многие забыли об этом, и считают, что в реестр можно безнаказанно гадить. Но Вы же выполняетесь на компьютере пользователя, а не у себя дома! Как так-то?
Многое из перечисленного это ограничения ОС, а не формата.
ОтветитьУдалитьХранить данные в xml, xml в zip архив, полученный zip записать в реестр :)
ОтветитьУдалить