Ver 3 が最高と言っているのであれば、95 (4.0)、98 (4.1)、Me (4.9) や NT 4 (4.0)、2000 (5.0)、XP (5.1/5.2)、Vista (6.0)、7 (6.1) のような非 Ver 3 には関わらず、レジストリ―のない ini ファイルの時代に引きこもってた方が幸せなのではないでしょうか。
また、環境を復元するという点では、Program Files 以下だけではなく Windows フォルダーもコピーする必要があるでしょう。
Windows フォルダーを適切に複写しようとしたら「エクスプローラーから DnD でコピー」なんかじゃ絶対にできませんね。
適切に Windows フォルダーをコピーするレベルで復元するのであれば、やはり単純にフルバックアップから戻した方が手間の面からも楽ですね。Windows 標準機能だけでできますし。
iniの方が1000倍もマシな設計です．
現実的な話をすると、今の Windows レジストリー上に含まれている ini ファイルを展開したとしたら、テキストレベルで数十 MB とかが当たり前になります。
単純なテキストファイルで、かつセクション程度しか階層構造がないファイルであるため、ここから対象となる場所を探して適切に変更する、というだけでもかなり手間のかかる話です。
また、速度的にもデメリットが非常に大きくなりますし、書き込み時の整合性確保周りも面倒ですね。
それを回避するためにカテゴリーごとなどある程度の単位で分割するとしたら、今度は大量の ini ファイルに分割されることとなってしまいます。
その上で、システムの標準設定値をオーバーライドするユーザー固有の設定をユーザー環境に別途 ini で……とかやるってことでしょうか。
そこまで行くと ini に 1000 倍もの優位性があるとはとても思えませんが。
ini ファイルに使いやすいと言える部分があるとしたら、それはユーザーフォルダー等の Windows 管理下に無い部分にプログラムをインストールするようなパターン程度です。
そして、その場合の話としては「ini ファイルであること」ではなく「設定を同じ場所にまとめる事で環境を汚染しない事」が重要となるだけで、別に ini ファイルである必要はありません。
この点では XML だろうと YAML だろうとなんでも一緒で、「ini ファイルの特長」ではありません。
Firefox の例などを出しましたが、「データ表現の能力が低い (一行のテキストのみ)」「速度面で不利」「アプリケーション側で情報を扱いにくい場合がある (階層的な表現はレジストリーと同等)」という面から、自由度が高いからテキストがいい→でも ini ファイルの表現能力じゃ使いにくいので、簡単なところだけ ini にして実際の情報は XML で、というパターンもある訳です。
速度面の影響は、テキストファイル一般では常に付きまといますね。
Ver3が最高の法則 (スコア:0)
Ver1.荒削りだけど光る原石
Ver2.Ver1でできなかった事を全て詰め込んだ結果ごちゃごちゃに
Ver3.Ver2までの反省点を踏まえて必要十分な内容で再構築
Ver4以降.バージョンを上げるために無駄なフューチャーを追加していく
Re: (スコア:0)
95, 98 ときて Me
2000, XP ときて Vista
あるいは NT4, 2K(XP) ときて Vista
はどうかなぁ・・・
Re:Ver3が最高の法則 (スコア:1)
Ver 3 が最高と言っているのであれば、95 (4.0)、98 (4.1)、Me (4.9) や NT 4 (4.0)、2000 (5.0)、XP (5.1/5.2)、Vista (6.0)、7 (6.1) のような非 Ver 3 には関わらず、レジストリ―のない ini ファイルの時代に引きこもってた方が幸せなのではないでしょうか。
Re:Ver3が最高の法則 (スコア:2)
レジストリなんて要らんというのは同意
ソフトの完全なアンインストールとかしんどい。
レジストリが残ってるおかげでなんかおかしくなっちゃうとかよくある話。
Re:Ver3が最高の法則 (スコア:1)
レジストリーは「よりマシな ini」ですので、レジストリーが持ってる問題の大半は ini でも持ってますよ。
win.ini 他のシステム設定ファイルに平気で設定を書き込むアプリケーションは大量にありましたし、Win9x 前提アプリでも同じノリでユーザー固有設定を HKLM 以下に書き込むクソアプリとか平気でありましたので。
Re:Ver3が最高の法則 (スコア:3)
何がどう「よりマシ」なんでしょう？？？
実際問題、レジストリはちらばって管理しきれないけど、iniは大抵exeと同じか近い所にあって探すのに苦労することないですよ。コピーも楽だし。
iniで管理してるアプリはそのフォルダだけコピれば他の環境でも同じように動きます。
レジストリのは他のPCで同じように動かすのがそうとう面倒くさい。
Re:Ver3が最高の法則 (スコア:1)
そういう「一つの環境を一人が占有して利用する事しか考えていない」状況であれば、そういう話もあるかもしれませんね。
で、会社の共用マシン (利用者はログオンするユーザーを切り替えて使う) などのパターンで、MUA が認証情報を ini ファイルに書くようなパターンだと、どこに配置される必要がありますか?
ユーザーごとに固有の ini ファイルを作成する必要が出てくるかと思いますが、そのファイル群は exe と同じか近いところに配置されるのが当たり前なのでしょうか。
ini ファイルが exe 近傍に配置されうるというのは「そういう時代」「そういう環境」でしか成立しない話だと思いますよ。
なお、.exe.config なんかは .exe と同じところに配置されますが、普通「アプリケーション固有の情報」までしか持たず、「ユーザー固有の情報」は普通 %AppData% 行きですね。
あと、バイト列や複数行からなる文字列を簡単に格納可能な ini ファイルって、既に ini ファイルではないように思いますが、どうでしょうか。
Re:Ver3が最高の法則 (スコア:2)
> 「一つの環境を一人が占有して利用する事しか考えていない」状況
Unix系OSはレジストリ無いけど、Windowsよりよほどきちんときっちりマルチアカウント対応できてる。昔から。(最近のWindowsアプリはだいぶマシになったと思うけど)
当然、ユーザー毎の設定情報はユーザーホームの下でしょ。くだらないあげ足取り。
なんでもかんでもiniファイルでやれば良いわけじゃない。適切にファイル分ければいいじゃない。それでもレジストリよりはずっと使いやすい。
Re:Ver3が最高の法則 (スコア:1)
自身のコメントである #2046893 [srad.jp] で言っている「ini のメリット」を自己否定されているように見えますけど。
適切に設定等を配置する場所を分散させるということは、「単純にコピーして同じように動く」事ができなくなります。
「なんでもかんでも ini ファイルでやれば良いわけじゃない」というのはレジストリーであっても当然同様の話ですし、最初から「レジストリーが持ってる問題の大半は ini でも持ってます」と言っています。
アプリケーションの設定をレジストリーに格納する場合は HKCU\Software 以下にベンダー\アプリケーションで固有のエントリーを作るものですし、この流儀にしっかり沿って作られているものであれば格納されている情報を色々探す必要などありません。
レジストリーに情報を適切に格納できないアプリケーションも ini ファイルを使うようにしたら解決! なんていうのはあり得ないわけで、残念なアプリの問題をレジストリーの問題にすり替えてませんか? という話です。
HKCU 以下の該当エントリーを消さないアプリのアンインストーラーがユーザー固有フォルダー以下の ini ファイルを消してくれるでしょうか。
レジストリーにゴミが残るのはうざくても、ユーザーフォルダーの中にゴミが残るのはうざくないのでしょうか。
いずれも同程度にダメで、同程度にうざい話だと思いますよ。
Re: (スコア:0)
なぜ、レジストリーのゴミが嫌われるのかをご存じないようですね。
それがあると、何かと動きが鈍くなるからなんです。要するにシステムのレスポンスを悪くする。
iniの消し忘れでは、そういう事はありませんよね？
そういう事です。
Re:Ver3が最高の法則 (スコア:1)
「何かと動きが鈍くなる」ではなく、レジストリーからの読み出しなど、アクセスが発生するタイミングでの遅延が発生する、ですね。
これは、不要なエントリーが存在していて、これを読み取るという無駄な作業が発生する事での遅延が起きる、ということです。
また、もう一つあるのがレジストリーを格納するファイルの肥大化の原因となったり、フラグメントの理由となる、という事です。こちらも低速化の原因となります。
これらを ini ファイル消し忘れのパターンと比較してみます。
「読み取りが発生するタイミングで、利用しない無駄なエントリー/内容を読み込む無駄の発生」は、これは普通に発生しますね。該当フォルダーの一覧取得やデスクトップ検索などが無駄に読み取るパターンです。
「肥大化の原因やフラグメントの理由となる」点についても、こちらも「普通のファイル」である以上、発生しえます。
NTFS の場合、小さなファイルは MFT 内に入りますから、削除し忘れの場合はデータ領域のフラグメントよりもより解消し辛い事となります。
MFT の肥大化は (ある程度大きなサイズをまとめて確保していく MFT の特性上) ディスクスペースの占有、IO 性能の低下などをもたらしますし、断片化はファイルアクセスに顕著な悪影響が発生します。
レジストリーであってもファイルであっても、ゴミは邪魔になるし、大量にゴミが発生するような使い方であればどっちにしろ悪影響は避けられません。
Re: (スコア:0)
全く解ってないですね．
各アプリの，設定とは無関係のヘルプの内容みたいなクソ文章がレジストリの中に保存されてるのはおかしいと思いませんか？
逆にOS再インストールした時にディレクトリ移動するだけで環境復元出来ないのはふざけてると思いませんか？
iniの方が1000倍もマシな設計です．
Re:Ver3が最高の法則 (スコア:1)
各アプリの，設定とは無関係のヘルプの内容みたいなクソ文章がレジストリの中に保存されてるのはおかしいと思いませんか？
ini ファイルで行頭に ; が付いている行の事ですか?
「格納することもできる」と「格納するのが普通」は全然異なる話ですけど。
レジストリー情報一般でそのようなテキストが入っているというのは見たことがないのですが、どの辺りの話をされていますか?
逆にOS再インストールした時にディレクトリ移動するだけで環境復元出来ないのはふざけてると思いませんか？
いいえ、まったく思いません。
*NIX 系で「/usr/bin、/usr/lib 等だけ別マシンに映して環境復元できないのはふざけてると思いませんか」って言ってるように思えますけど。
設定も含めてしっかりコピーして当たり前だと言うのであれば、わざわざ選択的にコピーするよりも単純にフルバックアップから戻した方が「復元」的な意味では簡単ですし。
また、環境を復元するという点では、Program Files 以下だけではなく Windows フォルダーもコピーする必要があるでしょう。
Windows フォルダーを適切に複写しようとしたら「エクスプローラーから DnD でコピー」なんかじゃ絶対にできませんね。
適切に Windows フォルダーをコピーするレベルで復元するのであれば、やはり単純にフルバックアップから戻した方が手間の面からも楽ですね。Windows 標準機能だけでできますし。
iniの方が1000倍もマシな設計です．
現実的な話をすると、今の Windows レジストリー上に含まれている ini ファイルを展開したとしたら、テキストレベルで数十 MB とかが当たり前になります。
単純なテキストファイルで、かつセクション程度しか階層構造がないファイルであるため、ここから対象となる場所を探して適切に変更する、というだけでもかなり手間のかかる話です。
また、速度的にもデメリットが非常に大きくなりますし、書き込み時の整合性確保周りも面倒ですね。
それを回避するためにカテゴリーごとなどある程度の単位で分割するとしたら、今度は大量の ini ファイルに分割されることとなってしまいます。
その上で、システムの標準設定値をオーバーライドするユーザー固有の設定をユーザー環境に別途 ini で……とかやるってことでしょうか。
そこまで行くと ini に 1000 倍もの優位性があるとはとても思えませんが。
ini ファイルに使いやすいと言える部分があるとしたら、それはユーザーフォルダー等の Windows 管理下に無い部分にプログラムをインストールするようなパターン程度です。
そして、その場合の話としては「ini ファイルであること」ではなく「設定を同じ場所にまとめる事で環境を汚染しない事」が重要となるだけで、別に ini ファイルである必要はありません。
この点では XML だろうと YAML だろうとなんでも一緒で、「ini ファイルの特長」ではありません。
Re: (スコア:0)
Portableアプリが流行る理由を考えて見ませんか？
そうしたら、レジストリーの面倒くささとかがわかると思いますけどね。
ディスクスペースも現在は大量にあり、別に設定を特別なツールなしに読めるテキストでも問題ないし
むしろそちらのほうが簡潔で自由度が高い。
iniファイルもさることながら、レジストリーのそういう硬直性が嫌なんです。
レジストリーを使わないとすると、iniしかありませんしね。
多人数で使い回しする場合は確かに困りますが、そういう所では別にレジストリーでもいいわけですよ。
できるだけ、一旦壊れる起動できなくなるレジストリーみたいに全てを一緒くたにするよりも、iniのように独立性が高いほうがなにかといいと思いますけどね。
Re:Ver3が最高の法則 (スコア:1)
親コメントにもある通り、ポータブルなアプリが利用するのは「移動が容易な設定ファイル」であって「ini ファイルであること」はどうでもいい訳です。
そんなに ini ファイルが素晴らしいのであれば、なぜ %AppData%/Mozilla 以下に .ini ファイルはほとんどなく、実際のプロファイル情報には .sqlite や .xml、.db などが並ぶのでしょうか。
また、移動プロファイルなどもある通り、レジストリーは固有のマシンのみに 100% 縛られるものではありません。
ini ファイルを利用したとしても、マシン固有の情報とならないように設定の保持や利用に開発側で気を使う必要がありますし、レジストリーであってもエクスポートしたり、環境移行ユーティリティー (OS 標準) でコピーすることも可能です。
Firefox の例などを出しましたが、「データ表現の能力が低い (一行のテキストのみ)」「速度面で不利」「アプリケーション側で情報を扱いにくい場合がある (階層的な表現はレジストリーと同等)」という面から、自由度が高いからテキストがいい→でも ini ファイルの表現能力じゃ使いにくいので、簡単なところだけ ini にして実際の情報は XML で、というパターンもある訳です。
速度面の影響は、テキストファイル一般では常に付きまといますね。
最近は .manifest とか .exe.config (いずれも XML)、そしてユーザー固有となるアプリケーションごとの情報は %AppData% 以下に (任意の取り扱いやすい形式で) 入れる、などという形が幅を利かせておりまして。
Win3.x 時代などの .ini ファイルに依存していた時代では、.ini ファイルが壊れたら普通に起動できなくなってましたけど。
今はレジストリーに依存しているから、レジストリーの破損が大きな影響がある、というだけですね。
また、アプリケーションのユーザー設定が格納されるのはシステム用のレジストリーファイルではなく、ユーザー固有のレジストリーファイルで、通常は %USERPROFILE%\ntuser.dat (バックアップも自動作成される) ではないでしょうか。
これが壊れてログオンできなくなることはありますが、Windows 自体が起動できなくなることはありません。