レジストリが無ければもっとまともなOSだったね

トラブルの9割はレジストリだろ

まったく関係ない。

レジストリにまつわる大きな勘違い。

■レジストリが肥大化した！
レジストリファイルサイズが大きくなったからどうかしたのですか？

■レジストリが肥大化すると起動が遅くなる
レジストリファイルの内容すべてを読み込んでいるわけじゃないから関係ありません。

■でもアプリをインストールしたらパソコンの起動が遅くなった！
レジストリは関係ありません。パソコンの起動時にアプリが実行されているから遅くなっているだけです。
もしそのアプリがレジストリをやめてiniファイルを使用したとしても、起動時間は同じですよ。

■レジストリが壊れるとパソコンが起動しなくなる！
ファイルが壊れることがそもそも異常でしょう？ もしそうなったらファイルどころじゃありませんよ。

■レジストリを最適化すると速くなる！
速くはなりません。そもそも遅くなっていません。レジストリの最適化とは、ファイル内の未使用データ領域を
消すことによってファイルサイズを減らしているだけです。もちろんレジストリファイルサイズが減っても起動時間に影響はありません。

■一般ユーザーがレジストリをいじるとパソコンがおかしくなる。危険だ。
それをいったら一般ユーザーがシステムファイルをいじってもパソコンはおかしくなります。
だからファイルにアクセス制限がかかっています。もちろんレジストリにもアクセス制限はあり、
システム関連のレジストリを読み書きするときには適切な権限が必要です。

■レジストリファイルって一つのファイルになっているんだよね。
違います。複数のファイルに分かれています。システム用と各ユーザー用に別のファイルになっています。

というのは嘘で
レジストリに書き込みと削除を繰り返し行なうと断片化します。
断片化が起きると読み込み速度も低下します。

■レジストリって書き込みと削除を繰り返すと断片化するよね？
断片化は（ほとんど）しません。これは「レジストリの最適化」と
関係がある話ですが、レジストリファイルの大きさは頻繁に変わったりしません。

書き込みしたからといってその場ですぐに増えるわけじゃないし、
削除してもレジストリファイルのサイズは減りません。

ファイルサイズは必要なときに余裕を持って拡大され
レジストリのキーを削除してもファイルサイズは減りません。

このような、ファイルの断片化を防ぐ機能が実装されています。
それゆえに、レジストリファイルの中に未使用領域ができるため、
「レジストリの最適化」（未使用領域の削減）という処理の意味がでてくるわけです。

もちろんレジストリの最適化はファイルサイズを減らすだけで
起動時間などの重さには一切関係ありません。

レジストリは設定を酷く散らばすため変なアプリが書き換えたら設定が変になります。
最悪システムです。

■レジストリは設定を酷く散らばすため変なアプリが書き換えたら設定が変になります。

それはレジストリに限った話ではありません。

■レジストリが壊れるとパソコンが起動しなくなる！
ファイルが壊れることがそもそも異常でしょう？ もしそうなったらファイルどころじゃありませんよ。

■レジストリって書き込みと削除を繰り返すと断片化するよね？
断片化は（ほとんど）しません。これは「レジストリの最適化」と
関係がある話ですが、レジストリファイルの大きさは頻繁に変わったりしません。
書き込みしたからといってその場ですぐに増えるわけじゃないし、
削除してもレジストリファイルのサイズは減りません。
ファイルサイズは必要なときに余裕を持って拡大され
レジストリのキーを削除してもファイルサイズは減りません。


後者ではレジストリがRDBのような独自ストレージの仕組みを
内部に持っていることを示唆しているのだから、
その仕組みにバグがあればレジストリが壊れることはあるでしょう。
前者でファイルシステムの信頼性の話にもっていくのはおかしい。

まぁ、壊れることなんて滅多にないけどね。一生のうちに一度おめにかかれればいいほうだろう。

SSD使えばいくら断片化しようがかわらん？

>>7
レジストリが最悪だろうが

10 名前：名無し~3.EXE[] 投稿日：2008/09/21(日) 21:28:39 ID:kkiAhz6P
>>7
レジストリが最悪だろうが

レジストリは最悪。

アプリを削除してもしつこく残り続ける。
掃除しないとOSあぼん。
設定をしつこく散らばし、掃除が面倒、しかも読み込んで重くなる。

■アプリを削除してもしつこく残り続けるんですが？

それはOSのせいですか？ アプリを消しても設定ファイルが残るのはOSのせいですか？

アンインストーラーが適切に削除すればいいだけの話だわな。

少なくとも、そういう設計なwindowsが最悪なだけ

ID:kkiAhz6Pを見てみましょう。ほら、何も中身がないｗ

名前：名無し~3.EXE[] 投稿日：2008/09/21(日) 18:56:44 ID:kkiAhz6P
トラブルの9割はレジストリだろ

6 名前：名無し~3.EXE[] 投稿日：2008/09/21(日) 19:49:32 ID:kkiAhz6P
レジストリは設定を酷く散らばすため変なアプリが書き換えたら設定が変になります。
最悪システムです。

10 名前：名無し~3.EXE[] 投稿日：2008/09/21(日) 21:28:39 ID:kkiAhz6P
レジストリが最悪だろうが

12 名前：名無し~3.EXE[] 投稿日：2008/09/21(日) 21:32:20 ID:kkiAhz6P
レジストリは最悪。

15 名前：名無し~3.EXE[] 投稿日：2008/09/21(日) 22:33:32 ID:kkiAhz6P
少なくとも、そういう設計なwindowsが最悪なだけ

設定ファイルをあちこちにばら撒いて訳わかめの、Linux（笑）のほうがいいとでも？

>>17
設定はしやすいし、重くもならないね

レジストリなんてただのDBなんだから、重いもヘッタクレもないだろｗ
読み書きの実装にもよるが、少なくともファイルに依存したシステムよりずっとスマートだｗ

ID:cPL3uwn3
糞スレかと思ったのに、勉強になっちゃったよ乙！

■レジストリについて…

オンメモリだから基本的に重くなります。
しかもレジストリを使用すると設定が散らかるために
OSがクラッシュする原因になります。
アンインストールしてもしつこく残り続けます。
弊害があまりに大きいので他のOSユーザーからは批判対象になっています。

つまりDBを使ったことのない犬厨だと

■オンメモリだから基本的に重くなります。

一部キャッシュはしていますが、すべてオンメモリではありません。
それに、そもそもレジストリだからオンメモリになるんですか？
それがレジストリではなくiniファイルだったとしても結局は同じことでしょう？

そもそもレジストリの意味が分かってねー奴がいるな。

■そもそもなぜレジストリなのですか？ 普通のテキストファイルでもよかったのでは？

なぜレジストリか。それはレジストリの方が速くて、
メモリ使用量も少なくて、ディスク使用量も少ないからです。

驚きましたか？

ではどういう理屈でそうなのか。説明しましょう。

普通のテキストファイルなら、全体を読み込まないと内容はわかりません。
途中のデータだけを参照するということはできないのです。
レジストリは途中のデータを参照できるように作られているため
データが途中であってもすぐに参照できます。

もしテキストファイルが独自形式だとしたら、アプリごとにテキストファイル解釈コードが
記述されます。プログラムごとにそういうコードが存在するためメモリ使用量も増えます。

レジストリはバイナリファイルになっています。これは無駄なデータが存在しないということです。
ディスクから読み込む量も減るので速く参照できます。当然メモリ使用量も減ります。

いまどきそんなのたいした負荷ではないのでは？と思うかもしれません。
そうですね。レジストリの方が優れていても今ではたいした負荷ではありません。
でもレジストリが設計されたのは今から10年以上前の話です。当時レジストリを作る理由は大きかったのです。

もうやめるべきでは？と思うかもしれません。でもやめる理由がありません。やめることで何が改善されるのですか？
ユーザーフォルダの下に設定ファイルがたくさんできる方式に変えてそれで何が改善されますか？

ゴミが残るのが最大で唯一といっていい問題だな。

やべっｗ何この糞スレ改め良スレｗ

レジストリ神のおかげで目からウロコ連発で、めちゃめちゃ参考になるんですけどｗ
完全にレジストリ勉強スレになったな。

やっぱり、みんなレジストリが糞の根源と思っていたんだ。
ホッとした。よかった。

>>28
そこは揺るぎない事実だけどな

13 名前：名無し~3.EXE[sage] 投稿日：2008/09/21(日) 21:33:37 ID:cPL3uwn3
■アプリを削除してもしつこく残り続けるんですが？

それはOSのせいですか？ アプリを消しても設定ファイルが残るのはOSのせいですか？

Visual Studioで開発するとインストーラ付きにしてもゴミが残ったりするからな。
OSのせいといってもいいだろ。
インスーラなしでもexeやdll削除の際にそれに関連するものは削除してくれてもいい。

＞すべてオンメモリではありません。

確かに「すべて」オンメモリではありませんが、
「ある程度」オンメモリになってしまえば、レジストリの肥大化により
os自体が重くなってしまうという現象には変わりないのです。

しかもゴミが残るのでずっと重くなりっぱなしで、消したら消したでトラブルになってしまいます。

そして、レジストリのオンメモリの弱点です。
必要な時にだけ設定を参照しに行くほかの
ファイル設定方式と違えば問題点が大きいのです。

問題なのは肥大化することによるオンメモリであり、
レジストリ信者の

「レジストリのいいところだけを取り扱い続ける恣意的すぎるプロ場ガンだと
それにだまされるカルト大衆」は自殺すれば世の中平和。

俺の全財産の額も肥大化している。

＞■

をつけた人の文章を読んでください。
あまりにも詭弁があふれております。
こちらが指摘した「設定が散らばってOSクラッシュの原因になる」については
答えもしませんし、それ以前に「重くなる」ことについては「すべての」といえばすむと思っています。

しかしよく考えてください。１００あったとして１００じゃなければ重くならないのでしょうか？
10とか20とかでも十分重くなるしレジストリが汚れるという現象自体はあるのではないのでしょうか？

それを言わずに恣意的なレジストリの美点だけを取り上げ続けるプロバガンダにはもううんざりです。
レジストリとともに消したいです。

> 「設定が散らばってOSクラッシュの原因になる」

答えるまでもなく、普通に考えて、ありえなくねｗ

レジストリの弱点

あまりにもわかりにくい管理データー方式。

レジストリを編集するに当たって
物凄いめんどくさい作業をしたことはあるでしょう。
レジストリが無いlinuxを使った人ならわかると思うけど、
凄くわかりやすい。編集もしやすい。

散らかったりアボンしてしまう管理形式。

レジストリがクソみたいな設定をするだけでOS全体に酷い被害を与えてしまうことがある。
しかも消せなかったりする。ゴミが残る。
だからレジストリを使わないアプリに人気があります。

消しにくい
レジストリが重くなり続けても消しにくいのです。
なので掃除ソフトを使用しますが、
使用したことによってトラブル続出なんてことがよくあります。

いい加減まともなDBを作成しろよMS。

設定が散らばるどころか、設定が一つのファイルにまとまっているしさぁｗ

>>36
Linuxで変な設定をした結果 X Windowがまともに起動しくなったよ。
あれなんで？

>>38
がんばって一生懸命働きまくって財産を肥大化させてくださいお願いします。
２ちゃんはやらない方がいいでしょう。

まあ、ここで事実を突きつけるのはかわいそうだけどさぁ。

実は、Linuxもレジストリ、導入したのよね。

これが証拠。
http://www.linuxtopia.org/online_books/centos_linux_guides/centos_desktop_deployment_guide/figs/intro/gconf-editor.png

一部のディストリでしょ

データベースの、インデックスという物のイメージがわくかどうかで、
理解度が変わるんだろうなぁ。

そうそう。レジストリに対する批判は、
レジストリ特有の問題ではないことに気づくべき。

常駐プログラムが増えたら重くなった。とか
レジストリと関係ないってｗ

レジストリは一般アプリの設定じゃなくてブロックしてOS情報だけを載せていれば問題は無かっただろう。
しかし現状では悪意あるアプリがレジストリをメチャクチャにできるわけだ。
それが問題だよな。

↑これもこういうこと↓

レジストリ特有の問題ではないことに気づくべき。


レジストリやめて、それでそこに保存してある設定ファイルはどうする？
テキストファイルに保存する。そう、そのテキストファイルは
悪意のアプリがめちゃくちゃにできるよね。

こういうこと。

>>45
それは難しいと思うけど。
少なくともレジストリ並みに酷くやっかいにはならなそうだね。

>>46
なんで難しいんだよｗ
rm -rf ~/ で簡単にユーザー設定削除できるって。

アプリのテキストをピンポイントで削除できるのか凄いな

>>48
レジストリの話？ｗ アプリのレジストリをピンポイントで削除できるのか？ｗ

あと書き換えられるのか。
レジストリだと、汚れてしまって起動しないだのおかしくなっただのはあるけどiniで聞いたことは無い。

> iniで聞いたことは無い。

その理由は、iniには現在起動に必要な情報がほとんど含まれていないから。
レジストリをやめて、起動に必要な情報をiniに書き込むようにすれば、

同じようにiniが汚れれば起動できなくなる。

レジストリが必要ないツールでも聞いたことが無いんだけど
出来るそうだね。
やってみて欲しいなあ。

はぁ。本当に頭悪いよ。

なんでこんなに頭が悪いのかな。


レジストリは設定の保存先に過ぎない。
どこに保存しようと、設定が壊れれば問題起きるだろ。
そんなの当たり前だろ。


「レジストリ特有の問題ではないことに気づくべき。 」

壊しやすく重くなりやすくいじりにくく消しにくくと最悪な設定保存技術ですね。

反論できなくなったからって、自分の都合のいい結論を
唐突に持ってこないように。厨房かよｗ

Macやlinuxではレジストリみたいに
設定が汚れるなんてレジストリに比べれば
相当に少ないわけだし、重くなることだって少ない。

他のアプリが設定ばら撒いたからってOS全体が酷いことになったりとか、
他のアプリに被害が出たとかもレジストリに見れば少ないし重くもならない。

最悪なシステムだよな本当に。

ただのデータストアにそこまで罪を負わせようとするなんて正気の沙汰とは思えないｗ

>>53
レジストリで問題なのは「情報が纏まっているから一部が壊れると他も影響を受ける」可能性
他のOSでの各種設定情報の保存方式なら、ファイルシステム上で分散して置くことが多いから
基本的にどれかが壊れても他は影響を受けない

勿論システムの根幹に関わる情報が壊れる時はどちらでも変わらないし
情報の一元管理にも所定のメリットは有ることは認めるが
「情報が壊れたとき何処までの範囲で影響が及ぶのか」で考えれば
>>25や>>53みたいな結論には普通至らないのではと思うが如何か

あとバイナリ形式の設定ファイルは別にレジストリの専売特許ではないよ
全体的に比較対象の知識がやや古い気がする

補足

>>8
>■レジストリが壊れるとパソコンが起動しなくなる！
>ファイルが壊れることがそもそも異常でしょう？ もしそうなったらファイルどころじゃありませんよ。

論点のすり替え入ってる気がするな
ファイルシステム上でファイルが壊れることと、データベース情報が壊れることは別

んで実際のレジストリでの問題発生は後者が殆ど

レジストリによる管理のWindows95よりも、iniファイルによる管理のWindows3.1の方が不安定だったのは何故?

>>60
その二つだと正直どちらも「不安定さ」では大差なかった気がするが
どっちも充分過ぎるくらい不安定になるための要素を抱えてた

それにシステムの根本的な作りが大きく違うから、
それらの安定度の比較はこの件と直接には結びつかない

実際殆どの場合はドライバに起因する問題だったし

レジストリはOSだけが使ってれば問題なかったと思うけどね。

MSがレジストリを使うことを推奨するもんだから、アンインストール時の
考慮が出来ないようなアホなソフト作者が糞ソフトを量産することに
なったんじゃないかと。

>>60
Windows3.1は16ビットOS、Windows95は32ビット＋16ビットのOSだったからじゃないのかな？

>>62
自分もそう思う

　
　　
　　
　　
　　「レ　ジ　ス　ト　リ　特　有　の　問　題　で
　　　
　　
　　　は　な　い　こ　と　に　気　づ　く　べ　き　。 」

　　
　　
　　

レジストリという入れ物にデータをまとめるのはいいとして、
プログラムが好き勝手に物を放り込んだり、
入れたっきり削除しなかったり、
レジストリの使用方法まで厳密に定義しなかったのがレジストリシステムの問題。
一般的にはレジストリの問題と言う。

でもVista()みたいに無駄に隠しファイルあるのもなあｗ
デスクトップに隠しファイルとかいらねーからｗｗｗｗｗｗｗ

>>59

> ファイルシステム上でファイルが壊れることと、データベース情報が壊れることは別

>
> んで実際のレジストリでの問題発生は後者が殆ど

レジストリファイルが壊れるってことまず無いよ。

データベース情報って言ったって、そのデータの実態はファイル。

具体的な名前を出すと、NTUSER.DATね。

データベース情報が壊れる = NTUSER.DAT が壊れるということ。


NTUSER.DATというファイルが壊れる。
NTUSER.iniというファイルが壊れる。

まったく同じ話。

>>66
> レジストリの使用方法まで厳密に定義しなかったのがレジストリシステムの問題。
> 一般的にはレジストリの問題と言う。

なんだよｗ つまりファイルの使用方法を厳密に定義し、
アンインストール時に設定ファイルを消し忘れるアプリがあったら
それはファイルシステムの問題っていうのかよｗ

>>69
レジストリはファイルシステムではないな。
データベースと言うなら合ってる。
データの肥大化や、整合性によって問題が起こるなら
それが起こらないように対処しておくべきだったということ。

レジストリクリーンアップ処理を謳ったアプリケーションがあるけど、
何らかの根拠で「不要なレジストリ」を判断できるなら、
「こういうデータは無効なデータになる」という根拠を明確にしておけば
安心して消せるし、ユーザー設定とインストール情報などを明確に分けておけば
ユーザー設定を残したままインストールし直すようなことも可能になる。

Macみたいにアプリケーションの名前がついたPreferences Fileをごみ箱に
捨てる方が楽でいいな。
不具合があっても特定しやすいし。

レジストリとかTEMPフォルダとかアプリのゴミ捨て場になってる気がする

>>70
> それが起こらないように対処しておくべきだったということ。

起こらないように対処していないとでも？


何を根拠に対処していないといっているのかわからん。

たとえば、NTUSER.DATというファイル（レジストリ情報が入っている）は
OSによってファイルロックがかけられ、同時に書き込みが出来ないようになっている。

ちゃんと処理をしているだろ。

>>70
> レジストリクリーンアップ処理を謳ったアプリケーションがあるけど、
> 何らかの根拠で「不要なレジストリ」を判断できるなら、

出来ない。

後半の文章は、アプリケーションが作成、削除する場合の話をしているから
アプリケーションが使うレジストリの話に限定して問題ないはずだ。

アプリケーションが使うレジストリは、使い方は自由。
例えば設定一つであっても、アンインストール時に、
再インストールするときに備えて設定を残すという選択も考えられるし、
完全に削除するという選択も考えられる。


だから、不要なレジストリと判断するのは不可能。

>>70
> ユーザー設定とインストール情報などを明確に分けておけば

ユーザー設定とインストール情報は明確に分かれている。XPの場合、

ユーザー設定は、C:\Documents and Settings\ユーザー名\NTUSER.DAT の中に
インストール情報はC:\WINDOWS\system32\config\SOFTWARE というファイルの中に
分かれて保存されている。


わざわざレジストリではなく、ファイル名を書いた理由は
レジストリと書いてしまうと、一つのファイルだと思ってしまうから。

ちゃんとファイルからして分かれて保存されているんだよ。

レジストリクリーナーの話が出たのでついでに説明しておく。

これは危険なプログラムだ。気軽に使っている人もいるようだが
動作をちゃんと知っておかなければ、不具合の元になる。

危険なプログラムであるからOSに付属するべきものではない系のソフトだ。
たとえ付属していたとしてもレジストリエディタ同様
パワーユーザーが理解して使うものだ。

レジストリクリーナーの基本は 設定情報に無効なファイル名が
指定されていた場合にその設定を削除するという動作だ。

つまり、shell="C:\Program Files\ABC\common.dll" などという指定が
レジストリに書いてありこのファイルが存在しない場合にそれ関連の
キーを削除するという動作を行っている。

さて、もしshell="D:\ABC\common.dll" とかかれていたらどうなる？
Dドライブはリムーバブルドライブ。一時的にHDDをはずしていた。
そうするとファイルが存在しない為にキーを削除してしまう。
後からDドライブをつけてもキーは消されている。

このように、安全に消せるかどうかは、最終的には人間が判断するしかない。
そしてそれは詳しい人で無いと判断が難しい。決して自動で簡単に行える処理ではない。

> ユーザー設定を残したままインストールし直すようなことも可能になる。

ユーザー設定を残したままインストールし直すことが可能。

これはつまり、アンインストールしてもユーザー設定が残るということ。

しかし、これをやると、アンインストールしてもゴミが残ると文句を言う。


わがままだよねｗ

なんだ。きちがいのオナヌーカ。
たしかにおれのヴぃすたはレジストリ最適化しても変わらなかった。

レジストリ最適化なんかで変わるわけ無いんだよ。


「レジストリ肥大化で重くなった」とよく言っている奴がいるがぜんぜん違う。


重くなる理屈はこう。

１．ソフトウェアインストール

２．OSの起動時やエクスプローラやその他のアプリ起動時に
インストールしたソフトウェアが起動。
（プラグインの形で右クリックメニューなどを拡張するようなものを含む）

３．いつもより余計にソフトウェアが起動している分重くなる。

重くなる理屈はここまで。


レジストリ？ 自動起動するための設定場所がレジストリにあれば
そりゃレジストリに書き込むでしょ。それだけの話。

>>68

そうではない
前者はファイルシステム上での話
後者はデータエントリレベルでの話

ファイルとしては破損していなくても、振る舞いの悪いアプリのインストーラ等によって
データエントリの特定箇所に異常が生じる場合がある、という趣旨の話だから全く別

これ自体は別にレジストリに限った話でどの管理方式でも当然起きてることだが、
>>58のとおりで影響範囲が違う
ファイルレベルで分けてると言ってもたったの２つだから分けたうちに入らない

>>80

> ファイルとしては破損していなくても、振る舞いの悪いアプリのインストーラ等によって
> データエントリの特定箇所に異常が生じる場合がある、という趣旨の話だから全く別

それがどういう理屈で、どういう状態になって異常が起きるか
具体的に説明できる？

振る舞いの悪いアプリケーションが、本来消してはいけない
設定レジストリキーを間違って消したとか、そういう話なら、


振る舞いの悪いアプリケーションが、本来消してはいけない
設定ファイルを間違って消すのと何の代わりも無い。

> >>58のとおりで影響範囲が違う
> ファイルレベルで分けてると言ってもたったの２つだから分けたうちに入らない

影響範囲の話にするのなら、じゃあこういう話をしよう。


レジストリはやめだ。今度からNTUSER.DATに保存していた情報全てを
NTUSER.INIに書き込むようにする。

これで影響範囲の問題は解決かね？

どんなに柔軟に設定が出来たとしても、項目が多すぎで手の付けようが無いんじゃ本末転倒

レジストリの所為にされてる事象の殆どは、WindowsがシェルとIEの
カスタマイズを一切拒否すれば解決するだろ。

1.NTFSファイルシステムレベルで壊れる
2.レジストリの構造が壊れる(NTUSER.DATのバイナリレイアウトが壊れる)
3.愚かなアプリケーションの誤書き換えにより、設定が壊れる

はっきりいって現在ではどれもかなりのレアケースだろ。
レジストリ批判派はいまだに98でも使ってるのだろうか。

>>81-82
こちらで
＞これ自体は別にレジストリに限った話で（なく）どの管理方式でも当然起きてること
と書いてるのだからそちらの指摘を受けるまでもないこと
括弧内抜けていたので訂正

>>83
全くかみ合っていないんだが
設定のファイルシステム上での細分化の話をしてるのだからその例えには全く意味がない

例えば問題の有るアプリhogeが有ったとして、それがhoge.iniなり.hogercなりhoge.plistを
各システム上で作るとすれば、そのアプリを実行するまでそれらは読み込まれることが無いし、
設定に起因する問題が起きてもそれらのファイルを削除するだけで解決する

断っておくけどレジストリの様な一元管理方式を全否定してる訳ではないから誤解なきよう願う
最初から一長一短だと書いてる

「レジストリ」という単語がゲシュタルト崩壊起こしている

例えば問題の有るアプリhogeが有ったとして、それがレジストリのキーhogeなり
各システム上で作るとすれば、そのアプリを実行するまでそれらは読み込まれることが無いし、
設定に起因する問題が起きてもそれらのキーを削除するだけで解決する

>>87

＞例えば問題の有るアプリhogeが有ったとして、それがhoge.iniなり.hogercなりhoge.plistを
＞各システム上で作るとすれば、そのアプリを実行するまでそれらは読み込まれることが無いし、
＞設定に起因する問題が起きてもそれらのファイルを削除するだけで解決する

そういう簡単すぎる話に絞ればファイルが有利になるのは当然。

現実世界で問題になるのは、わかりやすい例だとプラグイン。
プラグインのインストーラは、プラグインのホストの設定ファイルに書き込みを行わなければいけない。
アンインストーラはそれを適切に削除しなければならない。
プラグインが設定に起因する問題を引き起こしたとき、ホストの設定ファイルを全部削除するわけにはいかない。

こういうシナリオだと、統一されたAPI、高い信頼性で読み書きができる事は大事。
実際、プラグイン中心のアーキテクチャであるFirefoxはレジストリモドキをもっている。

今必要なのはベンダーに、アプリが使用するレジストリエントリ一覧の添付義務を課すことだな。
Windows認定ロゴマーク取得の要件に含めればいい。
そしてM$荷は、ゾンビ化したレジストリを削除するオーディットユーティリティの添付義務。

>>89
>ID: OJ14GPrc

君はどこまで話を噛み合なくさせれば気が済むのか
全くこちらの挙げたメリット／デメリットの意味を理解していないでしょ

一元管理でなければ基本的にアプリAの設定に起因する問題は
アプリAだけで閉じるのに対してレジストリの場合そうではない
この件に関しては既に君の得意な「等価な置き換え」は既に崩れているよという話だよ
勿論他の部分では一元管理の方が優れてることも有る、ただそれだけの話
いい加減分からないかな


>>90
ごく分かり易い形で、一元管理方式と分散管理方式の
それぞれのメリットデメリットを挙げただけだから

あ、悪い
ID:OJ14GPrcは別の人か
間違えたスマヌ

> 一元管理でなければ基本的にアプリAの設定に起因する問題は
> アプリAだけで閉じるのに対してレジストリの場合そうではない

なぜ、ファイル方式なら、アプリAだけで閉じて、
レジストリ方式なら、アプリAだけで閉じることはない。と言い切るの？

そんなの、アプリと設定内容しだいだろう。

あと、Windowsではアプリケーションのインストール場所に自由度があるから
ファイルシステム非依存のストレージに設定を置けるとアプリ間連携に便利という側面もある。
どこにインストールされたかわからなければ設定ファイルを探しようもない。

「レジストリの場合は、アプリAだけで閉じない」というのなら、

アプリAだけで閉じない場合がどういう場合か具体的な例を挙げてよ。

それと同じことがファイル方式でもおきるって
絶対いえるから。

>>94
話捉え間違えてるね、言ってることがこちらと違う
今までのところちゃんと読み直せば分かると思うよ

>>97
具体例挙げてね。

なんか小難しい議論になってるけど

「情報をアプリケーション毎にXMLファイルにしておく」

これよりレジストリ管理が優れてる事ってなんなの？

>>99
XMLだと肥大化するｗ

バイナリとタグ付きテキストを比較すれば明らか。

>>99

・ディスクのフットプリント。XMLはかなり冗長。*.iniよりも悪い。
レジストリのHiveは、*.iniの1/6ぐらいにはサイズを圧縮できている。
・レジストリにはリンク機能がある。XLinkはあまりつかわれていないね。
・レジストリは環境変数の展開機能がデフォルトで備わっている。

こんなとこかな。まぁデメリットもある。

>>96
そりゃ当然反論可能だろよ、元々>>94ほどに断定したことはこちらは言ってないのだから

俺の過去の経験例で良いの？
ほかの人も言っていたように、最近の話じゃないよ

以前CANVAS６をWin2kSP4に入れたらシステム全体が正常に立ち上がらなくなった
原因はアプリベンダー側ではなく単に非対応に気がつかず入れてしまっただけだったのセルフミス
調べた結果セーフモード起動でレジストリの特定のKEY項目を弄ることで復旧した
大分前だから細かな部分がおかしいかもしれないが大体そんな感じ

んで他のプラットフォームだと一般的なアプリに関する「設定」そのもので
ここまで大きな影響が出ることはまず経験していない
前にも書いた通りで普通はそのアプリが立ち上がらないだけで
システム全体の動作にまで深く影響を及ぼすことは実際かなり稀
（ドライバやライブラリなどに伴って起こる問題は別）

「原理的に絶対起きない」とか「問題を起こすアプリは存在しない」とか
断言してる様な話じゃないよ、ごく一般的な傾向の話な
それに今では当然当時とは状況も変わって来てる

>>102

つまりはそのCANVAS6とやらが、
システムに重大な影響を与える設定を書き換える必要があったわけね。
そうであれば、その設定がiniファイルだろうがなんだろうがインストーラはそれを書き換えにいっただろうし
結果クラッシュしたんじゃないの。

この体験談で何を伝えたいのかよくわからない。

記憶違いだったので訂正

誤：システム全体が正常に立ち上がらなくなった
正：「アプリケーションの追加と削除」のコントロールパネルが破壊される

>>103
（広い範囲で影響を与える可能性についての）具体例を書けと言われたから
物凄いピンポイントになるが経験したことを書いただけだが

言われてみればその通りでは有るな＞結果が一緒かもという点

ただ元の話に戻るが、一元管理か分散管理かの比較での一般的な傾向として
こちらの言ってることがそんなに間違ってるか？

元々はID:JGaE5+tQの意見がかなり偏ってると思ったのでそれを指摘してたけなんだが

あ、俺レス関係のIDを取り違えてるな
元々ID:OJ14GPrcと話してたのか
>>93は取り消しで>>105も最後の行は間違い

ぐだぐだになっちまったから取り敢えず消えるわ、済まん

　　　　 　＿＿＿＿＿＿
　　　 ／　　　　　　　　　 ）））
　　　/　　　／// /―――-ミ
　　 / 彡彡　// /　　　　　 ヽ)）
　　 / 彡彡　iiiiiiiiiiiiiii　　iiiiiiiiii|
　　 / 彡彡　＜　･ >　、<･ >l
　　/ 　　　|　 　　　　　ヽ　　 〉
　　/ 　（ | |　 　　 　＿＿)　 |　　　 ／￣￣￣￣￣￣￣￣￣
　　/ 　 | ≡ 　／, ―――　 |ゝ　＜　馬鹿にレジストリを触らせるな
　 /　　 |　　　|　 L ＿＿_」　l ヾ　　＼＿＿＿＿＿＿＿＿＿
＿ミ　　ｌ　　　＿＿＿＿＿_ﾉ　ゞ＿
　 |　　l　ヾ　　　　ー　 　／ |　　ｌ
　 |　　| 　 ＼ｰ　　　 ‐／　　|　　|

ん〜本当の中に嘘がちょっと混じってるのが一番タチが悪いって典型的な例だなw

レジストリが肥大化するとパフォーマンスが落ちるというのは本当でもあり嘘でもある。
Windows XPのSP1あたりまではレジストリのキャッシュをWindows全体が
共有する作業エリア(名前忘れたw)に確保していた。

だからレジストリによってそのエリアが食い散らかされると、他のデータがメモリから
追い出されるので結果的にWindows全体が遅くなる。

MicrosoftはXP SP2でこれを変更し、レジストリのキャッシュをOSの他の一般の作業エリアから分離した。
だからSP2以降はさほどレジストリが肥大化してもシステムのパフォーマンスに影響しない。

>>105

率直に言って

HKEY_LOCAL_MACHINE\SOFTWARE\アプリA
直下を編集したり消したりする事と、

C:\Program Files\アプリA\アプリA.config
を編集したり消したりする事に、

どんな本質的な違いがあるのかわからん。そんなの無いでしょ。

一元管理と分散管理の違いすら無い。
なぜなら、システムはHKEY_LOCAL_MACHINE\SOFTWARE\アプリA以下を管理しないから。
保存場所を提供しているだけで管理ではない。違う？
HKEY_LOCAL_MACHINE\SOFTWARE\アプリA 以下を管理、すなわち読み書きするのは
実際のところはアプリAだけ。

>>103
原理的には同じかもしれないけど、実際の頻度が違うって言ってるんだと思うよ。

その手の障害は最終的には、アプリのプログラマーのせいなのかもしれないけど、
そう言う余計な負担をかけたＭＳとレジストリの罪は結構大きいと思う。

>>109
だからさ
それはアプリAからレジストリへの読み書きが正しく行われることが大前提でしょ
そうでない場合に起きうる問題について語ってたんじゃないのか

で、ロジカルなレイヤーで違いがないのであればフィジカルなレイヤーの違いが問題になるんだが、
フィジカルを語れるほど我々はレジストリの内部構造に詳しくないと思うのだけど。

たとえば、ユーザーのレジストリファイルはNTUSER.DAT以外にも存在する。知らなかったでしょ。

レジストリエディタの見せる一枚岩のイメージに騙されているだけなんじゃないかと。

ユーザー設定が複数ファイルに分かれているのであれば、システム設定は何ファイルかわからないよ。
実際は余分なデータなんて大して読み込んでないんじゃないの、と。

>>111

だから俺は>>86で現象を整理したかったんだけど。
>>102の例は、>>86でいうところの2か3かでいうと、3の話をしてたでしょ。
レジストリの特定のKEYを弄ることで復旧できたのであれば、
レジストリは壊れてないよ。だから2ではない。

レジストリとiniファイルとどちらがパフォーマンスが高いかという話は、
結局データベースのパフォーマンスの問題と同じ。

データベースとファイルシステムというのはある意味同じことを
2重にやっているようなものだから、無駄ではある。

データベースのパフォーマンスを極限まで追求していけば、
ファイルシステムなしにデータベースがHDDを直叩きする形式になる。
実際そういうデータベースもあるわけだし、
ポシャったWinFSもファイルシステムとデータベースを統合するという発想から来ている。

実際ファイルシステムの上にデータベースを構築するのは二度手間で
非効率以外の何者でもない。むしろ「レジストリパーティション」みたいなものを作って、
そこにレジストリデータベースを格納すれば効率はよくなる。が、扱い憎いだろうねw
せいぜいページファイルみたいにNTFSの中で固定の領域を確保するとか。

で、レジストリvs iniファイルの問題は、結局はデータベースを全体で1個持つか、
アプリごとに分散させて持つかという問題に帰結する。

前述のようにファイルシステムが存在しない純粋なデータベースならこの問題は
そもそも存在しない。ファイルシステム上にレジストリデータベースが構築されているから、
データベースのファイルをアプリごとに持つか、Windows全体(やユーザ毎)に持つかという
問題が生まれる。

で、その前提なら、そりゃアプリ毎に持った方がデータのアクセス範囲が局在化されるんだから、
アプリ毎に持った方がアプリのパフォーマンスは多少良くなるだろう。

ただ、なぜWindowsがそういう形態をとっていないのか？といえば、
それは他のアプリやシステムをフックするアプリがあるからだろう。

つまり他のアプリのレジストリを書き換えて使用するアプリの存在がある。
こうなると話は違ってきて、全体でレジストリを一元管理した方が便利ともいえる。

regコマンドぐらい覚えろ、カスini厨共。

>>110

その余計な負担って何？
レジストリAPIは特別に複雑なんですという主張?

これもよくわからない。

>>113
だから>>102はあくまで一例、それが>>８６の3なのは当然分かっているよ
でも一般的な話では1−3（+α）まで全ての可能性があるのだから、
その例を前提に>>105以降の話を続けないでくれないか

下にも挙がっている様な様々な理由で実際に壊れる可能性は常に有って、
そのうちのいくつかはファイルシステム上で分散している方が有利なものもある

ttp://support.microsoft.com/kb/822705/ja

全ての可能性なんて言ってたらまとまる議論もまとまらんｗ

こちらが元々言ってたのはそちらが

＞そういう簡単すぎる話に絞ればファイルが有利になるのは当然

みたいにさらっと流したような程度のことだったからね

レジストリにHangameを発見した
やった記憶ないのに

>>117
レジストリアクセスのための API を「別に」覚えないとダメだろ。

テストデータ作るのも ini ファイルなら、使い慣れたエディタで
できるのに、わざわざ使いにくいレジストリエディタを使わないと
いけない。

さらに、ini ファイル編集してる時に、わざわざ他のファイル壊す
奴は単なる馬鹿だけど、レジストリエディタだと注意してても間違
えてシステムの設定を壊すことも「簡単に」できてしまう。

まあ、一つ一つはたいしたこと無いけど、集まるとそれなりに大変
なんだよ。

開発経験無いとわからんと思うが。

Uniblue RegistryBooster 2009ってやつでレジストリ調べたら500近くの無駄が発見されて何かもうアレだ

>>122

＞テストデータ作るのも ini ファイルなら、使い慣れたエディタで
＞できるのに、わざわざ使いにくいレジストリエディタを使わないと
＞いけない。

regファイルを作ってインポートでも regコマンドでもお好きなように。
レジストリエディタだけだと効率悪くて仕方ないだろ。

＞さらに、ini ファイル編集してる時に、わざわざ他のファイル壊す
＞奴は単なる馬鹿だけど、レジストリエディタだと注意してても間違
＞えてシステムの設定を壊すことも「簡単に」できてしまう。

注意してても HKLM\SOFTWARE\自アプリ 以外のキーを開いちゃいますってか。
眼科いったほうがいいんじゃない。

開発経験ほんとにあるのか?

どちらかというと>>122に一票かな

理由：気が楽

>>125

別にレジストリの使用を無理にすすめてるわけじゃないよ。俺もファイルの方が好きだ。
ただ「レジストリを使うとシステムを壊しやすい」という主張に反論してるだけ。

>>124
> regファイルを作ってインポートでも regコマンドでもお好きなように。

だから、「わざわざ」そんなことしないといけないのが面倒だって言ってるんだが。
インポートするだけって簡単に言うけど、毎回となると結構ウザイし色々ミスの要因
になる。

> 注意してても HKLM\SOFTWARE\自アプリ 以外のキーを開いちゃいますってか。

そうだよ。クリックするだけで開けちゃうからな。

>>122 に
>> まあ、一つ一つはたいしたこと無いけど、集まるとそれなりに大変なんだよ。

って書いたように、一回だけならいいんだけど、開発の現場だとそれこそ何十回〜何
百回と繰返す羽目になる。そんな手間なんてたいしたこと無いとか、注意してればそ
んなことするわけないという奴は、実務の開発経験が無い奴だと思う。

>>127

＞そうだよ。クリックするだけで開けちゃうからな。
開くだけじゃ値は変わらない。編集するまでに気づけないならやっぱり眼科。

＞一回だけならいいんだけど、開発の現場だとそれこそ何十回〜何
＞百回と繰返す羽目になる。そんな手間なんてたいしたこと無いとか、注意してればそ
＞んなことするわけないという奴は、実務の開発経験が無い奴だと思う。

だから自動化するための方法を書いてるんじゃないか。
一度regファイルを作れば
reg import 作ったファイル.reg
これで終わり。
一度元になるregファイルを作ったらマクロなりスクリプトなりで
全テストケース分のregファイルを作って、
あとはバッチ化して叩くもよし。単体テストに組み込むもよし。
何百回もレジストリエディタ開くのが実務の開発経験だっていうんならそんな経験はいらん。

>>128
> 開くだけじゃ値は変わらない。編集するまでに気づけないならやっぱり眼科。

間違いに気付かずに開いてるんだから、そのまま編集しちゃうぐらいわかるかと
思っていたんだが...。

> 何百回もレジストリエディタ開くのが実務の開発経験だっていうんならそんな
> 経験はいらん。

残念なことにテストでは、レジストリの値を確認する必要もあるんだな。
何回もやるようなテストだと、スクリプト書いてチェックするけど、バグの調査
とかで随時の確認が必要な時が面倒なんだよ。
わざわざエクスポートしてエディタで確認するってか？ (w

>>129

＞間違いに気付かずに開いてるんだから、そのまま編集しちゃうぐらいわかるかと
＞思っていたんだが...。

編集はレジストリエディタの右側のペインでやるだろ。
右側のペインをみて間違いに気付かないってのは、
保存する項目が全く一緒ぐらいじゃないとあり得ないぞ。
システムの設定を壊すには、システムとほぼ同じ保存項目を持つことになる。
そんなアプリあるかっての。

＞残念なことにテストでは、レジストリの値を確認する必要もあるんだな。
＞何回もやるようなテストだと、スクリプト書いてチェックするけど、バグの調査
＞とかで随時の確認が必要な時が面倒なんだよ

もうね、随時確認してる時点で…
テストケースを流した時点で、エラーがあれば
期待した値と実際の値を出力するようにしてるでしょう。。
わざわざ見に行くなんて驚き。それで品質コントロールできてる？

ユーザー環境で起きたのであれば、エクスポートバッチを送付して、
「出来たファイルを送ってください」が最速。
人のPCのレジストリエディタを開くのは互いに効率が悪い。

>>130
> 保存する項目が全く一緒ぐらいじゃないとあり得ないぞ。

残念なことに人間そんなに注意深くない。
あり得ないと言われてることが本当に起きないなら、世の中の
事故はだいぶ減るよ。

> もうね、随時確認してる時点で…

「バグの調査で」って書いてあるのが見えてないのか？
どこで変な値を書いてるかを調査するために、ブレークかけながら
随時確認するなんて普通にやると思うけど、もっといい方法がある
のか？

# ユーザー環境の話はいらんよ。
# 話をそらしたいのかもしれないけど。

＞どこで変な値を書いてるかを調査するために、ブレークかけながら
＞随時確認するなんて普通にやると思うけど

ブレークをかけながらの随時確認を

＞一回だけならいいんだけど、開発の現場だとそれこそ何十回〜何
＞百回と繰返す羽目になる

のであれば、設計や開発フローを見直す事をお勧めする。いや、ほんとに。
テストも全部目視ベースみたいだし。
レジストリエディタがないと開発できないような環境を自分たちで作り上げているように見える。


＞# ユーザー環境の話はいらんよ。
＞# 話をそらしたいのかもしれないけど。

バグ調査でレジストリエディタなんてほとんど無用ということを言いたかったのでね。
蛇足とは思ったがバリエーションの一つとして出したまで。

>>130の言い分を検証してみた結果
>>131は注意が散漫か学習意欲がないのだと思った

Windowsのヘルプを開いて"reg"で検索すれば、regコマンドの利用方法出てる
regコマンドを使えば、バッチファイルで確認用のファイルを作ることが可能、エクスポートされたファイルの拡張子をregなり、txtにしたら確認は楽になる
拡張子.regのファイルは、ダブルクリックすればレジストリにインポートできる
確認や値の修正の為に、いちいちregeditを開く必要はない

>>130便利なコマンドを教えてくれてありがとう

>>133

どういたしまして。
まぁ>>116が初出っぽいけどね。

>>126
システムとアプリの両方が使うから更新する機会が増える分、壊れやすくなる。
システムが使ってるから壊れたらシステムを道連れにする。
誰かが書いてたけど、システムとアプリのファイルを別にすればマトモだったのに。

>>132
> 設計や開発フローを見直す事をお勧めする。
> バグ調査でレジストリエディタなんてほとんど無用ということを言いたかったのでね。

で、具体的なやり方はどうするんだい？
まさかバグ作りこまないように注意するとか言うんじゃないよな？

> テストも全部目視ベースみたいだし。

>> 何回もやるようなテストだと、スクリプト書いてチェックするけど

って、書いてあるんだけど、君こそ眼科に行ったほうがいいんじゃね？ (w

>>133
> >>131は注意が散漫か学習意欲がないのだと思った

注意力はいざ知らず、今頃「>>130便利なコマンドを教えてくれてありがとう」って言っ
てる奴に学習意欲が無いって言われてもなぁ...。

> エクスポートされたファイルの拡張子をregなり、txtにしたら確認は楽になる
> 拡張子.regのファイルは、ダブルクリックすればレジストリにインポートできる

ini ならそんなことする必要が無いんだよ。

ID:wZC+gEJI も、レジストリの扱い方を一生懸命説明してるけど、「簡単にできる」
ことと「しなくていいこと」のどっちが楽かよ〜く考えて見ればいいのに。

# まあ、でかいソフトの開発経験が無いとわからんのかも知れんな。

>>136
"プログラマ"なら
バッチファイルぐらいは、使いこなそうよ
手間を掛けたくないなら、エクスポートしたファイルをメモ帳で開くまでバッチで出来るし
どうしても面倒なら、インポートまで一つのバッチで終わらす事だって可能でしょ
でもって、ちゃんとしたバッチファイルを1度作れば、何度使おうと失敗はないじゃん

大規模なソフト開発の経験があるなら、バッチファイルの作成ぐらい片手間だし
「しなくていいこと」が云々言うほどの事でもないじゃん
オイラみたいな日曜プログラマでも、その程度のバッチなら4行程度で作れると思うよ

>>136

＞で、具体的なやり方はどうするんだい？
＞まさかバグ作りこまないように注意するとか言うんじゃないよな？

モジュールの依存関係を整理して
単体テストをカッチリやる。常識だよね？
網羅的な単体テストを自動化しておけばデバッガの出番なんてほとんど無いよ。
xUnitのレッドを捕まえるだけで異常個所は明瞭なんだから。

>> 何回もやるようなテストだと、スクリプト書いてチェックするけど

それがちゃんとできてないからレジストリエディタのお世話になっているんだろ。
自動化されたテストにレジストリエディタの出る幕は無い。
ワンクリックして10秒で数百コンディションテストするような環境でiniかレジストリかなんて関係ない。
それなのに

＞インポートするだけって簡単に言うけど、毎回となると結構ウザイし色々ミスの要因になる。
＞一回だけならいいんだけど、開発の現場だとそれこそ何十回〜何
＞百回と繰返す羽目になる。

という発言から見るになんどもなんどもレジストリエディタのお世話になってるらしい。
スクリプトに一体何を書いているのか疑問だが。

>>136

＞# まあ、でかいソフトの開発経験が無いとわからんのかも知れんな。

でかいソフトの開発をしているのであれば、
ヒューマンエラーが起きやすい手順・ツールは必ず排除される。
なぜなら一人のミスで数十人の作業が止まることがあるから。
レジストリエディタでヒューマンエラーが起きやすいのであれば、
普段の作業はレジストリエディタを使用せずともいいように何らかのツールをつくり、
どうしてもレジストリエディタが必要なときだけ、注意深く行う、という流れになるだろう。

それなのに

＞残念なことに人間そんなに注意深くない。
＞あり得ないと言われてることが本当に起きないなら、世の中の
＞事故はだいぶ減るよ。

いわゆるあり得ないレベルのミスが起こるという。
それを許容するのも結局

＞一回だけならいいんだけど、開発の現場だとそれこそ何十回〜何
＞百回と繰返す羽目になる。

これのせいなんだろうけど。スクリプトに一体何を書いてｗ

なに？テストの話をしているの？

テストってのは条件をいろいろ変えて
処理を実行するもの。

レジストリだったらキーの値をいろいろ変えて、インポートしてテスト。これがめんどくさい？
でもに、iniでも設定を変えて、適切な名前に変えて（これがインポートに相当する）テスト。たいして違いはないのだよ。

>>122
> レジストリアクセスのための API を「別に」覚えないとダメだろ。

iniをアクセスするためのAPIも覚えないとだめだよ。

XMLをアクセスするためのAPIも覚えないとだめだよ。

>>136
> ini ならそんなことする必要が無いんだよ。
そうかな？

エクスプローラを起動して
C:\Documents and Settings\ユーザー名・・・あなたのユーザー名ですよ。知りませんか？

のところでiniファイルってユーザーごとに設定ファイルは違うから
ユーザーフォルダだとして、その以下のどこにあるんだ？

を添付してというの。結構大変なことだぞｗ

>>137
日曜プログラマが言いそうなことですな。
最初に書いただろ？

>> まあ、一つ一つはたいしたこと無いけど、集まるとそれなりに大変なんだよ。

日曜プログラマならバッチファイルは書けば終わるんだろうけど、職業プログラマは
そのバッチにものドキュメント書いて一緒に管理しないと保守できなくなるから、
１つでも減らしたいと思うのは当然。

>>138-139
テストとデバッグの話の区別がついてないのか...。
眼科の次は、精神科か小学校にでも行った方がいいぞ。(w

>>143

バグとは仕様を満たさない(ゆえに必ずテストを通らない)コードのことを指す。
デバッグとはバグの箇所を突き止め除去すること。
コードベース全体がよくテストされていてバグの箇所が最初から絞られていれば
デバッガを起動するまでもなく、素早くデバッグできるんだよ。
デバッガを起動することがデバッグではない。
テストとデバッグ効率は密接に関係している。

>>140
> たいして違いはないのだよ。

何回も言ってるけど、一回一回はたいして違わないよ。
だから

>>142
ねえ、一体何の話してるの？ >>136 のレスは...

>> エクスポートされたファイルの拡張子をregなり、txtにしたら確認は楽になる
>> 拡張子.regのファイルは、ダブルクリックすればレジストリにインポートできる

で、ユーザーがどうのこうのなんて言ってないんだけど...。

ついでに、「〜を添付して」が面倒なら >>130 によるとバッチファイルを送れば
いいらしいよ。(w

良スレなのに、もういい加減「壊れやすい」なんて本質的ではない問題はやめてほすぃ。

>>144
> バグの箇所が最初から絞られていれば

こんな馬鹿な仮定を立てられてもな。
でかいソフトの製品事故なんか経験したこと無いだろ？

まあ、そう言う幸福な環境を否定するわけじゃないよ。

ただ、2Mstep を越えるソースの中には、10年以上前のコードだって現実にある
んだから、理想論を振りかざされてもはあそうですかとしか言えないよ。

# 理想論は言いすぎか、「小規模開発とは違うんだよ」ぐらいにしとくかな。

>>143
regコマンドを知っていて、ドキュメントを書かないと管理できないようなプロジェクトに何度も関わるような会社であれば
おいらの言うようなバッチファイルなど、既にドキュメントの揃った状態でツール化されているのではないのでしょうか?

大規模開発云々と言う理由で、テスト&保守ツールの作成に無頓着ってのは
如何にサボって残業代を稼ごうかと考えている駄目社員の口上だと思うのですが

iniファイルはアクセス方法を一元化できない。
各種プログラミング言語処理系のライブラリで、まちまちの方法で
読み書きができてしまい、非スレッドセーフ、非プロセスセーフでの
アクセスを許してしまう。
レジストリ方式はセマフォを搭載でこの問題を解決。

>>149
それはあるね。

レジストリだと、OSがファイルをロックしているから
OS経由じゃないと書き込めない。

それに対してiniやXMLだと普通のテキストエディタから
書き込めることからもわかるように、ファイルがロックされていない。

複数のプロセス（特に質の悪いプロセス）が同時に
書き込んだりすると、iniやXMLは壊れやすい。

>>147

でかい開発、大規模開発という割にはスケールしない作業方法だけ述べてるね…
>>148は正論だよ。
レジストリとiniの差も満足に埋めれない作業方法が大規模流だと信じるならば
いつまでも人海戦術で頑張ってくれとしか言えない。

設定ファイルの話してた筈なのに、自称SE同士の煽り合いになってるな。

>>146
壊れやすいか？という問題なら、データベースとしてレジストリの完成度を見るべきだろうね。
たとえばデータベースの場合不慮の事故によって更新が中途半端になることを防ぐために
アトミックトランザクション機能がなければ一人前のデータベースとはいえない。

処理が途中で中断して変更が中途半端に終わったときは、変更される以前の状態まで戻す機能。
レジストリにはこの機能がない(と思う、恐らく)。
まあ、レジストリはWindowsの起動毎にバックアップが取られるから、
ある程度それが代用になっているのだろうけれど。

あと、IEのブックマークの順序とかもレジストリに書き込まれる。
ブックマーク自体は一つ一つがファイルだが、
IEのブックマーク一覧で表示される順序(ユーザが編集できる)はレジストリが記憶している。

ここまでレジストリに入れるのが適切なのか？と思う。

>>148
> おいらの言うようなバッチファイルなど、既にドキュメントの揃った状態で
> ツール化されているのではないのでしょうか?

当然してるよ。してないなんて誰も書いてないと思うけど。
書いてないものが見えるんなら、眼科すっとぱして精神科にかかった方がいいよ。(w

>>151
> レジストリとiniの差も満足に埋めれない作業方法

ねえ、誰が埋めれないって書いてるの？
なんか書いてないものが見える人が多いなぁ。(w

あくまでも、「バッチファイルの管理」とか「差を埋める」のが面倒だって書いてる
だけ。

そもそも発端は、>>117 の「その余計な負担って何？」から始まっててて、その負担
の説明してるのに、一生懸命「テストで頑張れ」ってちょっと頭に血が上りすぎだと
思うよ。

>>149
まあ、そう言うメリットはあるし、他にも色々メリットはある。
ただ、なんでもかんでもレジストリのメリットの方がデメリットを上回るわけじゃない
と言うだけのこと。

　何をいまさらと覗いてみたら、的外れな話してんなｗ

　Windowsにおけるシステムレジストリという仕組み、という意味で見た場合の根本的な問題点は、
OS標準の機能によるファイル操作によって、レジストリ上で指定されたシステムファイルの実体を
簡単に変更・移動・削除できてしまうため、簡単に破綻した状態が発生することにある点だ。

　DLLヘル問題とかファイルコピーツールに毛が生えただけのような標準インストーラとかのもっと
最低な仕組みに足引っ張られてる感が強いが、根本的にシステムファイルをあんなに簡単に
いぢれるような中途半端な仕組みにしたMSがクソとしか言いようがない。


　こういう視点で見れば、VistaのUACはいまさらではあるが評価できる。あれくらいウザければ、
アプリ側も無駄にシステムファイルをいぢろうとはしなくなり、システムファイルとアプリとの住み
分けも進むだろうからな。

　まあVista対応とか言っといてマニュアルにUACを切れとか平気で書いてるアプリの作者は
死ねばいいよ。まあVistaもVistaで、証明書だっけかのないデバドラは禁止とか言ってくるのが
クソなのは同意だけど。

>>155
なあ、>>122で言ってることと変わってない?
>>122を見る限りレジストリを直接regeditで編集しているとしか見えないんだが...
そして、関係ないレジストリキーを破壊してると書いてるんだが?
俺の目が悪いのか?

>>157
悪いのは目じゃなくて、その理解力の無い頭の方だと思う。

| >>129
| > バグの調査とかで随時の確認が必要な時が面倒なんだよ。

テストの話に限定してがってるのは ID:wZC+gEJI の方だから。

>>156

お前が一番的外れだｗ

>>158
>>129を読んでも、然るべき処置をとらず、不用意にregeditでレジストリを開いてレジストリを破壊することを肯定しているようにしか見えない
regeditで直接レジストリを開いてレジストリの値を確認したいのだろうと言うのは分かるが
どっちみち内容を更新するには"F5"キーを押さなきゃ駄目なんだから、バッチファイルを一々ダブルクリックするのも同じことじゃん

また、テストの話に限定したがってると言っているが、最初にテストの話をしてたのは貴方の方でしょう?
それに対して、プログラマなんだからテストぐらい工夫しろと言われても、当たり前の事だと思います
大規模なプログラムを開発していると言うなら、「例えを間違えました」ぐらい言えばいいと思うのですが

レジストリをユーザーが直接編集しないと直らないPIO病の話が例であれば貴方が言いたいことも通るでしょうが

デバッグでレジストリを編集し間違えてレジストリを破壊したなどと言う例を上げられたら
「お　前　が　間　抜　け　だ　か　ら　だ」
としか言いようがないし、それをそうじゃないと言われても
「大　嘘　吐　き　め、話　が　変　わ　っ　て　る　だ　ろ　う　が」
としか言いようがない
どう贔屓目に見ても、開発者を名乗ってするような話ではないと思います

デバッグでレジストリを編集し間違えてレジストリを破壊したなどと言う例を上げられたら
「お　前　が　間　抜　け　だ　か　ら　だ」デバッグでレジストリを編集し間違えてレジストリを破壊したなどと言う例を上げられたら
「お　前　が　間　抜　け　だ　か　ら　だ」デバッグでレジストリを編集し間違えてレジストリを破壊したなどと言う例を上げられたら
「お　前　が　間　抜　け　だ　か　ら　だ」デバッグでレジストリを編集し間違えてレジストリを破壊したなどと言う例を上げられたら
「お　前　が　間　抜　け　だ　か　ら　だ」デバッグでレジストリを編集し間違えてレジストリを破壊したなどと言う例を上げられたら
「お　前　が　間　抜　け　だ　か　ら　だ」デバッグでレジストリを編集し間違えてレジストリを破壊したなどと言う例を上げられたら
「お　前　が　間　抜　け　だ　か　ら　だ」デバッグでレジストリを編集し間違えてレジストリを破壊したなどと言う例を上げられたら
「お　前　が　間　抜　け　だ　か　ら　だ」デバッグでレジストリを編集し間違えてレジストリを破壊したなどと言う例を上げられたら
「お　前　が　間　抜　け　だ　か　ら　だ」デバッグでレジストリを編集し間違えてレジストリを破壊したなどと言う例を上げられたら
「お　前　が　間　抜　け　だ　か　ら　だ」デバッグでレジストリを編集し間違えてレジストリを破壊したなどと言う例を上げられたら
「お　前　が　間　抜　け　だ　か　ら　だ」

デバッグでレジストリを編集し間違えてレジストリを破壊したなどと言う例を上げられたら
「お　前　が　間　抜　け　だ　か　ら　だ」デバッグでレジストリを編集し間違えてレジストリを破壊したなどと言う例を上げられたら
「お　前　が　間　抜　け　だ　か　ら　だ」デバッグでレジストリを編集し間違えてレジストリを破壊したなどと言う例を上げられたら
「お　前　が　間　抜　け　だ　か　ら　だ」デバッグでレジストリを編集し間違えてレジストリを破壊したなどと言う例を上げられたら
「お　前　が　間　抜　け　だ　か　ら　だ」デバッグでレジストリを編集し間違えてレジストリを破壊したなどと言う例を上げられたら
「お　前　が　間　抜　け　だ　か　ら　だ」デバッグでレジストリを編集し間違えてレジストリを破壊したなどと言う例を上げられたら
「お　前　が　間　抜　け　だ　か　ら　だ」デバッグでレジストリを編集し間違えてレジストリを破壊したなどと言う例を上げられたら
「お　前　が　間　抜　け　だ　か　ら　だ」デバッグでレジストリを編集し間違えてレジストリを破壊したなどと言う例を上げられたら
「お　前　が　間　抜　け　だ　か　ら　だ」デバッグでレジストリを編集し間違えてレジストリを破壊したなどと言う例を上げられたら
「お　前　が　間　抜　け　だ　か　ら　だ」デバッグでレジストリを編集し間違えてレジストリを破壊したなどと言う例を上げられたら
「お　前　が　間　抜　け　だ　か　ら　だ」

デバッグでファイルを編集し間違えてファイルを破壊したなどと言う例を上げられたら

「お　前　が　間　抜　け　だ　か　ら　だ」

ユーザーがシステムファイルを移動したらシステムを破壊したなどと言う例を上げられたら

「お　前　が　間　抜　け　だ　か　ら　だ」

rm -rf / を実行してディスクがフォーマットされたなどと言う例を上げられたら

「お　前　が　間　抜　け　だ　か　ら　だ」

>>159
スレタイ嫁ｗ

　なんか喪前らはぐちゃぐちゃもめてるけどな、実際のところ、iniファイルだろうがレジストリ
データだろうが大差ねえんだよ。

論理的に中身が壊れちまう頻度とか、変更手順がアプリ作る奴次第だって時点でどっちにしろ同じ。

壊れた時に巻き込む範囲が違うとか言うのはレジストリという手段を使ったかどうかじゃなくて、
Windows のシステムレジストリの使い方がおかしいことが原因だ。

　デバドラもアプリもごっちゃになって同じデータをいぢくってんだから壊れる時は全部巻き添え。
ここが全ての元凶なんだ。ちゃんと切り分けとけよって話なんだよ。

>>166

お前こそよく読め。

システムファイルの実体を 簡単に変更・移動・削除できてしまうため、
簡単に破綻した状態が発生することにある点だ。

などということは、どのOSだって簡単にファイルぐらい移動できるだろうの一言で終わりだ。

iniって削除するだけで設定完全初期化出来て便利だね
ユーザーがわは

簡単になんてできないけど

パス要求され、コピー許可や削除許可が求められる

レジストリの場合は簡単に管理的に壊れる

単純化すんなボケ

>>166
> 　デバドラもアプリもごっちゃになって同じデータをいぢくってんだから壊れる時は全部巻き添え。
> ここが全ての元凶なんだ。ちゃんと切り分けとけよって話なんだよ。

あと、壊れれば。なんて可能性の低い話してんなよ。

壊れねーだろうが？ 壊れねーだろ？

壊れれば。なんていえばHDDが壊れれば。なんて話できるだろうが。

>>169
> 簡単になんてできないけど
> パス要求され、コピー許可や削除許可が求められる

はい。その答えを待っていた。

スレタイ嫁。レジストリの話じゃねーよ。それは。
ファイルアクセス権限の話だろうが。


Windowsでもユーザー権限で利用すればって反論もできるが、
それもすれ違いだなｗ

こわれやすい

＞スレタイ嫁。レジストリの話じゃねーよ。それは。
＞ファイルアクセス権限の話だろうが。

ファイルアクセス権限を簡単に手に入れてしまえるレジストリの問題だろ

>>167
ぶっちゃけおまえらはレジストリに夢見すぎなんだよ。
あれは*.iniをPG側が検索しやすいようにただバイナリにしただけのものでしかないんだ。

おかしいのはレジストリというデータ形式じゃなくて、Windows側のレジストリの利用方法なんだよ。
俺は、あんな使い方するならファイルシステムに絡めるなりして関連性を守らないとダメだつってんの。

ただini形式にしただけじゃ何も解決しないんだよ。

>>172
> ファイルアクセス権限を簡単に手に入れてしまえるレジストリの問題だろ

はぁ？ お前がなんかのプログラムを起動したとして、
そのプログラムが設定ファイルを読み書きする。

そのときに毎回パスワード聞かれるか？ よく考えてみろ。

>>173

だから、レジストリ＝設定ファイルの利用方法の話とかいうのなら、
すでにすれ違いだろうがｗ

レジストリ関係ねーよ。レジストリ使わなくても結局同じことなんだよ。


お前（ら）がレジストリに悪夢持ちすぎなんだよｗ

■レジストリのアクセス権について、明らかに間違った知識が
広まる前に訂正しておく。


レジストリの実態は単一のファイルではない。

レジストリを読み書きできるからといって、レジストリの内容すべてに読み書きできるわけじゃない。

一般ユーザーでは、読み書きできない場所がある。
アクセス権という概念がレジストリにはある。

一般人もレジストリ汚せるから成立してるビジネスもあるんだよ

＞そのときに毎回パスワード聞かれるか？ よく考えてみろ。

linuxならos巻き込むものについては聞かれるね
レジストリでやると成立しないけど

だいたい、いろんなものをごっちゃにしている。

レジストリは一般ユーザーが読み書きできる場所と。
一般ユーザーが読み書きできない場所があることは説明した。

さて、ファイルも同じだ。一般ユーザーが読み書きできる場所と
読み書きできない場所がある。

レジストリの中で一般ユーザーが読み書きできる場所に保存しているのはな、
ようするの個人情報だ。ファイルだと一般ユーザーが読み書きできる場所に保存する情報だ。

レジストリで一般ユーザーが触れる。データはファイルにしても一般ユーザーが触れるんだよ。
でもシステムデータファイルなんかは、一般ユーザーが触れないというのだろう？

そういうデータは一般ユーザーが触れないレジストリ領域に書き込まれるんだよ。

>>178
su -lでログインしたら聞かれないよ

一般ユーザーが触れないレジストリ領域に書き込まれてもおｓ壊れる最低システムだな

一般ユーザーが触れないレジストリ領域に書き込まれなくてもおｓ壊れる最低システムだ

訂正

> os巻き込むものについては聞かれるね
> レジストリでやると成立しないけど
反論の意味を含めてこういう話をしてあげよう。

関連付け情報と追うものがある。これはOSを巻き込むものだ。
だから一般ユーザーは設定できない。そのためVistaでは関連付けの設定をする場合
UACによって管理者権限を取得することを求められる。（管理者じゃない場合はパスワードも聞かれる）

★ここからが、重要な話。これがうそではない証拠。であり俺の言っていることの信用度をさらにあげる話。

UACってのはアプリケーションを起動したときに聞かれる。そこで許可を与えずに、
いったん通常通りに起動したら、管理者権限を得るためにはアプリの再起動が必要になる。

だから、秀丸は関連付けの際、関連付け用のプログラムを別に起動する方法を採用し、
MediaPlayerClassic Homecinema は、もう一つ別のプロセスが起動する（だが関連付け設定の画面のみ有効）

レジストリでやると成立しないとか、何も知らないものの言う事。

UACは失敗だろ

>>182
一般ユーザーが触れるところをいくらいじっても
システムは正常に動くよ。

壊れるのはそのユーザーでログインしたときぐらい。

嘘だと思っているのなら、ユーザーフォルダの中にある
レジストリファイルの実態（ntuser.dat）を削除してみればいい。

システム全体、およびほかのユーザーにまったく影響はないから。

関連付けだけ







アホ

>>186
関連付けは例に挙げただけ。

「だけ」だというのなら、他は違うという証拠を・・・・

って正論持ってきても駄目だろうなｗ

たぶん、こいつには何を言っても無駄ｗ

かるとだね




レジストリに行儀悪いぷりが書き込んでosを壊したという話は？

＞関連付けは例に挙げただけ。

一例だけだろ？

じゃあ、二例目を。

システムを起動するのに重要なキーを
一般ユーザーはいじれない。

やってみればわかる。

> レジストリに行儀悪いぷりが書き込んでosを壊したという話は？

なんだ？ 行儀悪いアプリを作ってほしいのか？
システムを全部フォーマットするような。

rm -rf /

管理でないと話にならないosだから意味ないね

おっと。設定ファイルの話だったな。

rm -rf /etc

rm -rf /

やれるもんならやってみろ

rm -rf /etc やったら管理者じゃないからエラーになる？

レジストリだって、システム関連の重要なキーを
編集するとき管理者じゃなければエラーになる。


先に反論かいちゃったｗ

管理でないと話にならないosだから意味ないね

>>196

うぜーな。スレタイ嫁。

レジストリの話じゃねーだろそれｗ

>>160
> どっちみち内容を更新するには"F5"キーを押さなきゃ駄目なんだから、
> バッチファイルを一々ダブルクリックするのも同じことじゃん

これを同じだと思う神経なら、ini も reg も同じに思えるんだなろうな。

> また、テストの話に限定したがってると言っているが、最初にテストの
> 話をしてたのは貴方の方でしょう?

ああ悪い、最初はデバッグ用のテストデータとか書いてからな。
単体テストとかの方向に行ったので、>>129 で「デバッグ」って明記した
し、その後も何回か書いてるのに理解できないようですな。

> 「お　前　が　間　抜　け　だ　か　ら　だ」

まあ、不注意と言えばそれまでだけど、現実にあるからしょうがないのは、
>>131 に書いた通り。複数人で開発すると、そう言う人間にも仕事させな
いわけにはいかんのでな。

>>161-165
ついに発狂したのか？
ついでに、rm -rf / でディスクが「フォーマット」されたとか言う奴は
フォーマットと全消去の違いぐらい勉強したほうがいいと思うよ。

あと、プログラマの余計な負担に項目を１つ追加しておくよ。(w

・アホなレジストリ厨に絡まれる

＞ ついでに、rm -rf / でディスクが「フォーマット」されたとか言う奴は
＞ フォーマットと全消去の違いぐらい勉強したほうがいいと思うよ。

んぁ？ 「全消去」に直せばほかに反論点はないのか。

レジストリの破損をきっかけにWindowsのシステムが壊れるのは、レジストリ自体が悪いのではなく
MSの設計が悪い。
…でおｋ？

>>200
「言いたい事」はそれでおｋ

ただし、システムファイルの破損をきっかけにOSが壊れるのは、
OSの設計が悪い。と言っているのと同じこと。

>>201
いや、Windowsのレジストリはシステムだけでなくアプリの設定も詰め込んで無駄にアクセス機会を増やしてる。
だから「OSの」ではなく「MSの」と表現しなくてはならない。
安全性を考慮すればシステム用のレジストリとアプリ用のレジストリを分けるべきであった。

汚いゲリストリだなぁ

アクセス機会が増えたからってそれが何なんだろう・・・？

オープン、クローズの回数なら設定ファイルに分けたほうが多いけど。

>>198
> まあ、不注意と言えばそれまでだけど、現実にあるからしょうがないのは、
> >>131 に書いた通り。複数人で開発すると、そう言う人間にも仕事させな
> いわけにはいかんのでな。

こういう奴がいるから、保守用/テスト用のツールの作成が重要なんでしょ
失敗があったのなら、失敗しないやり方を研究すべきで、失敗の原因をシステムに擦り付けるのはナンセンス

レジストリが原因とは言っているが、例えそれがiniファイルで在ったとしても、そういう奴なら、system.iniやwin.iniを変更するのは目に見えてる

> 安全性を考慮すればシステム用のレジストリとアプリ用のレジストリを分けるべきであった。

分かれてるけどねｗ

>>206
レジストリが壊れたら１ユーザ分壊れるんだろ？
十分ダメだろ。

レジストリなんてめったに壊れないだろｗ

それこそファイルシステムが壊れるのと同じぐらいの確率だ。

なんでそんな低確率の話してんの？

>>208
　この場合の「レジストリが壊れる」は、物理的にレジストリのファイルが死ぬってことも、
論理的にレジストリと見れないファイルになるってことも、レジストリとしては正しいんだが
内容が正しくない状態になるってのぜんぶひっくるめて「壊れる」つってんだろ。

　まあ一部は別にiniでも起きることだが、レジストリのように他のアプリまで使えなくする
＝壊す可能性があるってだけで頻度とかの問題でなく充分危険視されるネタになる。

　１％の確率で起きる現象でも、20回やって１回も起こらない率は８割。２割も起こるんじゃ
無視できんだろ。

　１回当たりのハズレ引く可能性もっと低かったところで、環境それなりに整うまでに
インストールを何回やると思う？

だから、そんな壊れる確率は
かなり低いだろ。1%もねーよ。

それよりかディスクが壊れることの方が
確率高いよｗ

そもそも物理的・論理的な障害の前にはiniもレジストリも関係無いだろ

>>208,210
それはウソ。レジストリが壊れる可能性のほうがはるかに高い
…と、根拠がなくても良いのならいくらでも言える。
俺自身HDDの故障に逢ったことはないけどレジストリの破損でトラブった経験があるし、HDDやファイル自体が
壊れたという話よりアプリを追加しなくても使ってるうちに重くなるという話の方がよく聞く。

俺自身、レジストリの破損にあったことはないけど
HDDが故障したことは何度でもある。

>>211
iniファイルはアプリや設定内容毎に分かれてるから他を巻き込む可能性は低い。
(Windowsの)レジストリは分かれていないから他を巻き込む可能性が高くなる。

>>214
レジストリならOSによってバックアップ取られてるから、異常があったらバックアップから復元できる。
ini限らずファイルによって設定を管理してる場合は、バックアップ等々は各ソフトウェアによって実装してたりしてなかったり。
そう考えた場合、自分には被害のレベルとしては レジストリの破損 < iniファイルの破損 と考えるのだが。

それに、前の方で散々煽りあいになってるが、大なり小なり設定が壊れるという状況が本来異常かと。

上書き

うはっ。レジストリすげー上書きできねー。ロックかかっている。アクセス権がないって言われるｗｗｗ

という話がしたいらしい。

新しいPCに環境を移行するときにレジストリを使ってないソフトは
フォルダをそのままコピーするだけでいいから便利。

外付けHDDにソフトをインストールしておけば、
複数のPCで同じように使えるし。

自分で
>> それに、前の方で散々煽りあいになってるが、大なり小なり設定が壊れるという状況が本来異常かと。
とか書いてるが、流石に"異常"って言うほどでは無いので訂正。無いとは言い切れないか。

>>218
ユーザーフォルダに書き込まれる
設定ファイルとかどうすんの？

>>176
それはVistaだけだろう？

もう少しいうと、Windowsのアプリはちょっと前までシングルユーザで使うのが
大半だったから(Windows9xとか)、Program Filesの直下に平気で作業用のファイルを
作るアプリが多かったし、今も多い。さすがにVista登場で減ってきたが。

Program Filesは当たり前だけで全ユーザが共有しているので、
そこを書き込み禁止には出来ない。つまり誰でも読み書きできるようにしないと、
旧来のアプリが動かなくなってしまうので、禁止できなかった。

そこでMicrosoftはVistaでVirtual Storeというものを導入した。
一般ユーザモードで動いているアプリがProgram Filesにファイルを書き込もうとすると、
別なシステムが別なフォルダにリダイレクトしする。アプリからはProgram Filesの下に
書き込まれているように見えるが、実はユーザ毎のフォルダに書かれていて、
Windowsがアプリをだましている。

レジストリでも同様のことが行われていて、管理権限のないレジストリをユーザアプリが
書き換えようとすると「そのユーザ専用の」レジストリが作られ、それが書き換わる。

つまりユーザは自分が大本のファイルやレジストリを書き換えているつもりで、
実はユーザ毎に用意されたファイルやレジストリをいじっているだけ。
これがVistaの特徴(うっとうしい欠点ともいうw)

>>221
違う。

>>223
どういうデータが格納されてんの？

何の話？

>>225
だから普通ではアクセスできないレジストリって、どんなデータが入ったレジストリ？

ハードウェア情報とかそういう
管理者でしか設定できないデータ

>>227
ああ、そりゃそうだね。

わかりやすくいうとレジストリがボンバーマンでiniがロードランナーってこと？

iniファイルでさえ鬱陶しい。
設定ファイルなんてタブ区切りテキストでいいよ。

>>205
だから、テストとデバッグは区別してくれ。
で、失敗しないやり方を研究しろって言う割には、

> で、具体的なやり方はどうするんだい？

ってやると、回答なしなんだよな。

> レジストリが原因とは言っているが、例えそれが ini ファイルで在ったとしても、
> そういう奴なら、system.iniやwin.iniを変更するのは目に見えてる

レジストリだと全部のエントリが見えてるからクリック一発で違うエントリを開いて
編集できてしまう。それに対して自分の ini ファイル触ってる時に system.ini とか
win.ini を触ろうとしたら、ファイルを開くと言う違う通常とは操作が必要になるから
間違う可能性は格段に低くなるだろ。

もちろん、レジストリエディタを改良すれば済む話なんだけど、それこそ最初から言っ
てる

「 新 た な 負 担 」

だろ。

>>231

なんでレジストリエディタを改良なんておおがかりな話になるんだ。
自分のアプリに関連するキーだけexportして、書き換えて、importするだけで
他のアプリもシステムも壊すことは無いのに。

>>231
だから、バッチファイルで4行だと言っている

SET keyname="サブキーの完全なパスを指定"
reg export %keyname% work.reg
notepad work.reg
reg import work.reg

この程度のバッチファイルも組めないのか?

>>233
結局余計な手間がかかるんだね。

>>230
XMLを設定保存用のフォーマットにしようってこの時代に何を。

>>231
強力なツールや大きすぎる権限ってのは時にシステムを破壊する危険性がある代わりに
自由自在な操作や変更が可能。慣れれば素早くもなる。

レジストリエディタも本来はプロ用万能ツールの性質が強くて、慎重に、かつ必要最小限の使用にとどめるべきもの。
安全性から考えれば>>232も一理ある。

>>233は欠点があるけどね。
・編集した結果、書式が間違っていないことが条件。書式を間違えていると再登録に失敗する。
・バッチを途中で止めた場合書き戻されない。
・当然だが、保存し忘れれば編集結果は反映されない。(場合によっては利点)

>>232
ねぇ、何で話をループさせるの？

「exportして、書き換えて、importする」作業と、「書き換える」だけの
作業のどっちが楽か考えたらわかるだろ？

>>233
> この程度のバッチファイルも組めないのか?

違うサブキーを編集する時は、そのバッチを編集するんですね。
流石にそんなダサいバッチファイルは組めないよ。(w

>>234
そう、そんな簡単なことが理解できないのはなぜなんだろうね。

>>235
> 強力なツールや大きすぎる権限ってのは時にシステムを破壊する危険性がある代わりに
> 自由自在な操作や変更が可能。慣れれば素早くもなる。
> レジストリエディタも本来はプロ用万能ツールの性質が強くて、慎重に、かつ必要最小
> 限の使用にとどめるべきもの。

その意見には反対しないけど、ツールとしてそれしかないのが現状だから、面倒って言っ
てるだけ。例えば、キーとか値を正規表現で検索や置換することすらできないんだよ。

> 安全性から考えれば>>232も一理ある。

別に >>232 がダメって言ってるわけじゃない。
でも、エディタで編集するだけに比べたら、面倒でしょ？

>>236
>>235の言ってる欠点はあるが、アプリの利用するサブキーのみをエディタで編集すると言う目的は達しているから十分じゃん
大体、俺は日曜プログラマと言ってる
つまり素人です
イケてるツールが作りたいなら、プロである貴方でお作りください

そんな泣きながらレスするんなら初めから参入しなきゃいいのに...。

>>236

＞ねぇ、何で話をループさせるの？

具体的なやり方を聞かれたから安全で簡単なやりかたを書いたまでだけれど。
レジストリエディタの改良なんて現実的でない解よりはるかにスマートだよ。
使い捨てと割り切ればいいんだよ。

.NET TIPS
アプリケーション設定情報はどこに保存すべきか？
ttp://www.atmarkit.co.jp/fdotnet/dotnettips/263apppath/apppath.html

.NET FrameworkではXMLファイル方式が標準なのだから（レジストリも使えるけど）
少なくとも個別アプリの設定情報の管理に関しては
MS自身が脱レジストリを志向しているのは間違いないと思う

だがレジストリの枠組みは互換性確保のためにこの先も残り続けるだろう
一度導入した以上、そう簡単には廃止出来ないし、現状でそうするべきでも無いから
システム管理用途ではずっと使われ続けるかもしれないし

補足
と言っても.NETの普及が進んでいない現状だから、
将来に関してはまだ何とも言えない部分も多いけどね

>>239
せめて、この内容に回答してからレスしてくれないかなぁ。

> 「exportして、書き換えて、importする」作業と、「書き換える」だけの
> 作業のどっちが楽か考えたらわかるだろ？

>>242
>>233のバッチで解決済みではないのか?

>>242

ま、その二者で比べれば書き換えるだけが楽だけどね。
でも現実的な用途だとそこまで汎用的な編集はしないでしょ。
xx用データ1.reg
○○用データ2.reg
みたいなのを複数用意して何度も使いまわすケースのが多い。
アプリケーションの設定を手探りで行うわけがないからね。

>>243
彼は3分でバッチを書く手間を惜しんでいるのでね。

>>243, >>245
>>237 がかわいそうなので引き合いに出さないでやってくれます？ (w

>>244
> アプリケーションの設定を手探りで行うわけがないからね。

デバックですよ？ (何回目だ？)

モノグサ、無い物ねだり、理想郷、etc...
廃人プログラマーに多い、「困ったちゃん」ですね。

>>246
デバッグにつかうデータにパターンが無いわけないだろう？

windowsなら、iniにしてても同じ気がするなー
WINDOWSフォルダの中が、すげーことになってるから、
どうせ　ini　にしたって同じだろ
そこかしこに、iniファイルをばら撒いたり、勝手に消したりするんだろうなー

だな、自分のフォルダ以外悪さできないようにしないとな。

>>246
それと、>>237の書いたバッチは
>>231の「レジストリエディタを改良」発言よりはるかに使えるものだから
あんたとしては引き合いにだされると困るよな。

でもさー
そういうのって単なる「問題回避のためのTIPS」の範疇じゃん
全然スレタイに沿った本質的な話じゃないと思うんだよね

いつまで続ければ気が済むのかと

>>247-251
夜中までご苦労さんなことだな。

>>247
「新たな負担」があると言う事実を指摘したら、「ものぐさ」って...
いくら反論できなくなってるとは言え、馬鹿？

>>248
へ〜え、君ん所はあるんだ、すごいなぁ。
これで満足？

>>249-250
>> レジストリだと全部のエントリが見えてるからクリック一発で違うエントリを開いて
>> 編集できてしまう。それに対して自分の ini ファイル触ってる時に system.ini とか
>> win.ini を触ろうとしたら、ファイルを開くと言う違う通常とは操作が必要になるから
>> 間違う可能性は格段に低くなるだろ。

>>251
そうだよね。無いものよりは、はるかに使える。
でも、>>234 なんだよな。
# ダサいって言われたのがそんなにショックだったのか...。

こんなネタは前世紀までにしとけよ

>>253

>>155で

＞＞レジストリとiniの差も満足に埋めれない作業方法
＞ねえ、誰が埋めれないって書いてるの？
＞なんか書いてないものが見える人が多いなぁ。(w
＞あくまでも、「バッチファイルの管理」とか「差を埋める」のが面倒だって書いてる
＞だけ。

と書いてあったから、面倒ではあってもなんらかの工夫で差を埋めているのかと思ったが
問題意識を持っているはずのレジストリの誤操作に対しても完全に無防備のまま…
レジストリエディタ改良案よりはるかに使える他者の案はとりあえずこきおろす、と。
やっぱり何にも工夫してなさそう。

まあ、プロが改良型レジストリエディタが必要だと言ってるところを
ど素人の4行プログラムで見事に解決されたんじゃ、扱き下ろしたくもなるよな
そうでもしないと、プロであるというプライドがずたぼろだし

しかし、アマに劣るプロってw

>>256
とりあえず全然解決してないぞあれじゃ。
何か仕掛け作ってやるってんならもっと気合入れて作る必要がある。だから面倒だと言ってるんだろうしな。

レジストリとDocuments and Settingsフォルダ使うのどっちがいーの

>>257
ぜんぜん具体的じゃないｗ

問題は解決している。

>>252
そうだね。
レジストリの破損がシステムを巻き込んだり、使っているうちに重くなったりする問題を検証しきれないうちに擁護派に話を逸らされてる。

>>253
>>233を修正してやったぞ、VBスクリプトだからノートン君が煩いかもね
-------
Editor = "notepad"

KeyName = ""
Title = chr(34) + "簡易レジストリエディター" + chr(34)
KeyNameError = ":error1" + vbCrLf + "echo MsgBox " + chr(34) + "レジストリキーを確認してください" + chr(34) + ",0," + Title + " > error.vbs" + vbCrLf + "error.vbs" + vbCrLf + "del error.vbs" + vbCrLf + "goto end"
ImportError = ":error2" + vbCrLf + "echo MsgBox " + chr(34) + "レジストリの登録に失敗しました" + chr(34) + ",0," + Title + " > error.vbs" + vbCrLf + "error.vbs" + vbCrLf + "del error.vbs" + vbCrLf + "goto end"
While KeyName = ""
KeyName = InputBox("サブキーの完全なパスを指定","レジストリキーの設定")
Wend

Set objFS = CreateObject("Scripting.FileSystemObject")
Set objFile = objFS.CreateTextFile("edit.bat", True)

objFile.WriteLine("@echo off")
objFile.WriteLine("reg export " & chr(34) & KeyName & chr(34) & " work.reg")
objFile.WriteLine("if errorlevel 1 goto error1")
objFile.WriteLine(Editor & " work.reg")
objFile.WriteLine("reg import work.reg")
objFile.WriteLine("if errorlevel 1 goto error2")
objFile.WriteLine("del work.reg")
objFile.WriteLine("goto end")

objFile.WriteLine(KeyNameError)
objFile.WriteLine(ImportError)

objFile.WriteLine(":end")

objFile.Close

まあ、>>261を使うぐらいなら、>>233で十分な気がするけどな

>>260
> 使っているうちに重くなったりする問題を

これは過去レスで完璧なまでに論破されている。


重くなる原因は、単に常駐アプリが増える為である。
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^


XMLやiniにしても、常駐アプリが同じである以上重さは変わらない。
むしろバイナリからテキストになることで
データサイズが増える分、レジストリ以上に重くなる。
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

>>263
それは論破じゃなくて無理やり押し通してるだけ。
使用感が変わるほど常駐アプリをインストールしたら分かるだろ。
後半は「Windowsのレジストリ」の問題を「一般的なレジストリ」にすり替えただけだし。

>>263
レジストリだって元はテキストだからソフト内では関係ない

linuxなんかだと、重くなるほどソフトのインストールなんて出来ないし

>>74
だから定義しておけという話。
現在は何らかの推論でクリーンを実行してるんだろう。

>>75
あらかじめ定義しておくべき項目の一例として出したにすぎない。
AllUsersに対して1ユーザーの個人設定云々という話ではなく
LinuxのようにドットファイルだけバックアップしておけばOSインストールしなおしても
同じ設定ができるような（Linuxなら現状で問題ないという意味ではないが）
しくみもあればよかった。

あげ足とりばかりで使えんスレだな。

ム板っぽいなここ
板違いじゃないのか？

>>255-256, >>259
ねえ、マジで >>233 でいいって思ってるの？
問題が解決したと思ってるの？
引っ込みつかないだけじゃなくて？

いや、そう思ってるならいいんだけどね。
そもそも、何が問題かすら忘れてそうだし。

>>261
何で、わざわざバッチファイルなんか生成してるの？
直接 vbs から reg 呼べばいいと思うけど。

あと、好みの範疇かもしれないけど、KeyNameError にコード (更にはラベル)
まで含めるのはどうかと思う。

WriteLine() 中のコードを見てて、goto error2 のとび先？ って一瞬思ってし
まうので、保守性がちょっと悪い。

メッセージを差し替えたい要求があるなら、KeyNameError なんかはメッセージ
だけにした方がわかりやすいと思うよ。
(俺ならどうせ InputBox() のプロンプト直書きにしてるんだから、全部直書き
にするが。)

更に、chr(34) なんて古臭いものを使わなくても、

Title = """簡易レジストリエディター"""

で十分だと思うけど。

>>268
すまん、まさか４行バッチで勝ち誇る輩がでてくるとまでは予想できなかったよ。

>>269
ぷぷっ
発想力のないことを言い訳してるよw

>>122で
・自分の好みのエディターが使えない
・重要なレジストリキーを間違えて削除してしまう場合がある
と言ってる部分は、4行バッチで解消されている

>>127で言っている
・確認の為何度も、レジストリの内容を確認しなきゃだめ
これなんて、4行バッチをちょっと改造するだけで十分対応可能

わざわざ改悪したvbsに噛み付くなんて正気の沙汰とは思えない
つか、4行バッチよりスマートに出来ると言うなら証拠を見せて欲しいものだ

>>270
> いや、そう思ってるならいいんだけどね。
> そもそも、何が問題かすら忘れてそうだし。

想像通りのレス乙 (w

>>271
ぷぷっ
出来なかったからって

> 想像通りのレス乙 (w

みっともねぇwww
つか、センスねぇwww

>>261 への指摘がそんなに悔しかったんだろうか...。

>>273
おやおや
>>262でこんなん使う必要ないしと言ってるじゃん
目が腐ってるの?
しかも、>>269が指摘って...
指摘なんて言えるんかあれ...

本当、出来ない自分を隠すのに必死ですなぁ
能力はないが大口を叩くのは得意って奴ですかw
ダサい...ダサすぎますよ...
反論するなら、スマートなコードと共に反論しないと、口だけだって思われちゃうよw
まあ、口だけなんだろうけどwww

またバッチ云々で話題逸らしか…

使う必要ないと言いながら...

> しかも、>>269が指摘って...
> 指摘なんて言えるんかあれ...

相当根に持ってるみたいだな。(w

>>275
もう、腹がいてぇ
笑かすのはもう止めてくれw

口先だけかよwww

しかし、うらやましいねぇ
「そんなことは出来ない」
って言えば給料がもらえるなんて、羨ましい限りだ

>>1
実際のレジストリは良くはないと思うけど
レジストリがあったから悪いOSという事でもない。
しいて言えば使い方が悪い。
WIN.INI, SYSTEM.INIをちょっと高級にした程度で
使い方をちゃんと決めなかったからじゃね？

> 指摘なんて言えるんかあれ...

だったら、指摘のどこがおかしいか「指摘」したら？

# まさか、口先だけじゃないよね。(w

>>280
でたー
質問返しwww

馬鹿じゃねぇ
あそこで指摘すべきは、プライベートに設定された変数をパブリックにする気か?この気狂いめ!
ってのが正しい指摘だろ
それなのに
> (俺ならどうせ InputBox() のプロンプト直書きにしてるんだから、全部直書き
> にするが。)
さらに、パブリック化する気満々かよ!!!
レジストリエディタを使って、間違えて重要なキーを削除しちゃうような奴がいるのに、そこをパブリック化しちゃ駄目だろうよ
むしろ、4行バッチのレジストリキーを設定した後は、ファイルをリードオンリーにして、変更させないようにするべきだろうが

小手先のテクニックを披露して指摘したつもりかよ
マジ、プログラマとしてのセンスがないんじゃない?

レジストリが無ければこのスレのぐだぐだな展開も無かっただろうに

レジストリの何がだめかって
レジストリ使うソフトはOS再インスコ
した時に１から入れ直さないといけないということ・・・

アプリをインストールしたフォルダをCドライブからDドライブへ
移動したとしても、デスクトップのショートカットの関連付けも
自動的に修正されて、何の問題なくデスクトップのショートカットから
起動可能な状態を保てる様になっていないのは、レジストリやiniの
システムがよるのではないのでしょうか。

融通の利かないWinのショートカットにせよ、
固定された枠組みで拡張性の無いレジストリの仕組みにせよ、
今ではかなり技術的に劣る方式だから仕方が無い

linuxじゃあるまいし...
アプリのインストールしたフォルダをCからDへ移動するんなら
インストールしたアプリをアンインストールして移動先のドライブに再インストールしたほうが、大抵の場合そのままコピーするより速いでしょ

最近のアプリはアンインストールが、すげー遅い

>>283
全部統合したセットアップディスクじゃダメなの？
(その分選択肢せばまるけど)

>>281
> あそこで指摘すべきは、プライベートに設定された変数を
> パブリックにする気か?この気狂いめ!
> ってのが正しい指摘だろ

何を言ってるのかさっぱりわからん。
おそらく本人もよくわかってないんだろうな。

>>289
理解力もねぇwww
絶望的だよwww

もういいかげんやめないか？
両者とも必死で痛々しい。

>>291
やなこった
こんな面白い玩具を誰が捨てるものかw

>>284
サービスだよ。
それはレジストリといえばレジストリだが。

アンインストーラなしのソフト削除したらその分のレジストリも削除してほしいもんだ。

>>290
はいはい、君は偉いよ。
>>261 に加えて、そんな的確な指摘できるんだもんね。

>>294
本当に口先だけだねwww

ハードウェアに依存するアプリとか速度が必要なアプリは普通にインストールして

あとは仮想環境にいれればレジストリは大きくならないじゃん

結局ID:HjNiU+SJは、あら探し専門か。
問題の解決になっていないといいつつ、解決の為に必要な機能を挙げることすらしない。
でも態度だけはでかい。

そういや、レジストリってwindowsが起動してなくても、
HDDをマウントするだけで、バックアップが取れるんだっけ？

起動してたら逆に取れないだろ。

>>297
いや〜そう言うけど、>>281 だよ？
あら捜しがどうのこうの言う前に、彼が何を言ってるのかわかるんなら
説明して欲しいもんだ。

>>299
それどうやんの？

>>300
まだ言ってるよwww
本当に、プログラマかよwww

FirefoxPortable愛用している
ThunderbirdPortable愛用している
持ち歩けるのはすごく便利
他のアプリもレジストリを捨てて欲しい
レジストリは奴隷の足につけた鎖
レジストリからの自由運動を提唱したい

Date: 2008/09/25(木) 00:04:00 ID:70Q/Y/DR
Date: 2008/09/25(木) 00:16:06 ID:70Q/Y/DR
Date: 2008/09/25(木) 00:34:11 ID:70Q/Y/DR
Date: 2008/09/25(木) 00:49:28 ID:70Q/Y/DR
Date: 2008/09/25(木) 10:05:12 ID:70Q/Y/DR
Date: 2008/09/25(木) 19:32:39 ID:70Q/Y/DR
Date: 2008/09/25(木) 20:10:31 ID:70Q/Y/DR
Date: 2008/09/25(木) 21:48:06 ID:70Q/Y/DR
Date: 2008/09/25(木) 23:58:41 ID:70Q/Y/DR

一日にちゃんざんまいか...。
無職乙。

>>304
ねぇねぇ、どの辺が2ch三昧なの?

レジストリ弄るの失敗して起動しなくなることは事実なんだよね
レジストリ固有の問題じゃないとかいういいわけは聞き飽きた

>>3
不要レジストリを削除して、その後にレジストリのデフラグをかけてもまったく意味はないということですな？
ほったらかしでＯＫ？

>>306
聞き飽きたようだが、どんなOSであっても
設定をミスれば起動しなくなる。

聞き飽きたなんていってないで、
レジストリ固有の問題じゃないと認めるか、
反論を書けよ。

こういうレスがくるのは予測済みなんだろ？
先に反論を書いていてほしいものだ。

>>303
> FirefoxPortable愛用している
> ThunderbirdPortable愛用している
> 持ち歩けるのはすごく便利
> 他のアプリもレジストリを捨てて欲しい

ここで疑問を持ってほしい。
レジストリが無い他のOSはアプリを持ち歩けるのかと。

たとえアプリを持ち歩けたとしても、
設定ファイルごと持ち歩けるわけじゃないだろう？


そこで、レジストリ固有の問題じゃないじゃんと
頭のいい人は気づく。

データの置き場所の問題と
データの格納フォーマットの問題を混同している限り
このスレは伸び続けるであろう

微々たる起動時間を競うことよりも、整理のし易さ・安定度・長期継続性、を考えると時代錯誤も甚だしい

レジストリって一覧性悪いよね

そもそも、直にレジストリデータを弄る必要があるのか?
直にレジストリを弄らなくても、設定出来るじゃん普通

設定？なにそれ？

デフォのまま使えるじゃん普通。

>>309
ん、他のOSはその辺の自由度は高いと思うぞ。
つか、他のOS使った事あるの？
なんか、何がなんでもレジストリは良い物だと主張したくて
無理にレスしてるように見えるんだけど。

レジストリのお掃除してる時点で、言わずもがなw

レジストリのキーと同じ数の設定ファイルがHDDのいたるところに散乱している様子を想像してみようか・・・

レジストリ＝ゴミ屋敷

>>305
ああすまん、君にとっては「普通の生活」だったんだよな。

>>309
>たとえアプリを持ち歩けたとしても、
>設定ファイルごと持ち歩けるわけじゃないだろう？

設定ファイルごと持ち歩くのが当然でしょ
だからPortablなのよ
だから便利なのっ！
設定ファイル持ち歩けないなんて、頭のいい人は何考えてるの

ちなみに、Live2chも持ち歩いてる
どのPC使っても、未読・既読・取得ログも板ボタンも全て一環継続している
快適だよう

レジストリはWindowsだけが使えばいいのよ
Windowsを持ち歩こうとは思わないからさ

スレタイは、OSがレジストリを実装することを否定していたんだね
私の発言はズレてました、ごめん

>>319
自分の事は棚に上げて何言ってるんだろうね?

>>319
自分の事は棚に上げて何言ってるんだろうね?

>>322-323
Date: 2008/09/25(木) 10:05:12 ID:70Q/Y/DR
　　　　　　　　　　~~~~~~~
仕事サボるなよ。

あっ、元々仕事ないんだったな。(w

>>324
へぇー自分の勤務形態以外の勤務形態は無いんだ

はいはい、世の中「無職」も含めていろんな勤務形態がありますもんね。(w

人と同じ休みのある人はいいねぇ

>>320
ファイルに置くソフトでも、設定の置き場が%APPDATA%以下固定なら、やっぱり持ち運びできない。
「レジストリだと設定ごと持ち運べない」は完全にそのとおりなのんだけど、
レジストリvs設定ファイルの対比に用いるのはあまり適切ではない。

これも>>310に当てはまる事柄だと思う。

>>327
いいでしょ？

>>328
・レジストリ ⇒ とんな場合でも設定ごと持ち運べない
・ファイル ⇒ ソフトが頑張れば、持ち運べるように作ることができる。

持ち運びの容易さと言う観点からは、どっちが優位かは考えるまでもないと思うが。

どうしても持ち運びしたけりゃload.exe+Reinforce.dll使え

レジストリ利用アプリで仮想レジストリを使用しファイルから設定を読み込んでくれる

Documents and Settings以下に作られるファイルをアプリケーションと同フォルダにおける

Schwertkreuzといったほうが手っ取り早いか

今時ソフト持ち運ぶ奴なんて寝カフェ難民くらいだろｗ

３３３

お前ら、自分のミスをレジストリの存在のせいにしてね？

レジストリの存在がミスを誘因してるわけだから

誘因×
誘発○

誘引

>>329
こいつ息をする様に嘘を吐くな...
設定を持ち運び出来るようにするかどうかは、アプリケーションを設計次第じゃん
その証拠に、FFFTPなんかは、設定を移動できるように作られてるし

ここら辺のことを言ってるのか？
http://www2.biglobe.ne.jp/~sota/ffftp-qa/qa-26.html

だとしたら、論点ずれまくり杉。
そう言う操作が必要なことを問題にしてるんだから。

# またどうせ、そんな操作は簡単だから問題ないとか言い出すんだろうか？

>>339
君の様なセンスのない開発者が多いから、設定を持ち運べるプログラムが少なくないって事を言っているんだよ

設定を別のPC、もしくは再インストールしたPCに移す機能は欲しいが
そんなに頻繁にアプリケーションの設定を別のパソコンに移すことなんて無いじゃん
それとも、君は毎日別のPCからアクセスしてるのかい?

バイナリとデータが同じ場所にあること自体センスが悪いんだよ。

>>340
はいはい、思った通りの的外れレス乙。(w

>>342
的外れって事にしないと、自分が口先だけで、てんで駄目なプログラマーだってバレちゃうもんなw

そうだよねぇ、君は間違ってないよ。

これで満足？ (w

バイナリは、Program Files
設定は、
Document And Settings\All Users\Application Settings に共通の設定をXMLで保存
Document And Settings\(user)\Application Settings に固有の設定をXMLで保存

がこれからの常識になるよ。
All Users におかれた全体情報を、User固有の設定が継承・上書きする。
設定情報をエクスポート・インポートするためのツールがプログラムごとにできるだろうさ。

まぁ、そこまでするならレジストリのほうが楽だけどね

これからは
C:\ProgramData
C:\Users\(ユーザー)\AppData
だろ、いつの時代のOS使ってんだよｗｗｗ

Windows若気のいたりの訂正ですな、それをもとに詰るとはw

linux系の具体例も交えて話せる人おらんか？
同じ車種・燃料マップでメーカーの違うアフターパーツの
どちらがの良し悪しを話してるように思えてきてるんだが。

47氏みたいな人ってそうそういないんだね。

素人は、設定ファイルにどう必要データが書き込んであるか説明あれば、そこを触るか触らないか自己責任でなんとか出来るんだけど。
ところがレジストリィだと、直接的な設定データはまだしもOSがそれをどう扱かい、データを各所にどう撒き散らしているかまで把握しづらい。
また、OSもアプリケーションもレジィストリィで設定をどう扱っているか説明皆無だろう。
GUIでプロパティ設定出来るようになっていてもかったるいし、省略されている部分もあるし。　設定を複数ファイル用意して恣意的に切り変えることのほうが分かり易い。

>>349
GUIによる設定を否定するのはいいが
ダウンサイジングの波にさらわれていった、多くのコンピューター企業と同じ目に会わなきゃいいけどな
設定ファイルによる設定という方法が既に時代遅れになっていると思うぞ

>>350
じゃあどうやって設定を残しておくんだよ
どういうのが時代にあってんの？

>>350
> >>349
> GUIによる設定を否定するのはいいが
> ダウンサイジングの波にさらわれていった、多くのコンピューター企業と同じ目に会わなきゃいいけどな
全面的に否定するわけではない。
ある場面では設定ファイルを変更するのにGUIのフロントエンドを被せることやぶさかではない。
直接OSまたはアプリケーションが使っている設定ファイルだけでなく、その数々のバリエーションに対しても、
対象範囲を選んで更新するようなこと出来るのが望ましい。
また、GUIのフロントエンドにはプロパティの設定による環境の変化を連動反映するビューも歓迎だ。

>>352
> ある場面では設定ファイルを変更するのにGUIのフロントエンドを被せることやぶさかではない。

"ある場面"の説明がなされていないから、
前に言ったこととまったく逆のことをさも当たり前かのように言っているのが
よくわからないな。

Windows XP SP3のレジストリ破損問題、マイクロソフト作成のexeファイルが原因
http://www.computerworld.jp/topics/ms/109390.html

こんな事やってるようじゃデータベースの構造以前の問題じゃねえか？

>>354
ちゃんと続報かけよ。
どうみてもシマンテックの問題じゃねーか。
http://www.computerworld.jp/topics/os/109889.html

　「fixccs.exeファイルはSP3の導入時にレジストリ・キーを追加し、
さらにそれを削除しようとする。一方、SymProtectはレジストリ・キーへの
変更を阻止しようとする。つまり、SymProtectはfixccs.exeによって
追加されたキーの削除を阻止しようとする」（Symantecの広報担当者）

そして、これも設定ファイルでもおきる問題だね。

設定ファイルを書き換えようとするが
ウイルス対策ソフトがそれを阻止して問題になる。

>>1
たしかにそうだなあ

>>355
全文よく読めよ

『ただし、Symantecはデバイス・マネージャに何も表示されない件については、「自社のソフトウェアに特有の問題ではない」との主張を曲げておらず、
広報担当者は「この問題についてはSymantec製品を使っていないユーザーからも数多く報告されている」と述べた。』

って書いてあるだろが

殺人が他で行われてるからってその殺人鬼の罪がなくなるわけではない

>>358
主張するだけなら誰でも出来るなｗ


それでこの問題の原因はなんだったんだ？
レジストリ？ いいや、レジストリの破損はシマンテックの問題だ。
その他の問題？ レジストリとは関係ない話になるね。

>>356
俺はレジストリにあんまり詳しくはないのでよくわからんのだが、
レジストリは人為的なミスでなくてもプログラムバグにより破壊される
可能性があるってことなのかね？
そういう重要なキー部分に対するプロクションみたいな物はないの？
設定ファイルでも壊れる可能性もあるんだろうけど、
その場合、設定ファイルの場合はファイル自体を削除してしまえば
とりあえず戻せるのに対し、レジストリだと知識が無い人に対処できない
というのは問題じゃないかな。

>>361
設定ファイルを削除して直るかどうかはソフト次第でしょ

シマンテックの問題だろうが、
マイクロソフト作成のexeファイルだろうが
レジストリの存在が悪い事には違いなかろう。
そもそもレジストリがあるから、
こんなスレが立つんだw!

>>360
お前馬鹿か

デバイス・マネージャに何も表示されない件
つまりレジストリのハードウェア情報の欠落は何なの？って聞いてんだろがアホ！

>>364
しるかｗ

設定ファイルを壊したやつが悪いんだろ。
犯人がわかっていない状態で結論を出すな。

>>361
> レジストリは人為的なミスでなくてもプログラムバグにより破壊される
> 可能性があるってことなのかね？

それを言ったら、レジストリじゃなくても、プログラムのバグにより
設定ファイル、iniだってxmlだって破壊される可能性はあるよ。

> そういう重要なキー部分に対するプロクションみたいな物はないの？
あるよ。一般ユーザーはシステムのキーをいじれない。

> その場合、設定ファイルの場合はファイル自体を削除してしまえば
> とりあえず戻せるのに対し、レジストリだと知識が無い人に対処できない
> というのは問題じゃないかな。
レジストリだって消せば直る。
設定ファイルだって、どこになにが書かれているかわからなければ対処できない。
LinuxのGnomeのスタートメニューに相当する部分。どこで設定されているかなんて俺はしらんｗ

>>366
>レジストリだって消せば直る。

ほんとか？w

>366
>レジストリだって消せば直る。
アプリケーションの期限付きの体験版、アンインストールしてもレジストリは完全に消えないな。
消えるとすれば再インストールできるはず。
こういう情報は、OSメーカーとソフトハウスの範囲内での便宜、ユーザーは蚊帳の外。
別に困りはしないが、ちょつと気持ち悪い。

>>367
本当。アプリケーションが追加した設定は消せば前の状態になる。

当たり前だが、アプリケーションが既存のなにかの設定を変更している場合、
それは消すのではなく、元に戻さないといけない。

Linuxだって、新しいカーネルを入れたときに/etc/grub.confに
新しいカーネルで起動するように設定されるが、
/etc/grub.confを削除なんかしたら、Linuxが起動しなくなる。

>>369
元に戻すというのが問題。
アプリケーションが一つだけならとにかく、レジストリに設定されているアブリケーションは数多い。
ある期間にわたって使用した結果,具合が悪くてアプリケーションを前の設定に戻すとする。
素人なら、戻したい時期のレジストリのバックアップをかろうじて復活させようとする。
ところが、その間に他のアプリケーションの設定を変えていたり、インストールしたりしていたら関連する問題が浮上する。
問題が起きて元に戻したいアプリケーションに関する部分のみのレジストリの抜き出しと最新レジストリへの復帰はうまくゆくのだろうか。

アプリの設定は、HKEY_LOCAL_MACHINE\SOFTWARE\メーカー名\アプリ名 以下に全部まとまっている。
ユーザー個別の設定は、HKEY_CURRENT_USER\SOFTWARE\メーカー名\アプリ名 以下に全部まとまっている。

>>370
さっきも言ったが、俺はLinux（Gnome）のスタートメニューの
設定がどこに書かれているかわからない。

Gnomeの設定がどうファイルに書き込まれているかわからない。

教えてくれよw

>>371
主要たるものはそうだとしても、関連するキーとその価は、各所に散らばっているようだ。
そのあたりの副作用はどうなるのよ。
何らかの働きがあるから、データとしてコピーされたり、履歴として記録されていると思うが。
実際のところ昔はレジストリエディタが超亀なのと、特別なツールは付属していないようだったので細かな運用は諦めざるを得なかったが。

>>373
なんで各所に散らばっているかわかる？

それは、「アプリケーションの設定」ではなく
OSのシステム（エクスプローラなんかも含む）の修正や拡張だからだよ。

OSのシステムの拡張をするためには、アプリケーションの領域にデータを書き込む仕組みだけでは達成できない。
これはレジストリだけに限った話じゃない。たとえばLinuxだってアプリケーションが
OSのシステムを書き換えるためには、OSが使用している設定ファイルを変更する必要がある。

つまり、このアプリケーションは各所に散らばったファイルを修正するわけで
結局はレジストリと同じこと。

まずね。

アプリケーションの設定データ なのか
OSの設定データの変更 なのか

それを区別して考えよう。

>>374,375
アプリケーションのレジストリ戻す時点と最新のレジストリの時点での、システムの設定状態は違っているわけだろう。
アプリケーションのインストール状態も違うし関連付けなどの設定も違う。
当該のアプリケーションのレジストリイ設定を戻したら、例えば拡張子で実行するアプリケーションの状態も違ってくる。
クリックしたら実行のアプリケーションと右クリックで選択して実行するアプリケーションのそれなど、システム状況はチグハグを呈してくることもあるな。

>>376
だからね。設定ファイルを消すだけでいいっていうのは、
アプリの設定だけの話なの。

関連付けなどOSなどの設定ファイルを変更したら
設定ファイルを削除するだけじゃだめなのは当たり前の話なの。

>>374
シェルをOSに含めるのか？
よくわからないな、ここの住人の考え方は

>377
だろうw

378 名前：名無し~3.EXE[sage] 投稿日：2008/10/02(木) 00:43:54 ID:eQKEa0c8
>>374
シェルをOSに含めるのか？
よくわからないな、ここの住人の考え方は

各アプリケーションの設定状況のバックアップを、a, b, ・・・, c 個取っていれば、
それに、相当するものを、レジストリイで復元する可能性を担保するためには、
a * b * ・・・　* c 個のレジストリのバックアップが必要だ。
普通、　アプリケーション毎に、レジストリを抜き出して保存しておき復帰させるなどは特別の場合だけだ。
したがって、アプリケーション毎に設定ファイルを使用し、それをバックアップするほうが、復元への可能性を担保するには有効だ。

置き場諸問題はさておき(exeとデータを同じ場所というのはどのOSでも一般にあまり褒められた作法ではない)
レジストリはさすがに古い機構だよ。

おそらくは当時容量の少なかったHDDでクラスタギャップを抑える為に
設定を同一ファイルに詰め込みたかったというのが狙いだろう。
新規に作るアプリでレジストリを使う意味はあまりない。
バックアップする意味の乏しい環境に強く依存するウィンドウサイズ、位置なんかはレジストリに、
それ以外の設定はファイルにという使い分けも考えたけどあまり意味がないから今は全部.INI、その他でやってるよ。

話はずれるが .INI も大概古いが個人的には好きなフォーマットだな。
専用APIがあってフォーマットが固定されていて
読みやすく書き換えやすくAPIも読み出し時にデフォルト値の設定を強要するのがいい。
W系がないのでMSは潰したがってるみたいだけど
だったらAPIそのままにXMLに書き出すライブラリを用意してくれてたらよかったのに。

ここで俺がレジストリバックアップのテクニック

たとえばアプリケーション毎の設定をバックアップしたい場合

HKEY_LOCAL_MACHINE\SOFTWARE\メーカー名\アプリ名

HKEY_CURRENT_USER\SOFTWARE\メーカー名\アプリ名

これ以下をバックアップすればいい。

アプリごとの設定ファイルは、アプリ名フォルダ以下に格納されている。

レジストリに対応したバックアップソフトが無ければ、

レジストリエディタで、アプリ名 フォルダ以下のキーを
一つのファイルにまとめられるぞ！

CUIが好きな人ならreg export 〜\アプリ名 で
一つのファイルにまとめられるぞ！

>>382
APIは、探せばあるよ、たぶんな
腐れマイクロソフトは、日本人からどれだけぼったくれば気が済むんだろう
技術文書のローカライズ位、真面目にやりやがれ

API無いよ。
だって必要ないもの。

INI自体は悪くないけど、WindowsのAPIは、
毎度ファイルを開いて閉じての繰り返しで効率悪そうなのが精神的に好きじゃない。
だからINIのAPI使わないで直接読み書きしたくなる。

マウスカーソル動かすだけでバリバリメッセージが発生しまくるWindowsにおいては
INIなんて高々最大64kbなんだから一度キャッシュに乗せたら後はたいした負荷じゃない。

マウスカーソル動かしてもメッセージ発生しないOSなんてないじゃないｗ


まあさ、他のOSがウインドウに送られているメッセージを見る方法が
無いか、あまり知られていないのでそういうイメージがあるんだろうけどさｗ

レジストリがないOSは、レジストリに書いてある情報はどこに保存してあるの？

>>390
たとえば、Linuxでネットワークの設定は、
/etc/sysconfig/network
/etc/sysconfig/network-scripts/ifcfg-eth?
/etc/sysconfig/networking/devices/ifcfg-eth?
/etc/sysconfig/networking/profiles/???/?
あたりに書いてあるよ。

あとウインドウシステムのデフォルト設定は、/usr/share/以下にあるこれらじゃないかな？ さらにサブフォルダがたくさんある。
gnome/ gnome-dictionary/ gnome-mount/ gnome-screenshot/ gnome-volume-manager/
gnome-2.0/ gnome-doc-utils/ gnome-netstatus/ gnome-spell-1.0.7/ gnome-vpn-properties/
gnome-about/ gnome-games/ gnome-panelrc gnome-system-log/
gnome-applets/ gnome-mag/ gnome-pilot/ gnome-terminal/
gnome-background-properties/ gnome-media/ gnome-power-manager/ gnome-user-share/
gnome-default-applications/ gnome-menus/ gnome-screensaver/ gnome-utils/

linuxで設定ファイルいじってて一番いやなのは
設定ファイルの書式が統一されていないこと。

空白は無視されるのかされないのか？
空白はスペースかTabどちらでもいいのか駄目なのか？
コメントアウトは#なのか;なのか？
複数項目を設定できるのかできないのか、できるときは区切り文字は何か？
記述の前後に、依存関係があるのか、ないのか？
…
…
…

もうね、いやんなるんよ。

>>389
一体どこから(他のOSでは発生しないが)という謎の一文を受信したんだよｗ

> マウスカーソル動かすだけでバリバリメッセージが発生しまくるWindowsにおいては

の文からだろ。

確かに他のＯＳについての言及はないが大抵の人は「他のＯＳだって似たようなもんな
のにわざわざ Windows に限定して書く >>388 ってバカじゃねーの？」って思ってる。

まあ、それにわざわざ反応する >>389 もどうかと思ってるが。

今日の東京は涼しいね。

>>392

あるあるｗ
昔「念のためEOFの前に改行入れておいて」なんて言われた事があって、
「そんなおまじないをアプリ毎に覚えないとLinuxは使えないのか」と
げんなりした記憶がある。

http://t-chonan.blogspot.com/2007/01/nfs.html
> ただし気をつけなくてはならないのは、/etc/fstabは必ず最後に改行が入っていないといけないという点。


まあ事実だしなｗ

結局
レジストリがなくても糞ってことですか?

>>398
結局（笑） いるいる。君みたいなやつｗ

初めてのWindows98でレジストリエディタの検索の余りの亀さに驚いた。
これじゃ、実用にならないから、外部ツールを探したが、*.regファイルの関連付け実行は存在したが、読み出しがない。
レジストリィエディタの操作なんてやっておれない。　呆れたね。
regが付属していれば、それなりにレジストリィも活用出来ただろうけど。
インターネットに使えない時代だったので、情報薄くて困りものだったレジスリイ。それいらい悪印象が積もり続けた。

何年前の思い出を語っているの？

今も思っている、使っているからw
化石人に何か？

いや。ただ君の言うことの信用度が下がるなぁってだけ。
98レベルの知識でいろいろ言ってきそうだものｗ

>>403
ちゃんとWindows98と明記しているだろう。　データを使えるかどうかはそちらの器の問題w

>403
>>381　は俺の書き込みだが、なにか飛躍したことを書いていると思うか。

> 各アプリケーションの設定状況のバックアップを、a, b, ・・・, c 個取っていれば、
> それに、相当するものを、レジストリイで復元する可能性を担保するためには、
> a * b * ・・・　* c 個のレジストリのバックアップが必要だ。
> 普通、　アプリケーション毎に、レジストリを抜き出して保存しておき復帰させるなどは特別の場合だけだ。
> したがって、アプリケーション毎に設定ファイルを使用し、それをバックアップするほうが、復元への可能性を担保するには有効だ。

アプリケーションごとに抜き出すんじゃなくて
レジストリのアプリケーション設定を
全部まとめて抜き出しておけば言いだけじゃん。

アプリケーション設定は
HKEY_CURRENT_USER\SOFTWARE以下に全部まとまっているんだしさ。

>>406
なにを寝ぼけたことをw

まとめて抜き出してえられるのは、一つアプリケーションについては一つの設定バリエーションだ。
各アプリケーションの設定時期はまちまちであるのだから、そのすぺての可能性をバックアップするには、
最大すべてのアプリケーションを通じての設定変更回数になる。

>>381で問題にしているのは、各アプリケーション毎のバックアップの数だ。
それだけのバックアップを確保する為のレジストリの保存数を考えてみるという視点だ。
それを、各アプリ毎に抜き出そうが、アプリ全体を束で抜き出そうが総数は同じだ。
ならば、保存サイズにからみれば、各アプリ毎に抜き出すのが小さくて済む。
しかも、ここでの論点は、それくらいならレジストリを使うより外部の設定ファイルにするよいとの考え方を導くもので、レジストリイ抜き出しを作業化するものではない。

日本語でおK?

レジストリをバックアップする手間が面倒って話なんだから、
必要なところ、全部まとめて（テキストにエクスポートして）バックアップすればいいんですよ。

バックアップしたレジストリはテキスト形式だから
必要なところだけ抽出して元に戻せばいいだけ。

当のMS自体がアプリの設定はXMLファイル中心に持って行く方向性だから
レジストリの長所を今更語ってもなんだかなーという感じはするね

「レジストリは一般に誤解されているほどには悪くない」という趣旨なら分からなくはないが

>>382
.INIはサイドバー関連で生き残ってるらしいね

レジストリのバックアップが殊更めんどくさい様に言っているが...
アプリケーション毎に設定がある場合だって、バックアップがめんどくさい事には変わりは無いと思うが

>>408
可能性の計算ができんとは???

>>411
個々のアプリに依存関係がなければ個別にバックアップを取ればそれで終わり。
あえてかけ合わせる必要がどこにある。

>>412
依存関係には全く関係ない。
アプリケーションのインストールとカスタマイズは時間を追って実行され、その結果はレジストリイに反映される。
レジストリのアプリケーションに関連するキーと価は何回変更されるか。
すべてのアプリケーションのインストールと設定変更の延べ回数だろう。　これが必要なバックアップ数の上限となる。
特定のアプリケーションのある設定に戻りたいとする。
それに供することができるレジストリィのバックアップは，そのアプリケーションの該当する設定した時期のレジストリイから次の設定をする前のレジストリィのバックアップが対象となる。
復元にはその中から一つを選べばいい。　冗長なバックアップは、別のアプリケーションの設定を保存するために要したものだ。
一つのレジストリイにアプリケーションの設定の同じバージョンナンバーが並列して反映されるようであれば、バックアップファイルの数は著しく減少して効率的だ。
だが、実際の設定作業では、満遍なく一順して全アプリケーションを設定するようなことはまずない。
したがって、全体的なレジストリでバックアップを行う方式だと、当該アプリケーションの視点から見れば冗長なバックアップが必要になる。

個別に設定のバックアップを取った場合の上限も、各アプリレーションの設定回数の積になることは当然ではないか。
すべての設定の復元を担保するためには・・・。

>>413
すまん、間違えた。
個々のバックアップ数を取った場合は和で、その組み合わせの結果の可能性が積になる。
最初　a * b * …　* c の可能性の総数で、それを　担保するために、　a + b + … + c　の総数のファイルが必要だったところを、
一つの式で間に合わせていた。　

>>414
追記、レジストリ全体のバックアップのケースは、抜き書きして復元するのでなく、レジストリバックアップで一括して修復するケースとした場合に適用。
素人がやるのはこちら。これですべての可能な復元を担保することは困難との見解を言いたかったが、途中で錯綜・混乱して弁別しなかった。

だから、なんで「レジストリ全体」がバックアップの単位になる必要があるのよ。

>>416
素人がバックアップの中から、すべてのアプリケーション設定の適合したものを探し出すという想定で書いたまで。
その場合バックアップは数多く必要だ。
有象無象のユーザーの設定復元はレジストリイ全体からだろう。　デフォルトの設定では通常はぴったり望みの設定状況に復帰というより妥協したものになると思われる。
そうでなくて、アプリケーションの全体について設定を抜き出してバックアップするとか、対象とするアプリケーションの設定の抜き出しにするとかは、それを出来る者ががやればいいこと。
全体を対象にする必要はない。
前者の場合でも、個々のアプリケーション毎の設定ファイルを用いるケースだと、対応の仕方は分かり易いのではないかと。
設定ファイルに見分けがつき易い名前を付けて保存しとけばいい。
外部設定ファイルだと，読み込み優先順序とか上書き読み込みなどの機能があれば、柔軟な設定切替でアプリケーションを起動できる。
それに似た事もレジストリイを使ってもできるだろうが、抜粋レジストリィを用意したり、regなど使うことになる。
可能性はいずれの方式にもある。
レジストリイ方式は、設定ファイルの読み込みのオーバーヘッドが問題になった頃にデータベースの利点でそれをカバーすることにあったのではないか。
今となっては固執すべき方式ではない。　レジストリイを使わないアプリケーションだとほっとするw

ま、レジストリが不利になるような素人像を想定してそれを出発点とすれば
そりゃあレジストリが不利な結論にたどり着くさ。
そのオナニーに意味があるかどうかは別にしても。

設定ファイルの読み込みのオーバーヘッドが問題になったことなんてあったか？
レジストリってもともとOLE用に作られたんじゃなかったっけ？

>>419
MSはUnix採用を見合わせた過去あるみたい。　非力なCPU・ハードなどに加え設定ファイルについても少しは考えることあったんだろう。その一点のためということはないだろうが。
俺の買った当時最新鋭だった古いマシンだと、emacs系のテキストエディタの初期化には随分時間がかかるw

> emacs系のテキストエディタの初期化

あれは、LISP の処理系が走るから物によって時間がかかるのは当たり前。
.emacs をバイトコンパイルしとけばましになるかも。

そもそも古いマシンだと emcas 自体の起動に時間がかかるから、emacs -q
で起動した時間と比較しないと意味ないし。

>>421
書き加える余地があるもの以外、ほとんどバイトコンバイル済みだっけどね。
ていうか、なんにしろ使えるまでに時間がかかることの嫌さを言いたかったw

旧型パソコンを窓から（ｒｙ

Linuxでアプリごとにバックアップを取りたいんですが、
/etcの中にフォルダがたくさんあるんです！

>>422
> なんにしろ使えるまでに時間がかかることの嫌さを言いたかったw

だからそれは、

・LISP の処理系が走るから
・emcas 自体の起動に時間がかかるから

だろ。

「設定ファイルの読み込みのオーバーヘッド」の例としてはちょっと不適切。

>>425
オーバーヘッドの例として書いた訳ではないと弁解したでw
なんにしろというのは、emacsのことではないって、
それを書く前に、oSの起動にしろアプリケーションの起動にしろ、オーバーヘットで待たされるのは嫌なものさ、なんて間合いを入れておけば良かったけど。

>>426
とりあえずだな。

お前のパソコンのスペックをさらせ

Emacs+Mew+X-faceとか Gnusとか
懐かしいなあ・・

>427
化石マシンとだけ言っておこうw

>>429
そんな10年も前ぐらいのパソコンつかっていて
ごちゃごちゃいうのなら、新しいパソコン買ったほうがいいよ。
ニートならごめんだけどｗ

今なら10万円程度のパソコンで、PCエミュレータ動かして
その上にWindows98動かしても、今使っているパソコンよりかは
早く動くって。

>>430
バソコン買うだけなら、いつでも出来るけどね。
お前さんの想像力のなせる構成では、ちと面白くない。
その前に、PCなしでやることやれること沢山ある。 そのための訓練もしてた。
PCエミレータに構成し直すなんて時間の無駄。　Windowsだからねw

>>431
君がパソコンをいつでも買えるか買えないかなんて興味がない。
PCなしでやれるとか、だからなに？ 何のためにそんなことを言い出したのか理解できない。

俺は、買い換えたほうがいいよってアドバイスしているだけだ。
10年前のパソコンじゃ、もう寿命だろうし、パソコンが壊れたとき困るぞ。
Windows98も使うのやめたほうがいい。

>>432
ものには順序がある。PCシステムはすべての一部分。　最終的には無しでもやれることになっている。
そして、今、中心的なことはなしでやっている。
アンラーンということもある。
うっかり忘れてしまう程の状況ではないわw
パソコン壊れた時は壊れたですます。
現に、執拗な外部から攻撃にさらされている。
システムを頑強にするにはリソースの余裕がないし、得られることに較べて手間が掛かりすぎる。
お前の立場からアドバイスなんて笑わせる。

関係無い話をしてくるな！

どうやら、俺が上から目線で
アドバイスしたことに
むかついているようだな？

>>435
どこまで幸せなやっちゃw

野比「くそったれ!捨て犬の気分さ!」
ドラ「どうした、ノビ?ハニーにおあずけでも食らったかい?」
野比「ああ、是非そうありたいね。でも残念ながらジャイ公の奴さ」
ドラ「ちょっと待った、ちょっと待った(笑)いいかい、ノビ。僕は手を貸さない。いいね?」
野比「なぜだい!?親友だろう?」
ドラ「平和なティータイムをブチ壊すのが親友!?冗談だろ!?」
野比「ドラえもん・・・。そうだね・・・君に買ってきたドラ焼きもアイツに奪われてしまったしね・・・」
ドラ「もう一度言ってみろ」
野比「ドラ焼・・・」
ドラ「ファック!!」
野比「YEAH!そうこなくちゃ!」
ドラ「あのクソ野郎!!このM19でケツマンコ犯しまくってやるぜ!!」
野比「おいおい未だにそんな古臭い銃を使ってるのか」
ドラ「じゃあノビお前は何を使ってるんだい」
野比「M500ハンターモデルだ」
ドラ「おいマジかよ!!どこでそんなもん手に入れたんだ」
野比「ガンマニアのスネ公をちょっとおどしてね」
ドラ「そういう事か・・。でもその銃はお前の細腕じゃ・・」
野比「ではジャイ公の前に君で試してみるとするか・・・ドラえもん。」
ドラ「ああいいぜ!!!ノビとやり合うのも久しぶりだしな。楽しみだよ」

旧PCからレジストリ構成をサルベージする方法

・旧PCのHDDからNTUSER.DATを引っこ抜く
・ダミーのユーザーを作成し、NTUSER.DATを強制上書きする
・ダミーのユーザーでログインし(たぶんエラーが発生しまくるが気にしない)、
RegEditを起動し好きな部分を閲覧、エクスポートする

結局，レジストリィを抜き書きしたり、復帰したりしなくては細かな個別の設定バリエーションのメンテナンスには対応できない。
レジストリエディタかコマンドラインツールを使うことになる。そこがハードルになるユーザーも出て来る。
全体のレジストリイだけでは、小回りは効きにくいようだ。
設定ファイルならテキストエディタで対応するのも、GUIのメンテナンス用フロントエンドユーティリィティを被せて設定のバリエーションに部分的一括訂正なんていうのもやりようによっては色々できる。
つまり、設定ファイルはテキストエディタのみでの保守のしかたに限定されるわけではない。

>>439
わけわからん
日本語話せ

> 設定ファイルならテキストエディタで対応するのも、GUIのメンテナンス用フロントエンドユーティリィティを被せて設定のバリエーションに部分的一括訂正なんていうのもやりようによっては色々できる。
レジストリならレジストリエディタで対応するのも、GUIのメンテナンス用フロントエンドユーティリィティを被せて設定のバリエーションに部分的一括訂正なんていうのもやりようによっては色々できる。

どう見ても一緒だろ?

> 結局，レジストリィを抜き書きしたり、復帰したりしなくては細かな個別の設定バリエーションのメンテナンスには対応できない。
設定ファイルの場合にしても、設定ファイルのある位置をしらないと、設定ファイルのバックアップは取れないだろ?

>>440
>どう見ても一緒だろ?
設定のバリエーションを仮に五個作ったとしょう。
テキストエディタで五個のファイルの訂正該当する版を手動で訂正するしたり、マクロで処理したり、スクリプトで処理するなど様々なオプションがありうる。
GUIのフロントエンドで処理する場合、選択と同時に、その選択結果を同時にグラフィック表示という手もある。　そして訂正の対象群もグラフィカルに選択可能になる。
レジストリイ方式も抜き書き・復帰の動作を行うのなら、抜き書きに関して同様なことは行いうる。
でも，余計な手間はかかるな。
まず、二重の手間のユーティリィティは余り作られそうもない。
でも、設定ファイルのメンテをGUIでサポートすることはありうる。　その方向も進展するだろう。

>設定ファイルのある位置をしらないと
という仮定など、レジストリイの抜き書き・復帰などの操作ができるレベルにあるかどうかなどと比べられる。
そんなことはありうることだが、レジストリイ全体しか扱えない、または、レジストリィの手動回復もできない層を想定するのと同じで、それならば、なおのことレジストリイの細かな利用が出来ない向きへのレジストリイの弱点を浮かび上がらせることになる。

スクリプト処理ならregコマンドで対象データを簡単に操作できるレジストリのほうが便利。
iniファイルをスクリプト操作するよりはるかに楽。
一般にレジストリが嫌われるのはregeditによる対話的編集だよ。regeditはあまり使いやすくないからな。

>>442
>iniファイル
分かり易いテキストファイルが吉。
スクリプト操作は、ある層には不向きなんだがw
>regeditはあまり使いやすくないからな。
Windows98で初めて使って余りの亀さに驚いた。
コマンドラインツールでレジストリイの一部分を対象とした操作をベンダーはやるはずだと思って探したが、regは添付されていなかった。
こりゃ、一般ユーザなめとるなと考えたぞ。

>>442
> スクリプト処理ならregコマンドで対象データを簡単に操作できるレジストリのほうが便利。

それはあるね。

iniファイルの特定のキーを置き換えるコマンドなんてあるんだろうか？
テキストファイルの中身を正規表現とかで置換するコマンド（なんだっけ？）で
できないことはないだろうけど、間違って違うところにマッチするかもしれんし。

レジストリならキーをちゃんと指定できるし、やろうと思えばいったん
テキストファイルに変換することで、iniでやっているやり方も使えるという柔軟性がある。

まぁ、今日もレジストリの問題で泣いている人がいるわけで・・・

レジストリは問題ですよ。

IntelliPointの設定もレジストリだしな。
全部エキスポートして新環境でインポートしたら間違いなくおかしくなるし
Win7以降はもうAPI挿げ替えて実ファイルにマッピングしてしまえよ。

コメント付けられたり履歴管理(その部分だけ以前の状態に戻したい)が
できればレジストリでも別にいいんだけど。

レジストリでもコメントとつけられるぞ。

HKEY_???\abc\def\hij の値が1だった場合
HKEY_???\abc\def\hij_comment 1の場合有効

なんてキーをつければいいだけ。

ソフトに依っては、hij_comment と言うキーを使ってる可能性が無いわけじゃないから
そのキーがコメントかどうかを判断できない。

エクスポートした時に、コメントも一緒にエクスポートしてくれるわけじゃない。

結論: 却下

は？ エクスポートするときはフォルダ単位だろ。
コメントも一緒にエクスポートされる。

はぁ？ レジストリでフォルダ？

また、例の頭のおかしい人が来ちゃったのかな。

親のキーのことだろ。

MS自体そろそろ止めたがってるみたいだが＞レジストリ

互換性維持以外の目的はもう無さげ

ロックが大きすぎてスケーラビリティ悪いからねぇ。

新しい言葉を覚えてきたのかｗ

さっさとフォルダ単位でエクスポートしてこいよカス

フォルダっていうか、あるソフトの
キーをすべてをエクスポートならよくやるけど。

レジストリはフォルダのように階層構造になっているから
あるソフトのキーを選択した状態でエクスポートすると
それ以下のキーをすべてエクスポートできるよ。

マジ便利。

偏った思考の人同士が話し合っていても結論は出ないから、
そろそろレジストリのメリットとデメリット、
プログラミングするならこう使うべきだといった
方向性をまとめられる能力をもった人が現れないものか。

regを当初、添付していなかったことは、このスレのレジストリ信奉者の根拠が後付けであることだから、話はこんがらがるw

レジストリのメリットなんてものを
生み出そうとしているところに
無理がある。
失敗作は失敗作である事を認める
勇気を持とう。

そしてより良いシステムをみんなで
考えよう。

アンインストールする時に削除するプログラムを作らない馬鹿が増えた状況が
既にレジストリの糞さが証明されている

めんどくせえなあ

レジストリ変更しようとしてもなぜか変更できない・・・何故？
値を変更できません、みたいなメッセージが出てきます。
どなたか教えてください

アクセス許可ではねられてる
regeditで該当Key名を右クリックでアクセス許可でフルコントロールにすれば一応変更できると思う

アンインストールするときにレジストリを消すってのは
必ずしも正しいわけじゃないからね。

＼＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿／
　　　　　　　　 ∨
　　　　　　　　 　 ＿＿＿　　　　　　　　　　
　　　　　　　／　＿＿＿＿ヽ　　　　　　 　 　　
　　　　　　　|　 | /, −､, -､ｌ　　　　　　　　 　　
　　　　　　　| _|　-|○　|　○||　　　　　　
　　 , ―-､　（6　 ＿ｰ っ-´､}　　　　　　
　　 |　-⊂）　＼ ヽ_ ￣￣ﾉﾉ　　　　　　 　　
　 　 |￣￣|／ （_ ∪￣ / ､　＼　　　　　　　
　 　 ヽ　　｀　,.|　 　　￣　　|　　|　　　　
　 　 　 ｀− ´ |　　　　　　　| ＿|

レジストリがあるからむしろ高速化されてるんであって、なかったらいろんな設定読み込むのにHDのヘッドが大変だろう。

467 ：名無し~3.EXE：2008/10/29(水) 22:14:25 ID:2Qnl4Hmz
レジストリがあるからむしろ高速化されてるんであって、なかったらいろんな設定読み込むのにHDのヘッドが大変だろう。

468 名前：名無し~3.EXE[] 投稿日：2008/10/30(木) 05:29:15 ID:ox0fOuZ7
467 ：名無し~3.EXE：2008/10/29(水) 22:14:25 ID:2Qnl4Hmz
レジストリがあるからむしろ高速化されてるんであって、なかったらいろんな設定読み込むのにHDのヘッドが大変だろう。

ドライバの情報なんてテキスト形式でいちいち読み込んで解釈してたらかったるいから
独自バイナリ形式になるのかね？

レジストリはインターゼット上にあればよかったんじゃない？マイクロソフトのサーバとか。

インターゼットｗｗｗ

ゲシュタルト崩壊とマイクロスリップの同時浮上＋α
そんなことよりWindowsの糞仕様は皆の損失。
Vistaを見続けてはいけませんw

>>1
>トラブルの9割はレジストリだろ

実際、何割なんだろうね。

レジストリってただの設定ファイルなんで、
トラブルの9割が設定ミスとか言われてもなぁ。

トラブルの9割がプログラムだろ。
トラブルの9割がファイルだろ。
とか言われているのと同じで
意味不明としか思いませんｗ

レジストリが全部抱えてるからきれいにつかえてるが、これが無かったら無法地帯になるんじゃね
どこでも好き勝手にファイル作って

好き勝手なところにファイル作る奴はレジストリ使っても好き勝手なところに
エントリ作るから、状況は大して変わらんよ。

未だにCドライブのルートに
JUSTなんてフォルダを作るメーカーのことですね

あ〜あ〜はってしぃないぃぅい〜ゆめうぉおおいぃつづけぇ〜えええw

C:\Microsoft\Event Viewer\アプリケーションとサービス ログ\Microsoft\Windows
C:\PerfLogs\Admin

誰だよ勝手にこんなフォルダ作ったやつは・・・

レジストリとLinuxの/etcにある設定ファイルの違いは、キャッシュメモリの使い方じゃねーの？
CPUに近い分だけレジストリの方が読み書きが早いんじゃないっけ。
もしそうなら、レジストリ特有の問題ではないとは言い切れないよ・・・

レジストリはダブルクリックの度になめるよね
肥大化が一定量に達すると重くなるよね
右クリックでもなめるよね
アクション全部レジストリなめる事で動作してるよね
MSなアプリはプリフェッチ最優先で高速に見えるよね

>>482
I/O処理を学ぶところから始めましょう

>>482
たしかにほんの一つの動作で凄まじくレジストリの項目を見に行くからな。
だからゴミが残ることは大きな問題。

>>483
どういうこと？

常識的な話だが、必要なところしか見ないので、
いくらゴミがあっても
ディスクをちょっと利用しているだけでしかない。

>>485
存在しない実体ファイルのパスを見に行っちゃうこともあるけど。

>>486
それはアンインストーラがおかしいか、
無理やり実行ファイル消したのが原因。

もしレジストリの代わりに、設定ファイルに
ファイルパスを記述していても同じことだよ。

いずれにしてもレジストリがなければ
もっとまともだったに違いないと思っている人は
多いと思う。

>>488
そうかもしれんが、それが正しいかどうかは
まったく別の話。

/etcの混沌っぷりもアレだが
レジストリはポータビリティが低いのとMSが後方互換性重視してるせいでカオスってるからな

で、どうなってたら理想的なん？

>491
> で、どうなってたら理想的なん？
Windowsとともに消えてくれ。

ねーよｗ

レジストリがなくても、DLLとか、拡張子に依存とか、
レガシーな造りが盛りだくさん。

確かにレジストリがガンだよなぁ

>>478
あれってどういうつもりであんなマナー悪い動作してるの？
マナーが悪いことぐらい開発者も分かってるだろうに

DLLがレガシーか...

あああ

５００

５０１

WindowsしちになってもレジストリとかDLLとか残るのだろうか。
Windowsだから、仕方ないけど・・・

でもWindowsしちは評判は良さそうだよね。

もし無くなったらもはやWindowsではないぞそれ。

.NetアプリがMSが望む速度でバリバリ普及してたら今頃レジストリは消えてたかも知らん

.net自体がレジストリやwindowsフォルダに膨大なゴミをばら撒くけどな

>>505
COMに比べたらほんのわずかだよ。

XP以降ならRegistration-Free COMがある

>>506
.netランタイムのインストーラがレジストリやwindowsフォルダにゴミをばら撒くって事だろ
しかもMFCやVCLと違ってソフトが必ずランタイムDLLに依存してしまう

>>508
だからそれがわずか。

どこがわずかだよｗ

アンインスコしても数十〜数百MBのゴミが残るだろ
勝手に変なアカウント作るしレジストリにも膨大にゴミを残してくれるからOS再インスコしないと二度と元に戻らない

このスレ的にレジストリは少しという意味だ。
（XCOPYでいいはずの.NETなのにレジストリ使うのはまったくもってひどいが）
フォルダはたくさんだ。
まったく話が通じないな。

.net2.0sp1をインスコしてHKLM以下をregdiffで比較してみたよ

インスコ前後で相違数8461
アンインスコ後と比べても相違数4528

これのどこが「少し」なんだ？

レジストリ潔癖症はキモイからwindows使わなくていいよ。

.netは一度入れたらアンインストールしないものだと思っていたが。SxSだし。
Windows Updateと同じだと思えばいいよ。

結局、スレタイは正しいと言う事ですね。

ここは素人のあつまりか？
DLLと同じものは、他のOSにもあるだろ。
拡張子が違うだけで。

素人がああだこうだいうが、
プログラマからすれば的外れにしか見えんよ。

マの人はマ板にでも籠ってて下さいよ

DLLというよりCOMの問題でしょ。
本来は使用時にインターフェイスを問い合わせるのが筋だけど
そんなこといちいちやってたら遅すぎるのであらかじめレジストリに登録しておくってじっちゃがいってた。

DLLとCOMの違いを説明してください

ググレカス

>>520
ここで説明していただかないと意味が無いのです

じゃあぐぐってから発表しろ。

>>519
DLLはコードのパッケージングの物理的な単位でCOMは再利用しやすいコードを書くためのテクニック。
違いを説明してくださいと言われても、両者は根本的に異なる概念。
ググレカスで片づけられても仕方がない。

私は、レジストリを使った方がいいとか使わなければいいとか思ってないけどね。
レジストリを使った方が効率がいいものはレジストリを使えばいいし、
設定ファイルを使った方が効率がいいものは設定ファイルを使えばいいそれだけだよ。

関係ない話だけど、個人的には
HKEY_CURRENT_USER\AppEvents\Schemes はレジストリ、
HKEY_CURRENT_USER\AppEvents\EventLabels は設定ファイルでいいんじゃないかと思っている

　　　　　 　 　 　 　 　 　 　 　 死　　　昨　　　　過　　　お
　　 　 　 　 　 　 　 　 明　　　ぬ　　　日.　　 　 ご　　　前
　　 　 　 　 　 　 　 　 日　　　ほ　　　死.　　　　し.　 　 が
　　　　　　　　　　　 　 　 　 　 ど　　　ん.　　　　た　　　無
　　　　　 　 　 　 　 　 な　　　生.　 　 だ.　　 　 　 　 　 駄
　　　　　 　 　 　 　 　 ん　　　き.　 　 誰.　　 　 今　 　 に
　　　　　　　　 　 　 　 だ　 　 た.　 　 か.　　 　 日
　　　　　 　 　 　 　 　 　 　 　 か　　　が
　　　　　　　　　　　 　 　 　 　 っ　　　　 　 　 　 は
　　　　　 　 　 　 　 　 　 　 　 た

実際普通なユーザーが体験するレジストリ問題って関連付けがほとんどじゃね？と思った。
それ以外で普通に使ってて、レジストリうぜー！！！ってのは(何でもかんでもレジストリに設定を保存するアプリ以外)なさげ。

自分のレジストリ関連でやった作業は。
・関連付けの異常を初期化。
・プログラムから開く、の項目の初期化。
・.NETのFileDialogクラスが、予想と挙動が異なる原因を調べた。(原因がレジストリだった。)

>>525
レジストリにいっぱい時間取られました＞＜･･･とか書きたくなります。多分上記合計で20時間近く吹っ飛んでるわけで。

レジストリが汚れるってやつはレジストリの全項目を把握してるんだろうかと疑問に思う。

たかがレジストリごときで500レス超えるとはな
マジで繊細すぎる…

ぶっちゃけレジストリ遅くね？

レジストリを汚さないアプリは良いアプリ

レジストリの駄目さが良く分かる良スレ。

どうでも良いけどVC++でWin32ｱﾌﾟﾘのﾌﾟﾛｼﾞｪｸﾄを作成したとき、
レジストリエントリを作成する様なコードを問答無用で吐き出さないで欲しい。

はいはい

そもそもアプリのシステム設定程度は１ヶのテキスト形式のファイルがあれば事足りるハズで、
それをわざわざレジストリに書き込んでわけがわからんようにするというのは完全に本末転倒。

レジストリなんぞはユーザーに見えなくさせることを目的にしているとしか思えませんな。

ＯＳの設定についても同様であり、
単に１ヶか２ヶのテキスト形式ファイルがあれば簡単に事足りるしバックアップも超簡単。

何事も、
シンプルがいちばん宜しいわけですよ。

テキストファイルよりレジストリのほうがずっとわかりやすい。
超冗長なxmlよりもわかりやすいから困る。

50Mを35Mに整理したら軽くなったけどね

レジストリ使ったソフト
勝手にレジストリ使っておきながらアンインストールしたら残さないできれいに消せよ…

>>537
レジストリは肥大化する。絶対的なレジストリは絶対的に肥大化する。

レジストリが壊れると起動できなくなるとか言ってるヤツいるけど
boot.iniが壊れたらやっぱり起動できなくなるんじゃないのか?
http://www.google.co.jp/search?hl=ja&q=boot.ini+%E8%B5%B7%E5%8B%95%E3%81%97%E3%81%AA%E3%81%84

だから何なの？

>>540
.iniが壊れたら起動しなくなるんだから
レジストリより.iniが優れてることにはならない

>>221
XPでもHKLM\SECURITYの中は管理者権限があっても見れないぞ

>>541
iniなら1アプリ1ファイルに設定を入れるだろ？普通は。
だから初期化とかアプリのディレクトリの移動とかやりやすいんだよ。
ファイルコピーだけで済むから。
でもレジストリだと項目が分散している可能性もあるし、その上単なるファイルコピーでは通じない。
それにOSディスクとデータディスクを分けている場合は、
OSを入れ替えするときにレジストリの必要な部分だけバックアップしなきゃいけないけど、
どこが必要な部分なのかはっきり分からないor調べるのが面倒くさい。

潔癖症の俺からしたら、綺麗さっぱり消せるならそれでいい
Program filesのフォルダも消せないアンインストーラーはいったい何なんだ
CCleanerアンインストール時に、「ユーザー設定まで自分で消してったぞ、すげー」
とか喜んでる状況は異常な気が・・・

>>542
.iniがアプリと同じフォルダにあるとは限らない
%APPDATA%や%ProgramData%を使ってるかもしれない
もしかしたらその両方を使ってる可能性もある
それをいちいち調べるのは面倒じゃないのか?

レジストリいらね・・・。

Windowsいらね。

レジストリいらねとか言ってるヤツに限って
desktop.iniに文句を言う不思議

>>542
実行ファイルと同じディレクトリにini出力してそれで全て管理するソフトが最も好まれるね

実行ファイルと同じフォルダに設定ファイルをおくプログラムは
プログラム設計や情報管理面では最低な構築とされる。

>「最低な構築とされる。」
M$が決めたのか？ｗ

>>550
学習指導要領に載ってるだろ。

歓ばれはするが嫌がられることはない
お行儀のいいソフトとしてその「最低な構築とされる」ソフトが持て囃されてるのが現実ですよ

>>550
パソコン（マイコン）と呼ばれるものが影も形もない
ウン十年前のメインフレーム全盛時からの常識。

設定ファイルは一カ所に集めた方が管理面で効率的って話じゃないの？
/etcみたいな。バックアップ取り易い。

>>548は俺も嫌だな。逆にめんどい。

補足

実行ファイルと設定ファイルを別のフォルダ系統に分けて保存するのは
「マルチユーザー」前提のOSでは当然備えているべき設計。

なので WindowsNT 系の 2k、XP、Vista、Win7 上で動作するアプリは対応していて当たり前。
逆にシングルユーザー前提の Windows9x 系上で動作するアプリでは別に対応してなくていい。

で、OS側でほぼ強制的に対応させたのが Vista の Roming フォルダ

マルチユーザーなら尚のこと実行ファイルと同フォルダーにini出力するタイプが有難ねぇ、
USBメモリから環境を汚さずサクッと実行できたり、兎に角分かりやすいのが助かるわ

どっちもできるようにしろよ腐れが

そうだな
選べるのが一番いい
個人的にはあぷりけーしょんでーたは当然として
プログラムと同一フォルダだとしても設定フォルダにユーザー名フォルダを強制で作るタイプでも鬱陶しいが

選べるのは良いが此方がレジストリに書き込むことを許可するまで何も書き込むなよ！
VIXは選べるが先にレジストリに書き込みやがるから意味ねーんだよ ( ﾟдﾟ)､ﾍﾟｯ

ini に保存する辞典でキチンとレジストリから設定を削除するのなら
別にデフォルトでレジストリに書き込んでも問題ないだろ。

>>560
iniが共用だとして、次の人が個人別設定したい場合はどうするつもり？
個人別の情報（レジストリ）を見るしかないんじゃないの？

レジストリ賛成だし、Roming にも賛成している人間だから言われても困る。

オレが実行ファイルと同じ場所に ini を作成、使用する設定を
プログラムに組みこむなら、ini 利用時に個人別設定なんて使わせない。

そもそもWINDOWSフォルダやProgram Filesフォルダにユーザー権限じゃ書きこめないんだから
設定が別フォルダに分かれるのは必然なんだけど。

Google Chromeみたいに%LOCALAPPDATA%にインストールするなら
.exeと.iniを同じフォルダに置いてもいいよ

>>564
その行為がシステム全体に及ぼす悪影響を考えたことはないのか？
せっかくシステムが守ってやろうっていってるのにそれを無視して、
誰でも簡単に改変できるところにプログラムを置くなんて・・・

>>565
お前は%LOCALAPPDATA%を何だと思ってるんだ
%LOCALAPPDATA%が誰でも簡単に改変できるところなら
%APPDATA%を使うのも駄目じゃんよ

>>566
何が言いたいのかがわからん。
データの改変はプログラムで対処可能だが、
プログラムの改変はプログラムでは対処できない。
だからシステムで守ってやる必要がある。

プログラムの改変を防ぎたいってことか
そういうことなら分か

http://pc12.2ch.net/test/read.cgi/software/1205585085/

君らのパソコンなんかプログラム改変する価値ないわ

Program Files配下のファイルはOSが守ってくれる。

ほとんどのユーザーは管理者権限を常用してるから何の意味もない

Vista以降ならUACのお陰で管理者権限執行に確認が出る。

UACウザイとか言って無効化しちゃう馬鹿がたくさんいる

.iniはテキストデータしか格納できない駄作
レジストリなら数値やバイナリデータも格納できる

あと値に型があるのもいい　論理型があれば完璧なんだが

リカバリ依存症です。ＯＳ再インストールすればレジストリはまっさらな状態
になるのでしょうか？アカウントの認証とかＰＩＮとかあるじゃないですか？
あれの認証とかはレジストリ情報に残ってしまうのでしょうか？複数アカウントで
アウトになるのはレジストリになにかファイルがつくられてるのではないか
心配です。２週間に１度くらいフォーマットして、ＯＳ再インスコしてます。
隠しファイルでレジストリ残ってたりするのでしょうか？レジストリを
保存したとして、再インストールしてレジストリクイックしたら、内容は更新されますが
増えたレジストリになるのでしょうか？レジストリが初期状態のまま増えないようにしてほしいです

…えと…触って良いのかなコレ…

>>577
しーっ！目を合わせちゃいけません！

>>575
別にバイナリでもテキストに落とせばiniに格納できるだろ

>>579
シー！
馬鹿はスルーで

>>579
×バイナリでもテキストに落とせばiniに格納できる
○テキストに落とさないと格納できない

>>581
どこまで馬鹿なんだ

INIは読み書きが非常に遅いので糞

「Unix系の方が細かく設定が出来る!!!」
...って意見の裏側には、「Windowsの使い方が全くわからん」という深刻な悲鳴が隠れています

レジストリを一つとっても、REGコマンドを使いこなせば、自由自在に設定の保存が出来るというのにね

別にメモ帳で開けない設定ファイルでも良いじゃんね
レジストリはやっぱり要らない子

読み書きが遅いって、
どんだけ高頻度でしかも高サイズの設定ファイル弄るんだ笑

1. 高速なバイナリ形式であること。
2. クエリの方式が定型化されたDBMSであること。
3. Unixの.profileなどのファイルのように、一般ユーザーから見えない形式であること
4. ネストの深さに制限のないツリー構造であること。
5. マルチスレッドの問い合わせが可能なデータドリブン方式であること。
6. ファイルが分割され、ボトルネックになりにくいこと。

などを考えれば、レジストリそれ自体は良くできた設定DB。
ただ、iniファイルなどを選ばずあえてレジストリに保持したい設定というものは
一般ユーザーに公開されにくく、アンダーグラウンド化しやすいところが
多くの人がレジストリに対してダーティなイメージを持ちやすいところだと思う。
特にPCの自称上級者はレジストリが汚いことに我慢できなかったりするが
まぁ、意味のないこだわりだよね。

レジストリの仕組みを分かってない無知な人ほどレジストリの肥大化を嫌う傾向にある。

>>587
＞レジストリの仕組みを分かってない無知な人
世の中の大多数だな。

>>584
Windowsはよくわからん
http://itpro.nikkeibp.co.jp/article/COLUMN/20080819/312956/?ST=develop&P=2

トラブルの原因自体はVBアプリで利用していたサードパーティ製ツールのメモリーリーク・バグで，
ヒープ領域を使い果たしていただけだった。特に難しい解析，というわけでは無かった。
普通にダンプファイルを取り，クラッシュの原因を分析し，
システムモニターでメモリー利用量を測定しただけなのだから。
しかし，この簡単な解析にもUNIXエンジニアは参加しない。理由を聞くといろいろというが，
要は「Windowsなんか，やってられるか！」というマインドが伝わってくる。
どうもUNIXエンジニアはWindowsがお嫌いなようで，たとえ業務でもそれには関わりたくないようだ。
（中略）
そこで，そんな人には「このアセンブリコードからもわかるように。。。」とか，
「CPUに残されたレジスタの情報から，当然わかることですが。。。」と超上から目線で対応するようにしている。
私がわかる程度の知識で理解できない「自称高スキルエンジニア」ならばまともに話すこともないからだ。
こんなセミプロには，そこまでして「Microsoftを使っていないから俺って一段上いってる感を出したいのか，
シェアが低いと必死やなー」と腹で「ふふん」と笑っていれば良い。

レジストリはコマンドでキーのACLを取得・変更できない駄作
ファイルが対象ならcaclsコマンドがあるけど

>>590
powershellでできるんじゃね。
レジストリは駄作だけど。

起動終了のたびに細かいエラーを出すレジストリって最低。
時々起動時の読み出しに失敗して、再起動時にF８で、
「前回正常起動時も構成」を使うこともしばしば。

レジストリってシステムを壊すためにあるんだろ？w

×「前回正常起動時も構成」
○「前回正常起動時の構成」

自分の環境疑ってから言え

ほ

糞OS

アプリがシステムディレクトリのDLLを入れ替えるなんてふざけたOS

>>597
悪いのはアプリのほうだな。ｗ

レジストリって何者？レジストリクリーニングって必要？そもそもその存在意義とは？
http://www.lifehacker.jp/2010/03/100318registrywtf.html

■レジストリクリーニングって本当に必要なのでしょうか？
単刀直入に言おう。「レジストリクリーニングプログラムを走らせるな」と。
インチキであるとまでは決して言わない。だけれども、不要なレジストリエントリを掃除し、
行き場を失ったDLLファイルのいくつかを削除したところで、何も変わりはしない。

■じゃ、レジストリのデフラグは？
レジストリのデフラグ状況が、目も当てられないほどひどい場合であれば、
それをデフラグすることによって、パソコンのパフォーマンスは多少向上します。
しかし、レジストリをデフラグしたからと言って、パソコンのスピードが急に速くなる、ということはありえません。

600☆ get
などと、遊んでみる。

>もしそのアプリがレジストリをやめてiniファイルを使用したとしても、起動時間は同じですよ。

これは嘘だな。
INIファイルを探すためにHDDのランダムアクセスするから格段に遅くなる

>>556

メールのデータとか事務書類とか誰でも読み書きできるとこに置くんですね？
プライバシーも糞もねえなw

>>576
持ち運びたいデータはActiveDirectoryのユーザに入れておく
どのパソコンでログオンしても自動的に追いかけてくる

>>602
頭大丈夫？
メールのデータをiniに出力するの？w

起動アプリと同じ場所にあれば、ランダムアクセスにはならんだろ
レジストリの検索の方が時間がかかるんじゃ

メモリに展開されてるデータベースから検索する方が時間かかるってどんだけ

メモリ食いまくりってことだろ

レジストリ肥満状態でも64MBあれば入るだろ

常時、何かしら百メガ単位でswapしてるし、そんだけ管理がいい加減ってことじゃ

メモリ足りなくなってからディスクに書き込んだら時間がかかるから
暇な時に先にディスクに書き出すのはごく普通の処理だ。

実メモリ２Gを食いつぶすようなアプリなんてほとんど無いのに？

スワップとか言ってる時点で何も分かってない
NT系にメモリスワップなんか無い

ページングなんたらは何するもんなんでしょうね？

>>607,611
2GB使うアプリ無いならレジストリをメモリに常駐させたってよくない？

メモリに常駐させても、HDDへの書き出しが必要だからかな

iniファイル削除などで設定初期化が簡単
トラブルがあったらとりあえずiniファイルを退避させて起動で初期状態に戻る
アンインストールはフォルダとファイルを削除ですっきり元通り
これに尽きる
レジストリだと手を出し辛い（よくある注意書き、最悪の場合OSが起動しなくなりますのせいで）
色々な場所に設定を書き込むせいでどこに書き込んだか調べるのが面倒
一度書き込んだレジストリが消せない場合がある
アンインストールしてもインストール前に戻さないソフトが多数
レジストリチェックでインストールやアンインストールが正常に行われない事がある

OSのせいじゃないにしてもOSが管理してるならなんとかしろと言いたい

>>616
同感
昔は良かった

iniOS作ればいんじゃね？

OSの設定をCONFIG.SYS にするかOS.iniにするかが悩みどころ

集中管理とアプリやサービスやドライバの連携の弊害だからな。
全部アプリ個別のiniにしたところで、その辺の設定が分散するのは避けられないわけだが。

非常に煩雑な関連付け(HKCU以下のパス)設定もそう。ここが一番混乱している気がしてならない。

ただ、これだけ複雑なOSを要らないと言い切れないと―つまりある程度の利便性も捨てることにも
なるわけなんだが―レジストリのような集中管理型の巨大データベースからも逃れられない。

レジストリのせいで簡単にフォルダ移動できないのが嫌
アンインストール情報にはパスが書き込まれてるから安易に移動できない
レジストリに設定を保存するソフトでよく見られるのがソフトの格納場所のパスを書き込んでるタイプで
やっぱり安易に移動できない
iniだと同じフォルダか階下フォルダにあるのでそんな設定情報必要ないので移動が楽
ユーザー側にはメリットが少ないよ

>>619
他の何かとの連携がなければね。

その必要がないのにレジストリを使うな、
という話なら同意。

>>619
＞iniだと同じフォルダか階下フォルダにある

.exeの置き場所 → Program Files
.iniの置き場所 → %AppData% or %LocalAppData%

どー見ても違うフォルダなんだがww

.iniの置き場所 → C:\WINDOWS だろ。

レジストリが無ければもっとまともなOSだったね
http://hibari.2ch.net/test/read.cgi/win/1221991004/

レジストリじゃ無ければもっとまともなOSだったね

不出来やのう

窓の手でエクスプローラでファイルを右クリックした時の開くエディタの指定で
Vimで開くよう設定したのですが
ウィンドウやフォントのサイズも指定するには
レジストリをどう弄ればよろしいですか？

Linux上でやる

(´・ω・｀)

Vimが開いて、まだファイルを読み込みきってない間に
左上のアイコンクリック - プロパティ
を開く

でサイズ変更して`同じタイトルのウィンドウに適用する'を選択すると
目的が果たされるようになりました事、報告迄

Windowsを長時間使い込むと次第に起動が遅くなるのはレジストリが原因。
これを迷信だとかHDDのデフラグで速くなるとか言う輩がいるが、それこそデタラメ。
常駐プロセスが増えたりしない限り、起動時間が数倍も変わったりするわけがない。
理由は起動時のレジストリ走査に時間がかかるためで、レジストリ本体の肥大化に伴うツリーの
複雑化、データの分断化が主な要因。

どんなデータベースでも分断化は避けられず、業務用途では一定期間で最適化を行う。
これにより未使用領域を圧縮して、ひとつの論理データを連続領域に配置する等の処理が行われる。
Windowsのレジストリはよく知られているように、インストール直後は数十MB程度だったものが
２年も使うとGB単位まで膨れ上がってしまう。
これも当然のハナシで、ウィンドウ位置を少し変えたりするだけでもレジストリの更新が発生
してしまうため。嘘だと思うならこの前後のレジストリダンプをとって比較してみるといい。
さすがにWin7ではこの仕様は改められているようだが。

結論としてレジストリという仕組みが糞というわけではないが、使い方が大きく間違っていた。
実はレジストリの設計者自身はそれほど頻繁に更新するものとは考えていなかった。ところが当時の
INIファイルではデータの構造化が不可能で、レジストリだといろんな情報を置くのに都合がいいと
いう理由から、何でもかんでもここに置くようになった、というのが真相らしい。
レジストリには（比較的不変な）OS自身の設定情報を入れる程度に留めておいて、頻繁に変わる
ものや、アプリの設定情報といったローカルデータは別の入れ物（例えばXML）にすべきだった
（設計者がそう語っている）。

>>628
レジストリはハッシュテーブルで実装されてるから、検索にかかる時間はO(1)で済むよ。
容量が膨れあがるのはそのせい。

>>629
ハッシュテーブルってどんなものか知ってますか？

想像してみよう。キミの目の前に原稿用紙がある。
これをレジストリファイルだと見なして、キーと値をいくつか書きこんでみよう。
通常キーは昇順に並ぶようにするよ。その方が高速だからね。
さらに追加してみよう。今度はさっき書いたキーより小さいものがあるかもしれない。
そしたら並べ替えが必要だね。といってもさっき書いたところを消して書きなおすことはできない。
なぜならハミ出てしまう可能性があるからだ。しょうがないから新しい原稿用紙を用意して
書き写さないといけない。
同じようにまだまだ追加してみよう。原稿用紙がどんどん増えていくね。
今度はさっき書いた値を変更してみようか。でもやっぱり一度書いたところは使えなくなるね。
となると新しい用紙に書いて、キー側の参照も書き換えよう。ページ番号を書き換えるだけだ。
削除するとそのキーは使えないようにしなければならない。
・・・

とまあこんな風に使えば使うほど混沌としていく。DBだって似たようなものだからデータの
再配置なんてことをときどきやるわけだ。
レジストリ１件あたりで考えると、当初数十ミリ秒だったのが長いと数百ミリ秒程度になる。
微々たる時間だが、起動時は相当多くのデータを読み書きしないといけないから、数分かかる
ようになるのは当然のハナシです。

>>629-630
どちらも中途半端な知識だな。

起動時間よりアプリはインストールしなければならない！
って間抜けな状態を改善してくれ

レジストリに対する不満点は、
アプリケーションをアンインストールした時に完全に削除できたか
確認できず、現にゴミを残すことが多い事です。

そうではなく、アプリ毎に１つの設定ファイルにして、削除時は
その設定ファイルと、アプリのフォルダー削除のみで
きれいに削除可能であればすっきりするのになと思う。

汚れて肥大化しても良いようにデータベース化したんじゃ？
精神的に気に入らないというなら仕方ないけれど。

ソフトウェアベースだったらまだよかったのに

>>633
これってレジストリに限った問題なの?
.iniをちゃんと削除しないアンインストーラだってあるでしょ

あるかもしれないが、多くはないんじゃない？
それに対してほとんどのアンインストーラはレジストリにゴミを残していく

まぁ逆に、ゴミを残していくのがわかってるから掃除すればいい話だが

でかいファイルの中のちっちゃなゴミを消せば、そこだけ虫が食ったような穴が開くだけ。
ファイルサイズは変わらないし、その穴が別のデータで上書きされたらますます
ややこしくなる。１年も使えば起動が劇遅になるのはこれが原因。

アプリの設定情報なんてサイズはたかが知れている。
ひとつのファイルにしたらほとんどの場合は１クラスタに収まるだろう。
こいつの方がよほど効率がいいし、可搬性も高い。
HDDクラッシュなどの不測の事態に対するリスクだって小さい。

一般的にデータベースというやつは、時間の経過と共に内部がぐちゃぐちゃになっていくから
定期的に「最適化」という保守作業をやるのが常識。Winのレジストリは構造的にこれが不可能。
起動している間は常に更新しまくってるんだけどねえ。

近年ようやくMS自身が脱レジストリを推し進めているが、無数のソフトが勝手気ままに
レジストリを使っている現状では、APIを閉じることなど不可能。
だからこの運動音痴なイケてない仕組みは、今後半永久的に残ると思うよ。

>>619
http://www.computerworld.jp/topics/560/200490/
＞「Program Files」フォルダ内のプログラムは別の場所に移動させても、
＞Windows自体が別の場所に移動したことを認識していなければ、プログラムは起動しなくなる。
＞そこで「Program Files」フォルダの内容を移動させるときには、“ジャンクションポイント”を
＞いっしょに作っておく方法をお勧めしたい。ジャンクションポイントとは簡単に言えば
＞「フォルダのショートカット」であり、ジャンクションポイントを作っておけば、Dドライブにあるフォルダが、
＞あたかもCドライブの「Program Files」フォルダ内にあるかのように見せることができる。

>>638
>起動している間は常に更新しまくってるんだけどねえ。

Explorerでフォルダを開いたり、ウィンドウの位置を変えたりするだけでも
レジストリが更新されるんだよな。
これ知ったとき、MSの連中はイカれてんじゃねえかと本気で思ったよ。
どんどん遅くなっていくのも当然ってわけだ。

＞Explorerでフォルダを開いたり、ウィンドウの位置を変えたりするだけでも
＞レジストリが更新されるんだよな。

具体的にはどのキーをいじってるの？
情弱な俺では見つけられなかっただよ

一度バックアップをとった後、適当にいじってファイル丸ごとdiffとればすぐ分かる。
恐ろしく頻繁に更新されているのが分かるはずだ。

Process Monitor オヌヌメ

>>643
フォルダを開いたり閉じたりする時にレジストリが更新されるのは確認できたけど
ウィンドウの位置を変えただけではまったく反応無しに見えるなぁ

.iniをこの勢いで更新しまくってたら重くて使い物にならなかっただろうから
レジストリの導入は大正解だったって事だな

電波テロ装置の戦争(始)
魂は幾何学、コピー出来る公安はサリンオウム信者の子供を40歳まで社会から隔離している
オウム信者が地方で現在も潜伏している
それは新興宗教を配下とする公安(慶應卒T)の仕事だ発案で盗聴器を開発したら霊魂が寄って呼ぶ来た
<電波憑依>
スピリチャル全否定なら江原三輪氏、高橋佳子大川隆法氏は、幻聴で強制入院矛盾する日本宗教と精神科
<コードレス盗聴>
2004既に国民20%被害250〜700台数中国工作員3〜7000万円2005ソウルコピー2010ソウルイン医者アカギ絡む<盗聴証拠>
今年５月に日本の警視庁防課は被害者SDカード15分を保持した有る国民に出せ!!<創価幹部>
キタオカ1962年東北生は二十代で2人の女性をレイプ殺害して入信した創価本尊はこれだけで潰せる<<<韓国工作員鸛<<<創価公明党 <テロ装置>>東芝部品)>>ヤクザ<宗教<同和<<公安<<魂複<<官憲>日本終Googl検索

インストーラーやアンインストーラーって管理者権限で実行するファイルだから、
悪意あるプログラムだった場合windowsその物が破損するんだよな。
正直管理者権限で実行可能ファイルとかセキュリティ的にはあり得ない。

むしろ管理者権限が必要なアプリって何やってるんだろう？
リソースとかプロセスIDのアクセスだったらメモリのread権限だけで大丈夫だから権限を細分化して欲しい。

管理者とかユーザーで分けるのはいいけど
レジストリでなくマイドキュメントにファイル作って保存も結構嫌

>>649
じゃあ何処ならいいんだよ？

システム以外でレジストリを使う必要があるとは思えない

>>651
それを理解するには、レジストリがいつ出来て
何に使われているのか知る必要があるよ。

Mac方式にして

実行ファイルと同フォルダ以下にしか設定ファイルを置かないのが一番便利
不要になったらフォルダごとポイ

スマートフォンのOSのアプリやストアアプリはある意味フォルダ方式に回帰だよな

>>654
なんでMacもLinuxもその方式をやらないんだろうか？

OS Xは知らんがMac OS 9までは実行ファイル自体のリソースフォークに設定情報を
格納できたのでそもそも必要なかった

そんな話は聞いていない

>>656
そもそも実行ファイルと同フォルダ以下に
設定ファイルを置くのは今の時代では思想が古い。
今はユーザー毎に切り替えて使う事も念頭にあるから
ユーザー毎のライブラリに設定ファイルを入れた方が合理的。

フォルダごとコピーして設定を切替えられるから便利なんだよなあ
MPCも設定をiniにして、いくつか設定を使い分けてる
バックアップが簡単なのも大事だ

レジストリに書き込まないソフトはキレイなソフトですか?
ttp://www.inasoft.org/webhelp/rnsf7/HLP000090.html
レジストリは危険なのではないのですか?
ttp://www.inasoft.org/webhelp/rnsf7/HLP000101.html

> そこら辺はレジストリクリーナーのお話になってしまいますので、
> こちらのサイトを参照して下さい。

こちらってどちらだ? ヘルプファイル版だとリンクになってるのか?

iniが一番だね

設定変更もめんどい
レジストリは最悪のシステム

昔は一ファイルにまとめた方が効率良かったんだよ
ストレージが今と比べものにならんくらい少なかったからね
その程度の知識も知らずに叩いてる子を見るとほっこりするねぇ

win3.1から使ってるがレジストリは大して効率よくねーよ
iniで個別管理の方が遥かに優れてた

レジストリエディタを使用不可にする設定

これをすると、設定した自分自身もレジストリエディタが使えなくなってしまう。
そこで、その設定を行う前の値のバックアップは忘れないように。

この設定を行った後、レジストリエディタを起動させようとすると、
「レジストリ編集は、管理者に拠って使用不可にされています。」の
エラーメッセージが出て、レジストリエディタの起動はできないはず。

お前らが言いたいのは「レジストリは糞」じゃなくて「MSがやることは糞」だろ
Macがレジストリを使ってたら擁護してたはずだ

アップルは別にいいけどアップル信者は嫌いだな

レジストリ使うと禿げ散らかすって本当ですか？

http://msdn.microsoft.com/ja-jp/library/ms811694.aspx
マシン間でアプリケーションが矛盾する別の原因としてありがちなことは、
アプリケーションが永続データを読み込むときに起こります。
データは .ini ファイル、データベース、またはレジストリの場合があります。
通常データベースと .ini ファイルは、容易に比較できますが、
レジストリ データを比較するのは非常に困難です。
レジストリに問題があるのではないかと考えたときには、
regmon ユーティリティ (http://www.sysinternals.com/ から無償で入手可能) を実行して、
各システムのアプリケーションで読み込まれるレジストリ値を比較します。
何百ものレジストリ値を比較するのは一般の人にとっては大変なことなので
(そして、私のような難読症の人間には事実上不可能なので)、
次に作成するツールは RegistryHell ユーティリティにしなければと思っています。

ＯＳとか特殊なの以外ソフトごとに設定ファイル持ってるほうがいい
設定変更も構造もめんどいし下手に触ると全体に悪影響してしまうレジストリは最悪のシステム
フォルダごとコピーして別設定にしたり不要になったらフォルダごとポイ出来る系が理想
設定ファイル消せばとりあえず初期化できるとかな

インストーラーもフォルダ作って情報登録するだけの質素なのがいいね
込み入った奴は破損する・ゴミが残ると最悪だ

ぐちゃぐちゃ込み入った無数のソフトが勝手気ままにレジストリを書き散らかす状況はイケてない
システムファイルや共有ファイルの競合や散らかりもイケてない、食い込んでてえらい目にあったり
大きなシステムとして何でも根深く組み込む系統よりか、なるべくこぢんまりとした１つの世界みたいな…
簡単に外して付け替える事が出来るよみたいな、フリーソフトは良く出来てるの多いよね

複雑な集中管理もドライバ類とかどうしても組み込まれて根付くしかないもんだと仕方ないだろうけどさ・・・

なるべく散らかさないiniOS的な・・・いいかもねｗ
出来る限り散らかさず組み込まず独立でやるというＯＳ

特別な事情が無い限りはアプリ側で配下のフォルダでやってね・・・
USBメモリにも移動できるように・・・と

システム的部分ではどうしても効率がいいしレジストリのような物使うしかないけど
なるべくシステムを汚さないって事にはなる

マナー悪いソフトが減ればホントは今のままで解決するんだろうけどね

好き勝手なところにファイル作り、絶対必要でもないのにレジストリに好き勝手にエントリ作る
システムファイル部分に色々ぶちまけたり書き換えちまったりする、そして残していく
あれこれぐちゃぐちゃにするそんな行儀悪いソフトでの混沌っぷりが一番悪いのかもしれない

>>672
WIndowsがシングルユーザーOSで、セキュリティを気にしなくてもよくて、
自分で設定ファイルを壊したくせに
「何もしてないのに壊れた！やっぱりWindowsはゴミだゲイツ死ね！」
って大騒ぎする人がいないならそれでもいいのかもしれないけど
現実は3つともNoなわけで…

そもそもインストーラーとか勝手に作ってインストールを許してるのがおかしいだろ。
インストールは OS にさせるべき。
そしたらアンインストールも完璧にできるし、できなければ OS が腐っているというだけの話になる。

つ[Windowsストア]

OneGet , WindowsにおけるApt-Get的な、あるいはyum的な何か
ttp://opcdiary.net/?p=27863
OneGet について
ttp://opcdiary.net/?p=28038

正式版がリリ-スされれば少しは楽になるかもしれないし、ならないかもしれない

レジストリと ini ファイルについて考えるページ
ttp://www.geocities.co.jp/Beautycare/4965/public/save.html
Windows用アプリケーションで設定や情報をどこに保存すべきかの指針
ttp://d.hatena.ne.jp/paz3/20091127/1259303402
アプリケーションの設定をどうやって保存するか？　ini vs レジストリ vs xml
ttp://ambiesoft.fam.cx/blog/archives/18

レジストリの設定は変更してはいけないものだと思っていました
http://technet.microsoft.com/ja-jp/scriptcenter/ff189345.aspx#3

Microsoft サポート技術情報の文書を読んだことがある人は、次のような一文を読んだことがあると思います。

この問題を修正するには、レジストリの次の値を変更してください。

ここまでは結構なのですが、この文の後に必ず次のような免責事項が続きます。

警告 レジストリの値は決して変更しないでください。
決して。たった今そうしろと言ったばかりなのはわかっています。
でも、崖から飛び降りろと言われて本当にそうしますか。
レジストリの値は決して変更しないでください。"レジストリ" という言葉すら口に出さないでください。
かつて "レジストリ" という言葉を口にした人が、3 日後にバスにひかれたという実話があります。
実際のところ、コンピュータにレジストリを持つことも避けるべきです。
コンピュータにレジストリがあるのではないかという疑いがある人は、連絡してください。
訓練を受けた専門家を派遣して直ちにレジストリの除去を実施します。
誤ってレジストリに触れてしまったら、石鹸と水で手を洗って医者を呼んでください。
レジストリを飲み込んだり目の中に入れたりしないでください!

さて、正直なところ、これらの恐怖のいくつかは多少誇張気味ですが、
免責事項が用意されているのは主に法的な理由のためです
(忘れないでください。今や、レストランでホットコーヒーを注文して
実際にものすごく熱いコーヒーが出されたらレストランを訴えることができる時代です)。
作業を正しく行えば、レジストリの変更はまったく無害です。

レジストリはWintel系のOSに詳しくない素人がいじっていいシロモノではないのは確か。
私もレジストリエディタを使用して、MTU、RWINの調整を何度かした経験がある他、
細かなレジストリカスタマイズをレジストリ編集関連の雑誌を参照にしながら慎重に編集したことがある。

まあ、失敗もある。
レジストリ編集で、間違った編集を行い、Windowsが起動しなくなった経験がある。

レジストリの変更は、それだけ危険を伴う作業なので、必要な場合以外は、
レジストリエディタを使わないようにしている。

Q:cdromとusbに関するレジストリを「誤って中途半端に削除した」模様です
誰でもいいのでcdromとUSBに対する「基本」のレジストリを記述していただけるとありがたいです

USB：HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\{36fc9e60-c465-11cf-8056-444553540000}
http://www.dotup.org/uploda/www.dotup.org5405370.png
CD-ROM：HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\{4d36e965-e325-11ce-bfc1-08002be10318}
http://www.dotup.org/uploda/www.dotup.org5405368.png

ttp://light.dotup.org/uploda/light.dotup.org98869.png
7pro64だけど

utf-8/lfでインポートしたデータは何処へ。。。
*.regファイルを保存する時の文字コードには気をつけよーね！

アプリケーションのお行儀しだいでしょ。
拡張子別の挙動ぐらいテキストでまったり弄らせてくれと思ったりはするけど。

コマンドラインでscanreg fix/すれば動作がはやくなる
とはいってもスタートメニューから選択できないよね
一部パソコン雑誌で隠れコマンドとして手引きされているだけ

>>9
SSDでもランダム読み書きは2桁くらい遅くなるが
まあHDDの平均値よりは速いからな。

コントローラの出来が悪いとプチフリするが。

http://www.atmarkit.co.jp/ait/articles/1501/22/news143.html

テキストファイルを使ったシステムの設定管理方法は、
大規模化するマルチユーザー／マルチタスクのシステムには全く対応できない。
ユーザーごとに設定を分離／管理する機能もないし、設定値を安全に書き換えることすらも不可能だからだ。

ほとんどのレジストリエントリは静的な構造や値を持っているが、動的な値を持つエントリもあるし、
ユーザーや環境ごとに自動的にレジストリのセット（ツリー）を切り替えたり、
障害発生時には以前の値に戻したりする機能も持っている。
またWindows OSの設計思想に従って、
アクセス制御（アクセス権のないユーザーやプロセスなどからのアクセスを拒否する）や監査機能も備えているし、
値変更の通知機能（特定のレジストリの内容が変更されたことをプロセスに通知する機能）なども持っている。

レジストリ
それは自称中級者に残された最後のフロンティア