アカウント名:
パスワード:
Ver1.荒削りだけど光る原石Ver2.Ver1でできなかった事を全て詰め込んだ結果ごちゃごちゃにVer3.Ver2までの反省点を踏まえて必要十分な内容で再構築Ver4以降.バージョンを上げるために無駄なフューチャーを追加していく
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 ファイルの時代に引きこもってた方が幸せなのではないでしょうか。
レジストリなんて要らんというのは同意
ソフトの完全なアンインストールとかしんどい。レジストリが残ってるおかげでなんかおかしくなっちゃうとかよくある話。
レジストリーは「よりマシな ini」ですので、レジストリーが持ってる問題の大半は ini でも持ってますよ。 win.ini 他のシステム設定ファイルに平気で設定を書き込むアプリケーションは大量にありましたし、Win9x 前提アプリでも同じノリでユーザー固有設定を HKLM 以下に書き込むクソアプリとか平気でありましたので。
何がどう「よりマシ」なんでしょう？？？
実際問題、レジストリはちらばって管理しきれないけど、iniは大抵exeと同じか近い所にあって探すのに苦労することないですよ。コピーも楽だし。iniで管理してるアプリはそのフォルダだけコピれば他の環境でも同じように動きます。レジストリのは他のPCで同じように動かすのがそうとう面倒くさい。
そういう「一つの環境を一人が占有して利用する事しか考えていない」状況であれば、そういう話もあるかもしれませんね。
で、会社の共用マシン (利用者はログオンするユーザーを切り替えて使う) などのパターンで、MUA が認証情報を ini ファイルに書くようなパターンだと、どこに配置される必要がありますか? ユーザーごとに固有の ini ファイルを作成する必要が出てくるかと思いますが、そのファイル群は exe と同じか近いところに配置されるのが当たり前なのでしょうか。
ini ファイルが exe 近傍に配置されうるというのは「そういう時代」「そういう環境」でしか成立しない話だと思いますよ。 なお、.exe.config なんかは .exe と同じところに配置されますが、普通「アプリケーション固有の情報」までしか持たず、「ユーザー固有の情報」は普通 %AppData% 行きですね。
あと、バイト列や複数行からなる文字列を簡単に格納可能な ini ファイルって、既に ini ファイルではないように思いますが、どうでしょうか。
> 「一つの環境を一人が占有して利用する事しか考えていない」状況Unix系OSはレジストリ無いけど、Windowsよりよほどきちんときっちりマルチアカウント対応できてる。昔から。(最近のWindowsアプリはだいぶマシになったと思うけど)当然、ユーザー毎の設定情報はユーザーホームの下でしょ。くだらないあげ足取り。
なんでもかんでもiniファイルでやれば良いわけじゃない。適切にファイル分ければいいじゃない。それでもレジストリよりはずっと使いやすい。
自身のコメントである #2046893 [srad.jp] で言っている「ini のメリット」を自己否定されているように見えますけど。 適切に設定等を配置する場所を分散させるということは、「単純にコピーして同じように動く」事ができなくなります。
「なんでもかんでも ini ファイルでやれば良いわけじゃない」というのはレジストリーであっても当然同様の話ですし、最初から「レジストリーが持ってる問題の大半は ini でも持ってます」と言っています。
アプリケーションの設定をレジストリーに格納する場合は HKCU\Software 以下にベンダー\アプリケーションで固有のエントリーを作るものですし、この流儀にしっかり沿って作られているものであれば格納されている情報を色々探す必要などありません。 レジストリーに情報を適切に格納できないアプリケーションも ini ファイルを使うようにしたら解決! なんていうのはあり得ないわけで、残念なアプリの問題をレジストリーの問題にすり替えてませんか? という話です。
HKCU 以下の該当エントリーを消さないアプリのアンインストーラーがユーザー固有フォルダー以下の ini ファイルを消してくれるでしょうか。 レジストリーにゴミが残るのはうざくても、ユーザーフォルダーの中にゴミが残るのはうざくないのでしょうか。 いずれも同程度にダメで、同程度にうざい話だと思いますよ。
なぜ、レジストリーのゴミが嫌われるのかをご存じないようですね。それがあると、何かと動きが鈍くなるからなんです。要するにシステムのレスポンスを悪くする。
iniの消し忘れでは、そういう事はありませんよね？
そういう事です。
「何かと動きが鈍くなる」ではなく、レジストリーからの読み出しなど、アクセスが発生するタイミングでの遅延が発生する、ですね。 これは、不要なエントリーが存在していて、これを読み取るという無駄な作業が発生する事での遅延が起きる、ということです。 また、もう一つあるのがレジストリーを格納するファイルの肥大化の原因となったり、フラグメントの理由となる、という事です。こちらも低速化の原因となります。
これらを ini ファイル消し忘れのパターンと比較してみます。
「読み取りが発生するタイミングで、利用しない無駄なエントリー/内容を読み込む無駄の発生」は、これは普通に発生しますね。該当フォルダーの一覧取得やデスクトップ検索などが無駄に読み取るパターンです。
「肥大化の原因やフラグメントの理由となる」点についても、こちらも「普通のファイル」である以上、発生しえます。 NTFS の場合、小さなファイルは MFT 内に入りますから、削除し忘れの場合はデータ領域のフラグメントよりもより解消し辛い事となります。 MFT の肥大化は (ある程度大きなサイズをまとめて確保していく MFT の特性上) ディスクスペースの占有、IO 性能の低下などをもたらしますし、断片化はファイルアクセスに顕著な悪影響が発生します。
レジストリーであってもファイルであっても、ゴミは邪魔になるし、大量にゴミが発生するような使い方であればどっちにしろ悪影響は避けられません。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
物事のやり方は一つではない -- Perlな人
Ver3が最高の法則 (スコア:0)
Ver1.荒削りだけど光る原石
Ver2.Ver1でできなかった事を全て詰め込んだ結果ごちゃごちゃに
Ver3.Ver2までの反省点を踏まえて必要十分な内容で再構築
Ver4以降.バージョンを上げるために無駄なフューチャーを追加していく
Re: (スコア:0)
95, 98 ときて Me
2000, XP ときて Vista
あるいは NT4, 2K(XP) ときて Vista
はどうかなぁ・・・
Re: (スコア: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: (スコア:2)
レジストリなんて要らんというのは同意
ソフトの完全なアンインストールとかしんどい。
レジストリが残ってるおかげでなんかおかしくなっちゃうとかよくある話。
Re: (スコア: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 性能の低下などをもたらしますし、断片化はファイルアクセスに顕著な悪影響が発生します。
レジストリーであってもファイルであっても、ゴミは邪魔になるし、大量にゴミが発生するような使い方であればどっちにしろ悪影響は避けられません。