08/09/21 18:56:44 kkiAhz6P
トラブルの9割はレジストリだろ
2:名無し~3.EXE
08/09/21 18:57:28 cPL3uwn3
まったく関係ない。
3:名無し~3.EXE
08/09/21 19:12:26 cPL3uwn3
レジストリにまつわる大きな勘違い。
■レジストリが肥大化した！
レジストリファイルサイズが大きくなったからどうかしたのですか？
■レジストリが肥大化すると起動が遅くなる
レジストリファイルの内容すべてを読み込んでいるわけじゃないから関係ありません。
■でもアプリをインストールしたらパソコンの起動が遅くなった！
レジストリは関係ありません。パソコンの起動時にアプリが実行されているから遅くなっているだけです。
もしそのアプリがレジストリをやめてiniファイルを使用したとしても、起動時間は同じですよ。
■レジストリが壊れるとパソコンが起動しなくなる！
ファイルが壊れることがそもそも異常でしょう？ もしそうなったらファイルどころじゃありませんよ。
■レジストリを最適化すると速くなる！
速くはなりません。そもそも遅くなっていません。レジストリの最適化とは、ファイル内の未使用データ領域を
消すことによってファイルサイズを減らしているだけです。もちろんレジストリファイルサイズが減っても起動時間に影響はありません。
■一般ユーザーがレジストリをいじるとパソコンがおかしくなる。危険だ。
それをいったら一般ユーザーがシステムファイルをいじってもパソコンはおかしくなります。
だからファイルにアクセス制限がかかっています。もちろんレジストリにもアクセス制限はあり、
システム関連のレジストリを読み書きするときには適切な権限が必要です。
■レジストリファイルって一つのファイルになっているんだよね。
違います。複数のファイルに分かれています。システム用と各ユーザー用に別のファイルになっています。
4:名無し~3.EXE
08/09/21 19:32:22 y5wSY735
というのは嘘で
レジストリに書き込みと削除を繰り返し行なうと断片化します。
断片化が起きると読み込み速度も低下します。
5:名無し~3.EXE
08/09/21 19:43:13 cPL3uwn3
■レジストリって書き込みと削除を繰り返すと断片化するよね？
断片化は（ほとんど）しません。これは「レジストリの最適化」と
関係がある話ですが、レジストリファイルの大きさは頻繁に変わったりしません。
書き込みしたからといってその場ですぐに増えるわけじゃないし、
削除してもレジストリファイルのサイズは減りません。
ファイルサイズは必要なときに余裕を持って拡大され
レジストリのキーを削除してもファイルサイズは減りません。
このような、ファイルの断片化を防ぐ機能が実装されています。
それゆえに、レジストリファイルの中に未使用領域ができるため、
「レジストリの最適化」（未使用領域の削減）という処理の意味がでてくるわけです。
もちろんレジストリの最適化はファイルサイズを減らすだけで
起動時間などの重さには一切関係ありません。
6:名無し~3.EXE
08/09/21 19:49:32 kkiAhz6P
レジストリは設定を酷く散らばすため変なアプリが書き換えたら設定が変になります。
最悪システムです。
7:名無し~3.EXE
08/09/21 19:55:22 cPL3uwn3
■レジストリは設定を酷く散らばすため変なアプリが書き換えたら設定が変になります。
それはレジストリに限った話ではありません。
8:名無し~3.EXE
08/09/21 20:02:31 0lWW5dL4
■レジストリが壊れるとパソコンが起動しなくなる！
ファイルが壊れることがそもそも異常でしょう？ もしそうなったらファイルどころじゃありませんよ。
■レジストリって書き込みと削除を繰り返すと断片化するよね？
断片化は（ほとんど）しません。これは「レジストリの最適化」と
関係がある話ですが、レジストリファイルの大きさは頻繁に変わったりしません。
書き込みしたからといってその場ですぐに増えるわけじゃないし、
削除してもレジストリファイルのサイズは減りません。
ファイルサイズは必要なときに余裕を持って拡大され
レジストリのキーを削除してもファイルサイズは減りません。
後者ではレジストリがRDBのような独自ストレージの仕組みを
内部に持っていることを示唆しているのだから、
その仕組みにバグがあればレジストリが壊れることはあるでしょう。
前者でファイルシステムの信頼性の話にもっていくのはおかしい。
まぁ、壊れることなんて滅多にないけどね。一生のうちに一度おめにかかれればいいほうだろう。
9:名無し~3.EXE
08/09/21 21:04:20 tAUgF5xQ
SSD使えばいくら断片化しようがかわらん？
10:名無し~3.EXE
08/09/21 21:28:39 kkiAhz6P
>>7
レジストリが最悪だろうが
11:名無し~3.EXE
08/09/21 21:30:57 cPL3uwn3
10 名前：名無し~3.EXE[] 投稿日：2008/09/21(日) 21:28:39 ID:kkiAhz6P
>>7
レジストリが最悪だろうが
12:名無し~3.EXE
08/09/21 21:32:20 kkiAhz6P
レジストリは最悪。
アプリを削除してもしつこく残り続ける。
掃除しないとOSあぼん。
設定をしつこく散らばし、掃除が面倒、しかも読み込んで重くなる。
13:名無し~3.EXE
08/09/21 21:33:37 cPL3uwn3
■アプリを削除してもしつこく残り続けるんですが？
それはOSのせいですか？ アプリを消しても設定ファイルが残るのはOSのせいですか？
14:名無し~3.EXE
08/09/21 21:38:35 9NDxHgOX
アンインストーラーが適切に削除すればいいだけの話だわな。
15:名無し~3.EXE
08/09/21 22:33:32 kkiAhz6P
少なくとも、そういう設計なwindowsが最悪なだけ
16:名無し~3.EXE
08/09/21 22:36:45 cPL3uwn3
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が最悪なだけ
17:名無し~3.EXE
08/09/21 23:01:11 x4AnjQQl
設定ファイルをあちこちにばら撒いて訳わかめの、Linux（笑）のほうがいいとでも？
18:名無し~3.EXE
08/09/21 23:20:10 kkiAhz6P
>>17
設定はしやすいし、重くもならないね
19:名無し~3.EXE
08/09/21 23:24:33 EUaqNRyn
レジストリなんてただのDBなんだから、重いもヘッタクレもないだろｗ
読み書きの実装にもよるが、少なくともファイルに依存したシステムよりずっとスマートだｗ
20:名無し~3.EXE
08/09/21 23:30:55 ugqayTsZ
ID:cPL3uwn3
糞スレかと思ったのに、勉強になっちゃったよ乙！
21:名無し~3.EXE
08/09/21 23:48:32 kkiAhz6P
■レジストリについて…
オンメモリだから基本的に重くなります。
しかもレジストリを使用すると設定が散らかるために
OSがクラッシュする原因になります。
アンインストールしてもしつこく残り続けます。
弊害があまりに大きいので他のOSユーザーからは批判対象になっています。
22:名無し~3.EXE
08/09/21 23:57:47 EUaqNRyn
つまりDBを使ったことのない犬厨だと
23:名無し~3.EXE
08/09/22 00:08:42 OJ14GPrc
■オンメモリだから基本的に重くなります。
一部キャッシュはしていますが、すべてオンメモリではありません。
それに、そもそもレジストリだからオンメモリになるんですか？
それがレジストリではなくiniファイルだったとしても結局は同じことでしょう？
24:名無し~3.EXE
08/09/22 00:17:55 P15p6/eP
そもそもレジストリの意味が分かってねー奴がいるな。
25:名無し~3.EXE
08/09/22 00:24:26 OJ14GPrc
■そもそもなぜレジストリなのですか？ 普通のテキストファイルでもよかったのでは？
なぜレジストリか。それはレジストリの方が速くて、
メモリ使用量も少なくて、ディスク使用量も少ないからです。
驚きましたか？
ではどういう理屈でそうなのか。説明しましょう。
普通のテキストファイルなら、全体を読み込まないと内容はわかりません。
途中のデータだけを参照するということはできないのです。
レジストリは途中のデータを参照できるように作られているため
データが途中であってもすぐに参照できます。
もしテキストファイルが独自形式だとしたら、アプリごとにテキストファイル解釈コードが
記述されます。プログラムごとにそういうコードが存在するためメモリ使用量も増えます。
レジストリはバイナリファイルになっています。これは無駄なデータが存在しないということです。
ディスクから読み込む量も減るので速く参照できます。当然メモリ使用量も減ります。
いまどきそんなのたいした負荷ではないのでは？と思うかもしれません。
そうですね。レジストリの方が優れていても今ではたいした負荷ではありません。
でもレジストリが設計されたのは今から10年以上前の話です。当時レジストリを作る理由は大きかったのです。
もうやめるべきでは？と思うかもしれません。でもやめる理由がありません。やめることで何が改善されるのですか？
ユーザーフォルダの下に設定ファイルがたくさんできる方式に変えてそれで何が改善されますか？
26:名無し~3.EXE
08/09/22 00:43:30 EIT/il7M
ゴミが残るのが最大で唯一といっていい問題だな。
27:名無し~3.EXE
08/09/22 00:44:07 mJbuEzD3
やべっｗ何この糞スレ改め良スレｗ
レジストリ神のおかげで目からウロコ連発で、めちゃめちゃ参考になるんですけどｗ
完全にレジストリ勉強スレになったな。
28:名無し~3.EXE
08/09/22 01:05:51 jz1ZVWqR
やっぱり、みんなレジストリが糞の根源と思っていたんだ。
ホッとした。よかった。
29:名無し~3.EXE
08/09/22 01:37:03 gGsyVv/2
>>28
そこは揺るぎない事実だけどな
30:名無し~3.EXE
08/09/22 01:48:36 bs4gYTey
13 名前：名無し~3.EXE[sage] 投稿日：2008/09/21(日) 21:33:37 ID:cPL3uwn3
■アプリを削除してもしつこく残り続けるんですが？
それはOSのせいですか？ アプリを消しても設定ファイルが残るのはOSのせいですか？
31:名無し~3.EXE
08/09/22 01:55:06 EIT/il7M
Visual Studioで開発するとインストーラ付きにしてもゴミが残ったりするからな。
OSのせいといってもいいだろ。
インスーラなしでもexeやdll削除の際にそれに関連するものは削除してくれてもいい。
32:名無し~3.EXE
08/09/22 03:26:18 qoPc9cph
＞すべてオンメモリではありません。
確かに「すべて」オンメモリではありませんが、
「ある程度」オンメモリになってしまえば、レジストリの肥大化により
os自体が重くなってしまうという現象には変わりないのです。
しかもゴミが残るのでずっと重くなりっぱなしで、消したら消したでトラブルになってしまいます。
そして、レジストリのオンメモリの弱点です。
必要な時にだけ設定を参照しに行くほかの
ファイル設定方式と違えば問題点が大きいのです。
問題なのは肥大化することによるオンメモリであり、
レジストリ信者の
「レジストリのいいところだけを取り扱い続ける恣意的すぎるプロ場ガンだと
それにだまされるカルト大衆」は自殺すれば世の中平和。
33:名無し~3.EXE
08/09/22 03:28:59 OJ14GPrc
俺の全財産の額も肥大化している。
34:名無し~3.EXE
08/09/22 03:30:57 qoPc9cph
＞■
をつけた人の文章を読んでください。
あまりにも詭弁があふれております。
こちらが指摘した「設定が散らばってOSクラッシュの原因になる」については
答えもしませんし、それ以前に「重くなる」ことについては「すべての」といえばすむと思っています。
しかしよく考えてください。１００あったとして１００じゃなければ重くならないのでしょうか？
10とか20とかでも十分重くなるしレジストリが汚れるという現象自体はあるのではないのでしょうか？
それを言わずに恣意的なレジストリの美点だけを取り上げ続けるプロバガンダにはもううんざりです。
レジストリとともに消したいです。
35:名無し~3.EXE
08/09/22 03:34:31 OJ14GPrc
> 「設定が散らばってOSクラッシュの原因になる」
答えるまでもなく、普通に考えて、ありえなくねｗ
36:名無し~3.EXE
08/09/22 03:36:24 qoPc9cph
レジストリの弱点
あまりにもわかりにくい管理データー方式。
レジストリを編集するに当たって
物凄いめんどくさい作業をしたことはあるでしょう。
レジストリが無いlinuxを使った人ならわかると思うけど、
凄くわかりやすい。編集もしやすい。
散らかったりアボンしてしまう管理形式。
レジストリがクソみたいな設定をするだけでOS全体に酷い被害を与えてしまうことがある。
しかも消せなかったりする。ゴミが残る。
だからレジストリを使わないアプリに人気があります。
消しにくい
レジストリが重くなり続けても消しにくいのです。
なので掃除ソフトを使用しますが、
使用したことによってトラブル続出なんてことがよくあります。
いい加減まともなDBを作成しろよMS。
37:名無し~3.EXE
08/09/22 03:36:50 OJ14GPrc
設定が散らばるどころか、設定が一つのファイルにまとまっているしさぁｗ
38:名無し~3.EXE
08/09/22 03:37:51 OJ14GPrc
>>36
Linuxで変な設定をした結果 X Windowがまともに起動しくなったよ。
あれなんで？
39:名無し~3.EXE
08/09/22 03:40:48 qoPc9cph
>>38
がんばって一生懸命働きまくって財産を肥大化させてくださいお願いします。
２ちゃんはやらない方がいいでしょう。
40:名無し~3.EXE
08/09/22 03:41:24 OJ14GPrc
まあ、ここで事実を突きつけるのはかわいそうだけどさぁ。
実は、Linuxもレジストリ、導入したのよね。
これが証拠。
URLﾘﾝｸ(www.linuxtopia.org)
41:名無し~3.EXE
08/09/22 03:42:58 qoPc9cph
一部のディストリでしょ
42:名無し~3.EXE
08/09/22 03:49:48 UfYReAPj
データベースの、インデックスという物のイメージがわくかどうかで、
理解度が変わるんだろうなぁ。
43:名無し~3.EXE
08/09/22 03:53:57 OJ14GPrc
そうそう。レジストリに対する批判は、
レジストリ特有の問題ではないことに気づくべき。
常駐プログラムが増えたら重くなった。とか
レジストリと関係ないってｗ
44:名無し~3.EXE
08/09/22 03:55:54 qoPc9cph
レジストリは一般アプリの設定じゃなくてブロックしてOS情報だけを載せていれば問題は無かっただろう。
しかし現状では悪意あるアプリがレジストリをメチャクチャにできるわけだ。
それが問題だよな。
45:名無し~3.EXE
08/09/22 03:58:52 OJ14GPrc
↑これもこういうこと↓
レジストリ特有の問題ではないことに気づくべき。
レジストリやめて、それでそこに保存してある設定ファイルはどうする？
テキストファイルに保存する。そう、そのテキストファイルは
悪意のアプリがめちゃくちゃにできるよね。
こういうこと。
46:名無し~3.EXE
08/09/22 03:59:57 qoPc9cph
>>45
それは難しいと思うけど。
少なくともレジストリ並みに酷くやっかいにはならなそうだね。
47:名無し~3.EXE
08/09/22 04:01:13 OJ14GPrc
>>46
なんで難しいんだよｗ
rm -rf ~/ で簡単にユーザー設定削除できるって。
48:名無し~3.EXE
08/09/22 04:03:24 qoPc9cph
アプリのテキストをピンポイントで削除できるのか凄いな
49:名無し~3.EXE
08/09/22 04:04:14 OJ14GPrc
>>48
レジストリの話？ｗ アプリのレジストリをピンポイントで削除できるのか？ｗ
50:名無し~3.EXE
08/09/22 04:05:38 qoPc9cph
あと書き換えられるのか。
レジストリだと、汚れてしまって起動しないだのおかしくなっただのはあるけどiniで聞いたことは無い。
51:名無し~3.EXE
08/09/22 04:07:04 OJ14GPrc
> iniで聞いたことは無い。
その理由は、iniには現在起動に必要な情報がほとんど含まれていないから。
レジストリをやめて、起動に必要な情報をiniに書き込むようにすれば、
同じようにiniが汚れれば起動できなくなる。
52:名無し~3.EXE
08/09/22 04:08:29 qoPc9cph
レジストリが必要ないツールでも聞いたことが無いんだけど
出来るそうだね。
やってみて欲しいなあ。
53:名無し~3.EXE
08/09/22 04:08:48 OJ14GPrc
はぁ。本当に頭悪いよ。
なんでこんなに頭が悪いのかな。
レジストリは設定の保存先に過ぎない。
どこに保存しようと、設定が壊れれば問題起きるだろ。
そんなの当たり前だろ。
「レジストリ特有の問題ではないことに気づくべき。 」
54:名無し~3.EXE
08/09/22 04:10:11 qoPc9cph
壊しやすく重くなりやすくいじりにくく消しにくくと最悪な設定保存技術ですね。
55:名無し~3.EXE
08/09/22 04:11:35 OJ14GPrc
反論できなくなったからって、自分の都合のいい結論を
唐突に持ってこないように。厨房かよｗ
56:名無し~3.EXE
08/09/22 04:20:28 qoPc9cph
Macやlinuxではレジストリみたいに
設定が汚れるなんてレジストリに比べれば
相当に少ないわけだし、重くなることだって少ない。
他のアプリが設定ばら撒いたからってOS全体が酷いことになったりとか、
他のアプリに被害が出たとかもレジストリに見れば少ないし重くもならない。
最悪なシステムだよな本当に。
57:名無し~3.EXE
08/09/22 07:48:58 hpTXE3E0
ただのデータストアにそこまで罪を負わせようとするなんて正気の沙汰とは思えないｗ
58:名無し~3.EXE
08/09/22 09:47:31 PLJiNmDM
>>53
レジストリで問題なのは「情報が纏まっているから一部が壊れると他も影響を受ける」可能性
他のOSでの各種設定情報の保存方式なら、ファイルシステム上で分散して置くことが多いから
基本的にどれかが壊れても他は影響を受けない
勿論システムの根幹に関わる情報が壊れる時はどちらでも変わらないし
情報の一元管理にも所定のメリットは有ることは認めるが
「情報が壊れたとき何処までの範囲で影響が及ぶのか」で考えれば
>>25や>>53みたいな結論には普通至らないのではと思うが如何か
あとバイナリ形式の設定ファイルは別にレジストリの専売特許ではないよ
全体的に比較対象の知識がやや古い気がする
59:名無し~3.EXE
08/09/22 09:52:33 PLJiNmDM
補足
>>8
>■レジストリが壊れるとパソコンが起動しなくなる！
>ファイルが壊れることがそもそも異常でしょう？ もしそうなったらファイルどころじゃありませんよ。
論点のすり替え入ってる気がするな
ファイルシステム上でファイルが壊れることと、データベース情報が壊れることは別
んで実際のレジストリでの問題発生は後者が殆ど
60:名無し~3.EXE
08/09/22 10:07:22 zMJObued
レジストリによる管理のWindows95よりも、iniファイルによる管理のWindows3.1の方が不安定だったのは何故?
61:名無し~3.EXE
08/09/22 10:26:19 PLJiNmDM
>>60
その二つだと正直どちらも「不安定さ」では大差なかった気がするが
どっちも充分過ぎるくらい不安定になるための要素を抱えてた
それにシステムの根本的な作りが大きく違うから、
それらの安定度の比較はこの件と直接には結びつかない
実際殆どの場合はドライバに起因する問題だったし
62:名無し~3.EXE
08/09/22 10:27:45 nwaXeo3g
レジストリはOSだけが使ってれば問題なかったと思うけどね。
MSがレジストリを使うことを推奨するもんだから、アンインストール時の
考慮が出来ないようなアホなソフト作者が糞ソフトを量産することに
なったんじゃないかと。
63:名無し~3.EXE
08/09/22 10:40:44 WWBOv+Of
>>60
Windows3.1は16ビットOS、Windows95は32ビット＋16ビットのOSだったからじゃないのかな？
64:名無し~3.EXE
08/09/22 10:44:25 PLJiNmDM
>>62
自分もそう思う
65: [―{}@{}@{}-] 名無し~3.EXE
08/09/22 12:04:55 MxQvsqLh
「レ ジ ス ト リ 特 有 の 問 題 で
は な い こ と に 気 づ く べ き 。 」
66:>>65
08/09/22 12:28:13 UTKJsVzf
レジストリという入れ物にデータをまとめるのはいいとして、
プログラムが好き勝手に物を放り込んだり、
入れたっきり削除しなかったり、
レジストリの使用方法まで厳密に定義しなかったのがレジストリシステムの問題。
一般的にはレジストリの問題と言う。
67:名無し~3.EXE
08/09/22 13:08:35 36vrSFDN
でもVista()みたいに無駄に隠しファイルあるのもなあｗ
デスクトップに隠しファイルとかいらねーからｗｗｗｗｗｗｗ
68:名無し~3.EXE
08/09/22 14:21:45 JGaE5+tQ
>>59
> ファイルシステム上でファイルが壊れることと、データベース情報が壊れることは別
>
> んで実際のレジストリでの問題発生は後者が殆ど
レジストリファイルが壊れるってことまず無いよ。
データベース情報って言ったって、そのデータの実態はファイル。
具体的な名前を出すと、NTUSER.DATね。
データベース情報が壊れる = NTUSER.DAT が壊れるということ。
NTUSER.DATというファイルが壊れる。
NTUSER.iniというファイルが壊れる。
まったく同じ話。
69:名無し~3.EXE
08/09/22 14:23:10 JGaE5+tQ
>>66
> レジストリの使用方法まで厳密に定義しなかったのがレジストリシステムの問題。
> 一般的にはレジストリの問題と言う。
なんだよｗ つまりファイルの使用方法を厳密に定義し、
アンインストール時に設定ファイルを消し忘れるアプリがあったら
それはファイルシステムの問題っていうのかよｗ
70:名無し~3.EXE
08/09/22 14:40:05 UTKJsVzf
>>69
レジストリはファイルシステムではないな。
データベースと言うなら合ってる。
データの肥大化や、整合性によって問題が起こるなら
それが起こらないように対処しておくべきだったということ。
レジストリクリーンアップ処理を謳ったアプリケーションがあるけど、
何らかの根拠で「不要なレジストリ」を判断できるなら、
「こういうデータは無効なデータになる」という根拠を明確にしておけば
安心して消せるし、ユーザー設定とインストール情報などを明確に分けておけば
ユーザー設定を残したままインストールし直すようなことも可能になる。
71:名無し~3.EXE
08/09/22 15:28:09 dbBRDsPx
Macみたいにアプリケーションの名前がついたPreferences Fileをごみ箱に
捨てる方が楽でいいな。
不具合があっても特定しやすいし。
72:名無し~3.EXE
08/09/22 15:34:25 RO9b52DX
レジストリとかTEMPフォルダとかアプリのゴミ捨て場になってる気がする
73:名無し~3.EXE
08/09/22 17:11:11 JGaE5+tQ
>>70
> それが起こらないように対処しておくべきだったということ。
起こらないように対処していないとでも？
何を根拠に対処していないといっているのかわからん。
たとえば、NTUSER.DATというファイル（レジストリ情報が入っている）は
OSによってファイルロックがかけられ、同時に書き込みが出来ないようになっている。
ちゃんと処理をしているだろ。
74:名無し~3.EXE
08/09/22 17:16:34 JGaE5+tQ
>>70
> レジストリクリーンアップ処理を謳ったアプリケーションがあるけど、
> 何らかの根拠で「不要なレジストリ」を判断できるなら、
出来ない。
後半の文章は、アプリケーションが作成、削除する場合の話をしているから
アプリケーションが使うレジストリの話に限定して問題ないはずだ。
アプリケーションが使うレジストリは、使い方は自由。
例えば設定一つであっても、アンインストール時に、
再インストールするときに備えて設定を残すという選択も考えられるし、
完全に削除するという選択も考えられる。
だから、不要なレジストリと判断するのは不可能。
75:名無し~3.EXE
08/09/22 17:24:48 JGaE5+tQ
>>70
> ユーザー設定とインストール情報などを明確に分けておけば
ユーザー設定とインストール情報は明確に分かれている。XPの場合、
ユーザー設定は、C:\Documents and Settings\ユーザー名\NTUSER.DAT の中に
インストール情報はC:\WINDOWS\system32\config\SOFTWARE というファイルの中に
分かれて保存されている。
わざわざレジストリではなく、ファイル名を書いた理由は
レジストリと書いてしまうと、一つのファイルだと思ってしまうから。
ちゃんとファイルからして分かれて保存されているんだよ。
76:名無し~3.EXE
08/09/22 17:37:01 JGaE5+tQ
レジストリクリーナーの話が出たのでついでに説明しておく。
これは危険なプログラムだ。気軽に使っている人もいるようだが
動作をちゃんと知っておかなければ、不具合の元になる。
危険なプログラムであるからOSに付属するべきものではない系のソフトだ。
たとえ付属していたとしてもレジストリエディタ同様
パワーユーザーが理解して使うものだ。
レジストリクリーナーの基本は 設定情報に無効なファイル名が
指定されていた場合にその設定を削除するという動作だ。
つまり、shell="C:\Program Files\ABC\common.dll" などという指定が
レジストリに書いてありこのファイルが存在しない場合にそれ関連の
キーを削除するという動作を行っている。
さて、もしshell="D:\ABC\common.dll" とかかれていたらどうなる？
Dドライブはリムーバブルドライブ。一時的にHDDをはずしていた。
そうするとファイルが存在しない為にキーを削除してしまう。
後からDドライブをつけてもキーは消されている。
このように、安全に消せるかどうかは、最終的には人間が判断するしかない。
そしてそれは詳しい人で無いと判断が難しい。決して自動で簡単に行える処理ではない。
77:名無し~3.EXE
08/09/22 17:45:11 JGaE5+tQ
> ユーザー設定を残したままインストールし直すようなことも可能になる。
ユーザー設定を残したままインストールし直すことが可能。
これはつまり、アンインストールしてもユーザー設定が残るということ。
しかし、これをやると、アンインストールしてもゴミが残ると文句を言う。
わがままだよねｗ
78:名無し~3.EXE
08/09/22 18:18:43 RJwrGdOe
なんだ。きちがいのオナヌーカ。
たしかにおれのヴぃすたはレジストリ最適化しても変わらなかった。
79:名無し~3.EXE
08/09/22 18:58:40 JGaE5+tQ
レジストリ最適化なんかで変わるわけ無いんだよ。
「レジストリ肥大化で重くなった」とよく言っている奴がいるがぜんぜん違う。
重くなる理屈はこう。
１．ソフトウェアインストール
２．OSの起動時やエクスプローラやその他のアプリ起動時に
インストールしたソフトウェアが起動。
（プラグインの形で右クリックメニューなどを拡張するようなものを含む）
３．いつもより余計にソフトウェアが起動している分重くなる。
重くなる理屈はここまで。
レジストリ？ 自動起動するための設定場所がレジストリにあれば
そりゃレジストリに書き込むでしょ。それだけの話。
80:名無し~3.EXE
08/09/22 18:58:50 PLJiNmDM
>>68
そうではない
前者はファイルシステム上での話
後者はデータエントリレベルでの話
ファイルとしては破損していなくても、振る舞いの悪いアプリのインストーラ等によって
データエントリの特定箇所に異常が生じる場合がある、という趣旨の話だから全く別
これ自体は別にレジストリに限った話でどの管理方式でも当然起きてることだが、
>>58のとおりで影響範囲が違う
ファイルレベルで分けてると言ってもたったの２つだから分けたうちに入らない
81:名無し~3.EXE
08/09/22 19:02:41 JGaE5+tQ
>>80
> ファイルとしては破損していなくても、振る舞いの悪いアプリのインストーラ等によって
> データエントリの特定箇所に異常が生じる場合がある、という趣旨の話だから全く別
それがどういう理屈で、どういう状態になって異常が起きるか
具体的に説明できる？
82:名無し~3.EXE
08/09/22 19:04:36 JGaE5+tQ
振る舞いの悪いアプリケーションが、本来消してはいけない
設定レジストリキーを間違って消したとか、そういう話なら、
振る舞いの悪いアプリケーションが、本来消してはいけない
設定ファイルを間違って消すのと何の代わりも無い。
83:名無し~3.EXE
08/09/22 19:10:22 JGaE5+tQ
> >>58のとおりで影響範囲が違う
> ファイルレベルで分けてると言ってもたったの２つだから分けたうちに入らない
影響範囲の話にするのなら、じゃあこういう話をしよう。
レジストリはやめだ。今度からNTUSER.DATに保存していた情報全てを
NTUSER.INIに書き込むようにする。
これで影響範囲の問題は解決かね？
84:名無し~3.EXE
08/09/22 19:38:20 zMJObued
どんなに柔軟に設定が出来たとしても、項目が多すぎで手の付けようが無いんじゃ本末転倒
85:名無し~3.EXE
08/09/22 19:42:22 UfYReAPj
レジストリの所為にされてる事象の殆どは、WindowsがシェルとIEの
カスタマイズを一切拒否すれば解決するだろ。
86:名無し~3.EXE
08/09/22 19:58:08 hpTXE3E0
1.NTFSファイルシステムレベルで壊れる
2.レジストリの構造が壊れる(NTUSER.DATのバイナリレイアウトが壊れる)
3.愚かなアプリケーションの誤書き換えにより、設定が壊れる
はっきりいって現在ではどれもかなりのレアケースだろ。
レジストリ批判派はいまだに98でも使ってるのだろうか。
87:80
08/09/22 20:17:01 PLJiNmDM
>>81-82
こちらで
＞これ自体は別にレジストリに限った話で（なく）どの管理方式でも当然起きてること
と書いてるのだからそちらの指摘を受けるまでもないこと
括弧内抜けていたので訂正
>>83
全くかみ合っていないんだが
設定のファイルシステム上での細分化の話をしてるのだからその例えには全く意味がない
例えば問題の有るアプリhogeが有ったとして、それがhoge.iniなり.hogercなりhoge.plistを
各システム上で作るとすれば、そのアプリを実行するまでそれらは読み込まれることが無いし、
設定に起因する問題が起きてもそれらのファイルを削除するだけで解決する
断っておくけどレジストリの様な一元管理方式を全否定してる訳ではないから誤解なきよう願う
最初から一長一短だと書いてる
88:名無し~3.EXE
08/09/22 20:20:15 ChpnzRb9
「レジストリ」という単語がゲシュタルト崩壊起こしている
89:名無し~3.EXE
08/09/22 20:32:10 OJ14GPrc
例えば問題の有るアプリhogeが有ったとして、それがレジストリのキーhogeなり
各システム上で作るとすれば、そのアプリを実行するまでそれらは読み込まれることが無いし、
設定に起因する問題が起きてもそれらのキーを削除するだけで解決する
90:名無し~3.EXE
08/09/22 20:34:29 hpTXE3E0
>>87
＞例えば問題の有るアプリhogeが有ったとして、それがhoge.iniなり.hogercなりhoge.plistを
＞各システム上で作るとすれば、そのアプリを実行するまでそれらは読み込まれることが無いし、
＞設定に起因する問題が起きてもそれらのファイルを削除するだけで解決する
そういう簡単すぎる話に絞ればファイルが有利になるのは当然。
現実世界で問題になるのは、わかりやすい例だとプラグイン。
プラグインのインストーラは、プラグインのホストの設定ファイルに書き込みを行わなければいけない。
アンインストーラはそれを適切に削除しなければならない。
プラグインが設定に起因する問題を引き起こしたとき、ホストの設定ファイルを全部削除するわけにはいかない。
こういうシナリオだと、統一されたAPI、高い信頼性で読み書きができる事は大事。
実際、プラグイン中心のアーキテクチャであるFirefoxはレジストリモドキをもっている。
91:名無し~3.EXE
08/09/22 20:34:50 Q8ffxTuV
今必要なのはベンダーに、アプリが使用するレジストリエントリ一覧の添付義務を課すことだな。
Windows認定ロゴマーク取得の要件に含めればいい。
そしてM$荷は、ゾンビ化したレジストリを削除するオーディットユーティリティの添付義務。
92:名無し~3.EXE
08/09/22 20:52:15 PLJiNmDM
>>89
>ID: OJ14GPrc
君はどこまで話を噛み合なくさせれば気が済むのか
全くこちらの挙げたメリット／デメリットの意味を理解していないでしょ
一元管理でなければ基本的にアプリAの設定に起因する問題は
アプリAだけで閉じるのに対してレジストリの場合そうではない
この件に関しては既に君の得意な「等価な置き換え」は既に崩れているよという話だよ
勿論他の部分では一元管理の方が優れてることも有る、ただそれだけの話
いい加減分からないかな
>>90
ごく分かり易い形で、一元管理方式と分散管理方式の
それぞれのメリットデメリットを挙げただけだから
93:名無し~3.EXE
08/09/22 20:53:42 PLJiNmDM
あ、悪い
ID:OJ14GPrcは別の人か
間違えたスマヌ
94:名無し~3.EXE
08/09/22 21:01:25 OJ14GPrc
> 一元管理でなければ基本的にアプリAの設定に起因する問題は
> アプリAだけで閉じるのに対してレジストリの場合そうではない
なぜ、ファイル方式なら、アプリAだけで閉じて、
レジストリ方式なら、アプリAだけで閉じることはない。と言い切るの？
そんなの、アプリと設定内容しだいだろう。
95:名無し~3.EXE
08/09/22 21:02:30 hpTXE3E0
あと、Windowsではアプリケーションのインストール場所に自由度があるから
ファイルシステム非依存のストレージに設定を置けるとアプリ間連携に便利という側面もある。
どこにインストールされたかわからなければ設定ファイルを探しようもない。
96:名無し~3.EXE
08/09/22 21:07:15 OJ14GPrc
「レジストリの場合は、アプリAだけで閉じない」というのなら、
アプリAだけで閉じない場合がどういう場合か具体的な例を挙げてよ。
それと同じことがファイル方式でもおきるって
絶対いえるから。
97:名無し~3.EXE
08/09/22 21:11:23 PLJiNmDM
>>94
話捉え間違えてるね、言ってることがこちらと違う
今までのところちゃんと読み直せば分かると思うよ
98:名無し~3.EXE
08/09/22 21:11:59 OJ14GPrc
>>97
具体例挙げてね。
99:名無し~3.EXE
08/09/22 21:18:44 dbBRDsPx
なんか小難しい議論になってるけど
「情報をアプリケーション毎にXMLファイルにしておく」
これよりレジストリ管理が優れてる事ってなんなの？
100:名無し~3.EXE
08/09/22 21:22:29 OJ14GPrc
>>99
XMLだと肥大化するｗ
バイナリとタグ付きテキストを比較すれば明らか。
101:名無し~3.EXE
08/09/22 21:25:52 hpTXE3E0
>>99
・ディスクのフットプリント。XMLはかなり冗長。*.iniよりも悪い。
レジストリのHiveは、*.iniの1/6ぐらいにはサイズを圧縮できている。
・レジストリにはリンク機能がある。XLinkはあまりつかわれていないね。
・レジストリは環境変数の展開機能がデフォルトで備わっている。
こんなとこかな。まぁデメリットもある。
102:名無し~3.EXE
08/09/22 21:40:03 PLJiNmDM
>>96
そりゃ当然反論可能だろよ、元々>>94ほどに断定したことはこちらは言ってないのだから
俺の過去の経験例で良いの？
ほかの人も言っていたように、最近の話じゃないよ
以前CANVAS６をWin2kSP4に入れたらシステム全体が正常に立ち上がらなくなった
原因はアプリベンダー側ではなく単に非対応に気がつかず入れてしまっただけだったのセルフミス
調べた結果セーフモード起動でレジストリの特定のKEY項目を弄ることで復旧した
大分前だから細かな部分がおかしいかもしれないが大体そんな感じ
んで他のプラットフォームだと一般的なアプリに関する「設定」そのもので
ここまで大きな影響が出ることはまず経験していない
前にも書いた通りで普通はそのアプリが立ち上がらないだけで
システム全体の動作にまで深く影響を及ぼすことは実際かなり稀
（ドライバやライブラリなどに伴って起こる問題は別）
「原理的に絶対起きない」とか「問題を起こすアプリは存在しない」とか
断言してる様な話じゃないよ、ごく一般的な傾向の話な
それに今では当然当時とは状況も変わって来てる
103:名無し~3.EXE
08/09/22 21:49:24 hpTXE3E0
>>102
つまりはそのCANVAS6とやらが、
システムに重大な影響を与える設定を書き換える必要があったわけね。
そうであれば、その設定がiniファイルだろうがなんだろうがインストーラはそれを書き換えにいっただろうし
結果クラッシュしたんじゃないの。
この体験談で何を伝えたいのかよくわからない。
104:102
08/09/22 21:50:27 PLJiNmDM
記憶違いだったので訂正
誤：システム全体が正常に立ち上がらなくなった
正：「アプリケーションの追加と削除」のコントロールパネルが破壊される
105:名無し~3.EXE
08/09/22 22:00:35 PLJiNmDM
>>103
（広い範囲で影響を与える可能性についての）具体例を書けと言われたから
物凄いピンポイントになるが経験したことを書いただけだが
言われてみればその通りでは有るな＞結果が一緒かもという点
ただ元の話に戻るが、一元管理か分散管理かの比較での一般的な傾向として
こちらの言ってることがそんなに間違ってるか？
元々はID:JGaE5+tQの意見がかなり偏ってると思ったのでそれを指摘してたけなんだが
106:名無し~3.EXE
08/09/22 22:08:35 PLJiNmDM
あ、俺レス関係のIDを取り違えてるな
元々ID:OJ14GPrcと話してたのか
>>93は取り消しで>>105も最後の行は間違い
ぐだぐだになっちまったから取り敢えず消えるわ、済まん
107:名無し~3.EXE
08/09/22 22:11:03 6R5ZvqH5
＿＿＿＿＿＿
／ ）））
/ ／// /――-ミ
/ 彡彡 // / ヽ)）
/ 彡彡 iiiiiiiiiiiiiii iiiiiiiiii|
/ 彡彡 ＜ ･ > 、<･ >l
/ | ヽ 〉
/ （ | | ＿＿) | ／￣￣￣￣￣￣￣￣￣
/ | ≡ ／, ―― |ゝ ＜ 馬鹿にレジストリを触らせるな
/ | | L ＿＿_」 l ヾ ＼＿＿＿＿＿＿＿＿＿
＿ミ ｌ ＿＿＿＿＿_ﾉ ゞ＿
| l ヾ ー ／ | ｌ
| | ＼ｰ ‐／ | |
108:名無し~3.EXE
08/09/22 22:16:09 /slNidle
ん～本当の中に嘘がちょっと混じってるのが一番タチが悪いって典型的な例だなw
レジストリが肥大化するとパフォーマンスが落ちるというのは本当でもあり嘘でもある。
Windows XPのSP1あたりまではレジストリのキャッシュをWindows全体が
共有する作業エリア(名前忘れたw)に確保していた。
だからレジストリによってそのエリアが食い散らかされると、他のデータがメモリから
追い出されるので結果的にWindows全体が遅くなる。
MicrosoftはXP SP2でこれを変更し、レジストリのキャッシュをOSの他の一般の作業エリアから分離した。
だからSP2以降はさほどレジストリが肥大化してもシステムのパフォーマンスに影響しない。
109:名無し~3.EXE
08/09/22 22:16:32 hpTXE3E0
>>105
率直に言って
HKEY_LOCAL_MACHINE\SOFTWARE\アプリA
直下を編集したり消したりする事と、
C:\Program Files\アプリA\アプリA.config
を編集したり消したりする事に、
どんな本質的な違いがあるのかわからん。そんなの無いでしょ。
一元管理と分散管理の違いすら無い。
なぜなら、システムはHKEY_LOCAL_MACHINE\SOFTWARE\アプリA以下を管理しないから。
保存場所を提供しているだけで管理ではない。違う？
HKEY_LOCAL_MACHINE\SOFTWARE\アプリA 以下を管理、すなわち読み書きするのは
実際のところはアプリAだけ。
110:名無し~3.EXE
08/09/22 22:20:18 Iuk5dY05
>>103
原理的には同じかもしれないけど、実際の頻度が違うって言ってるんだと思うよ。
その手の障害は最終的には、アプリのプログラマーのせいなのかもしれないけど、
そう言う余計な負担をかけたＭＳとレジストリの罪は結構大きいと思う。
111:名無し~3.EXE
08/09/22 22:20:22 PLJiNmDM
>>109
だからさ
それはアプリAからレジストリへの読み書きが正しく行われることが大前提でしょ
そうでない場合に起きうる問題について語ってたんじゃないのか
112:名無し~3.EXE
08/09/22 22:21:09 hpTXE3E0
で、ロジカルなレイヤーで違いがないのであればフィジカルなレイヤーの違いが問題になるんだが、
フィジカルを語れるほど我々はレジストリの内部構造に詳しくないと思うのだけど。
たとえば、ユーザーのレジストリファイルはNTUSER.DAT以外にも存在する。知らなかったでしょ。
レジストリエディタの見せる一枚岩のイメージに騙されているだけなんじゃないかと。
ユーザー設定が複数ファイルに分かれているのであれば、システム設定は何ファイルかわからないよ。
実際は余分なデータなんて大して読み込んでないんじゃないの、と。
113:名無し~3.EXE
08/09/22 22:23:48 hpTXE3E0
>>111
だから俺は>>86で現象を整理したかったんだけど。
>>102の例は、>>86でいうところの2か3かでいうと、3の話をしてたでしょ。
レジストリの特定のKEYを弄ることで復旧できたのであれば、
レジストリは壊れてないよ。だから2ではない。
114:名無し~3.EXE
08/09/22 22:26:26 /slNidle
レジストリとiniファイルとどちらがパフォーマンスが高いかという話は、
結局データベースのパフォーマンスの問題と同じ。
データベースとファイルシステムというのはある意味同じことを
2重にやっているようなものだから、無駄ではある。
データベースのパフォーマンスを極限まで追求していけば、
ファイルシステムなしにデータベースがHDDを直叩きする形式になる。
実際そういうデータベースもあるわけだし、
ポシャったWinFSもファイルシステムとデータベースを統合するという発想から来ている。
実際ファイルシステムの上にデータベースを構築するのは二度手間で
非効率以外の何者でもない。むしろ「レジストリパーティション」みたいなものを作って、
そこにレジストリデータベースを格納すれば効率はよくなる。が、扱い憎いだろうねw
せいぜいページファイルみたいにNTFSの中で固定の領域を確保するとか。
115:名無し~3.EXE
08/09/22 22:32:44 /slNidle
で、レジストリvs iniファイルの問題は、結局はデータベースを全体で1個持つか、
アプリごとに分散させて持つかという問題に帰結する。
前述のようにファイルシステムが存在しない純粋なデータベースならこの問題は
そもそも存在しない。ファイルシステム上にレジストリデータベースが構築されているから、
データベースのファイルをアプリごとに持つか、Windows全体(やユーザ毎)に持つかという
問題が生まれる。
で、その前提なら、そりゃアプリ毎に持った方がデータのアクセス範囲が局在化されるんだから、
アプリ毎に持った方がアプリのパフォーマンスは多少良くなるだろう。
ただ、なぜWindowsがそういう形態をとっていないのか？といえば、
それは他のアプリやシステムをフックするアプリがあるからだろう。
つまり他のアプリのレジストリを書き換えて使用するアプリの存在がある。
こうなると話は違ってきて、全体でレジストリを一元管理した方が便利ともいえる。
116:名無し~3.EXE
08/09/22 22:44:39 QsJYlC0q
regコマンドぐらい覚えろ、カスini厨共。
117:名無し~3.EXE
08/09/22 22:51:07 hpTXE3E0
>>110
その余計な負担って何？
レジストリAPIは特別に複雑なんですという主張?
これもよくわからない。
118:名無し~3.EXE
08/09/22 23:09:27 PLJiNmDM
>>113
だから>>102はあくまで一例、それが>>８６の3なのは当然分かっているよ
でも一般的な話では1－3（+α）まで全ての可能性があるのだから、
その例を前提に>>105以降の話を続けないでくれないか
下にも挙がっている様な様々な理由で実際に壊れる可能性は常に有って、
そのうちのいくつかはファイルシステム上で分散している方が有利なものもある
URLﾘﾝｸ(support.microsoft.com)
119:名無し~3.EXE
08/09/22 23:35:05 hpTXE3E0
全ての可能性なんて言ってたらまとまる議論もまとまらんｗ
120:名無し~3.EXE
08/09/22 23:40:34 PLJiNmDM
こちらが元々言ってたのはそちらが
＞そういう簡単すぎる話に絞ればファイルが有利になるのは当然
みたいにさらっと流したような程度のことだったからね
121:名無し~3.EXE
08/09/23 00:26:48 PoDzwV0j
レジストリにHangameを発見した
やった記憶ないのに
122:名無し~3.EXE
08/09/23 00:38:07 DMbPzsAc
>>117
レジストリアクセスのための API を「別に」覚えないとダメだろ。
テストデータ作るのも ini ファイルなら、使い慣れたエディタで
できるのに、わざわざ使いにくいレジストリエディタを使わないと
いけない。
さらに、ini ファイル編集してる時に、わざわざ他のファイル壊す
奴は単なる馬鹿だけど、レジストリエディタだと注意してても間違
えてシステムの設定を壊すことも「簡単に」できてしまう。
まあ、一つ一つはたいしたこと無いけど、集まるとそれなりに大変
なんだよ。
開発経験無いとわからんと思うが。
123:名無し~3.EXE
08/09/23 00:41:21 PoDzwV0j
Uniblue RegistryBooster 2009ってやつでレジストリ調べたら500近くの無駄が発見されて何かもうアレだ
124:名無し~3.EXE
08/09/23 06:32:22 wZC+gEJI
>>122
＞テストデータ作るのも ini ファイルなら、使い慣れたエディタで
＞できるのに、わざわざ使いにくいレジストリエディタを使わないと
＞いけない。
regファイルを作ってインポートでも regコマンドでもお好きなように。
レジストリエディタだけだと効率悪くて仕方ないだろ。
＞さらに、ini ファイル編集してる時に、わざわざ他のファイル壊す
＞奴は単なる馬鹿だけど、レジストリエディタだと注意してても間違
＞えてシステムの設定を壊すことも「簡単に」できてしまう。
注意してても HKLM\SOFTWARE\自アプリ 以外のキーを開いちゃいますってか。
眼科いったほうがいいんじゃない。
開発経験ほんとにあるのか?
125:名無し~3.EXE
08/09/23 06:40:06 keX6LEbo
どちらかというと>>122に一票かな
理由：気が楽
126:名無し~3.EXE
08/09/23 06:48:33 wZC+gEJI
>>125
別にレジストリの使用を無理にすすめてるわけじゃないよ。俺もファイルの方が好きだ。
ただ「レジストリを使うとシステムを壊しやすい」という主張に反論してるだけ。
127:名無し~3.EXE
08/09/23 07:08:12 DMbPzsAc
>>124
> regファイルを作ってインポートでも regコマンドでもお好きなように。
だから、「わざわざ」そんなことしないといけないのが面倒だって言ってるんだが。
インポートするだけって簡単に言うけど、毎回となると結構ウザイし色々ミスの要因
になる。
> 注意してても HKLM\SOFTWARE\自アプリ 以外のキーを開いちゃいますってか。
そうだよ。クリックするだけで開けちゃうからな。
>>122 に
>> まあ、一つ一つはたいしたこと無いけど、集まるとそれなりに大変なんだよ。
って書いたように、一回だけならいいんだけど、開発の現場だとそれこそ何十回～何
百回と繰返す羽目になる。そんな手間なんてたいしたこと無いとか、注意してればそ
んなことするわけないという奴は、実務の開発経験が無い奴だと思う。
128:名無し~3.EXE
08/09/23 07:22:55 wZC+gEJI
>>127
＞そうだよ。クリックするだけで開けちゃうからな。
開くだけじゃ値は変わらない。編集するまでに気づけないならやっぱり眼科。
＞一回だけならいいんだけど、開発の現場だとそれこそ何十回～何
＞百回と繰返す羽目になる。そんな手間なんてたいしたこと無いとか、注意してればそ
＞んなことするわけないという奴は、実務の開発経験が無い奴だと思う。
だから自動化するための方法を書いてるんじゃないか。
一度regファイルを作れば
reg import 作ったファイル.reg
これで終わり。
一度元になるregファイルを作ったらマクロなりスクリプトなりで
全テストケース分のregファイルを作って、
あとはバッチ化して叩くもよし。単体テストに組み込むもよし。
何百回もレジストリエディタ開くのが実務の開発経験だっていうんならそんな経験はいらん。
129:名無し~3.EXE
08/09/23 07:48:59 DMbPzsAc
>>128
> 開くだけじゃ値は変わらない。編集するまでに気づけないならやっぱり眼科。
間違いに気付かずに開いてるんだから、そのまま編集しちゃうぐらいわかるかと
思っていたんだが...。
> 何百回もレジストリエディタ開くのが実務の開発経験だっていうんならそんな
> 経験はいらん。
残念なことにテストでは、レジストリの値を確認する必要もあるんだな。
何回もやるようなテストだと、スクリプト書いてチェックするけど、バグの調査
とかで随時の確認が必要な時が面倒なんだよ。
わざわざエクスポートしてエディタで確認するってか？ (w
130:名無し~3.EXE
08/09/23 08:10:55 wZC+gEJI
>>129
＞間違いに気付かずに開いてるんだから、そのまま編集しちゃうぐらいわかるかと
＞思っていたんだが...。
編集はレジストリエディタの右側のペインでやるだろ。
右側のペインをみて間違いに気付かないってのは、
保存する項目が全く一緒ぐらいじゃないとあり得ないぞ。
システムの設定を壊すには、システムとほぼ同じ保存項目を持つことになる。
そんなアプリあるかっての。
＞残念なことにテストでは、レジストリの値を確認する必要もあるんだな。
＞何回もやるようなテストだと、スクリプト書いてチェックするけど、バグの調査
＞とかで随時の確認が必要な時が面倒なんだよ
もうね、随時確認してる時点で…
テストケースを流した時点で、エラーがあれば
期待した値と実際の値を出力するようにしてるでしょう。。
わざわざ見に行くなんて驚き。それで品質コントロールできてる？
ユーザー環境で起きたのであれば、エクスポートバッチを送付して、
「出来たファイルを送ってください」が最速。
人のPCのレジストリエディタを開くのは互いに効率が悪い。
131:名無し~3.EXE
08/09/23 08:47:29 DMbPzsAc
>>130
> 保存する項目が全く一緒ぐらいじゃないとあり得ないぞ。
残念なことに人間そんなに注意深くない。
あり得ないと言われてることが本当に起きないなら、世の中の
事故はだいぶ減るよ。
> もうね、随時確認してる時点で…
「バグの調査で」って書いてあるのが見えてないのか？
どこで変な値を書いてるかを調査するために、ブレークかけながら
随時確認するなんて普通にやると思うけど、もっといい方法がある
のか？
# ユーザー環境の話はいらんよ。
# 話をそらしたいのかもしれないけど。
132:名無し~3.EXE
08/09/23 09:13:24 wZC+gEJI
＞どこで変な値を書いてるかを調査するために、ブレークかけながら
＞随時確認するなんて普通にやると思うけど
ブレークをかけながらの随時確認を
＞一回だけならいいんだけど、開発の現場だとそれこそ何十回～何
＞百回と繰返す羽目になる
のであれば、設計や開発フローを見直す事をお勧めする。いや、ほんとに。
テストも全部目視ベースみたいだし。
レジストリエディタがないと開発できないような環境を自分たちで作り上げているように見える。
＞# ユーザー環境の話はいらんよ。
＞# 話をそらしたいのかもしれないけど。
バグ調査でレジストリエディタなんてほとんど無用ということを言いたかったのでね。
蛇足とは思ったがバリエーションの一つとして出したまで。
133:名無し~3.EXE
08/09/23 09:14:38 F1rYwugh
>>130の言い分を検証してみた結果
>>131は注意が散漫か学習意欲がないのだと思った
Windowsのヘルプを開いて"reg"で検索すれば、regコマンドの利用方法出てる
regコマンドを使えば、バッチファイルで確認用のファイルを作ることが可能、エクスポートされたファイルの拡張子をregなり、txtにしたら確認は楽になる
拡張子.regのファイルは、ダブルクリックすればレジストリにインポートできる
確認や値の修正の為に、いちいちregeditを開く必要はない
>>130便利なコマンドを教えてくれてありがとう
134:名無し~3.EXE
08/09/23 09:26:30 wZC+gEJI
>>133
どういたしまして。
まぁ>>116が初出っぽいけどね。
135:名無し~3.EXE
08/09/23 10:13:34 C/zN2T0x
>>126
システムとアプリの両方が使うから更新する機会が増える分、壊れやすくなる。
システムが使ってるから壊れたらシステムを道連れにする。
誰かが書いてたけど、システムとアプリのファイルを別にすればマトモだったのに。
136:名無し~3.EXE
08/09/23 10:45:40 DMbPzsAc
>>132
> 設計や開発フローを見直す事をお勧めする。
> バグ調査でレジストリエディタなんてほとんど無用ということを言いたかったのでね。
で、具体的なやり方はどうするんだい？
まさかバグ作りこまないように注意するとか言うんじゃないよな？
> テストも全部目視ベースみたいだし。
>> 何回もやるようなテストだと、スクリプト書いてチェックするけど
って、書いてあるんだけど、君こそ眼科に行ったほうがいいんじゃね？ (w
>>133
> >>131は注意が散漫か学習意欲がないのだと思った
注意力はいざ知らず、今頃「>>130便利なコマンドを教えてくれてありがとう」って言っ
てる奴に学習意欲が無いって言われてもなぁ...。
> エクスポートされたファイルの拡張子をregなり、txtにしたら確認は楽になる
> 拡張子.regのファイルは、ダブルクリックすればレジストリにインポートできる
ini ならそんなことする必要が無いんだよ。
ID:wZC+gEJI も、レジストリの扱い方を一生懸命説明してるけど、「簡単にできる」
ことと「しなくていいこと」のどっちが楽かよ～く考えて見ればいいのに。
# まあ、でかいソフトの開発経験が無いとわからんのかも知れんな。
137:名無し~3.EXE
08/09/23 11:25:07 F1rYwugh
>>136
"プログラマ"なら
バッチファイルぐらいは、使いこなそうよ
手間を掛けたくないなら、エクスポートしたファイルをメモ帳で開くまでバッチで出来るし
どうしても面倒なら、インポートまで一つのバッチで終わらす事だって可能でしょ
でもって、ちゃんとしたバッチファイルを1度作れば、何度使おうと失敗はないじゃん
大規模なソフト開発の経験があるなら、バッチファイルの作成ぐらい片手間だし
「しなくていいこと」が云々言うほどの事でもないじゃん
オイラみたいな日曜プログラマでも、その程度のバッチなら4行程度で作れると思うよ
138:名無し~3.EXE
08/09/23 11:43:42 wZC+gEJI
>>136
＞で、具体的なやり方はどうするんだい？
＞まさかバグ作りこまないように注意するとか言うんじゃないよな？
モジュールの依存関係を整理して
単体テストをカッチリやる。常識だよね？
網羅的な単体テストを自動化しておけばデバッガの出番なんてほとんど無いよ。
xUnitのレッドを捕まえるだけで異常個所は明瞭なんだから。
>> 何回もやるようなテストだと、スクリプト書いてチェックするけど
それがちゃんとできてないからレジストリエディタのお世話になっているんだろ。
自動化されたテストにレジストリエディタの出る幕は無い。
ワンクリックして10秒で数百コンディションテストするような環境でiniかレジストリかなんて関係ない。
それなのに
＞インポートするだけって簡単に言うけど、毎回となると結構ウザイし色々ミスの要因になる。
＞一回だけならいいんだけど、開発の現場だとそれこそ何十回～何
＞百回と繰返す羽目になる。
という発言から見るになんどもなんどもレジストリエディタのお世話になってるらしい。
スクリプトに一体何を書いているのか疑問だが。
139:名無し~3.EXE
08/09/23 11:51:39 wZC+gEJI
>>136
＞# まあ、でかいソフトの開発経験が無いとわからんのかも知れんな。
でかいソフトの開発をしているのであれば、
ヒューマンエラーが起きやすい手順・ツールは必ず排除される。
なぜなら一人のミスで数十人の作業が止まることがあるから。
レジストリエディタでヒューマンエラーが起きやすいのであれば、
普段の作業はレジストリエディタを使用せずともいいように何らかのツールをつくり、
どうしてもレジストリエディタが必要なときだけ、注意深く行う、という流れになるだろう。
それなのに
＞残念なことに人間そんなに注意深くない。
＞あり得ないと言われてることが本当に起きないなら、世の中の
＞事故はだいぶ減るよ。
いわゆるあり得ないレベルのミスが起こるという。
それを許容するのも結局
＞一回だけならいいんだけど、開発の現場だとそれこそ何十回～何
＞百回と繰返す羽目になる。
これのせいなんだろうけど。スクリプトに一体何を書いてｗ
140:名無し~3.EXE
08/09/23 12:05:52 8/i6ME+4
なに？テストの話をしているの？
テストってのは条件をいろいろ変えて
処理を実行するもの。
レジストリだったらキーの値をいろいろ変えて、インポートしてテスト。これがめんどくさい？
でもに、iniでも設定を変えて、適切な名前に変えて（これがインポートに相当する）テスト。たいして違いはないのだよ。
141:名無し~3.EXE
08/09/23 12:08:01 8/i6ME+4
>>122
> レジストリアクセスのための API を「別に」覚えないとダメだろ。
iniをアクセスするためのAPIも覚えないとだめだよ。
XMLをアクセスするためのAPIも覚えないとだめだよ。
142:名無し~3.EXE
08/09/23 12:18:46 8/i6ME+4
>>136
> ini ならそんなことする必要が無いんだよ。
そうかな？
エクスプローラを起動して
C:\Documents and Settings\ユーザー名・・・あなたのユーザー名ですよ。知りませんか？
のところでiniファイルってユーザーごとに設定ファイルは違うから
ユーザーフォルダだとして、その以下のどこにあるんだ？
を添付してというの。結構大変なことだぞｗ
143:名無し~3.EXE
08/09/23 13:12:21 DMbPzsAc
>>137
日曜プログラマが言いそうなことですな。
最初に書いただろ？
>> まあ、一つ一つはたいしたこと無いけど、集まるとそれなりに大変なんだよ。
日曜プログラマならバッチファイルは書けば終わるんだろうけど、職業プログラマは
そのバッチにものドキュメント書いて一緒に管理しないと保守できなくなるから、
１つでも減らしたいと思うのは当然。
>>138-139
テストとデバッグの話の区別がついてないのか...。
眼科の次は、精神科か小学校にでも行った方がいいぞ。(w
144:名無し~3.EXE
08/09/23 13:21:54 wZC+gEJI
>>143
バグとは仕様を満たさない(ゆえに必ずテストを通らない)コードのことを指す。
デバッグとはバグの箇所を突き止め除去すること。
コードベース全体がよくテストされていてバグの箇所が最初から絞られていれば
デバッガを起動するまでもなく、素早くデバッグできるんだよ。
デバッガを起動することがデバッグではない。
テストとデバッグ効率は密接に関係している。
145:名無し~3.EXE
08/09/23 13:22:29 DMbPzsAc
>>140
> たいして違いはないのだよ。
何回も言ってるけど、一回一回はたいして違わないよ。
だから
>>142
ねえ、一体何の話してるの？ >>136 のレスは...
>> エクスポートされたファイルの拡張子をregなり、txtにしたら確認は楽になる
>> 拡張子.regのファイルは、ダブルクリックすればレジストリにインポートできる
で、ユーザーがどうのこうのなんて言ってないんだけど...。
ついでに、「～を添付して」が面倒なら >>130 によるとバッチファイルを送れば
いいらしいよ。(w
146:名無し~3.EXE
08/09/23 13:29:45 +R45Ppzd
良スレなのに、もういい加減「壊れやすい」なんて本質的ではない問題はやめてほすぃ。
147:名無し~3.EXE
08/09/23 13:32:27 DMbPzsAc
>>144
> バグの箇所が最初から絞られていれば
こんな馬鹿な仮定を立てられてもな。
でかいソフトの製品事故なんか経験したこと無いだろ？
まあ、そう言う幸福な環境を否定するわけじゃないよ。
ただ、2Mstep を越えるソースの中には、10年以上前のコードだって現実にある
んだから、理想論を振りかざされてもはあそうですかとしか言えないよ。
# 理想論は言いすぎか、「小規模開発とは違うんだよ」ぐらいにしとくかな。
148:名無し~3.EXE
08/09/23 13:43:05 F1rYwugh
>>143
regコマンドを知っていて、ドキュメントを書かないと管理できないようなプロジェクトに何度も関わるような会社であれば
おいらの言うようなバッチファイルなど、既にドキュメントの揃った状態でツール化されているのではないのでしょうか?
大規模開発云々と言う理由で、テスト&保守ツールの作成に無頓着ってのは
如何にサボって残業代を稼ごうかと考えている駄目社員の口上だと思うのですが
149:名無し~3.EXE
08/09/23 13:51:29 A4mqX0XU
iniファイルはアクセス方法を一元化できない。
各種プログラミング言語処理系のライブラリで、まちまちの方法で
読み書きができてしまい、非スレッドセーフ、非プロセスセーフでの
アクセスを許してしまう。
レジストリ方式はセマフォを搭載でこの問題を解決。
150:名無し~3.EXE
08/09/23 13:59:33 8/i6ME+4
>>149
それはあるね。
レジストリだと、OSがファイルをロックしているから
OS経由じゃないと書き込めない。
それに対してiniやXMLだと普通のテキストエディタから
書き込めることからもわかるように、ファイルがロックされていない。
複数のプロセス（特に質の悪いプロセス）が同時に
書き込んだりすると、iniやXMLは壊れやすい。
151:名無し~3.EXE
08/09/23 14:35:54 wZC+gEJI
>>147
でかい開発、大規模開発という割にはスケールしない作業方法だけ述べてるね…
>>148は正論だよ。
レジストリとiniの差も満足に埋めれない作業方法が大規模流だと信じるならば
いつまでも人海戦術で頑張ってくれとしか言えない。
152:名無し~3.EXE
08/09/23 15:05:38 FDUFKxHn
設定ファイルの話してた筈なのに、自称SE同士の煽り合いになってるな。
153:名無し~3.EXE
08/09/23 15:11:21 9NhQkWAd
>>146
壊れやすいか？という問題なら、データベースとしてレジストリの完成度を見るべきだろうね。
たとえばデータベースの場合不慮の事故によって更新が中途半端になることを防ぐために
アトミックトランザクション機能がなければ一人前のデータベースとはいえない。
処理が途中で中断して変更が中途半端に終わったときは、変更される以前の状態まで戻す機能。
レジストリにはこの機能がない(と思う、恐らく)。
まあ、レジストリはWindowsの起動毎にバックアップが取られるから、
ある程度それが代用になっているのだろうけれど。
154:名無し~3.EXE
08/09/23 15:20:29 9NhQkWAd
あと、IEのブックマークの順序とかもレジストリに書き込まれる。
ブックマーク自体は一つ一つがファイルだが、
IEのブックマーク一覧で表示される順序(ユーザが編集できる)はレジストリが記憶している。
ここまでレジストリに入れるのが適切なのか？と思う。
155:名無し~3.EXE
08/09/23 16:06:03 DMbPzsAc
>>148
> おいらの言うようなバッチファイルなど、既にドキュメントの揃った状態で
> ツール化されているのではないのでしょうか?
当然してるよ。してないなんて誰も書いてないと思うけど。
書いてないものが見えるんなら、眼科すっとぱして精神科にかかった方がいいよ。(w
>>151
> レジストリとiniの差も満足に埋めれない作業方法
ねえ、誰が埋めれないって書いてるの？
なんか書いてないものが見える人が多いなぁ。(w
あくまでも、「バッチファイルの管理」とか「差を埋める」のが面倒だって書いてる
だけ。
そもそも発端は、>>117 の「その余計な負担って何？」から始まっててて、その負担
の説明してるのに、一生懸命「テストで頑張れ」ってちょっと頭に血が上りすぎだと
思うよ。
>>149
まあ、そう言うメリットはあるし、他にも色々メリットはある。
ただ、なんでもかんでもレジストリのメリットの方がデメリットを上回るわけじゃない
と言うだけのこと。
156:名無し~3.EXE
08/09/23 16:25:13 odqR9sts
何をいまさらと覗いてみたら、的外れな話してんなｗ
Windowsにおけるシステムレジストリという仕組み、という意味で見た場合の根本的な問題点は、
OS標準の機能によるファイル操作によって、レジストリ上で指定されたシステムファイルの実体を
簡単に変更・移動・削除できてしまうため、簡単に破綻した状態が発生することにある点だ。
DLLヘル問題とかファイルコピーツールに毛が生えただけのような標準インストーラとかのもっと
最低な仕組みに足引っ張られてる感が強いが、根本的にシステムファイルをあんなに簡単に
いぢれるような中途半端な仕組みにしたMSがクソとしか言いようがない。
こういう視点で見れば、VistaのUACはいまさらではあるが評価できる。あれくらいウザければ、
アプリ側も無駄にシステムファイルをいぢろうとはしなくなり、システムファイルとアプリとの住み
分けも進むだろうからな。
まあVista対応とか言っといてマニュアルにUACを切れとか平気で書いてるアプリの作者は
死ねばいいよ。まあVistaもVistaで、証明書だっけかのないデバドラは禁止とか言ってくるのが
クソなのは同意だけど。
157:名無し~3.EXE
08/09/23 16:33:28 F1rYwugh
>>155
なあ、>>122で言ってることと変わってない?
>>122を見る限りレジストリを直接regeditで編集しているとしか見えないんだが...
そして、関係ないレジストリキーを破壊してると書いてるんだが?
俺の目が悪いのか?
158:名無し~3.EXE
08/09/23 17:25:27 DMbPzsAc
>>157
悪いのは目じゃなくて、その理解力の無い頭の方だと思う。
| >>129
| > バグの調査とかで随時の確認が必要な時が面倒なんだよ。
テストの話に限定してがってるのは ID:wZC+gEJI の方だから。
159:名無し~3.EXE
08/09/23 17:36:39 8/i6ME+4
>>156
お前が一番的外れだｗ
160:名無し~3.EXE
08/09/23 18:07:26 F1rYwugh
>>158
>>129を読んでも、然るべき処置をとらず、不用意にregeditでレジストリを開いてレジストリを破壊することを肯定しているようにしか見えない
regeditで直接レジストリを開いてレジストリの値を確認したいのだろうと言うのは分かるが
どっちみち内容を更新するには"F5"キーを押さなきゃ駄目なんだから、バッチファイルを一々ダブルクリックするのも同じことじゃん
また、テストの話に限定したがってると言っているが、最初にテストの話をしてたのは貴方の方でしょう?
それに対して、プログラマなんだからテストぐらい工夫しろと言われても、当たり前の事だと思います
大規模なプログラムを開発していると言うなら、「例えを間違えました」ぐらい言えばいいと思うのですが
レジストリをユーザーが直接編集しないと直らないPIO病の話が例であれば貴方が言いたいことも通るでしょうが
デバッグでレジストリを編集し間違えてレジストリを破壊したなどと言う例を上げられたら
「お 前 が 間 抜 け だ か ら だ」
としか言いようがないし、それをそうじゃないと言われても
「大 嘘 吐 き め、話 が 変 わ っ て る だ ろ う が」
としか言いようがない
どう贔屓目に見ても、開発者を名乗ってするような話ではないと思います
161:名無し~3.EXE
08/09/23 18:08:03 NgR8l7C7
デバッグでレジストリを編集し間違えてレジストリを破壊したなどと言う例を上げられたら
「お 前 が 間 抜 け だ か ら だ」デバッグでレジストリを編集し間違えてレジストリを破壊したなどと言う例を上げられたら
「お 前 が 間 抜 け だ か ら だ」デバッグでレジストリを編集し間違えてレジストリを破壊したなどと言う例を上げられたら
「お 前 が 間 抜 け だ か ら だ」デバッグでレジストリを編集し間違えてレジストリを破壊したなどと言う例を上げられたら
「お 前 が 間 抜 け だ か ら だ」デバッグでレジストリを編集し間違えてレジストリを破壊したなどと言う例を上げられたら
「お 前 が 間 抜 け だ か ら だ」デバッグでレジストリを編集し間違えてレジストリを破壊したなどと言う例を上げられたら
「お 前 が 間 抜 け だ か ら だ」デバッグでレジストリを編集し間違えてレジストリを破壊したなどと言う例を上げられたら
「お 前 が 間 抜 け だ か ら だ」デバッグでレジストリを編集し間違えてレジストリを破壊したなどと言う例を上げられたら
「お 前 が 間 抜 け だ か ら だ」デバッグでレジストリを編集し間違えてレジストリを破壊したなどと言う例を上げられたら
「お 前 が 間 抜 け だ か ら だ」デバッグでレジストリを編集し間違えてレジストリを破壊したなどと言う例を上げられたら
「お 前 が 間 抜 け だ か ら だ」
162:名無し~3.EXE
08/09/23 18:09:48 NgR8l7C7
デバッグでレジストリを編集し間違えてレジストリを破壊したなどと言う例を上げられたら
「お 前 が 間 抜 け だ か ら だ」デバッグでレジストリを編集し間違えてレジストリを破壊したなどと言う例を上げられたら
「お 前 が 間 抜 け だ か ら だ」デバッグでレジストリを編集し間違えてレジストリを破壊したなどと言う例を上げられたら
「お 前 が 間 抜 け だ か ら だ」デバッグでレジストリを編集し間違えてレジストリを破壊したなどと言う例を上げられたら
「お 前 が 間 抜 け だ か ら だ」デバッグでレジストリを編集し間違えてレジストリを破壊したなどと言う例を上げられたら
「お 前 が 間 抜 け だ か ら だ」デバッグでレジストリを編集し間違えてレジストリを破壊したなどと言う例を上げられたら
「お 前 が 間 抜 け だ か ら だ」デバッグでレジストリを編集し間違えてレジストリを破壊したなどと言う例を上げられたら
「お 前 が 間 抜 け だ か ら だ」デバッグでレジストリを編集し間違えてレジストリを破壊したなどと言う例を上げられたら
「お 前 が 間 抜 け だ か ら だ」デバッグでレジストリを編集し間違えてレジストリを破壊したなどと言う例を上げられたら
「お 前 が 間 抜 け だ か ら だ」デバッグでレジストリを編集し間違えてレジストリを破壊したなどと言う例を上げられたら
「お 前 が 間 抜 け だ か ら だ」
163:名無し~3.EXE
08/09/23 18:13:27 8/i6ME+4
デバッグでファイルを編集し間違えてファイルを破壊したなどと言う例を上げられたら
「お 前 が 間 抜 け だ か ら だ」
164:名無し~3.EXE
08/09/23 18:14:29 8/i6ME+4
ユーザーがシステムファイルを移動したらシステムを破壊したなどと言う例を上げられたら
「お 前 が 間 抜 け だ か ら だ」
165:名無し~3.EXE
08/09/23 18:15:34 8/i6ME+4
rm -rf / を実行してディスクがフォーマットされたなどと言う例を上げられたら
「お 前 が 間 抜 け だ か ら だ」
166:名無し~3.EXE
08/09/23 18:15:34 odqR9sts
>>159
スレタイ嫁ｗ
なんか喪前らはぐちゃぐちゃもめてるけどな、実際のところ、iniファイルだろうがレジストリ
データだろうが大差ねえんだよ。
論理的に中身が壊れちまう頻度とか、変更手順がアプリ作る奴次第だって時点でどっちにしろ同じ。
壊れた時に巻き込む範囲が違うとか言うのはレジストリという手段を使ったかどうかじゃなくて、
Windows のシステムレジストリの使い方がおかしいことが原因だ。
デバドラもアプリもごっちゃになって同じデータをいぢくってんだから壊れる時は全部巻き添え。
ここが全ての元凶なんだ。ちゃんと切り分けとけよって話なんだよ。
167:名無し~3.EXE
08/09/23 18:17:09 8/i6ME+4
>>166
お前こそよく読め。
システムファイルの実体を 簡単に変更・移動・削除できてしまうため、
簡単に破綻した状態が発生することにある点だ。
などということは、どのOSだって簡単にファイルぐらい移動できるだろうの一言で終わりだ。
168:名無し~3.EXE
08/09/23 18:20:24 PoDzwV0j
iniって削除するだけで設定完全初期化出来て便利だね
ユーザーがわは
169:名無し~3.EXE
08/09/23 18:26:26 NgR8l7C7
簡単になんてできないけど
パス要求され、コピー許可や削除許可が求められる
レジストリの場合は簡単に管理的に壊れる
単純化すんなボケ
170:名無し~3.EXE
08/09/23 18:26:31 8/i6ME+4
>>166
> デバドラもアプリもごっちゃになって同じデータをいぢくってんだから壊れる時は全部巻き添え。
> ここが全ての元凶なんだ。ちゃんと切り分けとけよって話なんだよ。
あと、壊れれば。なんて可能性の低い話してんなよ。
壊れねーだろうが？ 壊れねーだろ？
壊れれば。なんていえばHDDが壊れれば。なんて話できるだろうが。
171:名無し~3.EXE
08/09/23 18:28:11 8/i6ME+4
>>169
> 簡単になんてできないけど
> パス要求され、コピー許可や削除許可が求められる
はい。その答えを待っていた。
スレタイ嫁。レジストリの話じゃねーよ。それは。
ファイルアクセス権限の話だろうが。
Windowsでもユーザー権限で利用すればって反論もできるが、
それもすれ違いだなｗ
172:名無し~3.EXE
08/09/23 18:31:04 NgR8l7C7
こわれやすい
＞スレタイ嫁。レジストリの話じゃねーよ。それは。
＞ファイルアクセス権限の話だろうが。
ファイルアクセス権限を簡単に手に入れてしまえるレジストリの問題だろ
173:名無し~3.EXE
08/09/23 18:33:38 odqR9sts
>>167
ぶっちゃけおまえらはレジストリに夢見すぎなんだよ。
あれは*.iniをPG側が検索しやすいようにただバイナリにしただけのものでしかないんだ。
おかしいのはレジストリというデータ形式じゃなくて、Windows側のレジストリの利用方法なんだよ。
俺は、あんな使い方するならファイルシステムに絡めるなりして関連性を守らないとダメだつってんの。
ただini形式にしただけじゃ何も解決しないんだよ。
174:名無し~3.EXE
08/09/23 18:33:52 8/i6ME+4
>>172
> ファイルアクセス権限を簡単に手に入れてしまえるレジストリの問題だろ
はぁ？ お前がなんかのプログラムを起動したとして、
そのプログラムが設定ファイルを読み書きする。
そのときに毎回パスワード聞かれるか？ よく考えてみろ。
175:名無し~3.EXE
08/09/23 18:35:49 8/i6ME+4
>>173
だから、レジストリ＝設定ファイルの利用方法の話とかいうのなら、
すでにすれ違いだろうがｗ
レジストリ関係ねーよ。レジストリ使わなくても結局同じことなんだよ。
お前（ら）がレジストリに悪夢持ちすぎなんだよｗ
176:名無し~3.EXE
08/09/23 18:38:53 8/i6ME+4
■レジストリのアクセス権について、明らかに間違った知識が
広まる前に訂正しておく。
レジストリの実態は単一のファイルではない。
レジストリを読み書きできるからといって、レジストリの内容すべてに読み書きできるわけじゃない。
一般ユーザーでは、読み書きできない場所がある。
アクセス権という概念がレジストリにはある。
177:名無し~3.EXE
08/09/23 18:43:02 PoDzwV0j
一般人もレジストリ汚せるから成立してるビジネスもあるんだよ
178:名無し~3.EXE
08/09/23 18:46:23 NgR8l7C7
＞そのときに毎回パスワード聞かれるか？ よく考えてみろ。
linuxならos巻き込むものについては聞かれるね
レジストリでやると成立しないけど
179:名無し~3.EXE
08/09/23 18:48:32 8/i6ME+4
だいたい、いろんなものをごっちゃにしている。
レジストリは一般ユーザーが読み書きできる場所と。
一般ユーザーが読み書きできない場所があることは説明した。
さて、ファイルも同じだ。一般ユーザーが読み書きできる場所と
読み書きできない場所がある。
レジストリの中で一般ユーザーが読み書きできる場所に保存しているのはな、
ようするの個人情報だ。ファイルだと一般ユーザーが読み書きできる場所に保存する情報だ。
レジストリで一般ユーザーが触れる。データはファイルにしても一般ユーザーが触れるんだよ。
でもシステムデータファイルなんかは、一般ユーザーが触れないというのだろう？
そういうデータは一般ユーザーが触れないレジストリ領域に書き込まれるんだよ。
180:名無し~3.EXE
08/09/23 18:49:26 F1rYwugh
>>178
su -lでログインしたら聞かれないよ
181:名無し~3.EXE
08/09/23 18:51:59 NgR8l7C7
一般ユーザーが触れないレジストリ領域に書き込まれてもおｓ壊れる最低システムだな
182:名無し~3.EXE
08/09/23 18:54:27 NgR8l7C7
一般ユーザーが触れないレジストリ領域に書き込まれなくてもおｓ壊れる最低システムだ
訂正
183:名無し~3.EXE
08/09/23 19:02:02 8/i6ME+4
> os巻き込むものについては聞かれるね
> レジストリでやると成立しないけど
反論の意味を含めてこういう話をしてあげよう。
関連付け情報と追うものがある。これはOSを巻き込むものだ。
だから一般ユーザーは設定できない。そのためVistaでは関連付けの設定をする場合
UACによって管理者権限を取得することを求められる。（管理者じゃない場合はパスワードも聞かれる）
★ここからが、重要な話。これがうそではない証拠。であり俺の言っていることの信用度をさらにあげる話。
UACってのはアプリケーションを起動したときに聞かれる。そこで許可を与えずに、
いったん通常通りに起動したら、管理者権限を得るためにはアプリの再起動が必要になる。
だから、秀丸は関連付けの際、関連付け用のプログラムを別に起動する方法を採用し、
MediaPlayerClassic Homecinema は、もう一つ別のプロセスが起動する（だが関連付け設定の画面のみ有効）
レジストリでやると成立しないとか、何も知らないものの言う事。
184:名無し~3.EXE
08/09/23 19:06:43 NgR8l7C7
UACは失敗だろ
185:名無し~3.EXE
08/09/23 19:07:30 8/i6ME+4
>>182
一般ユーザーが触れるところをいくらいじっても
システムは正常に動くよ。
壊れるのはそのユーザーでログインしたときぐらい。
嘘だと思っているのなら、ユーザーフォルダの中にある
レジストリファイルの実態（ntuser.dat）を削除してみればいい。
システム全体、およびほかのユーザーにまったく影響はないから。
186:名無し~3.EXE
08/09/23 19:07:55 NgR8l7C7
関連付けだけ
アホ
187:名無し~3.EXE
08/09/23 19:09:33 8/i6ME+4
>>186
関連付けは例に挙げただけ。
「だけ」だというのなら、他は違うという証拠を・・・・
って正論持ってきても駄目だろうなｗ
たぶん、こいつには何を言っても無駄ｗ
188:名無し~3.EXE
08/09/23 19:10:19 NgR8l7C7
かるとだね
レジストリに行儀悪いぷりが書き込んでosを壊したという話は？
189:名無し~3.EXE
08/09/23 19:11:05 NgR8l7C7
＞関連付けは例に挙げただけ。
一例だけだろ？
190:名無し~3.EXE
08/09/23 19:13:24 8/i6ME+4
じゃあ、二例目を。
システムを起動するのに重要なキーを
一般ユーザーはいじれない。
やってみればわかる。
191:名無し~3.EXE
08/09/23 19:14:23 8/i6ME+4
> レジストリに行儀悪いぷりが書き込んでosを壊したという話は？
なんだ？ 行儀悪いアプリを作ってほしいのか？
システムを全部フォーマットするような。
rm -rf /
192:名無し~3.EXE
08/09/23 19:15:04 NgR8l7C7
管理でないと話にならないosだから意味ないね
193:名無し~3.EXE
08/09/23 19:15:37 8/i6ME+4
おっと。設定ファイルの話だったな。
rm -rf /etc
194:名無し~3.EXE
08/09/23 19:15:49 NgR8l7C7
rm -rf /
やれるもんならやってみろ
195:名無し~3.EXE
08/09/23 19:18:07 8/i6ME+4
rm -rf /etc やったら管理者じゃないからエラーになる？
レジストリだって、システム関連の重要なキーを
編集するとき管理者じゃなければエラーになる。
先に反論かいちゃったｗ
196:名無し~3.EXE
08/09/23 19:19:36 NgR8l7C7
管理でないと話にならないosだから意味ないね
197:名無し~3.EXE
08/09/23 19:20:20 8/i6ME+4
>>196
うぜーな。スレタイ嫁。
レジストリの話じゃねーだろそれｗ
198:名無し~3.EXE
08/09/23 19:23:31 DMbPzsAc
>>160
> どっちみち内容を更新するには"F5"キーを押さなきゃ駄目なんだから、
> バッチファイルを一々ダブルクリックするのも同じことじゃん
これを同じだと思う神経なら、ini も reg も同じに思えるんだなろうな。
> また、テストの話に限定したがってると言っているが、最初にテストの
> 話をしてたのは貴方の方でしょう?
ああ悪い、最初はデバッグ用のテストデータとか書いてからな。
単体テストとかの方向に行ったので、>>129 で「デバッグ」って明記した
し、その後も何回か書いてるのに理解できないようですな。
> 「お 前 が 間 抜 け だ か ら だ」
まあ、不注意と言えばそれまでだけど、現実にあるからしょうがないのは、
>>131 に書いた通り。複数人で開発すると、そう言う人間にも仕事させな
いわけにはいかんのでな。
>>161-165
ついに発狂したのか？
ついでに、rm -rf / でディスクが「フォーマット」されたとか言う奴は
フォーマットと全消去の違いぐらい勉強したほうがいいと思うよ。
あと、プログラマの余計な負担に項目を１つ追加しておくよ。(w
・アホなレジストリ厨に絡まれる
199:名無し~3.EXE
08/09/23 19:24:46 8/i6ME+4
＞ ついでに、rm -rf / でディスクが「フォーマット」されたとか言う奴は
＞ フォーマットと全消去の違いぐらい勉強したほうがいいと思うよ。
んぁ？ 「全消去」に直せばほかに反論点はないのか。
200:名無し~3.EXE
08/09/23 19:27:14 xcqR7dLh
レジストリの破損をきっかけにWindowsのシステムが壊れるのは、レジストリ自体が悪いのではなく
MSの設計が悪い。
…でおｋ？
201:名無し~3.EXE
08/09/23 19:30:11 8/i6ME+4
>>200
「言いたい事」はそれでおｋ
ただし、システムファイルの破損をきっかけにOSが壊れるのは、
OSの設計が悪い。と言っているのと同じこと。
202:名無し~3.EXE
08/09/23 19:35:40 xcqR7dLh
>>201
いや、Windowsのレジストリはシステムだけでなくアプリの設定も詰め込んで無駄にアクセス機会を増やしてる。
だから「OSの」ではなく「MSの」と表現しなくてはならない。
安全性を考慮すればシステム用のレジストリとアプリ用のレジストリを分けるべきであった。
203:名無し~3.EXE
08/09/23 19:39:36 2DmMwEjQ
汚いゲリストリだなぁ
204:名無し~3.EXE
08/09/23 19:39:43 8/i6ME+4
アクセス機会が増えたからってそれが何なんだろう・・・？
オープン、クローズの回数なら設定ファイルに分けたほうが多いけど。
205:名無し~3.EXE
08/09/23 19:41:02 F1rYwugh
>>198
> まあ、不注意と言えばそれまでだけど、現実にあるからしょうがないのは、
> >>131 に書いた通り。複数人で開発すると、そう言う人間にも仕事させな
> いわけにはいかんのでな。
こういう奴がいるから、保守用/テスト用のツールの作成が重要なんでしょ
失敗があったのなら、失敗しないやり方を研究すべきで、失敗の原因をシステムに擦り付けるのはナンセンス
レジストリが原因とは言っているが、例えそれがiniファイルで在ったとしても、そういう奴なら、system.iniやwin.iniを変更するのは目に見えてる
206:名無し~3.EXE
08/09/23 19:43:42 8/i6ME+4
> 安全性を考慮すればシステム用のレジストリとアプリ用のレジストリを分けるべきであった。
分かれてるけどねｗ
207:名無し~3.EXE
08/09/23 19:56:07 xcqR7dLh
>>206
レジストリが壊れたら１ユーザ分壊れるんだろ？
十分ダメだろ。
208:名無し~3.EXE
08/09/23 19:58:21 8/i6ME+4
レジストリなんてめったに壊れないだろｗ
それこそファイルシステムが壊れるのと同じぐらいの確率だ。
なんでそんな低確率の話してんの？
209:名無し~3.EXE
08/09/23 20:12:44 odqR9sts
>>208
この場合の「レジストリが壊れる」は、物理的にレジストリのファイルが死ぬってことも、
論理的にレジストリと見れないファイルになるってことも、レジストリとしては正しいんだが
内容が正しくない状態になるってのぜんぶひっくるめて「壊れる」つってんだろ。
まあ一部は別にiniでも起きることだが、レジストリのように他のアプリまで使えなくする
＝壊す可能性があるってだけで頻度とかの問題でなく充分危険視されるネタになる。
１％の確率で起きる現象でも、20回やって１回も起こらない率は８割。２割も起こるんじゃ
無視できんだろ。
１回当たりのハズレ引く可能性もっと低かったところで、環境それなりに整うまでに
インストールを何回やると思う？
210:名無し~3.EXE
08/09/23 20:15:55 8/i6ME+4
だから、そんな壊れる確率は
かなり低いだろ。1%もねーよ。
それよりかディスクが壊れることの方が
確率高いよｗ
211:名無し~3.EXE
08/09/23 20:20:11 V98F8yLX
そもそも物理的・論理的な障害の前にはiniもレジストリも関係無いだろ
212:名無し~3.EXE
08/09/23 20:23:55 xcqR7dLh
>>208,210
それはウソ。レジストリが壊れる可能性のほうがはるかに高い
…と、根拠がなくても良いのならいくらでも言える。
俺自身HDDの故障に逢ったことはないけどレジストリの破損でトラブった経験があるし、HDDやファイル自体が
壊れたという話よりアプリを追加しなくても使ってるうちに重くなるという話の方がよく聞く。
213:名無し~3.EXE
08/09/23 20:25:14 8/i6ME+4
俺自身、レジストリの破損にあったことはないけど
HDDが故障したことは何度でもある。
214:名無し~3.EXE
08/09/23 20:25:45 xcqR7dLh
>>211
iniファイルはアプリや設定内容毎に分かれてるから他を巻き込む可能性は低い。
(Windowsの)レジストリは分かれていないから他を巻き込む可能性が高くなる。
215:名無し~3.EXE
08/09/23 20:34:15 V98F8yLX
>>214
レジストリならOSによってバックアップ取られてるから、異常があったらバックアップから復元できる。
ini限らずファイルによって設定を管理してる場合は、バックアップ等々は各ソフトウェアによって実装してたりしてなかったり。
そう考えた場合、自分には被害のレベルとしては レジストリの破損 < iniファイルの破損 と考えるのだが。
それに、前の方で散々煽りあいになってるが、大なり小なり設定が壊れるという状況が本来異常かと。
216:名無し~3.EXE
08/09/23 20:35:10 NgR8l7C7
上書き
217:名無し~3.EXE
08/09/23 20:36:44 8/i6ME+4
うはっ。レジストリすげー上書きできねー。ロックかかっている。アクセス権がないって言われるｗｗｗ
という話がしたいらしい。
218:名無し~3.EXE
08/09/23 20:37:28 GeQvkmjX
新しいPCに環境を移行するときにレジストリを使ってないソフトは
フォルダをそのままコピーするだけでいいから便利。
外付けHDDにソフトをインストールしておけば、
複数のPCで同じように使えるし。
219:215
08/09/23 20:39:03 V98F8yLX
自分で
>> それに、前の方で散々煽りあいになってるが、大なり小なり設定が壊れるという状況が本来異常かと。
とか書いてるが、流石に"異常"って言うほどでは無いので訂正。無いとは言い切れないか。
220:名無し~3.EXE
08/09/23 20:40:07 8/i6ME+4
>>218
ユーザーフォルダに書き込まれる
設定ファイルとかどうすんの？
221:名無し~3.EXE
08/09/23 21:07:00 9NhQkWAd
>>176
それはVistaだけだろう？
222:名無し~3.EXE
08/09/23 21:15:55 9NhQkWAd
もう少しいうと、Windowsのアプリはちょっと前までシングルユーザで使うのが
大半だったから(Windows9xとか)、Program Filesの直下に平気で作業用のファイルを
作るアプリが多かったし、今も多い。さすがにVista登場で減ってきたが。
Program Filesは当たり前だけで全ユーザが共有しているので、
そこを書き込み禁止には出来ない。つまり誰でも読み書きできるようにしないと、
旧来のアプリが動かなくなってしまうので、禁止できなかった。
そこでMicrosoftはVistaでVirtual Storeというものを導入した。
一般ユーザモードで動いているアプリがProgram Filesにファイルを書き込もうとすると、
別なシステムが別なフォルダにリダイレクトしする。アプリからはProgram Filesの下に
書き込まれているように見えるが、実はユーザ毎のフォルダに書かれていて、
Windowsがアプリをだましている。
レジストリでも同様のことが行われていて、管理権限のないレジストリをユーザアプリが
書き換えようとすると「そのユーザ専用の」レジストリが作られ、それが書き換わる。
つまりユーザは自分が大本のファイルやレジストリを書き換えているつもりで、
実はユーザ毎に用意されたファイルやレジストリをいじっているだけ。
これがVistaの特徴(うっとうしい欠点ともいうw)
223:名無し~3.EXE
08/09/23 21:20:09 8/i6ME+4
>>221
違う。
224:名無し~3.EXE
08/09/23 21:21:23 9NhQkWAd
>>223
どういうデータが格納されてんの？
225:名無し~3.EXE
08/09/23 21:22:18 8/i6ME+4
何の話？
226:名無し~3.EXE
08/09/23 21:23:00 9NhQkWAd
>>225
だから普通ではアクセスできないレジストリって、どんなデータが入ったレジストリ？
227:名無し~3.EXE
08/09/23 21:24:31 8/i6ME+4
ハードウェア情報とかそういう
管理者でしか設定できないデータ
228:名無し~3.EXE
08/09/23 21:37:08 9NhQkWAd
>>227
ああ、そりゃそうだね。
229:名無し~3.EXE
08/09/23 22:06:40 0oL0cQnB
わかりやすくいうとレジストリがボンバーマンでiniがロードランナーってこと？
230:名無し~3.EXE
08/09/23 22:10:44 GeQvkmjX
iniファイルでさえ鬱陶しい。
設定ファイルなんてタブ区切りテキストでいいよ。
231:名無し~3.EXE
08/09/23 22:12:37 DMbPzsAc
>>205
だから、テストとデバッグは区別してくれ。
で、失敗しないやり方を研究しろって言う割には、
> で、具体的なやり方はどうするんだい？
ってやると、回答なしなんだよな。
> レジストリが原因とは言っているが、例えそれが ini ファイルで在ったとしても、
> そういう奴なら、system.iniやwin.iniを変更するのは目に見えてる
レジストリだと全部のエントリが見えてるからクリック一発で違うエントリを開いて
編集できてしまう。それに対して自分の ini ファイル触ってる時に system.ini とか
win.ini を触ろうとしたら、ファイルを開くと言う違う通常とは操作が必要になるから
間違う可能性は格段に低くなるだろ。
もちろん、レジストリエディタを改良すれば済む話なんだけど、それこそ最初から言っ
てる
「 新 た な 負 担 」
だろ。
232:名無し~3.EXE
08/09/23 22:18:41 wZC+gEJI
>>231
なんでレジストリエディタを改良なんておおがかりな話になるんだ。
自分のアプリに関連するキーだけexportして、書き換えて、importするだけで
他のアプリもシステムも壊すことは無いのに。
233:名無し~3.EXE
08/09/23 22:38:08 F1rYwugh
>>231
だから、バッチファイルで4行だと言っている
SET keyname="サブキーの完全なパスを指定"
reg export %keyname% work.reg
notepad work.reg
reg import work.reg
この程度のバッチファイルも組めないのか?
234:名無し~3.EXE
08/09/23 22:51:27 xcqR7dLh
>>233
結局余計な手間がかかるんだね。
235:名無し~3.EXE
08/09/23 23:03:42 Ep73VlPk
>>230
XMLを設定保存用のフォーマットにしようってこの時代に何を。
>>231
強力なツールや大きすぎる権限ってのは時にシステムを破壊する危険性がある代わりに
自由自在な操作や変更が可能。慣れれば素早くもなる。
レジストリエディタも本来はプロ用万能ツールの性質が強くて、慎重に、かつ必要最小限の使用にとどめるべきもの。
安全性から考えれば>>232も一理ある。
>>233は欠点があるけどね。
・編集した結果、書式が間違っていないことが条件。書式を間違えていると再登録に失敗する。
・バッチを途中で止めた場合書き戻されない。
・当然だが、保存し忘れれば編集結果は反映されない。(場合によっては利点)
236:名無し~3.EXE
08/09/23 23:14:53 DMbPzsAc
>>232
ねぇ、何で話をループさせるの？
「exportして、書き換えて、importする」作業と、「書き換える」だけの
作業のどっちが楽か考えたらわかるだろ？
>>233
> この程度のバッチファイルも組めないのか?
違うサブキーを編集する時は、そのバッチを編集するんですね。
流石にそんなダサいバッチファイルは組めないよ。(w
>>234
そう、そんな簡単なことが理解できないのはなぜなんだろうね。
>>235
> 強力なツールや大きすぎる権限ってのは時にシステムを破壊する危険性がある代わりに
> 自由自在な操作や変更が可能。慣れれば素早くもなる。
> レジストリエディタも本来はプロ用万能ツールの性質が強くて、慎重に、かつ必要最小
> 限の使用にとどめるべきもの。
その意見には反対しないけど、ツールとしてそれしかないのが現状だから、面倒って言っ
てるだけ。例えば、キーとか値を正規表現で検索や置換することすらできないんだよ。
> 安全性から考えれば>>232も一理ある。
別に >>232 がダメって言ってるわけじゃない。
でも、エディタで編集するだけに比べたら、面倒でしょ？
237:名無し~3.EXE
08/09/23 23:32:36 F1rYwugh
>>236
>>235の言ってる欠点はあるが、アプリの利用するサブキーのみをエディタで編集すると言う目的は達しているから十分じゃん
大体、俺は日曜プログラマと言ってる
つまり素人です
イケてるツールが作りたいなら、プロである貴方でお作りください
238:名無し~3.EXE
08/09/23 23:56:02 DMbPzsAc
そんな泣きながらレスするんなら初めから参入しなきゃいいのに...。
239:名無し~3.EXE
08/09/23 23:56:46 wZC+gEJI
>>236
＞ねぇ、何で話をループさせるの？
具体的なやり方を聞かれたから安全で簡単なやりかたを書いたまでだけれど。
レジストリエディタの改良なんて現実的でない解よりはるかにスマートだよ。
使い捨てと割り切ればいいんだよ。
240:名無し~3.EXE
08/09/24 00:03:52 peHYaINU
.NET TIPS
アプリケーション設定情報はどこに保存すべきか？
URLﾘﾝｸ(www.atmarkit.co.jp)
.NET FrameworkではXMLファイル方式が標準なのだから（レジストリも使えるけど）
少なくとも個別アプリの設定情報の管理に関しては
MS自身が脱レジストリを志向しているのは間違いないと思う
だがレジストリの枠組みは互換性確保のためにこの先も残り続けるだろう
一度導入した以上、そう簡単には廃止出来ないし、現状でそうするべきでも無いから
システム管理用途ではずっと使われ続けるかもしれないし
241:名無し~3.EXE
08/09/24 00:07:38 peHYaINU
補足
と言っても.NETの普及が進んでいない現状だから、
将来に関してはまだ何とも言えない部分も多いけどね
242:名無し~3.EXE
08/09/24 00:08:41 Ibvs5ueU
>>239
せめて、この内容に回答してからレスしてくれないかなぁ。
> 「exportして、書き換えて、importする」作業と、「書き換える」だけの
> 作業のどっちが楽か考えたらわかるだろ？
243:名無し~3.EXE
08/09/24 00:10:00 gG74zKwr
>>242
>>233のバッチで解決済みではないのか?
244:名無し~3.EXE
08/09/24 00:17:43 WYLjp3Ob
>>242
ま、その二者で比べれば書き換えるだけが楽だけどね。
でも現実的な用途だとそこまで汎用的な編集はしないでしょ。
xx用データ1.reg
○○用データ2.reg
みたいなのを複数用意して何度も使いまわすケースのが多い。
アプリケーションの設定を手探りで行うわけがないからね。
245:名無し~3.EXE
08/09/24 00:18:18 WYLjp3Ob
>>243
彼は3分でバッチを書く手間を惜しんでいるのでね。
246:名無し~3.EXE
08/09/24 01:00:54 Ibvs5ueU
>>243, >>245
>>237 がかわいそうなので引き合いに出さないでやってくれます？ (w
>>244
> アプリケーションの設定を手探りで行うわけがないからね。
デバックですよ？ (何回目だ？)
247:名無し~3.EXE
08/09/24 01:01:24 JwR4Ld5v
モノグサ、無い物ねだり、理想郷、etc...
廃人プログラマーに多い、「困ったちゃん」ですね。
248:名無し~3.EXE
08/09/24 01:05:41 WYLjp3Ob
>>246
デバッグにつかうデータにパターンが無いわけないだろう？
249:名無し~3.EXE
08/09/24 01:06:15 aSHQp448
windowsなら、iniにしてても同じ気がするなー
WINDOWSフォルダの中が、すげーことになってるから、
どうせ ini にしたって同じだろ
そこかしこに、iniファイルをばら撒いたり、勝手に消したりするんだろうなー
250:名無し~3.EXE
08/09/24 01:12:12 hi7mMxWr
だな、自分のフォルダ以外悪さできないようにしないとな。
251:名無し~3.EXE
08/09/24 03:06:16 WYLjp3Ob
>>246
それと、>>237の書いたバッチは
>>231の「レジストリエディタを改良」発言よりはるかに使えるものだから
あんたとしては引き合いにだされると困るよな。
252:名無し~3.EXE
08/09/24 03:10:29 peHYaINU
でもさー
そういうのって単なる「問題回避のためのTIPS」の範疇じゃん
全然スレタイに沿った本質的な話じゃないと思うんだよね
いつまで続ければ気が済むのかと
253:名無し~3.EXE
08/09/24 06:36:21 Ibvs5ueU
>>247-251
夜中までご苦労さんなことだな。
>>247
「新たな負担」があると言う事実を指摘したら、「ものぐさ」って...
いくら反論できなくなってるとは言え、馬鹿？
>>248
へ～え、君ん所はあるんだ、すごいなぁ。
これで満足？
>>249-250
>> レジストリだと全部のエントリが見えてるからクリック一発で違うエントリを開いて
>> 編集できてしまう。それに対して自分の ini ファイル触ってる時に system.ini とか
>> win.ini を触ろうとしたら、ファイルを開くと言う違う通常とは操作が必要になるから
>> 間違う可能性は格段に低くなるだろ。
>>251
そうだよね。無いものよりは、はるかに使える。
でも、>>234 なんだよな。
# ダサいって言われたのがそんなにショックだったのか...。
254:名無し~3.EXE
08/09/24 08:15:10 tAAU2h0I
こんなネタは前世紀までにしとけよ
255:名無し~3.EXE
08/09/24 08:15:30 WYLjp3Ob
>>253
>>155で
＞＞レジストリとiniの差も満足に埋めれない作業方法
＞ねえ、誰が埋めれないって書いてるの？
＞なんか書いてないものが見える人が多いなぁ。(w
＞あくまでも、「バッチファイルの管理」とか「差を埋める」のが面倒だって書いてる
＞だけ。
と書いてあったから、面倒ではあってもなんらかの工夫で差を埋めているのかと思ったが
問題意識を持っているはずのレジストリの誤操作に対しても完全に無防備のまま…
レジストリエディタ改良案よりはるかに使える他者の案はとりあえずこきおろす、と。
やっぱり何にも工夫してなさそう。