レジストリ vs プライベートINI

フリーソフトで設定を保存するにはどちらが良いか。
プログラマの視点から、逆にユーザの視点から、
それぞれの利点や欠点について意見を聞かせてください。

　　　　　　　　　　　　　　　　　　　　　　　 　　　,. 、
　　　　　　　　　　　　　　　　　　　　　　 　 　 /　/　 ＝ -
　　　　　　　　　　　　　　　　　　 　 　 　 　 /　/　　＝ -
　　　　　　　　　　　　　　 　 　 　 　 　 　 /　/　　＝ -　　　　はいはい2ゲットｽﾞｻｰｰ
　　　　　　　　　　　　　　　 　 　 　 　 　 /　/　　　　　　　　っと。
　　　　　　　　　　　　　　　　　　　　　 　/　/　　　　
　　　　　　　　　　　　 　 -―￣￣ ｀ ―'　 ,　_
　　　　　　　　　　,　´ 　　　　　　　　　　 　 　 ￣"　ー 　　　　　　　　_＝
　　　　　　　　_／　　　　　　　　　 　 　 　 　 　 　 　 　 　 ｀　、　　＝
　　　　　　 , ´　　　　　　　　　　　　　　　　 　　,ﾍ　　　　　　　　ヽ　　　＝
　　　　,／　　 ,|　　　　　　 　 　 　 　　　　 　 　●　　　　 　 　,／
　　　と,-‐ ´￣　　　　　　　 　 　 　　　　r(　　 `'　　　　　　く　　　三　＝　　　　　(⌒
　　(´＿＿　　　､　　　　　　　 　　　　 　`(　　　,ﾍ　　　　　　 ヽ　　　　三　＝(⌒
　　　　　 ￣￣｀ヾ＿　　　　　　　　　　　　　　　●　　　　　　　 　_>　　　（　⌒　　　　(⌒
　　　　　　　 　 ,＿ 　＼　　　　　　　　　　　　　`' _＿　　 -‐ ´　　　三＝(⌒　　　(⌒
　　　　　　　　(＿_ ￣~"　＿＿ , --‐一~￣￣￣　　　　　　三　　＝(⌒ 　(⌒
　　　　　　　　　　￣￣￣　　　　　　　　　　　　　　　　＝（⌒(⌒　　＿＿
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　

みんなINI派なんだろうな……

んじゃあINIに一票。ユーザーの視点です。

フロッピーに入る程度のソフトなら、出先で使えるINIの方がありがたい。

INIで設定情報記録しつつレジストリにまで書き込んでるﾊﾞｫｹｪーなソフトないよね？

ini派だけど、エディタみたいな、設定が多い奴はレジストリの方が早いだろうねぇ。
普段レジストリでも、iniファイル書き出し機能があって、iniファイルを引数で指定できて、おまけに、設定画面からレジストリ削除が出来れば良いなぁと思う。

なんかWin32APIヘルプとか見ると、iniは使うなレジストリ使えとか
書いてあるので、ついついレジストリ使うような仕様にしてしまってました。
でも最近はiniに回帰しつつある・・・

レジストリだとテストの際、値を書き換えるのが面倒臭い。
ini の方が扱いやすい。

iniがいい。
レジストリがぶっくぶく太るのはイヤ。

レジストリだと、OSを再インストールしたら全部設定が飛んじゃう・・・

レジストリって嫌われるよね。
だけどどこに書き込まれてるかちゃんと README に書いてあれば
おれは悪くないと思う。そういう情報があれば移行の手段もあるし、
何よりも早いじゃない。
危険というなら、初心者がシステムディレクトリ開くのだって危険。
肥大化は scanreg で対応。

ini を使ってても IrfanView や Dibas（どっちも好きなソフトだけど）
みたいに、Windows ディレクトリに作っちゃうのはどうかと思う。

>>7
いいかもしんない！

>>8
MSはレジストリを推奨してるんだよねぇ
理由はなんなんだろ・・・

>>12
Windows ディレクトリに作っちゃうのはどうかと思う。

それはたぶん皆一致の意見かな。
ここもわざわざレジストリ vs "プライベート"INIスレだし

プログラマ板でもレジストリに関してのスレ
どっちかっていうと作り手側の意見かな。
http://pc.2ch.net/test/read.cgi/prog/997370579/l50

>>14
うん？
＞"プライベート"INI
って、そのソフト固有の INI って意味じゃなかったのか。
（WIN.INI とかじゃなく）
不勉強かもしれないが、あまり聞かない言葉なんで誤解したよ。

>>16
Windowsフォルダのiniに書き込むのはWriteProfileString()で、
他のフォルダ（普通はソフト本体と同じフォルダとか）のiniに書き込むのが
WritePrivateProfileString()だからプライベートって呼んでるんだけど、
もしかしてこれってメジャーな呼び方じゃないのかな

>>17
WriteProfileString() なんて使ったこと無いからピンと来なかった。
それにしても、遅いよね。WritePrivateProfileString()

>>18
もちろん俺も使ったことありませんヽ(´ー`)ノ ＜WriteProfileString()

レジストリの利点って余りないよな。

推奨されてるのに利点が・・・

デビュー当時マルチユーザーとか一元管理できるとか、そんな触れ込みだったよね。
つか、昔も%windir%に無断でiniファイルを(大量に)作られたり、win.iniがぐちゃぐちゃになったりで嫌な思いしたんだけど、結局発端は作者のマナーなんだよねぇ。

Windows 2000以降だと\Program Files以下に書き込むにはPower Users以上
が必要だし、ユーザーごとに設定を変えられないからじゃないかなあ。> 推奨

>>23
でもそれらの理由ならINIでもいいんだよね・・・
高い権限が必要なフォルダにインストールしなければいいわけだし、
（そもそもINIファイルを使っているのでフォルダをどこに移動してもいい）
ユーザごとにINIファイルを分ければ設定も変えられるし。

やっぱりWindowsの再インストールが面倒くさいのがレジストリの嫌なとこだな。
良くて、レジストリをregファイルに書き出しておく機能があるくらいだもの。面倒臭すぎ。
iniファイルならCD-Rや外付けHDDにディレクトリごとコピーするだけ。

GMASK逝ってよし！
勝手にWIN.INIに足すなボケ！

逆に言うとiniファイルの利点って移動が楽ってことだけだよね。
それが大きいんだけど。

.ini ファイルだと、ドキュソなユーザがメモ帳で勝手に編集しちゃうし、
第一、ユーザごとに設定を分けられない。

レジストリだと、無理に編集するにはレジストリエディタを使わざるを得なくなり、
そういうドキュソユーザに対して、かなりハードルになる。
それに HKCU 使えば、簡単にユーザごとに設定を分けられる。

さらに文字列じゃなくても、たとえば DWORD 値を直接読み書きできるので、
.ini ファイルの記述をチェックしなくていい。

ファイルだと、ディレクトリごと消されたり、勝手に移動されたりするけど、
レジストリだと、そんなバカなユーザからかなり守れる。
いわゆる「フールセーフ」ってことかな。

プログラマ板も見て総合的に判断すると、
レジストリ ＋ INIのような設定の簡易移動
だと良さそうでは？レジストリ設定のインポート・エクスポート機能。
これの逆で
INI ＋ マルチユーザ対応、64KBの壁、文字列以外の記録、etc
は大変なので。

家族一人一人でログインユーザ作ってるから、
マルチユーザに対応してないINIは使いにくい。
INIでも Special Launch とか シン覚え書 なんかは
マルチユーザ対応してるのでいい。

レジストリもバッチファイル作っとけば保存・復元ラク。
例えば、こんな。
REM *** Becky! Internet Mail ***
REGEDIT /E E:\Reg\RimArts.reg "HKEY_CURRENT_USER\Software\RimArts"
REM *** 秀丸エディタ ***
REGEDIT /E E:\Reg\Hidemaru.reg "HKEY_CURRENT_USER\Software\Hidemaruo\Hidemaru"

復元時は上記のregファイルを実行していくだけ。

XPが出たし、まぁこれがすぐに浸透するかどうかは別として、
これからマルチユーザ対応は当たり前にやっていかなきゃならないと思うよ。

でもパソコンを複数人で共有するってそんなにあることなのかな？
会社、学校ならインストールするようなソフトは
レジストリを利用したマルチユーザー管理も納得だけど
オンラインソフトなどを入れるのは個人使用のパソコンが多いだろうし
その場合、家族と共有してる人はそれほど多いのかなと・・・
結局一人一台代わりと基本なのでは

長々とｽﾏﾝだけど言いたいことは
「INIの方がうれしいよう！」ってことです

アプリケーション名＋ユーザー名.INIで管理したらどう？
レジストリはユーザーごとに用意する必要がなくなって
ユーザーの参照くらいになると思うけど。
インストール後の再起動でレジストリのエラーになると
古いレジストリで更新情報が行方不明になるから
INIのほうがありがたいんだわ。

>>33
まぁINIファイルをマルチユーザ対応にすることはそれほど難しいことじゃないです。
おっしゃるようにファイル名をユーザごとに変える方法や、ユーザごとにフォルダを
分ける方法など。
ただ、レジストリなら簡単なのにINIなら難しいという問題はその他にも
既出のように64KBの壁や、文字列以外の記録、初心者が誤操作しやすい（iniを謝って削除するなど）
などがあるので、そのへんはどう対応するのかと。

気になったのは
>インストール後の再起動でレジストリのエラーになると
>古いレジストリで更新情報が行方不明になるから
で、レジストリを使う人にはけっこう重要なことかもしれないので
もう少し詳しく教えてもらいますか？
「古いレジストリで更新情報が行方不明になる」とは？

>>34
>「古いレジストリで更新情報が行方不明になる」とは？
壊れたレジストリが破棄されて、バックアップが適用されるって事だろ。

>>35
>古いレジストリで
あぁ、エラー前のレジストリが適用されて、って意味か。
それは確かにINIの方がいいかもなぁ。

マルチユーザー環境だとレジストリが有利っつーのはウソでしょ。
例えば１ユーザーで複数アカウントを切り替えて使ってる場合
（普段用と管理用…等）レジストリよりINIの方が有利。

個人的には>>33,34のような方法でマルチユーザに対応しつつ、
コマンドライン等から別のINIを適用可、ってのがマンセー。
自分が知ってる範囲内では、WWWC、Irvine、xyzzy、limechat等が
この方式。
あとFFFTP等のini／レジストリ切り替え式も良いかも。

ちなみに64k、書換、バイナリデータ対策は、iniに拘らなければ
即解決。

>>37
FFFTP使ってたけどそんな設定があったなんて知らなかった。
それいいね。基本的に開発時に迷ったらユーザの選択式にすればいいと思う。

iniが遅いってのはどう？レジストリと比べて体感的に変わる？

>>39
QXでは実感できるが、自分で実験したことはないので微妙。
つか、エディタ並に設定項目が多いような物以外は、超能力者でもない限り、iniでもregでもわからないはず。

>>37
>マルチユーザー環境だとレジストリが有利っつーのはウソでしょ。
>ちなみに64k、書換、バイナリデータ対策は、iniに拘らなければ
両方とも、"開発者側から見ると"楽で良いねというお話なの。

# 小物の場合は特に独自形式で保存なんかしたくないなぁ。

>>39 書き込みは、はっきりレジストリより遅いですよ。

>>41
有利なところはなく、開発者から見て楽なだけなんだね。成る程。
では、今度からレジストリに保存するソフトは、
開発で楽をしてユーザに負担を強いるソフトと思うことにしよう。

>>43
再インストールする前に%userprofile%をバックアップするのって、そんなに負担？
移動プロファイルならバックアップする必要すらないし。

>>41 はM$が死んだら苦労するだろうね。
独自形式なんて他のOS（特にUnix）では割と常識。

>>44
regファイルへの書き出しや移動プロファイルはともかく、
レジストリ本体のバックアップなんて気持ち悪くてできん。
M$自体、自身が定めたガイドに従ってないから、
何が起こることやら…

実装が楽な順
　INI＞レジストリ＞独自ファイル

ファイルについて言うと、データを読み書きする位置をわざわざ自分で
seekしなくて良い INI程、楽なものはない。

まとめてみました
http://www.geocities.co.jp/Beautycare/4965/public/save.html

デスクトップとノートパソコンで同じ設定を使いたいので、INIの方が楽でありがたいです。
ファイル同期ソフトで一発です。

まあ、レジストリでも別に良いのですが・・・
レジストリ使っているのに、説明に「アンインストールはインストールしたフォルダを削除するだけ」と書いたり、
付属のアンインストーラー使ってもレジストリが残っていたりというのは勘弁してほしいです。

レジストリって単独で動くようなアプリには関係ない話じゃない？

レジストリを使って一般ユーザに設定を変更させないようにするには
どうすればいい？HKEY_LOCAL_MACHINE\SOFTWAREに保存？
iniの場合は管理者しか書き込み権限のないフォルダに入れておけばいいと
思うんだけど。

>>45
出来ないなんて一言も言ってないけど…。だるいってだけで。
つか、何煽ってんの？

>>41=45は苦労(=だるい思い)をするだろうとは書いたが、
出来んとは書いてないゾ。
反論するならもっとマシなコト書こうYO!
見本書くから良く見とくベシ。

Win2k以降に限るけど、レジストリには環境変数を
使えるという利点がある。
例えば [HKEY_CLASSES_ROOT\txtfile\shell\open\command] に
REG_EXPAND_SZ 型で"%editor%" "%1" と書いておけば、
環境変数 Editor にset したエディタで txt を開くことが可能。
んで Win2k の環境変数は共通設定をユーザー毎に
オーバーライド可能だから、特別なソフトを使わなくても
ユーザー毎に好きなエディタを使わせる事が可能。

もっともiniや独自形式でも、コストはかかるが
共通設定→ユーザ別設定の継承は可能。

スマソ、Win2k 以降と書いたが、NT4.0 でも可能かも。
（持ってないので良く知らん）

あと環境変数に頼るのは、少し格好悪いカモ。

>>47
ご苦労様。
良ければ「レジストリが肥大化しない」の「代替策」のところに、
scanreg
と一言、付け加えておいて下さい。
あと、あえて突っ込むとしたら「代替適用ができる」のところかな。
ＱＸみたいにレジストリ番号でも引数で指定できるソフトもあるんだし……。
というか、これって、最後の「レジストリとiniファイルの切り替え式」
の話であって、別に ini の利点でも何でもないでしょ。

iniをマルチユーザに対応させるときの、iniを置く場所はどこが良い？
exeと同フォルダ？またはそのサブフォルダ？
またはWin2kで言えばC:\Documents and Settings\ユーザ名\Application Data
のような場所・・・？

>>55
つい最近までずっと、exeと同フォルダまたはそのサブフォルダが
良いかなと思っていたけど、
アプリのデータや設定ファイルは分離してた方が、
バックアップとりやすいかな、と思えてきた。
ApplicationDataに集中させるのも管理しやすいかも。
iniを切り換えたいときはパラメータで渡せばすむし。

オンラインソフトだと「Change Proxy」がApplicationData以下
のフォルダにiniを作ってる。
パッケージソフトだとAtok14の各種iniやユーザ辞書も同様。

例えばPowerUsers権限以上しか書き込めないフォルダにソフトがインストール
されていると、Users権限のユーザは同フォルダにiniを作れないよね？
そうするとやっぱりApplicationDataに置いたほうがいいのかな。

この場合アンインストールソフトを使うならAdministratorで実行しなきゃ
ならないのかな。そうすればレジストリのHKEY_CURRENT_USER\Softwareと違って
全ユーザのiniを消せるよね。

マルチユーザ用iniはC:\Documents and Settings\ユーザ名\Application Data
に置くということでええか。ええか。ええのんか。
ちなみにこれはWin2kの場合だが、他のWindows（95/98/Me/NT/XP）では
どのフォルダに該当するのか教えてくれ。

98SEは C:\Windows\Application Data
95,98も同だと思うけど

>>59
マルチユーザの場合は
C:\Windows\Profiles\ユーザ名\Application Data
じゃなかった？

Profiles の存在を忘れてた
マルチユーザで使うこと無いんで
>60 ですね

そのフォルダってどうやって取得するんだっけ。
APIあったよね？？

>>62
やったことないけど、SHGetSpecialFolder() でできそう。
MSDN見れ。

Irvineも
\Documents and Settings\[ユーザ名]\Application Data\Irvine
を使ってる。

つーことでおまぃたちこれからini使うときはそこ使うこと。

>>62
↓これ？
http://pc.2ch.net/test/read.cgi/prog/997370579/444

>>63
SHGetSpecialFolderLocation() の間違い。ｽﾏｿ

インストールしたフォルダのみ削除すればいいという簡便さが失われる

むしろそれだけか。

んだんだ。そんな深いところにあるファイル消すの面倒だろ。
Adminが消しちゃって設定だけ残ったら、結局iniのメリット半減だし。

そもそもUser権限なんかで使っているところって、どれくらいあるんだ？
そんなのが増えたら漏れの作ったソフトは関連付けしないのがほとん
どなんで、ソフトその物をマイ ドキュメントに入れてもらってｲｲ！

関連付けする奴はマイ ドキュメントにフォルダ作って入れるってのは
どうよ？ これならユーザーも探しやすい。

って関連付けするっての段階でレジストリいじるが、ユーザー毎の設
定の置き場所って事で・・

>>70
>Adminが消しちゃって設定だけ残ったら、結局iniのメリット半減だし。
レジストリと一緒で普通はアンインストールプログラムも入れるはず。
もしくはReadme.txtで促す。
レジストリと違ってAdminだと他のユーザのフォルダにもすぐアクセスできて
プログラム上から設定消すのは簡単だと思う。

>そもそもUser権限なんかで使っているところって、どれくらいあるんだ？
Win2k使ってるけど普通の作業はUsersだけど？

マイドキュメントってどのバージョンのWindowsからあるんだっけ。
ちなみに俺はマイドキュメントを共有フォルダに設定してる(;´Д`)
マイドキュメント使うならApplication Dataの方がAdminが管理できて
いいと思うけどなぁ。

ところでマルチユーザ用iniを同フォルダ（またはそのサブフォルダ）に作るって人、
プライベートなデータも別の一般ユーザから見えてしまうわけだけど
そのへんはどうなんだろうか。
まぁPCを一人で使ってる人がほとんどだと思うから気にならないと思うけど。

>>64
Irvineは設定の保存先を変更できるように修正されてるね。
マルチユーザ用にデフォルトApplication Dataフォルダで、
そこに保存するのがやだって人用に変更オプションをつけるのがベターかな。

>>6
Irvineがそうですが何か。

つーことでおまぃたちこれからini使うときは\Application Data使って、
オプションで設定の保存先を変更できるようにすること。
そうすればユーザーから「なんて柔軟性のあるソフトなのかしら……好き（ぽっ」
となること間違い無しだ。

age

HOMEディレクトリに .rc ファイル作るのが好きだな。
バックアップが楽珍でいい。

「INIファイルに保存するようにはできないのですか？
「レジストリ嫌です。INI INI INI INI 総理 総理 総理 総理
ってギャーギャー掲示板で騒ぐのやめてほしい

>>76
何のリソースファイル？

インストールされている位置が
%userprofile%の下なら同一フォルダ
それ以外の場所なら%userprofile%\Application Data
を保存先のデフォルトにする。さらに設定で変更可能、でどうよ?

>>79
そんなややこしいソフト誰が使うんだよボォケ

>>74
変更した保存先の情報はどこに保存するんだよ。
まさかレジストリじゃないよな?

そんなことより>>1よ、ちょと聞いてくれよ。スレとあんまり関係ないけどさ。
先日CloneCD3.0.8.2のキー登録したんです。CloneCD。
そしたらのキーの入力に失敗してしまいました。
Win9x系ではレジストリの
HKEY_CURRENT_USER\Software\Elaborate Bytes\CloneCD\Stolen
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\MagnaCarta
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\MagnaCarta
を削除すればもう一度やりなおせるらしいですが、当方Win2Kです。
全体を探してみたのですが、StolenとMagnaCartaは見つかりませんでした。
もちろん一度アンインストールして再度キー入れ直したりもしてみましたがダメでした。
「登録キーが誤っています。正しいキーを入力してください。」だそうです。
どうすればよいでしょう？ご存知の方いましたら教えていただけませんか

>>80
使う側は全然ややこしくないだろボゲェ
作る側がちょっとめんどいってだけだ

>>81
それは同フォルダに保存すればいいんじゃないの？
user1=C:\・・・
user2=C:\・・・
user3=D:\・・・
みたく。

>>84
ならそこに保存しろよ！……と思う。

>>81
EXEの末尾にパスと追加したデータの長さを記録、とか？
DOSならこれで無問題かと…
でも少なくとも32BitなWinでは違うと思うのでsage

>>85
いや、だから>>57や>>71の後半あたりの事情もあるからこういう話になったわけで…

>>57とか>>71とか>>84を考慮したときのセットアップ例
条件漏れがないかチェック希望

ifPCを一人で使っていてアカウントが一つ
　インストール場所：好きな場所
　設定の保存場所　：好きな場所
ifPCを一人で使っていて複数アカウントを使っている
　if設定をアカウントごとに変更
　　インストール場所：好きな場所
　　設定の保存場所　：デフォルト（%userprofile%\Application Data）
　　　　　　　　　　　または他アカウントとかぶらない場所
　if設定を全アカウントで共通
　　インストール場所：好きな場所
　　設定の保存場所　：全ユーザ共通の場所
if自分が管理者でPCを複数人で使っている
　ifUsers自身に設定の変更を許可する
　　ifUsers自身に設定の保存先の変更を許可する
　　　インストール場所：UsersにWrite権限のある場所
　　　設定の保存場所　：Usersにおまかせ
　　ifUsers自身に設定の保存先の変更を許可しない
　　　インストール場所：UsersにWrite権限の無い場所
　　　設定の保存場所　：デフォルト（%userprofile%\Application Data）
　ifUsers自身に設定の変更を許可しない　　
　　インストール場所：UsersにWrite権限の無い場所
　　設定の保存場所　：全Users共通かつUsersにWrite権限の無い場所

if NTだったら>>88

else
インストール場所：好きな場所
設定の保存場所：インストール場所\ユーザー名.iniまたはフォルダ

9xならどこに置こうが見られるんだからインストールした場所で
いいんでない？

>>89
あ、うん、もちろんNT系の話。＜88
確かに9xならどこに置いても同じなんだけど、
どう？OSごとに置く場所変わるのって。
まぁ、別にいいっちゃぁいいけど。

そんなことやってるとどこに設定ファイルがあるか分からない(or忘れた)となるじゃん
シンプルにアプリと同じ場所がいいよ

デフォルト%userprofile%\Application Dataだっつってんだろ
なんでこれがわからないんだよ
つーかこれに限らずソフトが使う設定ファイル・レジストリの場所は
Readme.txtやヘルプに書くこと。

>>87
iniファイル作れないのに
user1=C:\・・・
user2=C:\・・・
user3=D:\・・・
は書けるの？

>>93
ini作れないならデフォルトApplication Dataを読みに行くよ

>92
GetPrivateProfileInt()もWritePrivateProfileString()も
デフォルトはWindirですが何か？
設定ファイルとかレジストリの場所をドキュメントに書
くのは常識だな。
つーか書いてないソフトは逝ってよし！

>90
設定内容にもよるがNT系と9x系で同じ設定使うのも
問題かと思われ。

>>95
>デフォルトはWindirですが何か？
そうじゃなくてGetPrivateProfileInt()に与えるディレクトリを
デフォルトでApplication Dataにするという意味ですが何か？

>設定内容にもよるがNT系と9x系で同じ設定使うのも
>問題かと思われ。
同じなのは設定じゃなくて設定を保存する場所だと思われ。

>>95
>つーか書いてないソフトは逝ってよし！

趣旨には同意＆揚げ足取りスマソ。
ソフトが逝ってよしなんではなくて、作者が逝ってよしでは？

つーことでおまぃたちこれからini使うときは\Application Data使って、
オプションで設定の保存先を変更できるようにすること。
保存先情報はexeと同ディレクトリに保存。
こうすることで>>88のような各環境に対して様々なセットアップパターンを提供できる。
そうすればユーザーから「なんて柔軟性のあるソフトなのかしら……好き（ぽっ」
となること間違い無しだ。

>>81
起動するたびに検索する

>>81
そのくらいレジストリ使ってもいいじゃねーかYo!

使うなら使うでいいんだけどさ、大した用途じゃないのに
インストールしなきゃならんのは敬遠してしまうよ。
ブラウザとかメーラーとかならいいけど。

あと、それ以前にアンインストールも書いてないのがあるのが問題。
どういうつもりだ？
問い合わせたら、レジストリつかってんじゃねーか。

>>101
レジストリに設定が残るくらい、別にいいだろう。
勝手にシェル拡張して、アンインストーラーが無いとかいうのは惨いけど。

ときどき、自分自身のディレクトリに設定ファイルを作ってるつもりで
カレントディレクトリにしてるアプリがあるのはちょっとナニかなあ……
と思う。ファイルを編集するようなアプリじゃなくても（ゲームとかでも）
ちゃんと自分自身のディレクトリを取得して欲しいよね。
それはともかく……。

>>101
レジストリ使ってるかどうかと、アンインストール方法を書かないってのは
直接の関係はないと思う。
>>102
良くないって（笑）。そう思っている人が多いのがレジストリが嫌われる
一因になってると思うよ。

ini を使うのであれ、レジストリを使うのであれ、アンインストール方法
を書くのは大前提……ということでしょ。

俺は特にこだわらないけど、Readme.txtなどにでも、アンインストールの事を書いておいて欲しい。
それさえあれば、レジストリでもINIでも構わないんだけどなぁ。
なんだかんだと、アンインストールの所が無かったり、あっても、具体的に書いてないものばかりなんだよなぁ。

>>103
いいって。それくらい。
そうやつて、レジストリが、レジストリがって言って回る人が多いから、
レジストリが嫌われるんだって。

>>104
ここに逝ってよし。

readme.txtにアンインストール情報を！
http://pc.2ch.net/test/read.cgi/prog/997370579/

そういうそふとはよほど有名じゃない限りつかわない。
さっさと廃れてしまえ

レジストリや設定ファイルの場所はドキュメントに書くこと。
実際に消すか消さないかはユーザに任せること。
どうせインストーラ／アンインストーラ使ってもレジストリ残るし。

つーかよ、>>81,100で設定の保存先をレジストリに保存するって
具体的にレジストリのどこに保存するの？

俺ｲﾆ派。
Delphiで開発しているんだけど、INIを扱うクラスが豊富だよ。
通常のAPIをラップしたのもあるんだけど、独自に実装してあるINIクラスが便利だよ。
独自実装だから、win9xとNTでのAPI非互換問題もないし、何より速い。
バイナリもINIに書き込める。

↑は、Delphiに標準でついてくるクラスです。

>>108
普通は HKEY_CURRENT_USER\Software 以下に保存するんじゃない？

VC用のiniクラスを教えれ。
俺も探すから。

スレとは関係ないけど、

C:\Documents and Settings\Administrator\Local Settings\Application Data
C:\Documents and Settings\Administrator\Application Data

この違いは何なの？

>>98
保存先情報をexeと同じ位置にしたらマルチユーザーに対応できないし
Users権限では保存先を変更できない状況がありうると思うのですが
そのへんどうよ?
つーかそれなら全部exeと同じ位置に書けばいいじゃん。

>>100
なら全部レジストリに書いてもいいじゃん。

まったく使わないか全面的に使うかのどちらかしかありえないよ。
中途半端に複数の手段を併用されてもバックアップのときとかに
わけわからなくなるだけ。

>>114
同意。
複数の手段を併用するのはやめてほしい。
バックアップのし易さ↓
INIのみ＞レジストリのみ＞INIとレジストリ併用
って感じで、レジストリのみより寧ろ悪くなる。


FFFTPなんかはINIとレジストリ、
どっちを使うかオプションで選べるようになってるけど、
じゃあその「どっちを使うか」という情報をどのような手段で保存しているのかな。

デフォルトはINIを使うようになってるようだけど、
Program Files下への書き込み権限のないユーザでも
正しく保存できるように配慮されてるのだろうか。

>>114
>保存先情報をexeと同じ位置にしたらマルチユーザーに対応できないし
なんでよ？マルチユーザ対応にするために使うんだけど。

>Users権限では保存先を変更できない状況
それは管理者が保存先を変更するなというルールを用いてるか、
でなければUsersでも変更できる場所にインストールすれ。
だいたい、
>全部exeと同じ位置に書けばいいじゃん。
って言うのだってUsersが変更できる場所にインストールすることが前提の発言だろ？

>>115
FFFTPの場合は簡単じゃん？
どっちかを調べて設定がなければ他方を読み込む。
今話してるのはマルチユーザの場合はどうするかってことで、
それを同フォルダに置くかディレクトリに置くか、と。

つーかみんな過去ログ読んでる？

訂正
>それを同フォルダに置くかディレクトリに置くか
それを同フォルダに置くかレジストリに置くか

>>117
補足というかなんというかFFFTPはINIがあればINI優先になる。
どこに設定を保存しているかってのは、ちょっと発想が貧困だな。
ただ、ヘルプにもあるようにマルチユーザー用ではない。

>設定をINIファイルに保存するようにします。マルチユーザ環境でない時に使用してください。INIファイルは、ffftp.exe のあるフォルダに作成します。
>ＩＮＩファイルの方がレジストリよりもバックアップが簡単に出来るので便利です。

マルチユーザーで、個々に別々の設定を使いたいのならレジストリ使え
ば良いんじゃない？
共通の設定で構わないのなら、マルチユーザーでもEXEのあるフォル
ダにiniでも良いだろ。読み込みはできるんだから。
User権限で設定が変えられないのは仕方が無い。黙って管理者の設
定したままで使え。

ところでどんな情報を保存してる？
ウィンドウの起動位置や起動状態（最小化／最大化など）みたいな
ちょっとしたことだけ保存されたら嫌？

>>116
＞>保存先情報をexeと同じ位置にしたらマルチユーザーに対応できないし
＞なんでよ？マルチユーザ対応にするために使うんだけど。

漏れは114じゃないが、
マルチユーザ環境 = exeのあるフォルダはユーザ権限では書き込み不可
を想定と思われ。
保存先情報をexeのあるフォルダに保存というのは矛盾してる。

>>120
それは嫌すぎる。
だいたいﾚｼﾞｽﾄﾘ使うﾂｰﾙとかって、
どーでもいい情報に限ってﾚｼﾞｽﾄﾘに保存する傾向がある気がする…

まぁActiveXの登録とかｼｪﾙ拡張みたいな、
「OSの機能の恩恵をそのｱﾌﾟﾘｹｰｼｮﾝで享受する為にﾚｼﾞｽﾄﾘを用いる」
とかそういうのならむしろ歓迎。
けど、下らん情報しか保存しないくせにレジストリに保存するのは逝ってよし。
ところで逆に、レジストリじゃないといけない事って何？
たいていはINIで事足りると思われ。

てかマルチユーザ考えなきゃいけない場面ってそんなにある？
漏れ的にはPCは１人一台orそれ以上が基本だと思うから、
INIﾏﾝｾｰ派。

>>122
＞ところで逆に、レジストリじゃないといけない事って何？

OSや他のアプリケーションとの連携に関する物はしかたないよね。
代表的なとこでは拡張子の関連づけとか。

それ以外だと、例えば各スクリーンセーバの設定情報とかがあるかな。
スクリーンセーバの実行ファイルってSystemフォルダに置かれるから、
そこにINI作られるとイヤーン。
Win3.1の頃はWIN.INIに勝手にセクション作って保存してたんだっけかな?
そういうのも嫌だよね。
まだレジストリの方がマシ。

＞てかマルチユーザ考えなきゃいけない場面ってそんなにある？
＞漏れ的にはPCは１人一台orそれ以上が基本だと思うから、
＞INIﾏﾝｾｰ派。

大学とか会社とか、そういう組織で使う場合かな。
あとはまあ家族で使う場合とかもあり得るかも知れないけど
家族でそんなきっちり管理者とユーザと権限分けて…
…とかってあんまやらないかな?

俺は個人でしか使わないからINIマンセーなんだけど。

レジストリじゃないといけないケース、もう1つ思い出した。
そのアプリがインストールされてる場所を示す情報。
バージョンアップの際インストーラが
前のバージョンを上書きするために必要。
レジストリに場所を保存しておかないと
いちいち全フォルダスキャンして探すことになってうざいからね。

例えばRocketMouseはインストーラがデフォルトで
Program Files\MajoSoft\Rockm にインストールしようとするんだけど、
俺は嫌なので Program Files\RocketMouse にインストールしてる。
ところが新バージョンで上書きインストールしようとしても
また Program Files\MajoSoft\Rockm にインストールしようとしやがる。
いちいち修正するの面倒。
設定なんかはレジストリに保存してるくせに、
そういう情報は保存しないのって気が利いてないなーと思う。

>>121
だーかーらー、デフォルトで\Application Dataを読むようにするんだって。

思うにセクションにユーザー名を使えば楽にマルチユーザーに対応できると思うのだが。

誰もが他人の設定を書き換えられちゃうけどな

>>125
あー、やっと意味がわかった気がする。
保存先をexeと同じフォルダのINIに記録するんじゃなくて、
Application Dataか、それともexeと同じフォルダか、
どちらのパターンを使うかって情報をexeと同じフォルダのINIに記録するわけね。
権限の関係でexeと同じフォルダを使えない場合は
デフォルトでApplication Dataに逝くから問題ないと。
要するにFFFTPと同様のパターンか。

>>126
それだと全ユーザがPower Users以上の権限を持ってないと破綻する
中途半端なマルチユーザ対応になってしまうような。

>>128
えっと、どちらかのパターンかじゃなくて、
Application Dataか、他のフォルダか（exeと同フォルダに限らず）を保存。
例えば、
suzuki=（suzukiのApplication Dataフォルダパス）
だとApplication Dataを読みに行って、
suzuki=（他のフォルダのパス）
だと他のフォルダを読みに行く。
Write権限がなければデフォルトでApplication Dataに行く。

Write権限は無いけどRead権限がある場合は、iniを読んで変更先へ行く。
（この場合、変更先はWrite権限のあるAdminなどがiniを手動編集）
こうすれば管理者がUsersの設定先を共通のものにして、Usersに
同じ設定を使わせることができる。
でもこれは全Usersを編集しなくちゃならなくてめんどうなので、
ShareFlg=1
SharePath=C:\share\hoge.ini
みたいなキーを作っといてShareFlgが1なら全UsersがSharePathのiniを
読みに行くようにするとか。

どちらかしか使わないなんてケチ臭いこと言わないで、
system wide settingはexeと同じフォルダに置くiniファイルに記録
%APPDATA%以下にiniがあれば、その情報で上書き
みたいにすればいいんじゃない?
iniを保存する時はデフォルトでは%APPDATA%に保存しようとするけど
exeと同じフォルダを指定もできるようにする。
%APPDATA%に入れる時はexeと同じフォルダにあるiniファイルとの差分
のみ保存してくれた方がメンテナンスしやすいかも。

>>129をちょっと修正
>Application Dataか、他のフォルダか（exeと同フォルダに限らず）を保存。
で、
suzuki=
の時（つまりキーがカラの時＝デフォルト）にApplication Dataを読みに行く。
そして、
>suzuki=（他のフォルダのパス）
>だと他のフォルダを読みに行く。
はこの通り。
Write権限がなければsuzukiキーはカラのままなのでApplication Dataを読みに行く。
全ユーザを共通の設定にするには
ShareFlg=1
SharePath=C:\share
みたいなキーを作っといてShareFlgが1なら全UsersがSharePathを読みに行く。
ShareFlgのデフォルトは0で。

なんだかよくわからなくなるからexeと同フォルダに設定を保存する方がいいと
言う人がいるけど、使う側は今までどおりで特に問題ない。
設定の保存場所がApplication Dataになるというだけ。
どうしてもexeと同フォルダにしたいというなら保存先を変更すればいい。
たぶん設定ダイアログで保存先フォルダを選択するだけの操作になると思う。
それだけすればバックアップやアンインストールのやり方も今までと同じになる。
これだけの操作で済むんだから手間にならないよね？
そしてこれだけの手間で、やろうと思えば>>88のようなセットアップパターンが提供できる。

>>130
設定の保存先を記録するiniもsystem wide settingだしね。
ソフトによるだろうけどsystem wide settingなものは同フォルダでいいと思う。

なるほど、設定のオーバーライドはいいかもしんない。

これはオーバーライドできないって情報もシステムワイドセッティングに
持たせられるともっとよさげ。

>>130 >>131
なんだかややこしいので、
結局作る人的にはレジストリが一番楽なのであった…

>>134
俺もややこしく思うから、マルチユーザとか考えずに、
EXEと同じ場所にINIファイル作って使うようにしよ…
どうせ多重インストールしても問題ない作りにしてるんだし。
マルチユーザしたければ多重インストールしてください、と。

フロッピーで使うことを考慮するならEXEと同じ場所だな
そもそもWindows95で %userprofile%\Application Data を取得できるのか？

CString strINI;
int nShareFlg = GetPrivateProfileInt(セクション, _T("ShareFlg"), 0, exeと同フォルダのini);
if(ShareFlg == 1){
　　GetPrivateProfileString(_T("SHARE"), _T("SharePath"), NULL, buff, buffのサイズ, exeと同フォルダのini);
　　strINI.Format(_T("%s"), buff);
}else{
　　GetPrivateProfileString(_T("USERS"), ユーザ識別名, NULL, buff, buffのサイズ, exeと同フォルダのini);
　　if(!lstrcmp(buff, NULL))
　　　　strINI = %userprofile%\Application Dataのパス；
　　else
　　　　strINI.Format(_T("%s"), buff);
}

以後strINIにあるiniファイルに読み書き、みたいな感じじゃダメ？

うーん、このスレを有名ソフトの作者が見てて実装してくれればなぁ・・・
俺はもう少しここでの案が固まったら自作ソフトに実装しようと思う。
無名ソフトだがな！

関係ないけどTeraPadがバージョンアップしてマルチユーザ対応になってた。
exeのサブフォルダにユーザのフォルダ作ってるけど。

>>130
UNIXのrcファイルがそうだな
>>138
>exeのサブフォルダにユーザのフォルダ
インストーラが各サブフォルダのセキュリティ設定まで
してくれるならそれもアリだと思うけどね

>>135
マルチユーザーにしたければレジストリ使って下さいじゃ、ダメかな？
……と、ずっと言いたかったんだけど、まあここの議論から新しい
可能性が生まれるってことも否定できないし。

>>140
設定の保存方法をユーザーに選ばせるというのはどうもなあ…
はっきりいって大多数のユーザーにとって設定がどこに保存
されるかなんてどうでもいいことだし。

ちなみにXPのガイドラインでは、システム全体にインストール
する権限がないユーザーがインストールしようとした場合、
個人用にインストールするかどうか選択権を与えることが
推奨されている。

マルチユーザーの奴は別々にインストールしやがれ！

>>140
たしかにレジストリの方が推奨されてるし手っ取り早いからいいんだけど
それでもやっぱりiniがいいっていう作者・ユーザがたくさんいるわけで・・・
マルチユーザでレジストリを使うよりApplication Dataのような場所を使う
理由の一つは、かなり前に書いたんだけどアンインストールが楽だってこと。
レジストリでは各ユーザの設定は基本的に消さないけど、iniだとAdminから
アンインストーラ使えば全ユーザのApplication Dataを走査して設定を消せる。
もちろんこう言うと「各ユーザのレジストリくらいそのままにしてても問題ない」
となるわけだけど、消したい人もいるわけで、だからこそドキュメントに
設定ファイルやレジストリの場所を書くわけで。
まぁ別にどっちがいいという話ではなくて、言われるとおり可能性の一つを探って
みようじゃないか、と。

>>141
>>140が言ってるのは作る側がソフトを作るときにレジストリを使用するような
ものを作って下さい、ってことだと思われ。

>>143
個人的には覗けるからといって勝手にファイル消されたら
思わず暗号化したくなるくらいムカつく。
ちなみに他ユーザーのレジストリはregedt32を使えれば
余裕で覗けるし、プログラムがユーザプロファイルをロード
するためのAPIも提供されてる。

>>144
>個人的には覗けるからといって勝手にファイル消されたら
ん？どこに対するレス？管理者が勝手に設定を消したらムカつくってこと？
管理者がアンインストールするなら問題ないんじゃ？
仮に管理者がソフトをアンインストールして、各ユーザの設定だけ残すと
どんなメリットが？

>ちなみに他ユーザーのレジストリはregedt32を使えれば
regedt32を使ってハイブをロードするのは簡単だけど、アンインストーラに
実装するのはファイルを削除することより面倒だと思った、が、
言われてみれば変わらないかも。LoadUserProfileだよね？

>>145
UNIXではrootが一般ユーザーのrcファイルを消して回ったりする
のが普通なんですか?
むしろ管理者権限でユーザーのプライバシーを侵してまで
わざわざ削除することにどんなメリットがあるのか聞きたい
んですが。

"Designed for Microsoft Windows XP" Application Specification 2.2
にはこう書かれています。
http://www.microsoft.com/winlogo/downloads/AppSpec22.doc
> The removal must be clean enough to allow the application to be
> reinstalled later. User preferences may be considered user data and
> left behind, but an option to do a completely clean removal should be
> included.
>
> In general, all user data should be left on the system after removal. If
> your application removal is about to remove user data, the user must
> be prompted for confirmation.

ちなみにレジストリを使わなくてもApplication Data
に.iniファイルを保存するなら、このガイドラインには違反しません。

>>145
>仮に管理者がソフトをアンインストールして、各ユーザの設定だけ残すと
>どんなメリットが？
については、管理者じゃない人間が
「え〜！　あのソフト消しちゃったのォ！　また入れてよ」
ということで入れ直したとき、以前の設定で使えるというメリットが（笑）。

……しかし、まあ、この場合「消すけどいい？」って最初に訊くべきで、
「うん、いいよ」と答えたら、答えた以上、自分の設定も消されても文句はない
という関係があるべきで。その場合も >>144 はムカつくのかな？
言いたいのは、使う側（管理者とそれ以外の人間）の問題であって、
そーゆー仕様ならソフト側は >>143 の言うようにバッサリ消すような
アンインストール方法を用意した方がスッキリはするわな。

フリーソフトを試すごとにゴミがたまっていくなんてやめて欲しいが。

要するに全部消すのか各ユーザの設定は残すのかを選択するオプションを
アンインストーラに付けろってことか

>>150
いや、繰り返しになるけど、アンインストーラの仕様としては、
消す場合はバッサリ消した方がいいんじゃないの？
おれが言いたいのは「消すけどいい？」と他のユーザーに訊くのは管理者の責任で
ソフト側はそこまで用意する必要ないんじゃないかってこと。

>>151
いや、上の英文のこと。

>>152
了解。直後に書かれたっぽい気がしたので、誤解した。スマソ。

やっぱりこういう設定の話をしていくとインストーラ／アンインストーラまで
話が及んでいくねぇ。
汎用のインストーラ／アンインストーラでこういうオプションは提供
できるのかな？？
情報求ム。

つーことでおまぃたちこれから "ini使うときは" \Application Data使って、
オプションで設定の保存先を変更できるようにすること。
保存先情報などのシステムワイドな情報はexeと同ディレクトリに保存。
こうすることで>>88のような各環境に対して様々なセットアップパターンを提供できる。
各ユーザーの設定を削除できるアンインストーラが含まれているのが望ましい。
各ユーザーの設定を残すのならば、アンインストーラを使わずにインストールした
フォルダを削除するだけでよい。アンインストーラを使ってもよいがその場合、
アンインストーラには各ユーザーの設定を残すか削除するかの選択オプションが
含まれているのが望ましい。
そうすればユーザーから「なんて柔軟性のあるソフトなのかしら……好き（ぽっ」
となること間違い無しだ。

Application Data って、素のWindows95で使える？
どうやって、Application Dataのフォルダを取得するの?

>>156
今MSDN見たんだけど、Windows95だとIE4.0以上がインストール
されてないとダメってこと？

もしWin95にはIE4.0以上をインストールしなければフォルダが取得できないなら、
Ａ．Windows95をサポート外にする
Ｂ．ユーザーにIE4.0以上をインストールすることを促す
Ｃ．SHGetSpecialFolderLocationを使わず自力でApplication Dataを探す
Ｄ．Windows95は例外としてexeと同じフォルダに置く

>>158
そこまでコーディングに手間かけてられない
(んなヒマあったらもっと別のトコロに力注ぎたい&注いで欲しい)
ので、素直に多重インストールOKなコーディング、
EXEと同じフォルダ決めうちで構わないと思うが…

ぶっちゃけた話、そういうのが簡単にできるクラスやアンインストーラを
作っていただきたい。

ちょっと質問。
IE4.0以上をインストールしてなくても、Windows95に
\ユーザ名\Application Dataフォルダ自体はあるんだよね？
（できれば正確なパスを教えて欲しい）

>>161
確かIE4.0以前のWindows95には存在しなかったはず。

なんてこった

http://www.geocities.co.jp/Beautycare/4965/public/GetDataDirPath.txt
NT系ならデフォルトで
　ユーザ名\Application Data\アプリケーション名\
のパスを、9x系ならデフォルトで
　exeがあるフォルダ\ユーザ名\
のパスを取得し、システムワイドiniファイルがあれば
それに従ったパスを取得する関数を作ってみた。
とりあえず動く用でエラーチェックなど細かいことはしていない。MFC。Win2kで確認。
>>156-158よりWin95だとDLLのバージョンの問題があるらしく、
DLLバージョンチェックがめんどうなので乱暴にNT系と9x系で
デフォルトフォルダの場所を分けたけど、バージョンチェックとか
細かいこともやってくれる人がいたら幸せ。

>>164
とりあえずこういうことをやるだけでもエライ！

>>164
CSIDL_APPDATAをサポートしない環境ではSHGetSpecialFolderLocationが
E_INVALIDARGを返すから、戻り値を見て自力で計算するかどうか決めるほう
がOSのバージョンチェックよりもいいと思われ
どうしてもバージョンチェックでやるとしても、シェル関数の場合はDLLバージョン
を見るべき。
http://msdn.microsoft.com/library/en-us/shellcc/platform/Shell/versions.asp

つーかshfolder.dll付けてSHGetFolderPath使えば解決。

あと全ユーザ共通設定にされてて、.iniの位置がUsers権限で
書き込めない場所だったら困るなあとか。
せめて書き込めるかどうかチェックしてほしい。

shfolder.dllを入れるのが一番簡単で確実かな？サイズも大きくないし。

>>168
それは設定する人間（たぶん管理者）がDQNぽいけど、
確かにプログラムでチェックしたほうが親切には違いない。

shfolder.dllはこちら
http://www.microsoft.com/downloads/release.asp?ReleaseID=30340&area=search&ordinal=1

>>171
あれ？「shfolder.dllを入れる」ってのはshfolder.dllを
ユーザーにインストールしてもらうって意味じゃないよね？

もしかしてデフォルトNT4.0もCSIDL_APPDATAをサポートしてない？
やっぱShFolder.dllか。

/etcがホスィ。
パーミッションもホスィ。

昨日OS再インストールしたんで、断然INIファイル派です。

shfolder.dllを付ける場合、どういう方法でつける？

>>172
ライセンス的に再配布可能であることがはっきりしてたほうが
安心かと思って

>>177
おまえ気が利くな

shfolder.dllが簡単だと思ったらSDKをDLしないとshfolder.libとか
手に入らなくて鬱

http://www.geocities.co.jp/Beautycare/4965/public/GetDataDirPath.txt

shfolder.dll＋SHGetFolderPath版てことで。

起動時にiniをサーチする順番
　(1)コマンド指定フォルダ
　(2)プライベートフォルダ(c:\document and settings\... 等)
　(3)本体と同じフォルダ
設定変更時／終了時の書き込み先優先順
　(1)コマンド指定フォルダ（指定されている場合）
　(2)起動時と同じフォルダ（←ミソ）
　(3)プライベートフォルダ（user名が取得できた時のみ）
　(4)本体と同じフォルダ（書き込み可能な場合）
としとけばいいんじゃねーノ？
んで、
・ユーザー毎に設定を分けたい場合は、プライベートフォルダに
　iniを個別に作っておく。(win2kならdefault userを使うとラク)
　あるいはショートカットのコマンド指定で振り分け。
　（これも環境変数%user%を使えばラク）
・シングルユーザで使うorマルチユーザ環境で設定を共有したい場合は
　コマンド指定or本体と同じフォルダにiniを置く。
とすりゃいい。

あと以下は必須じゃないが
・レジストリや環境設定によるフォルダ指定機能
・ツールやプロパティでiniを移動する機能
・本体フォルダに書き込めない場合の次候補（temp等）
なんかも用意しとくと完璧だと思われ。

× 環境変数%user%
　　　↓
○ 環境変数%username%

なんか扱いが分かりやすいのがINIの利点なのに面倒くさくなっていくな…
作者としても、ユーザとしても。

>>183
同意。
実際にこのシステムのソフトが作られたとしても
「分かりにくい」とかいってまたここで叩かれそう。

>>181
iniの保管先をシステムワイドiniじゃなくて優先順位で区別するみたいだけど
>・ユーザー毎に設定を分けたい場合は、プライベートフォルダに
>　iniを個別に作っておく
や
>・シングルユーザで使うorマルチユーザ環境で設定を共有したい場合は
>　コマンド指定or本体と同じフォルダにiniを置く。
みたいにアプリケーションを使う前に、ユーザに前処理が必要になるってのは
どうもなぁ……

>ユーザに前処理が必要になるってのはどうもなぁ……
スマソ。説明が悪かった。（特に後半は蛇足）

一応ソフトがデフォルトでiniを保管する場所は
・マルチユーザ環境ならプライベートフォルダ。
・プライベートフォルダに書き込めない（≒シングルユーザ）なら、
　本体と同じフォルダ。
で、保存する場所を変えたい場合にのみ
・手動でiniを移動させる。
・コマンド（や環境変数、レジストリ）で強制的に指定する。
のだと考えてオクレ。

コレで
・マルチユーザーのことを考えろやｺﾞﾙｧ。
・マルチユーザ環境で設定を共有できなきゃｲﾔﾝ。
・iniは本体と同じ位置がｲｲ!（持ち歩きたい）
・面倒なのは逝ｯﾃﾖｼ。
といった要求をすべて満たせると思うのだが。

保全age

>>186
デフォルトでレジストリにしちゃってさ、インストール時に

標準／レジストリに設定を保存します。
特に問題を感じない場合は、こちらをセレクトして下さい。

カスタム／設定の保存場所をカスタマイズします。
マルチユーザーでの ini ファイル使用なども考慮することができます。

で、いいんじゃないの？　どうでしょ？

>>188
そこまでする必要ないよ。こんなソフトあったらむしろヤだよ、俺。
どうせ半年もすればOSごと再インストールするんだし、細かいこと
気にしないで、もっと気楽に使おうよ。みんな几帳面すぎ！

レジストリの掃除にはうるさくても、部屋の掃除はしてなかったりして…

>>189
気楽に行きたいのなら、黙って「標準」を選べばいいと思うんだが……。
インストール時に選択肢のあるソフトなんていくらでもあるじゃない？
ちなみにおれは、「レジストリ使ってもＯＫ派」なんだけど、
ここでの議論は面白いし、何かの形で実を結ぶ可能性があると思うよ。
それより……
＞どうせ半年もすればOSごと再インストールするんだし、
この手の話が出るたび、いつも不思議に思う。
まともに使ってて、そんなに再インストールってある？
おれ、結構いろんなソフト使ってるけど、二台持ってるうち、
一台は Win95 で、３年以上普通に動いてるし、もう一台は Win2000 に変えるまで
Win98 のまま、１年半、問題なかったけどなあ……。
スレ違い気味でスマソ。

>>190
だいたい同意です。
俺も「レジストリ使ってもＯＫ派」。

9x使ってた時は、年に2,3回はOSから再インストールしてたかも。
2kにしてからは再インストールしようと思わない。

インストーラを使うなら>>188に同意。
ソフト側で対応するならマルチユーザ用iniもありだと思うんだけど、
デフォルトはexeと同じフォルダに保存するようにした方がいいと思う。
PCを一人で使ってる人が圧倒的に多いだろうから。
オプションでマルチユーザ用を選択するというのはどうか。

http://www.geocities.co.jp/Beautycare/4965/public/sample0.html
ユーザの設定ファイルはデフォルトで \ユーザ名\Application Data\sample0\ に
setting.iniという名前で保存し、保存場所は変更可能なサンプルプログラムを
作ってみた。
逆に>>192のようなデフォルトがexeと同フォルダバージョンも作ってみようかと思う。

>PCを一人で使ってる人が圧倒的に多いだろうから。
家ではそうかも知れないけど、職場や学校でもPC使ってる人も相当いると思うYO!
もっともシングルユーザ環境で使いまわししてる場合が多いだろうから、
「マルチユーザはオプションで」というのには同意。
ただ>>193のサンプルみたいに、一般ユーザーが各々指定しないとダメ(?)なのは
あまり意味が無いと思う。
普通マルチユーザ設定は管理者がやる事だし。

>181,186
・デフォルトでは本体と同じフォルダ
・↑が（管理者により）書き込み禁止にされてるなら、
　　本体と同じフォルダ/setting/個人用フォルダ
・↑も書き込み禁止なら、Win標準の個人用フォルダ
・もしくはコマンド/レジストリ/環境変数/ini 等で指定のフォルダ（最優先）
に保存の方が良くない？

>>194
>ただ>>193のサンプルみたいに、一般ユーザーが各々指定しないとダメ(?)なのは
管理者が設定してUsersが書き込み権限のないフォルダに入れておけば
いいんだよ。

>管理者が設定してUsersが書き込み権限のないフォルダに入れておけば
>いいんだよ。
ユーザー数×ソフト数だけ設定しないとイカンのですよ？

>>196
え？なんで？
>>193はデフォルトでマルチユーザ対応なんだよ？
全ユーザ共通にしたかったら一回チェック入れるだけでいいんだよ？

指定したフォルダ以下に変更したい、という要望は多いと思いますが？
特に>>193氏のサンプルはWin標準の個人用フォルダ以下ですし。

Win2k、半年に一回のペースで再インスコしてます。
でもWin9xの時は2ヶ月持てば(ﾟдﾟ)ｳﾏｰだった(；´д｀)

てなわけで使うなとヒステリックには叫ばないけど、
「なるべくならレジストリ使わないでINI使ってくれ」派。

（　・∀・）あと目くじら立てずにもう少しﾏﾀｰﾘ逝こうよ

>>198
あぁそうか、設定を共通ではなく、かつフォルダの位置を変更したい
場合か。確かに。

分かってもらって良かったYO!
でもiniはテキストファイル=>一括変換も可能だから、さほど設定に苦労はしないカモ
…と今更気付く。
少し言い過ぎでした。ゴメンナサイ。（特に>>193氏）

ところで2ch-modeの設定ファイルがいつのまにか消えてて、気付かずage進行してた…
切腹。

http://www.geocities.co.jp/Beautycare/4965/public/sample1.html
デフォルトがexeと同フォルダに保存するバージョンを作った。
>>194案も考慮してみた。
たいていの人（従来通りexeと同フォルダに保存すればii!!と言う人）には
設定することすら必要ない。今まで通り起動して閉じるだけ。
アンインストールも展開したフォルダごと削除。

マルチユーザに対応すれ！と言う人にも、たぶんチェックボタンやラジオボタンを
押すだけで十分だと思う。

なお、UIはもっと改善したほうが良さそう。あまりうまい言葉が思いつかなかった(;´Д`)

Win98とWin2000をデュアルブートで使っているのですが、
Win98で使っていたINIに設定を保存するアプリをWin2000で使ったら
動作がおかしくなる事ってありますか？
（もちろん2000にも対応しているアプリで）

>>203
2000に対応してておかしな動作をするならバグなんじゃないすか

>>204
レスありがとうございます。
設定情報以外にOSに関する情報とかもあったりするのかと思って、
今まで積極的に使えないでいました。これからWin2000で使ってみ
ようと思います。

>>205
アプリによるだろうに。

http://www.geocities.co.jp/Beautycare/4965/public/sample1.html
・EXEファイルのあるフォルダ以下にユーザ別フォルダを置く
という項目を追加した。

HKEY_LOCAL_MACHINEとHKEY_USERSの使い分けがまともなら
こんな泥臭いことにはならなかったのに。
Unixの、一般ユーザーでもホームディレクトリの下に
勝手にソフト入れられる世界とは雲泥の差だ。
まあUnixはUnixで、ソフト毎に書式が違ったりして
結構アレなんだが。
もう少しだけUnixを忠実にパクって欲しかった。
MSがTerminal Server Editionの悲劇を繰り返さない
ことを祈る。

設定がなければexeと同フォルダでインストーラがマルチユーザ対応の
設定を書くというのはどうか。
インストーラなら書けないということはないはずだしわざわざインストール
しようとする人はマルチユーザで使えたほうが望ましいだろうし

Win9xがDQNでなければレジストリが便利だろうが

>>208
2回死ぬほど激しく同意

>>209
>インストーラなら書けないということはないはずだし
どういう意味？

>>212
インストーラはAdminで起動するはずだしそうじゃなければ
個人用インストールになるはずなのでどっちにしても
問題ない

>>208
でも~/直下に環境設定ファイル・フォルダを置きまくるという慣習はとっても嫌ずら。>Unix
~/etc 以下とかにまとめてほすィー。
自前でスクリプトを直せば良いんだろうけど、面倒。

レジストリなんて大嫌い。
あと、Windows＆Systemフォルダに大量にある謎のファイル。

>>207のサンプルにある機能でとりあえずええか？ええか？ええのんか？

誰も見てないに1ドラクマ

ごめん、おせっくすのこと考えてて見てなかった。

つーかインストーラっている？
必要なさそうなのにわざわざインストーラ使ってるのがあると思われ

http://www.nakka.com/lib/
iniファイルアクセス関数
これ使うと速くなるのかな？

>>219
インストーラ使うまでも無いソフトはzipなんかでまとめてくれるだけでｲｲ。
特にフリーソフトを何個か試用するときはすぐ使えてすぐ削除する操作を
くりかえすから。

>>216
（・∀・）ｲｲ！乳頭の色はピンクが（・∀・）ｲｲ！

.iniアクセスをむやみに独自関数に置き換えられると
NTでレジストリにリダイレクトする機能が効かなくなって
嫌だな

iniのアクセス速度が気になるのは大量のデータを起動時に読み込むような
時くらいしかないんじゃ？

さて、独りでこっそり進めるか……

shfolder.dllは明示的リンクのほうがええかな

同梱するなら明示リンクでいいと思われ

揚げ

http://www.geocities.co.jp/Beautycare/4965/public/cmultiini.html
CMultiINIクラスをこっそりアプするか……

揚げ

HKEYの読み方はﾋｯｷｰで(・∀・)ｲｲ?

>>231
どうでも、(・∀・)ｲｲ!!

ﾋｯｷｰ・ｶﾚﾝﾄ・ﾕｰｻﾞｰ
おおきなお世話じゃ!!!

zipのまま使えるランチャーと、その仕様準拠のフリーソフトって、イイけど、無理だろな。
少なくとも、体験版でバリバリレジストリを汚すのは、止めて欲しい。
ぐるぐるまわるけど、HDDも安くなったんだし、exeとiniは、同じ場所で良いのでは?

だから、同じ場所じゃマルチユーザ対応できんだろが(るーぷ)

ユーザごとにEXEいれろってことじゃないの？

>>234
HDDの容量は問題にしてないと思われ

ユーザが自由に EXE ファイル入れれちゃ管理のかの字もねーよ(^^;

おいおい話がかみあってねーぞ

Setting Policy を共有できるクラスとかライブラリあったらいいのに。
プログラム側では、
system wide な読み込み、個人データ読み書きとかのメソッド使うだけで、
後ろでなにやってるかは気にしないと。

>>240
あってもみんなが使わないと意味ない
というかそれがまさにレジストリAPIでは…

http://www.geocities.co.jp/Beautycare/4965/public/cmultiini.html
CMultiINIDialogクラスをこっそりアプしてみるか……

そもそもレジストリエディタがダメ。
ツールバーもねぇし。
検索トロイし。
拡張子大文字で付けるし。
比較機能ぐらい付けろや。

汎用プロファイルマネージャっていうのはどうか
プロファイルマネージャってのはNetscape6についてるやつ

>>240 みたいなライブラリのフロントエンドに >>244 みたいなのを
もってくればいいなじゃいかね。

>>240 のいってるのってまさに GConf やんかー。
http://cj3134981-a.kkbnj1.kt.home.ne.jp/documents/gconf-1.0.x-refs/html/

このGConfっての採用したソフトで有名なのってある？
サンプルとして見てみたい。

　　　　　　　　　　　　　　　　　　　　　　　 　　　,. 、
　　　　　　　　　　　　　　　　　　　　　　 　 　 /　/　 ＝ -
　　　　　　　　　　　　　　　　　　 　 　 　 　 /　/　　＝ -
　　　　　　　　　　　　　　 　 　 　 　 　 　 /　/　　＝ -　　　　はいはい1000ゲットｽﾞｻｰｰ
　　　　　　　　　　　　　　　 　 　 　 　 　 /　/　　　　　　　　っと。
　　　　　　　　　　　　　　　　　　　　　 　/　/　　　
　　　　　　　　　　　　 　 -―￣￣ ｀ ―'　 ,　_
　　　　　　　　　　,　´ 　　　　　　　　　　 　 　 ￣"　ー 　　　　　　　　_＝
　　　　　　　　_／　　　　　　　　　 　 　 　 　 　 　 　 　 　 ｀　、　　＝
　　　　　　 , ´　　　　　　　　　　　　　　　　 　　,ﾍ　　　　　　　　ヽ　　　＝
　　　　,／　　 ,|　　　　　　 　 　 　 　　　　 　 　●　　　　 　 　,／
　　　と,-‐ ´￣　　　　　　　 　 　 　　　　r(　　 `'　　　　　　く　　　三　＝　　　　　(⌒
　　(´＿＿　　　､　　　　　　　 　　　　 　`(　　　,ﾍ　　　　　　 ヽ　　　　三　＝(⌒
　　　　　 ￣￣｀ヾ＿　　　　　　　　　　　　　　　●　　　　　　　 　_>　　　（　⌒　　　　(⌒
　　　　　　　 　 ,＿ 　＼　　　　　　　　　　　　　`' _＿　　 -‐ ´　　　三＝(⌒　　　(⌒
　　　　　　　　(＿_ ￣~"　＿＿ , --‐一~￣￣￣　　　　　　三　　＝(⌒ 　(⌒
　　　　　　　　　　￣￣￣　　　　　　　　　　　　　　　　＝（⌒(⌒　　＿＿

>>246
GConf は GNOME の一部だったはず。
だから 基本的に UNIXer 向けじゃないかと。

あくまで一例として挙げたまで。

レジストリ API と INI API をぶんどって
ほにゃららするような DLL 作らんかね。

どうほにゃららするのが一番問題だな。
薄いラッパならGoogleですぐヒットするほど公開されてる。

おれは「レジストリ使っていい派」だけど（しつこい）、
INI API ぶんどりは賛成ナリ。INI への読み書きが早くなればなにより。
ついでにタブ区切り式定義ファイルとかも
読み込みだけでいいから出来たらイイかも。
辞書ソフトとかに応用が……（あ、スレ違いになりつつある）

>>249
ここで挙げられたいろんな置き場所をユーザが選べるようにするってのは？
んで、レジストリ & INI API で書き込まれたものは
全部そのユーザが指定した場所の指定した形式に落されると。

あーでも、レジストリ API をぶんどるのは危険かなぁ。
Windows 自身が使ってる部分とかもあるだろうし。

バックエンド切り離せればなぁ...
設定を ACAP から引っ張ってきたり、LDAP から引っ張ってきたり...
いろいろ楽になると思うんだが。

プログラマーも楽だろうし。

ぶんどる利点を挙げてくれい

>>252
普通に INI とかレジストリを使ってる既存のアプリケーションを
変更することなく設定の置き場所変えられる点。

新しい方法考えたとしても、結局プログラマがそれに対応しなきゃ使えないわけだし。
だったら API を置き換えるしかないんじゃないかと。

APIぶんどるのは難しいよ

>>254
素人な漏れには DLL 置き換えみたいな方法しか思いつきません。
なんか危険な気がする。

他にどんな方法が考えられます？

そこまでやるなら素直にOSから作るがよろし

どこが素直なのか理解に苦しみ悶えアンアンといやらしい声が漏れてしまいそうだ。

>>256
なんか素人丸出しな意見だね。

>>257
素直にうけた。

>>256
素直を通り越してひねくれにいっとるわい

age

結局APIぶんどりは無理ってことか？

毎度、APIどんぶりくれよ

APIどんぐりならあるんだが...

c:\Documents and Settings\ユーザー\Application Data
c:\Documents and Settings\ユーザー\Local Settings\Application Data
とかのディレクトリを求めるにはどうすればいい？

なんかいいやりかたないかな

INI 派。特に対したわけでもないソフトがレジストリ使っていると萎える。
たいしたソフトなら別に良いんだけどっていうのはわがままですか？


　　　　　　　　　　　　　　　　　　　　　　　 　　　,. 、
　　　　　　　　　　　　　　　　　　　　　　 　 　 /　/　 ＝ -
　　　　　　　　　　　　　　　　　　 　 　 　 　 /　/　　＝ -
　　　　　　　　　　　　　　 　 　 　 　 　 　 /　/　　＝ -　　　　はいはい0x10Aゲットｽﾞｻｰｰ
　　　　　　　　　　　　　　　 　 　 　 　 　 /　/　　　　　　　　っと。
　　　　　　　　　　　　　　　　　　　　　 　/　/　　　
　　　　　　　　　　　　 　 -―￣￣ ｀ ―'　 ,　_
　　　　　　　　　　,　´ 　　　　　　　　　　 　 　 ￣"　ー 　　　　　　　　_＝
　　　　　　　　_／　　　　　　　　　 　 　 　 　 　 　 　 　 　 ｀　、　　＝
　　　　　　 , ´　　　　　　　　　　　　　　　　 　　,ﾍ　　　　　　　　ヽ　　　＝
　　　　,／　　 ,|　　　　　　 　 　 　 　　　　 　 　●　　　　 　 　,／
　　　と,-‐ ´￣　　　　　　　 　 　 　　　　r(　　 `'　　　　　　く　　　三　＝　　　　　(⌒
　　(´＿＿　　　､　　　　　　　 　　　　 　`(　　　,ﾍ　　　　　　 ヽ　　　　三　＝(⌒
　　　　　 ￣￣｀ヾ＿　　　　　　　　　　　　　　　●　　　　　　　 　_>　　　（　⌒　　　　(⌒
　　　　　　　 　 ,＿ 　＼　　　　　　　　　　　　　`' _＿　　 -‐ ´　　　三＝(⌒　　　(⌒
　　　　　　　　(＿_ ￣~"　＿＿ , --‐一~￣￣￣　　　　　　三　　＝(⌒ 　(⌒
　　　　　　　　　　￣￣￣　　　　　　　　　　　　　　　　＝（⌒(⌒　　＿＿

>>265
過去ログにあったような。

>>266
確かに「ちょっとした設定しかないのにレジストリを使われると萎える」
という意見は多い。でもその理由は「なんとなく」ってのもまた多い。
俺は、使っているレジストリエントリをドキュメントに書いてくれたり、
アンインストーラで消してくれるソフトなら、ちょっとした設定にレジストリを
使ってもいいと思ってる。

SHGetSpecialFolderLocation()使え
あとは自分で調べれ
ちなみにApplication DataはCSIDL_APPDATAだ。

>>267
>確かに「ちょっとした設定しかないのにレジストリを使われると萎える」
>という意見は多い。でもその理由は「なんとなく」ってのもまた多い。

こういう人種も。
http://pc.2ch.net/test/read.cgi/win/1007435105/637-640n

>>267
レジストリを消しても再構築しないとサイズは元に戻らないよ。
ちょっとした設定ならINIがいい。

えーと、言いたかったのはレジストリとINIのどちらを使ったほうがいいか
じゃなくて、レジストリを使うかどうかの判断に「ちょっとした設定」か
「重要な設定」かはあまり関係ないのではないかと。
> 「ちょっとした設定しかないのにレジストリを使われると萎える」
っていうと、まるで重要な設定ならレジストリを使ってもいい、みたく聞こえるじゃない？
でも実際は重要な設定だろうとなかろうとINIの方がバックアップなどに便利だし、
レジストリを使うなら重要な設定だろうとなかろうとレジストリを使ってることには
変わりないんだし。

それより、気になったのが>>269の挙げてくれたスレの
> 将来的にはレジストリにアプリのデータを保存しないようにすると、なにかでよんだ気がする。
> 多分DOS/V magazine。
ってやつ。本当だとしたらうれしいんだけど、いつのDOS/V magazineかなぁ。

当たり前だけどレジストリは登録するもんであって
iniは初期化するもんであって
どちらもアプリケーションのデータを置くものじゃないのね。
つーか、Application Dataに置くのが正解。
C#のIDEで有名なSharpDeveropとかIrvineはそうしてる。

あとAPIぶんどりの話が出てたけどAPIって本来の目的と外れた場所で
使われてることもあるから全然関係無いのがまともに動かなくなったりするよ。
たとえば.url(ｲﾝﾀｰﾈｯﾄｼｮｰﾄｶｯﾄ)とか。

漏れ、可能な限りINI派。

>>271
多分だがそういうことではなくて、シェル拡張とか
アンインストーラの登録とか、拡張子関連づけとか、
「レジストリに書き込まねば実現できない」
ことってあるでしょ？
それのことでは無いかと思われ。

どっちにしろﾃﾞﾌｫでONにされるとムカっと来るが(藁


>>273
素で疑問に思ったことなので気を悪くされたらｽﾏｿ。
ではINIって元々どういう事が記憶されてたの？

漏れはPC触りだしてそういうことに手を突っ込むように
なってから、INIは設定ﾌｧｲﾙだとﾊﾞｶｰﾘ思ってた…
INIがInitializeの略だと知ったのは、実は去年…

>>273
名前の通りにいけばそうだけど、じゃあアプリケーションが
HKEY_CURRENT_USER\Software に登録するものって例えば何？
MS自体がINI→レジストリに設定を保存するように推奨してるんだから、
これらはもともと同じ働きをするものと考えて良いんじゃないかな。

>>274
INIは設定ファイルだよ。ファイルのプロパティ見てごらん。

>>274
>INIって元々どういう事が記憶
今のレジストリと同じ。
元々OSの初期化のために作られて、ついでにアプリケーションの設定にも使われた。
初期化のためにあるから書き込みよりも読み出し用って感じ。
読み取り用のAPIには数値を取得するものがあるけど書き込み用には数値用のが無くて、
数値を書き込む場合は一度文字列に変換してから文字列として書き込まないといけなかったりする。

当然、今現在はただのレガシーAPIで、
開発者用のMS配布のドキュメントには
>Note This function is provided only for compatibility with 16-bit Windows-based applications.
>Applications should store initialization information in the registry.
と、ちゃんと書かれてある。

>>275
>HKEY_CURRENT_USER\Software
今現在の使われ方をするためのものとして存在してるけど、"ついで"として使われてるだけ。

ちなみに俺はiniファイル派だったりする。
自分で作るアプリは全てiniに設定を保存してる。
たぶん世の中がXMLで設定を保存するようになってもiniファイル使ってると思う。

> 今現在の使われ方をするためのものとして存在してるけど、"ついで"として使われてるだけ。

あんたの好みという以外の根拠は?

良スレage

「アプリケーションのデータ」って例えば？
アプリの設定は含まれないよな？

設定とデータの区別ってわからないね。
MozillaなんかはApplication DataにブックマークやCookieを保存するけど
これはデータとも言えるし設定とも言えるし…

Microsoftはレジストリに保存するかApplication Dataに保存するかは
64KBを目安に決めれと言ってる

フリーウェアなんかは絶対にレジストリをいじられたくなかったり
でもさんざんいじられてるのでそのうち新規ウィンドウズインストールできれいに消すことになる

>>283
だからさー、そういうときはいじられたくない根拠を書こうや

>>282
それは64KBを超える場合はレジストリにしろってこと？
ソースを教えて欲しい。

設定とアプリのデータについて個人的には、
「データ」はおおざっぱに言えば操作によって増減するファイルのようなもの、
（例えばブックマークやキャッシュファイルやクッキーなど）
「設定」はそれ以外のアプリに関する設定だと思っていた。
思いっきりローカルルールだけど。

上で言われているように，もっとMSは
レジストリを使う人のためにレジストリ礼儀作法を厳しく指示するべき…

たまに大量のデータをレジストリに投げ入れたりする酷いプログラムに出くわす．
高速に何度もレジストリにアクセスするようなプログラムまである．

NT系でも9x系でも，レジストリをダイエットさせる再構築には
再起動が必要不可欠だから，運用形態によっては悲惨だ．

>>286
その為のWindowsロゴだったりするんだけどね。
http://www.microsoft.com/japan/windows/logo/

ini使ってると、マルチユーザーでまるで使い物にならなくなるんだよね。
反面、個人で使う場合、iniの方が便利な事も・・・

>>285
逆逆。64KBを超える場合はApplication Dataにしろって書いてある。
http://www.microsoft.com/japan/winlogo/downloads/AppSpec22j.doc
> ・HKCU (HKEY_CURRENT_USER) レジストリハイブは、小さなデータ
> 　(約 64K) の保存やユーザーごとのポリシー設定の保存に適しています。
(中略)
> ・大きなファイルベースのデータは、［Application Data］ フォルダに
> 　入れなければなりません。たとえば、Internet Explorer の一時
> 　インターネット キャッシュはユーザー プロファイルに格納され、
> 　レジストリには格納 されていません。
> ・インストール時に、アプリケーションで HKCU と HKLM に合計 128K を
> 　超えるデータを保存してはいけません。ただし、HKEY_CLASSES_ROOT
> 　は例外です。

よくレジストリの利点は（iniと違って）64KBの壁が無いことだ、っていうけど
まったく逆を推奨してるんだね…

>>289
いや、Application Dataっていうのは、iniというわけでなく・・・
ユーザー毎に持ってるフォルダなので、そこに自由な形式のデータを格納しなっせ。
という事だと思われ。

さーて、MSDNライブラリのWin2000アプリケーション仕様書をちゃんと読むか・・・

>>290
>>289は別にiniを使うとは言ってないと思うが。

>>292
早合点。ｽﾏｿ。

本題から全然外れるけど、
レジストリのsoftware直下のキー名がソフト同士でかぶったり
したことってないのかな。

つーか、Windows も UNIX の仲間もうんこちゃん。まっきんも勿論。
超漢字使え。

>>294
基本的に"software\[作者が付けた任意の名前]\[ソフトウェア名]"になるから
かぶる事は無いんだけどたまに行儀の悪いソフトがsoftware直下に
ソフト名を持ってくるのもあるから注意せないかん。

でかいソフトやレジストリを必ず弄るソフト(関連付けとか)でインストーラ付きのソフトならともかく
ツールと呼ばれる程度のソフトでインストールされたフォルダ以外に
設定とかデータを残しては欲しくないな。

マルチユーザの場合はマルチインストール。これ最強。

>>297
>>284

別にレジストリ弄るのは良いんだよ。
アンインストーラさえついててキッチリ消してくれるならな。
ただ、アンインストーラついてても消さない糞アプリもあるわけで
レジストリに書き込むアプリは何と無く使いたくない。

んで、あちこちにファイル作られるとアンインストール面倒。
それからバックアップもめんどい。

つーかこれ何回も言われてる事だろ。
いちいち書く必要も無いと思うが。

レジストリ弄ってもいい
その代わりアンインストールするとき完全に消せ

これがホントの気持ち

ポイントは
”完全に”
だね
消してると見せかけてよく見ると
鼻くそ程度のこってることがあって
あまり精神的に良くないことが在る

というか、消すのって実は難しいの？

おまえら細かいこと気にしすぎ。レジストリなんか
使ってるうちにどんどん肥大してくよ。新しいソフト
入れなくてもさ。
ディスクのイメージでもとっておいて、数ヶ月に1回
リカバリすればいいじゃん。よさそうなソフトあったら
どんどん試しちゃおうぜ、レジストリなんて気にしないで。

>>303
> ディスクのイメージでもとっておいて、数ヶ月に1回
> リカバリすればいいじゃん。

めんどくさいから嫌だ。

＝＝＝＝＝　終了　＝＝＝＝＝

レジストリなんて，構造覚えてれば，何処にゴミが溜まったか
すぐに分かるから，いくらでもダイエットできるが．
systemに溜まった用途不明のdllだけはドウシヨウモナイ…

>>305
そのダイエットに使う時間は無意味だと思いませんか？

実際無意味だよ。レジストリのサイズ気にするのなんて。

独自のDLLはアプリと同じフォルダに置いて欲しいもんだ。

>>306
好きでやってるんだからほっといてやれよ

アプリケーションにレジストリの書き出し機能がついてると便利だな

自分が作っているものに関してはINI保存+DLL同じ個所。
なんと言っても「アンインストールのとき〜」という記述が楽。

　Win32の手引きとも言えるリファレンスにはレジストリを使え、
と書いているがこれはActiveXの考えと同じだと思う。つまり保
存されているところがどこかを認識せずに使えるってところだな。

　たしかに>>307の言うとおり大した問題じゃないが、INIだとバ
ックアップが楽だという利点がある。レジストリだと全部バック
アップするということをするのもいいかもしれないが効率が良く
ないし。>>310のとおりのような機能があるのもいいと思う。

ふと思ったんだけどさ、設定保存/復帰用のAPIをEXEに仕込んでおくってどうよ?
具体的引数はまだ考えてないけど、とりあえず設定を保存/復帰ファイル名をPCharで。

で、もしこれが標準になれば1つのアプリを走らせるだけで、
INIだろうが独自形式のファイルだろうがレジストリだろうが、
ほぼ全ての使っているアプリの設定の保存/復帰が出来る。

って、寝起きの時の妄想をちょっとまとめただけだから、
あまりキツイツッコミは無しで(汁

過去ログ見れば同じ流れがあるんだが、INIの場合、マルチユーザに対応するためにどうする？
マルチインストールという答えはやめて欲しい。
バージョンアップのたびに何回もインストールするのはめんどうだし、
インストールするユーザの数が少ないとは限らないから。

レジストリ使うかini使うか選択できればいいと思われ
作者は大変だが

>>313
作者からﾏﾙﾁｲﾝｽﾄﾛｰﾙって答えが返ってきたら、
各ﾕｰｻﾞ用のINIを差し替えるて起動するﾊﾞｯﾁ、
もしくはそう言うﾂｰﾙを作ってみては?

>>315
ツール作るにしても結局作者がINI差し替え機能をサポートしてないとならないんだよな。
というか差し替え機能があるなら初めからマルチインストールとは答えないと思われ。

>>316
説明が足りなかったｽﾏｿ。
>そう言うﾂｰﾙ
というのは、
単に現在のﾕｰｻﾞ名を取得、そこから例えば
AppName_CurrentUserName.ini
みたいなﾌｧｲﾙを
AppName.ini
という名前に上書きｺﾋﾟｰ、そしてAppName.exeを起動。
AppName.exeの終了まで待機し、終了したら
AppName.ini→AppName_CurrentUserName.ini
と上書きｺﾋﾟｰする。
こんな感じ。

つまり、対象ｱﾌﾟﾘに切り替えを指示するのではなくて、
こちらが切り替えてしまうｱﾌﾟﾘ。
つうか説明下手でｽﾏｿ、うまく伝わるか不安だ…

俺はマルチインストールでいいと思うけどな。
全てのユーザにインストールし直すのが面倒なのは
各ユーザにインストール任せれば良いんだし。
そもそもユーザごとに使いたいアプリは違うだろうし
管理者の好みを押し付けるってのはなぁ。

管理が行き届きにくくなるって欠点はあるけど。

各ユーザにインストールを任せるってのはなぁ…
ド素人がいないとも限らないし。
実際、XPを家族で使ってるとして、インストールや各種設定なんて
恐くてやらせたくない。
これが学校とかだったらなおさらどんなユーザがいるかわからないしなぁ。
っていうか学校でユーザごとに好き勝手にインストールできるような環境だったら
管理どころじゃないよね。

学校で思い出したんだけど（別に学校じゃなくてもいいけど、大規模な
マルチユーザ環境といえば学校が手っ取り早い例なので。）、
普通、PCごとにリカバリしていくわけで、たいていアプリケーション類は
CドライブのProgram Filesフォルダにインストールされる。
で、ユーザの誰がどのPCを使うかはわからない。（例えて言うなら出席番号順に座るとは限らない）
この場合、UsersアカウントはProgram Filesフォルダには書き込み権限が無いとも考えられる。

こういうとき、アプリケーションの設定はどこに保存するか？
手っ取り早いのはレジストリで、どうしてもINIっていうならApplication Dataフォルダとか。
でもこのアプリケーションを自宅で使うならアプリケーションと同じフォルダに
INIを保存してくれた方が楽。（楽な理由は今まで出し尽くされてきた。）

要するに使う環境によってレジストリ、INI、どっちが便利かってのは
変わってくるんだよね。
だから一番いいのはアプリケーション側がどちらもできるような機能をサポートしてること。
でも作者もめんどうだろうし、作者によって仕様が異なるのも使いにくそう。
だからインターフェイスが統一されて利用するのも簡単なライブラリなんかが
あればいいなと思ったけど、俺にはそんなライブラリを作るスキルは無い！ばか！

>312
COMコントロールとかはそんな感じで標準化されているね。

INI使われると、XPのファーストユーザースイッチ機能やTerminalクライアント
なんかが使えなくな〜る。

>>322
インストール後にも変化するようなINIファイルは、
%USERPROFILE%\Application Data\
%USERPROFILE%\Local Settings\Application Data\
あたりにいれておけば問題なし

>>323
ファーストユーザースイッチと、Terminalクライアントの場合、
同じユーザーが同時にログインして、同時にアクセスすることになるんだけど
大丈夫？
INIが開けませんって落ちるアプリをよく見かけるので・・・。

>>324
標準のプロファイルAPIを使ってる限り問題ないと思うけど。
独自に読み書きしてる場合でも普通は読み書き終わったら閉じるんじゃないの?
落ちるようなアプリはよほど設計がタコなんだろ。
でも%USERPROFILE%の下にini入れるくらいだったらレジストリ使うが。
iniのメリットの大半はexeと同じディレクトリにあることによるものだよね?

age

私物じゃない学校のパソコンとかでオンラインソフト入れるってのもなぁ。
基本的にブラウザと表計算とワープロ入っていればいいし
後、足りない物があれば適当な市販ソフト入れれば十分だと思うが。

共有のパソコンで個人的なことなんて怖くてできん。
というより何をやるわけ？

>>327
学校のPCにも普通にFTPクライアントやTelnetクライアントなどの
オンラインソフトが「標準で」入っているが？
エディタもオンラインソフトだった学校があったな。

>共有のパソコンで個人的なことなんて怖くてできん。
家にPCが一台しかなければ十分ありえる状況だと思うが。

>>328
だから、いちユーザがそのパソコンで何をやるのさ？
FTPはまぁ必要っぽいけどHPビルダーでも入れとけって感じだし
telnetやテキストエディタなんてWindows標準ではいってるやん。
管理者ならともかく、いちユーザには必要なさげ。

＞家にPCが一台しかなければ十分ありえる状況だと思うが。
家庭のパソコンと学校とか会社のパソコンでは話が全然変わるよ。
と言うより、自分が管理しているパソコンとそうでないパソコンではと言った方がいいか。

>>329
いや、今言ってるのは管理者の話だろ？
管理者がソフトを学生用PCにインストールするとき、ソフトはマルチユーザに
対応してるべきで、その対応の仕方はレジストリ云々・・という話の流れだったと思うが。

それからWindows標準という話ならFTPクライアントも標準で入ってるが、
それらが使いにくいまたは機能が少ないから、（市販にせよフリーにせよ）他の
ソフトを使うわけで。

自分が管理してようとなかろうと自分のアカウントがあれば個人的なことはするだろ。
つーかそのためのアカウントだろ。

age

>>330
うん、だから学生用PCのソフトなら適当な市販ソフト入れておけば十分って事。
オンラインソフトを入れるまでもないんじゃないの？と言いたかった。

市販ソフトとオンラインソフトとどう違うのかって言われると
その辺はあいまいなんだけどね。
オンラインソフトでも市販品に負けない物もたくさん有るし。

纏めると､マルチユーザの環境なんてそのPCを使いこなすなんてことは殆どないから
簡単なソフトならそんなにマルチユーザの環境は気にすることもないんじゃないかな？
それだとレジストリ使う必要はないしINIファイルも実行ファイルと同じフォルダに置けばいい。

>>332
ソフトによって完成度が違うからどっちがいいとは言えないね。
FTPクライアントソフトが例に出たけど、それでビルダーを入れるのは
本末転倒では？ビルダーを入れるまでもないんじゃないの？と。
金かかるし。まぁこの話はスレ違い。

簡単なソフトってのがどんなのを指すのかわからないけど、マルチユーザを
意識しなくていいソフトならそれでいい。
今はマルチユーザを意識するソフトの話をしてるの。
あと、NT系OSを使えばマルチユーザ環境になるんだから、
PCを使いこなすかどうかは関係ないと思う。

坊や達、スレ違いだ。

>>334
同。

>>333
学校とかでFTP使うのってHPをアップロードする時ぐらいじゃない？
ダウンロードはブラウザからも出来るんだし、他のパソコンにファイル送るならメールで良いし。
HPアップロードするなら作成ソフトも必要でしょ。
と思って書いたんだが。まぁこれは終わろう。

マルチユーザ環境で使用する若しくはマルチユーザの環境で使われるだろうソフトで
アンインストールする事がないようなソフトなら
レジストリに設定を保存する方がいいと思う。

でもそんなソフトってそんなにないんじゃないのかな？
大抵のソフトはマルチユーザ環境を意識する必要はないと思うが。
NT系OSを使ったからといってマルチユーザ環境になる訳ではないしね。
# 二人以上が同じパソコンを共有して使う時点でマルチユーザ環境になる。
若しかしたら近いうちにパソコンは一人に一台の時代がくるかもしれないし。
だからあえてレジストリを使う必要はない。

それに同じディレクトりのINIに設定を保存すると
パソコンを2台使っている時、ネットワークドライブとか割り当てて
別のパソコンのソフトを起動すると同じ設定で起動できて便利。

>>336
>FTPクライアント
その学校での用途まで知るかよ。エディタで作成→アップロード、anonymousサーバに接続、など。
とにかく色々な環境があるんだからそんなに限定しようとするなよ。

>二人以上が同じパソコンを共有して使う時点でマルチユーザ環境になる。
一人で使っててもアカウントが複数ならマルチユーザ。

>でもそんなソフトってそんなにないんじゃないのかな？
>大抵のソフトはマルチユーザ環境を意識する必要はないと思うが。
何度言ったらわかるんだ。
意識しなくていいものはそれでいいんだよ。
話の前提は意識するソフトだ。前提を覆さないでいただきたい。
例え。テキストエディタはマルチユーザを意識しなくて良いか。
エディタをカスタマイズ＝個人の設定
個人の設定である以上他のユーザとは違う設定である可能性があるため
マルチユーザに対応しておいた方が良い。
もちろん対応してなくても作者の勝手。ただ対応してたほうがいいだろって話。

>パソコンを2台使っている時、ネットワークドライブとか割り当てて
これは同意。

>>336
> マルチユーザ環境で使用する若しくはマルチユーザの環境で使われるだろうソフトで
> アンインストールする事がないようなソフトなら

そんなソフトあるのか(;´Д`)

そんなソフトは（・∀・）ﾅｲ！

>>337
＞一人で使っててもアカウントが複数ならマルチユーザ。
それ言うならWin9x系だって一緒。
でも確かに言い方は間違ってた。2アカウント以上使っていて。だね。
ただ個人で2アカウント使うような場合はレジストリより設定を共有できるINIファイルの方が便利。

＞例え。テキストエディタはマルチユーザを意識しなくて良いか。
この場合は必要ない。各自、自分の好きな奴をインストールすればOK。
学校とかそういった場所ではそもそもエディタなどインストールする必要ない。
どうしても使いたいっていうなら使えば良いけど。
それで下手にマルチユーザ対応にしてレジストリなんか使う必要が出てくると
個人で使う場合、厄介になるだけだから俺はINIファイルを使うようにする。
少数のユーザのことを考えるより大多数のユーザのことを考えたい。
#レジストリのことを気にするやつも少数って言えば少数ですが。

・・・んー、説明が下手で分かってもらえないか。スマン。
乱暴に言えば意識しなければならないソフトなんて殆どない。
だから意識するソフトの話は意味がない。
意識する必要のないソフトを下手にマルチユーザ対応にするのは良くない、と言う事。

>>338
ワードとかエクセルとかそんなの。普通アンインストールしないでしょ。
あとNT系ならサービスで動くようなソフトはこれに入るかな。

>乱暴に言えば意識しなければならないソフトなんて殆どない。
しなければならないんじゃなくてした方がいいだろってことね。前言ったけど。

どうもマルチユーザ＝レジストリって考えてるようだけど、iniや他のファイル使っても
マルチユーザを意識することとは別。

それと俺はレジストリが良いって言ってんじゃないんだよ。
マルチユーザを考慮に入れたほうがいいだろってこと。
一番いいのはレジストリ／iniかつシングル／マルチユーザの選択式だと思ってる。
色々な環境があるんだからそれに対応できるオプションがあればいいじゃん。
それを「学校ではオンラインソフトではなく市販ソフト」とか
「マルチユーザを意識する必要はほぼ無い」とか限定的なことを言うから
それは違うだろ、と。そうじゃない環境も十分あるだろ、と。

>>ワードとかエクセルとかそんなの。普通アンインストールしないでしょ。
おいおい。
そりゃ君はそうかもしれないけどもだねぇ・・・

>パソコンを2台使っている時、ネットワークドライブとか割り当てて
Microsoftの回答は移動プロファイルですね。

iniシングルはともかくiniマルチのメリットが思いつかん。

おうちに自分のパソコン持ってる学生さんかな？

> 纏めると､マルチユーザの環境なんてそのPCを使いこなすなんてことは殆どないから
大多数の人にとってはたしかにそうかもね。半年間週一回情報処理の授業受けるとか、
ちょっとWeb見るとか、年に二回レポート書くとか、、

> 少数のユーザのことを考えるより大多数のユーザのことを考えたい。
いろんな事情で仕方なくマルチユーザの環境でPCを使いこなさなければならない少数のユーザが
なるべくストレス無く快適に使える環境を構築するのが私たちの仕事なので…。

> 乱暴に言えば意識しなければならないソフトなんて殆どない。
> だから意識するソフトの話は意味がない。
だったらほかのスレへ（・∀・）ｶｴﾚ！ということで。
ここはマルチユーザーを意識して作るソフトの設定の保存方法を論ずるスレだからね。

>>343
iniでマルチなのがメリットだと思うが。

>>341
＞しなければならないんじゃなくてした方がいいだろってことね。
これが意見の違いかな。俺はしない方がいいと考える。理由は何回も言ったとおり。

＞どうもマルチユーザ＝レジストリ・・・
マルチユーザを意識するならレジストリに格納するべき。
>>343の言ってる通りINIファイルに格納するメリットがないと思う。
メリットがあるとしたらどんな物があるか教えてくれると有り難い。

＞一番いいのはレジストリ／iniかつシングル／マルチユーザの選択式だと思ってる。
これも確かに良いんだけど問題はその設定を何処に保存するか。
当然、同じフォルダのINIファイルに保存するようにすると思うけど
その設定を他のユーザが書き換えないとも限らない。
その対策も出来ないこともないが、そこまでやるのは面倒だし無駄に思える。
俺も幾つかフリーウェア作って公開してるけど
余計な機能ってのはバグを生むし管理しにくくなる要因の一つで好ましくない。
まぁ、それは各作者が好きで決めればいいことだとは思うが
そこまでする事はないのでは？と言うのが意見。

＞それを「学校ではオンラインソフトではなく市販ソフト」とか ・・・
そう見えてしまう書き方をしたのは悪かったが、別に断定してる訳ではない。
十分、と言っても全体から見ればごく少数だろう、
そのごく小数のために・・・はもう書いたか。

＞そりゃ君はそうかもしれないけどもだねぇ・・・
だから"全員"じゃなく"普通"ね。
とかいう俺も普段使ってるパソコンからワードとエクセルは消し去ってるし。

>>344
＞いろんな事情で仕方なくマルチユーザの環境で・・・
少数ならばソフトに頼るのではなくマルチインスコとか他の方法で対応できるはず。
それが面倒だって気持ちは分からないでもないが。

＞ここはマルチユーザーを意識して作るソフトの設定の保存方法を論ずるスレだからね。
いや、今の話の流れはそうだけどスレ自体は
「フリーソフトでレジストリを使うかINIを使うか。プログラマとユーザの視点から意見を言う」
と言うスレじゃないのか・・・。

言いたいのはもし他のソフトウェア作家がこのスレを見て
自分のソフトをマルチユーザ対応にした方がいいのかなと思うのは
本当にそうなのかちゃんと考えて欲しい、と言う事。

要するに>>346は作るのが大変でバグが生まれるかもしれないから
余計なことはしたくないってことだろ。そんなんこいつのスキルの問題じゃん。

> ＞そりゃ君はそうかもしれないけどもだねぇ・・・
> だから"全員"じゃなく"普通"ね。
> とかいう俺も普段使ってるパソコンからワードとエクセルは消し去ってるし。

矛盾してて何が言いたいのかわからん。

レジストリを使う必要があるからレジストリを使う。
例えばCOM登録や関連付けなど。
「アンインストールしなくてもいい」なんてふざけた理由は無い。

問題は、つかってんのか、どういう風にアンインストールすれば
よいのか、どこにかきこんだのかをはっきり明示してくれれば
いいんだよ。

あとは、そのソフトの価値と比較していれるかいれないか
は各自がきめればよい。

プログラマも用もなくレジストリをいじってるわけではないと思う。
無駄に使ってる奴には、頼めばいい。


終了／・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・

>>349
同意。>>346の一連の発言を見てると単にレジストリを使いたくない（使って欲しくない）から
マルチユーザを否定してるように見える。
レジストリを使う理由も隔たってるし。（彼曰くマルチユーザに対応すべきでアンインストールしないようなソフトだっけ？）

>>346
> マルチユーザを意識するならレジストリに格納するべき。
> >>343の言ってる通りINIファイルに格納するメリットがないと思う。
> メリットがあるとしたらどんな物があるか教えてくれると有り難い。
例えば一つのフォルダに全ユーザの設定をまとめて置けば移動・削除が楽。
ようはiniの利点と同じ。
他のユーザが設定を書きえる（他のユーザは信頼できない人間である）可能性
がある場合、まず9x系使ってるならその心配はするだけ無駄。
NT系はレジストリやApplicationDataフォルダ。
だから選択式。選択設定の保存先はレジストリでもいいしあるサブフォルダに入れて
そのフォルダをUsersが書き込めないようにする。

少数とか多数とかって統計でも取ってるの？
仮に取っててかつ小数を切り捨てるのは作者の勝手だけど、
それは君の勝手であってそれを根拠にマルチユーザ自体が不必要ということにはならない。

>>320のような環境のとき、マルチインストールってどこにするつもりだ？

俺が整理してやる。
>>346はレジストリを使う（使われる）のが嫌い。
　↓
マルチユーザ対応が推奨されると多くのソフトがレジストリを使い出すと思ってる。
（>>346はマルチユーザ対応にはレジストリを使うべきだと考えているため）
　↓
自分のソフトも対応させなければいけないかもしれない。でもスキルがない。
　↓
>言いたいのはもし他のソフトウェア作家がこのスレを見て
>自分のソフトをマルチユーザ対応にした方がいいのかなと思うのは
>本当にそうなのかちゃんと考えて欲しい、と言う事。

すべてはレジストリを使いたくないという>>346の信仰に端を発している。
だから「マルチユーザに対応する必要がない」や「レジストリはマルチユーザに対応すべきで
アンインストールしないようなソフト」などというあいまいな理由でこじつけられたわけだ。

>>340
素朴な疑問なんだが、なぜワードやエクセルは普通アンインストールしないソフトなんだ？
根拠を教えてくれ。

>353
>スキルがない
というのは理由にならんだろ。
INIより少々面倒ではあるが、操作自体は全然難しいところはない。

>>355
スマソ。選択方式を実装するのが大変、ってのとごっちゃになった。
つーかその一行は無い方がわかりやすいかも。

>>347
プログラマなら分かると思うがこれはスキルの問題ではない。
もし、ユーザの要望に何でもこたえてゴタゴタしたコードを組むようでははっきり言って未熟。
スパゲティー・プログラムになって手におえなくなるのがオチ。
仕事でクライアントが後からあれもしろ、これもしろ、と言われてやるのは仕方がないが。
最初から仕様を決めてしっかりと組むのなら問題ない。
それにみんながスキル有ると思ったら大間違い。

>>348
それはまた別の話でしょ。ここでは設定を何処に保存するかって話をしている。
使う必要がある時に使うのは当たり前。

>>350
俺も>349にほぼ同意してる。
ただ不必要にレジストリを使うようなまねはして欲しくないだけ。
何と無くレジストリに設定を保存しいてるソフトも多々あるわけで、、、

マルチユーザ(多人数)で使うようなソフトってのは基本的にアンインストールしないのでは？
この辺は経験がないんではっきりとは分からないんだけど
多人数で使ってるソフトをポコポコ変えられては使用者が迷惑するだけだと思う。
だからマルチユーザを意識する＝アンインストールしないソフトって認識なんだが。

>>351
＞例えば一つのフォルダに全ユーザの設定をまとめて置けば移動・削除が楽。
この場合、全てのユーザがそのファイルに書き換える権限がないといけないが
そうするとEXEと違う場所に置くかEXEを全てのユーザが書換えを実行できる場所に
インストールする必要が出てきて現実的じゃない。
インストールしたフォルダの書換え権を全てのユーザに許可できるなら
それも良いかもしれない。NTFSなら出来るのかな？

＞NT系はレジストリやApplicationDataフォルダ。
選択式でレジストリやApplicationDataに保存すると
INIファイルのメリットがなくなって本末転倒。

んでマルチユーザ自体が不必要なんじゃなくて
意味もなくマルチユーザ対応にする事が不必要と言っている。

>>353
設定を保存するだけならINIを使うよりレジストリを使った方が簡単なのだが。
だから意味もなくレジストリに設定を保存するソフトが多い。

>>354
ワープロや表計算ソフトってのはVerUPを除いてコロコロ変える物じゃないでしょ。
そんな事したらそれまで作った文書が読めなくなる。
別の奴を使い出すにしろ元の奴は残すのでは？

>>357
> ＞例えば一つのフォルダに全ユーザの設定をまとめて置けば移動・削除が楽。
> この場合、全てのユーザがそのファイルに書き換える権限がないといけないが
> そうするとEXEと違う場所に置くかEXEを全てのユーザが書換えを実行できる場所に
> インストールする必要が出てきて現実的じゃない。
悪いが意味がよくわからない。
Usersは保存場所の設定を読み込めればいい。設定するのは管理者なんだから。

> 選択式でレジストリやApplicationDataに保存すると
> INIファイルのメリットがなくなって本末転倒。
ここではiniのメリットを捨てて「他のユーザから自分の設定を守る」メリットが優先される。
これはそういう選択肢。
そしてこれを選択するのはあくまでもユーザの権利。作者は機能を提供するだけ。

> 意味もなくマルチユーザ対応にする事が不必要と言っている。
違うでしょ。君が言ってるのは
> 乱暴に言えば意識しなければならないソフトなんて殆どない。
> だから意識するソフトの話は意味がない。

>357
>ここではiniのメリットを捨てて「他のユーザから自分の設定を守る」メリットが優先される。
INIでも、アクセス権設定すれば、自分以外のユーザーから守れるyo！

＞ワープロや表計算ソフトってのはVerUPを除いてコロコロ変える物じゃないでしょ。
＞そんな事したらそれまで作った文書が読めなくなる。

これとレジストリの話とどう関係があるんだ？
レジストリを使ってもいいソフトにワープロや表計算ソフトを挙げたんだろ？
なのにその理由じゃレジストリだろうがiniだろうが関係ないじゃん。

>>359
それがめんどくさいんだってさ。

>>357
>もし、ユーザの要望に何でもこたえてゴタゴタしたコードを組むようでははっきり言って未熟。
>スパゲティー・プログラムになって手におえなくなるのがオチ。
>仕事でクライアントが後からあれもしろ、これもしろ、と言われてやるのは仕方がないが。
>最初から仕様を決めてしっかりと組むのなら問題ない。

だからここで話し合ってたんだろ。
それにおまえが「意味がない」と水を差した。
言ってることとやってることが違うぞ。

>それにみんながスキル有ると思ったら大間違い。

そんなしょーもないこと思ってないし
スキルの無い人間には何も求めていない。安心しろ。

＞それはまた別の話でしょ。ここでは設定を何処に保存するかって話をしている。
＞使う必要がある時に使うのは当たり前。

それはこっちのセリフだ。
設定の保存でレジストリを使うソフトと「アンインストールしないソフト」とどういう関係があるんだ？

> ワープロや表計算ソフトってのはVerUPを除いてコロコロ変える物じゃないでしょ。
> そんな事したらそれまで作った文書が読めなくなる。

ソフトをコロコロ変えるか変えないかはユーザが選ぶこと。
作者が選ぶことじゃない。
>>357の論理では普通アンインストールしないものはレジストリを使って良いことになるが、
エディタはどうなんだ？>>340ではマルチユーザに対応する必要がないのでレジストリを
使わないということになっているが。
ワープロとエディタでどうしてこんな差をつける？

>>357
>>352へのレスが抜けてる

>>358
＞Usersは保存場所の設定を読み込めればいい。設定するのは管理者なんだから。
ん？俺も良く分からん。なんか話がずれてるかな。
その理屈だとユーザは各々の設定を保存できない訳？それはダメでしょ。

＞違うでしょ。君が言ってるのは
それはあくまで乱暴に言ったらの事で本気でそう思っている訳ではないです。
極論として言ったまでです。
これは書かなかったほうが良かったか。

>>360
それは＞なぜワードやエクセルは普通アンインストールしないソフトなんだ？
の根拠です。レジストリの話とは直接の関係は無いです。
レジストリを使うべきソフトにワープロや表計算ソフトを挙げたのは
大勢のユーザが使うであろうソフトならレジストリを使った方が簡単で扱いやすいから。
アンインストールしないソフトならレジストリを使っても良いってのは
アンインストール時にゴミを残すような仕様でも使い続けているなら問題ない。
ただ､ためしに入れてみたって人にとっては大いに問題だけど。

>>362
極論を書いてしまった俺のミスだな、スマン。

＞スキルの無い人間には何も求めていない。
フリーソフト作家にはプログラムの勉強の為に作ってる人も多い。
そういった人はスキルもあまり高くない場合が多い。
それでもアイデアが良くていいソフトも有るがそれを捨てるのは勿体無いと思うぞ。

>>363
>360のレスを参照。

>>364
エディタは種類もたくさん有って結構変える物でしょ。
俺も幾つかエディタは変えた。

>>365
ユーザのフォルダなら好きな場所へユーザが決めればいい。

>>366
> ＞Usersは保存場所の設定を読み込めればいい。設定するのは管理者なんだから。
> ん？俺も良く分からん。なんか話がずれてるかな。
> その理屈だとユーザは各々の設定を保存できない訳？それはダメでしょ。
あぁ各ユーザの設定を保存するファイルが、書き込み権限のあるフォルダに置かれてないと
ダメだってことか。もちろんその通り。
しかしそれを言うなら君の「exeと同じフォルダにiniを保存」も同じ条件だよ。
これが現実的じゃないって？
ということは君は自称多数派を選びながら現実的じゃない方法を選んでるわけかな？

>>367
答えは､マルチインストール。
EXEもユーザのフォルダにおけば良い。

> それでもアイデアが良くていいソフトも有るがそれを捨てるのは勿体無いと思うぞ

誰が良いソフトを捨てると言った。
未熟なやつに「様々な環境に順応できるマルチユーザ方式を実装しろ」とは言わないという意味だ。

>>368
答えになっていない。
「exeと同じフォルダにiniを保存」も同じ条件だがこれは現実的なのか、と聞いている。
そして一つのフォルダに全ユーザの設定を置く方法を否定もできていない。
マルチインストールは代替方法を示しただけ。

ちなみに
> ユーザのフォルダなら好きな場所へユーザが決めればいい。
ユーザが勝手にこんなことされちゃ管理にならないんだよ。

＞エディタは種類もたくさん有って結構変える物でしょ。
＞俺も幾つかエディタは変えた。

いい加減にその自分ルールはやめてくれ。
コロコロ変えられたら迷惑って言ったのはおまえだろ。
場当たり的な反論してるから矛盾だらけなんだよ。

> レジストリを使うべきソフトにワープロや表計算ソフトを挙げたのは
> 大勢のユーザが使うであろうソフトならレジストリを使った方が簡単で扱いやすいから。
> アンインストールしないソフトならレジストリを使っても良いってのは
> アンインストール時にゴミを残すような仕様でも使い続けているなら問題ない。
> ただ､ためしに入れてみたって人にとっては大いに問題だけど。

ユーザのゴミが残っても問題にはならないんだが。
ま、仮に精神衛生面で問題になるとしよう。
で、大勢で使うならレジストリ使ったほうが簡単で扱いやすい、って
ユーザが大勢で使うかどうかがなぜ君にわかるんだい。

WEBブラウザはどうなんだ？
種類がたくさんあるぞ。
でもIEはレジストリ使ってるな。
IEはユーザ数が多いソフトだからレジストリ使ってると便利で扱いやすいよな。
そういうことだろ？

つーか、自分ルールで「大勢が使う」だの「アンインストールしない」だのと
ソフト基準に決めるから矛盾だらけになるし、基準があいまいなんだって。
あくまでも使うのはユーザでそのユーザはどんな環境で何人で使うかわからないんだから。

＞ユーザのフォルダなら好きな場所へユーザが決めればいい。

ソフトは管理者が事前にインストールしておくもんなの。
ユーザの中には素人もいる。

つっこまれて困るような極論はもはや論外。

＞エディタは種類もたくさん有って結構変える物でしょ。
あぁ?ワープロがレジストリでエディタがiniな理由が競合ソフトの数??
じゃあ何か、新ジャンルのソフトを作るときはレジストリで作ってもいいが
競合ソフトが増えてきたらiniに変えなきゃならないのか?
競合ソフトは何種類出るまで待てばいいのよ?
つーかそんなこと言って各作者が賛同するとでも思ってるのか?

>>368
そうそう、言い忘れたけどどうしてもマルチインストールじゃなきゃﾔﾀﾞ！
と言い張るなら選択式で「シングルユーザ＋ini」を選択すればよい。
これが選択式の便利なところ。

>>370
ユーザのフォルダにEXEを置けば大丈夫では？
管理の問題では例えばどんな問題が？

>>371
それはワープロとエディタの違いを言ったまででしょ。
で、エディタをマルチユーザでみんなが使った場合コロコロ変えられると迷惑。
だからコロコロ変えるようなエディタをマルチユーザで使うべきでない。
マルチユーザで使わないらレジストリを使うものでない。
何か矛盾してます？

>>372
＞ユーザが大勢で使うかどうかがなぜ君にわかるんだい。
マルチユーザ環境なら大勢でしょ。
例え2人だけの環境でも「大勢」になる。この場合は「複数」といった方が正しいが。

>>373
＞IEはユーザ数が多いソフトだからレジストリ使ってると便利で扱いやすいよな。
違う､IEの場合はユーザ全員が使うもの（実際に使うかは別として）だからレジストリの方が良い。
決してシェアや知名度で決める物ではない。

レジストリを使うべきかどうかの基準は
マルチユーザを意識したほうがいいソフトはレジストリ､
それから関連付けなどレジストリを使う必要があるソフトもレジストリ。
そうでないソフトはINIファイル。
オンラインソフトはたくさん有るんだし役割も全然違うから
明確な規準で分ける事は不可能。と言うかそれを俺に決める権利は無い。
言えるのはadmin権限で動かさなければならないようなソフトは
マルチユーザ対応する意味は殆ど無いと言うことぐらいか。

>>374
前にも書いたけど素人が使うような環境なら（学校のPCとか）
ブラウザと表計算とワープロとその他適当にあれば十分では？
オンラインソフトもユーザが設定を変えれない方が都合が良い。
ヘビーな方には個別にユーザフォルダにオンラインソフトを入れていけばよいと思うが。

>>376
＞あぁ?ワープロがレジストリでエディタがiniな理由が競合ソフトの数??
＞じゃあ何か、新ジャンルのソフトを作るときはレジストリで作ってもいいが
＞競合ソフトが増えてきたらiniに変えなきゃならないのか?
んな分けない。
俺の文も分かりにくくて悪いがもう少しちゃんと読んでくれ。

>>377
そういう事じゃないんだけどね。
確かにそれも良いんだけどマルチインストールの利点はそのユーザだけに
ソフトを使わせる事が出来るって所にあると思うが。
家庭とか少数のマルチユーザ環境ならそっちの方が管理も楽そう。

> 例えば一つのフォルダに全ユーザの設定をまとめて置けば移動・削除が楽。
> ようはiniの利点と同じ。
ユーザーを削除したときにゴミが残る。
レジストリの「ゴミ」はやたらに気にする人が多いけど
こういうのはまったく気にならないの?

> NT系はレジストリやApplicationDataフォルダ。
Application Dataフォルダだと移動・削除が楽というメリットはなくなる。
iniのメリットを捨てるならレジストリでいい。

> 選択設定の保存先はレジストリでもいいし
結局レジストリに保存するのではiniを使う意味がない。

> あるサブフォルダに入れて
> そのフォルダをUsersが書き込めないようにする。
別フォルダが必要になると移動・削除が楽というメリットが損なわれる。
保存場所に指定したiniが保護されていなければ意味がない。

> 管理の問題では例えばどんな問題が？
どんなプログラムが置かれるかわからないから。

> だからコロコロ変えるようなエディタをマルチユーザで使うべきでない。
ユーザがソフトをマルチユーザ環境で使うかどうかはあんたが決めることではない。
さらにユーザがコロコロ変えるかどうかはあんたにはわからない。
あんたにはユーザがどんな環境でインストールしてどのくらいでアンインストールするのか
またはしないのか、などはわからない。
ワープロはコロコロ変えないがエディタはコロコロ変えるという明確な根拠がない。
一つのエディタをずっと使いつづけるかもしれない。そしてこの可能性は否定できない。
第一、「ほとんどのソフトはマルチユーザ環境で使うべきではない」などと
作者が主張したところで誰が従ってくれる？「多数」が従ってくれるのか？

> マルチユーザ環境なら大勢でしょ。
> 例え2人だけの環境でも「大勢」になる。この場合は「複数」といった方が正しいが。
そう、だからどんなソフトでもマルチユーザで使われる可能性がある。
「マルチユーザで使うな」と主張するのは無駄ということは先述の通り。
だからマルチユーザで使われないなどと仮定するのがそもそも無理がある。

> 違う､IEの場合はユーザ全員が使うもの（実際に使うかは別として）だからレジストリの方が良い。
> 決してシェアや知名度で決める物ではない。
全員が使うからレジストリという主張はできないはず。
なぜならあんたはマルチインストールを主張してるから。
逆に全員が使うからレジストリを使うという主張ができるなら。
全員が使うオンラインソフトもレジストリを使って良いということになる。
そして全員が使うかどうかはあんたが決めることじゃなくてユーザ
（管理すべき場所では管理者）が決めること。
この場合、「IEはレジストリを使うべきではない。マルチインストールされているべき」
と主張しないと前言と矛盾する。
さらにIEがいいならWEBブラウザはレジストリを使ってもいいことになる。
しかしWEBブラウザには多くの種類がある。あんたは種類が多いとini、という論理のため、
これも矛盾する。

> オンラインソフトはたくさん有るんだし役割も全然違うから
> 明確な規準で分ける事は不可能。と言うかそれを俺に決める権利は無い。
最初の主張と変わっている。
ソフトの種類（ワープロだの表計算だの）で分けようとしてたのはあんた。
にもかかわらずここへきて「分けることは不可能」。これが矛盾。

> 言えるのはadmin権限で動かさなければならないようなソフトは
> マルチユーザ対応する意味は殆ど無いと言うことぐらいか。
これも以前と意見が変わっている。
この逆は「admin権限で動かさないソフトはマルチユーザ対応する意味がある」
ほとんどのソフトがマルチユーザ対応する意味が無いと言ったのは誰か。

> 前にも書いたけど素人が使うような環境なら（学校のPCとか）
> ブラウザと表計算とワープロとその他適当にあれば十分では？
だからそれはあんたが決めることじゃない。
十分かどうかどうしてわかるのか。

> オンラインソフトもユーザが設定を変えれない方が都合が良い。
あんたが言う「マルチインストール」はユーザが設定を変えられる。
まったく意見が逆になってる。

> ヘビーな方には個別にユーザフォルダにオンラインソフトを入れていけばよいと思うが。
管理者の身になって考えてみること。
相手がヘビーユーザかどうかなぜわかる。さらにユーザごとに入れるソフトを変える方が手間がかかる。
本末転倒。

> 俺の文も分かりにくくて悪いがもう少しちゃんと読んでくれ。
読んだからそういう反応が来たんだろう。
否定するなら根拠を提示すること。

> 確かにそれも良いんだけどマルチインストールの利点はそのユーザだけに
> ソフトを使わせる事が出来るって所にあると思うが。
だからシングル＋iniでインストールしてるんだからそのユーザだけが自由に使えるだろ。
さらに「あるフォルダに全ユーザ設定を保存する方法」を否定できていない。
これが否定できないということは、iniでマルチユーザ対応させることを否定できない。
ということはレジストリにゴミを残さずともマルチユーザに対応できる場合がある。
ということはマルチユーザ＝レジストリ、という論理は破綻。

> ユーザーを削除したときにゴミが残る。
> レジストリの「ゴミ」はやたらに気にする人が多いけど
> こういうのはまったく気にならないの?
iniの利点は「削除が楽」
気になるなら削除しなさい。

> Application Dataフォルダだと移動・削除が楽というメリットはなくなる。
> iniのメリットを捨てるならレジストリでいい。
選択肢を与えてるだけなので好きなのを選択するのは当たり前。
レジストリを使いなさい。

> 結局レジストリに保存するのではiniを使う意味がない。
なぜか。どちらか一方を使わなければいけないなどと誰が決めたのか。
さらにレジストリが嫌ならばiniに保存すればよい。
iniを使いなさい。

> 別フォルダが必要になると移動・削除が楽というメリットが損なわれる。
exeのサブフォルダに作りなさい。

> 保存場所に指定したiniが保護されていなければ意味がない。
意味が無いことはない。そもそも9xを使っているならそんなこと考えるだけ無駄。
保護を優先させるならNT系でレジストリを使いなさい。

全部選択式でいけますがなにか。

結局、レジストリ使用とINIファイルを選べれば良いのでは？
マルチユーザーで使うときにはレジストリ使わせて、シングルユーザーなら
INIファイルをEXEと同じフォルダに作る。インストール時にでも選択させれば
とってもいい感じだと思うんだけど。

保存方法を選択できるようにすれば>>378の言う「exeと同じフォルダにini」も
選択できるのに、なぜ>>378はそこまで固執するんだ？
別に今すぐ選択できるように実装しろと言ってるわけでもないのに。
選択できれば色々な環境に合わせてユーザが選べるから便利だ、って話なんだが。
固執する特別な理由でもあるのか？

>>378はとんでもないこと言ってるな。
>で、エディタをマルチユーザでみんなが使った場合コロコロ変えられると迷惑。
>だからコロコロ変えるようなエディタをマルチユーザで使うべきでない。
>マルチユーザで使わないらレジストリを使うものでない。
>何か矛盾してます？

「エディタ」を「ワープロ」に置き換えると即矛盾なんだが。
特に一行目から二行目への話の持っていき方がすごい。
>で、エディタをマルチユーザでみんなが使った場合コロコロ変えられると迷惑。
迷惑ならコロコロ変えなければいいだけなんだが、それを
>だからコロコロ変えるようなエディタをマルチユーザで使うべきでない。
という話へスライドさせている。繰り返すが迷惑なら変えなければいいのだが、
なぜかエディタはコロコロ変えなければいけないソフトのようだ。
その「コロコロ変える」かどうかの判断要素は
>エディタは種類もたくさん有って結構変える物でしょ。
種類の多さだそうだ。そこで反論されると
>それはワープロとエディタの違いを言ったまででしょ。
さらに
>俺の文も分かりにくくて悪いがもう少しちゃんと読んでくれ。
と一蹴。ワープロではレジストリを使い（＝コロコロ変えない）、
エディタではiniを使う（＝コロコロ変える）という、その差の付け方が
「種類の多さ」というのはおかしいと指摘されているのだがなぜか強気に一蹴。
これだけツッコミ要素満載な発言をしておいて
>何か矛盾してます？


こやつの厨房ぶりはもはや神の領域だ。

どこを縦に読めばいいの？

#うーむ、最近は話が長くて読めん。

>>386
激しく同意。もうちょっと簡潔に。

厨房は放置。これ最強。

>>380
＞どんなプログラムが置かれるかわからないから。
ソフトのインストールは管理者がする事。
ユーザは場所を決めるだけ。

＞ユーザがソフトをマルチユーザ環境で使うかどうかはあんたが決めることではない。・・・
そう、マルチユーザ環境で使うかもしれないしシングルユーザ環境で使うかもしれない。
コロコロ変える人もいれば固定して使い続ける人もいる。
そこでマルチユーザ環境で固定して使う人の為に意味も無くレジストリを使われると
シングルユーザ環境でコロコロ変える人にとっては迷惑になる。

＞「ほとんどのソフトはマルチユーザ環境で使うべきではない」
では無く､「ほとんどのソフトはマルチユーザ環境を意識する必要が無い｣と言っている。
マルチユーザ環境を意識していないソフトでも
マルチユーザ環境で使う事は出来るし使っても構わない。
ただし、そのソフトをユーザが使いあうようなインストールの仕方(マルチユーザ)は
今後アンインストールしないと決めなければするべきでない。

＞全員が使うオンラインソフトもレジストリを使って良いということになる。
そうだが、必ず全員が使うオンラインソフトなんて物は基本的にない。
ある環境では全員使うかもしれないが他の環境では使わないかもしれない。

＞この場合、「IEはレジストリを使うべきではない。マルチインストールされているべき」
＞と主張しないと前言と矛盾する。
IEの場合はWindowsを使っている限り全てのユーザに入っている。
だからこの場合は「IEはレジストリを使うべきではない」にはならない。
「種類が多いとini」なのではなくマルチユーザで使うかどうかで決める。
最初からマルチユーザで使うことを前提としたソフトなら
例え種類が多くてもレジストリを使うべき。
「種類が少ない場合はレジストリ」ってのは何故出てきたんだろう、
全くそんな考えは無いんだが。どの辺でそう取られてしまったのか。

＞さらにIEがいいならWEBブラウザはレジストリを使ってもいいことになる
IEがいいならWEBブラウザも使って良いというのはおかしい。
IEと他のブラウザは全然別物。何故一緒にできる？

＞ソフトの種類（ワープロだの表計算だの）で分けようとしてたのはあんた。
この場合の明確な規準ってのはもっと細かなソフト単位での話。
あのソフトはレジストリこのソフトはINIなんて決められない。
一般的なワープロや表計算はマルチユーザを意識して作られているから例にあげた訳で
もし、マルチユーザを意識しないワープロを作ったとしたら
それはINIに設定を保存すべきだと思う。

>>381
＞この逆は「admin権限で動かさないソフトはマルチユーザ対応する意味がある」
そうじゃなくて逆にいえば、admin権限でしか動かないソフトは
マルチユーザで動かしてもはっきりいって使えないと言う程度の事。

＞十分かどうかどうしてわかるのか。
だから「では？」と聞いている。
違うのならその理由を知りたいだけ。
と言うかこの答えは>344で出てるんだけど他の意見も聞きたかった。

＞あんたが言う「マルチインストール」はユーザが設定を変えられる。
これは初心者がパソコンを使う場合は変えれない方が良いと言う事。
そりゃ環境によって状況も変わる。

＞相手がヘビーユーザかどうかなぜわかる。
詳しい人間かどうかは会えば分かる。知らない人間にパソコンを使わせる状況なら
使いやすさよりも制限をきつくするべき。

＞さらにユーザごとに入れるソフトを変える方が手間がかかる。
多少の手間はパソコンを管理してるのなら仕方が無い。
それに環境によって違うだろうけどそんなにソフトを変える必要があるのか？
無茶苦茶手間がかかって嫌なら必要時以外は変えなければいいと思うが？
それをマルチユーザに対応する事で解消したはいいが
個人で使ってる人の手間が増えるとしたらそれは良くない。

＞否定するなら根拠を提示すること。
根拠は示したつもりなんだが。

＞だからシングル＋iniでインストールしてるんだからそのユーザだけが自由に使えるだろ。
ゴメン、よく分からん。マルチユーザ環境の話なのに何故シングル＋ini？
これは俺の言うマルチインストールの事になるが。

＞「あるフォルダに全ユーザ設定を保存する方法」を・・・
無論、INIでマルチユーザ対応させることも可能、が実装に手間がかかる。
レジストリを使うなら非常に簡単に対応できる。
そうまでしてINIに保存するメリットが思いつかない。
だからマルチユーザならレジストリを使った方が良いといってるだけ。
作者の趣味でINIに保存したいのなら別に構わないよ。

>>384
マルチユーザ対応にする場合、確かにそれは有りだと思う。
でも、必要ないのにマルチユーザに対応させるのはどうか？と言う話。


>>385
エディタをコロコロ変えるというのは個人で使う場合の話。
それとマルチユーザで使う場合の話がごっちゃになってるから変になるんだな。

>で、エディタをマルチユーザでみんなが使った場合コロコロ変えられると迷惑。
>だからコロコロ変えるようなエディタをマルチユーザで使うべきでない。
>マルチユーザで使わないらレジストリを使うものでない。
これはマルチユーザでの話。
エディタを変えなければならないと言う事はない。

書き直すと、
エディタをマルチユーザでみんなが使った場合コロコロ変えられると迷惑。
だから後で変えたくなるようなエディタはマルチユーザで使うべきでない。
そんなエディタならレジストリを使わない方が良い。
全てのエディタがずっと使い続けても良いと言う訳ではないでしょう。
マルチユーザ環境を意識して作った
完成度の高いエディタならマルチユーザで使うのも良い。
しかしそれがみんなに受け入れられるか問題。
使いたいエディタは人によってまちまちだろうから。
そうするとマルチユーザで使う意義が無いと思う。

これで分からないかな？
文章が書くのは苦手なんで突っ込み所満載かも知れんがそこは勘弁。

なんか話がぐちゃぐちゃになってきて自分でも何が主張している事か
分かりづらくなってきたんで一旦仕切りなおし。

俺の主張は、
基本的にマルチユーザ環境は無理して意識する必要は無い。
必要のあるものだけ対応すればいい。
で、必要があるかどうかは作者が決める訳だが、
作者はホントに必要なのか考えて欲しい。
対応したいならば保存方法を選択できるようにし
シングルユーザで使用してもレジストリを使わないようにするといい。
それからマルチユーザ環境でもマルチインストールの方がいい事もある。

と、これだけ。
途中、矛盾してる点もあるかも分からんが
文書力の無さがなせる技。許して欲しい。


なんかスレ汚しまくってるし続けても
訳分からなくなるだけだからこれで最後にします。
出て来いというなら出てきますがけど・・・。
スレ汚しスマン。

いい加減に厨房論理はやめれと。
矛盾を文章力の無さに転嫁するなと。
スレ違いもいい加減にすれと。

あー全然ダメ。
> エディタをマルチユーザでみんなが使った場合コロコロ変えられると迷惑。
> だから後で変えたくなるようなエディタはマルチユーザで使うべきでない。
迷惑ならコロコロ変えなきゃいいの。
それとも君の妄想世界の管理者は頭が悪くてどうしてもコロコロ変えなきゃ気がすまないのか？

> 全てのエディタがずっと使い続けても良いと言う訳ではないでしょう。
ワープロ、というか全てのソフトウェアに同じことが言えますが、何か？

> マルチユーザ環境を意識して作った
> 完成度の高いエディタならマルチユーザで使うのも良い。
> しかしそれがみんなに受け入れられるか問題。
> 使いたいエディタは人によってまちまちだろうから。
使いたいワープロ、というか使いたいソフトウェアは人によってまちまちですが、何か？

それとまだ理解せずにレスしてたようだけど、つーか他の発言も理解してないんだろうけど、
> ゴメン、よく分からん。マルチユーザ環境の話なのに何故シングル＋ini？
> これは俺の言うマルチインストールの事になるが。
選択式はそのマルチインストールもサポートしてるってこと。
シングル＋iniモードでマルチインストールすれば同じことだろ。

>>392
矛盾やツッコミどころが多い文章を書くのは
単に考えて発言してないからだ。
考えてないから自分でわけわかんなくなってる。
厨房の長文は一番たちが悪いのでもう来ないで下さい。

こういうヴァカは考えろって言っても無駄なんだよな
自分で体験するまで一生わからないんだよ

矛盾探しゲームを提供してくれる>>346がいるというスレはここですか？

さぁ、君はいくつの間違いを見つけられるかなぁ？でははりきってGO!

最後にするつもりだったが何か？と聞かれたので。
＞ワープロ、というか全てのソフトウェアに同じことが言えますが、何か？
＞使いたいワープロ、というか使いたいソフトウェアは人によってまちまちですが、何か？

だから、マルチユーザとしてインストールするのは良くないと言っているの。

>>399
ほら、また矛盾。
ワープロにも同じことが言えるということは、ワープロもマルチユーザとして
インストールするのは良くないことになる。
場当たり反論はもうやめてね。厨房くん。

>>400
「というか、」が入ってたから除外しなかっただけ。

>>401
はぁ？「全ての」って言ってんだからワープロに限らず、って意味だろ。
君は日本語も危ういのかい？

>>401
これ以上レスしても墓穴掘るだけだよ。

>>402

そろそろ許してやれよ(藁
楽しんでやってるなら止めないが、疲れるだけだから
もう止めたほうがいいぞ。

>>401
出てこないって言ったのに出てきてｶｯｺﾜﾙｲ。

>>402
そんな厨房に上げ足取りｶｯｺﾜﾙｲ。

>>405
揚げ足取りではないだろ

俺はどっちもどっちに見えるな。

ツッコミ祭りは終わりか

んじゃあこのへんから再開っつーことで
>>276-325

若いって良いなぁ。

今度厨房が来たら皆さん素無視の方向で。
ツッコミたい気持ちもわかりますが、そこは我慢する方向で。

VS.NETが出たよね。英語版だけど。
あれについてるセットアッププロジェクトってのでmsiが作れるんだけど
どこまで細かく設定できるのかな。
VisualStudioInstaller1.1よりマシにはなってるだろうけど。

インストーラで保存先を選択させたり、アンインストーラで各ユーザの設定まで
削除するかどうか選択させたり、という話題があったので一応そのネタふり。

レジストリ使うと確かにマルチユーザ対応が楽で良いけど、
逆に特定のユーザー間で設定を共有するのが難しい。
例えば一般ユーザとAdminを使い分けつつ、
エディタの設定を統一したい場合とか。

INIファイルを使うのはかまわないが、
インストール後も変更がある場合は、プログラムと同じディレクトリや、
systemRoot(c:\windows , c:\winnt)に入れるのはやめてほしい

systemrootも、program filesも、adminのみ変更可にして、一般ユーザーは
読み取りと実行のみ許可してるから、行儀の悪いアプリがあると、NTFSのACLを
いじらないといけなくなるからめんどくさい

>>413
INI派だが禿しく同意

レジストリ使ったアプリでアンインストール時に
きちんとレジストリを消すようなアプリでも
カレントのユーザーのレジストリしか消さないんだよなぁ。
これはどうにかして欲しい。

>415
マルチユーザーでレジストリが別になる領域があることを、そもそも知らない。ってプログラマー多いよ。
DOSやそれもない頃のプログラマーは特に。

全部既出だな…

>>413-414
その場合どこにINIを置いて欲しい？
俺はそういうソフト用にUsersも書き込める別のProgramフォルダを用意して
そこにインストールしてる。

>>417
やっぱりEXEと同じﾌｫﾙﾀﾞかな。
そうやってINIを使うツール用フォルダを作って整理しておけば、
一括バックアップ/レストアが出来るし。

そのためにもiniを使うか、そのiniはどこへ置かれるのかをreadme.txtに
記載して欲しいね

>>419
そこら辺はアンインストールの方法に、という話になって

readme.txtにアンインストール情報を！
http://pc.2ch.net/test/read.cgi/prog/997370579/

にループするのでは…

ループはしないでしょ

>>416
それは本当にプログラマか？
ヘルプを読まないただのDQNだと思われ。

>>422
HELPを見るようじゃ、ベテランとは呼べない。

全員分消すのがすさまじくめんどくさいという説も。

>>422
プログラマーなんて上は神から、下は char と double の違いがわからなかったり、malloc が使えないやつまでいるからなあ。
しかも、別分野に特化してて遊び半分に Win なソフトを作ることだってあるわけだし。
そもそもスタンドアローンの 9X 系だとログインプロンプト見ないほうが普通だし。
別に >>416 の話もおかしくは聞こえないなあ。

>>423
別にベテランじゃなくてもいいだろ（ｗ

MSは、アンインストール時に全ユーザのレジストリ設定を残すように言ってるんだっけ。
逆に全ユーザのレジストリ設定を削除するオプションをアンインストーラに付けるなら
ユーザにそのことを通知すべきとも言ってるんだよな。確か。
早いとこそれを簡単に実現できるAPIとかMSI作成アプリを出して欲しいよ。

>>382
> 全部選択式でいけますがなにか。
何もかも選択させればいいと言うのは一見親切なように見えるけど
実は選択の責任をユーザーに押し付けてるだけでそれも一種の手抜き。

使用の責任はユーザ個人にある。
使用許諾に書いてあるだろ。

>>428
去年か一昨年の4月1日に消費者契約法だか何だかが改正されて
そういった一方的な契約って無効にならなかったっけ？
かなり前に新聞でチラッと見ただけで自信は無いのだが。

>>429

フリーで損害でも補償しろとでも？
ひぐちみたいなこと言うんじゃねｰよ。
嫌なら使うなﾎﾞｹｪ

>>430
だから、そこんとこどーなのか聞いてる訳だよ。
別にフリーソフトに損害賠償を請求してる訳じゃないって。
つーかそんなの通る分けなかろう。

作者に過失があれば別だけど、
>>427が言ってるのは選択するかどうかの責任。
損害じゃないし。

選択の責任ってなんだよ？
ソフトを使うということは、選択の連続だが全部作
者に責任を取れと？
それとも全ての選択に対して説明をつけて、いち
いち確認しろと？

だいたい選択の責任とか言い出す優柔不断で頭
の弱い奴はソフト使うな。マジで

今後の人生体力と笑顔で乗り切ってくれ(藁

>>433
いや、だから>>427の言ってることは的外れだろってこと。

　一　重要事項について事実と異なることを告げること。
　　　当該告げられた内容が事実であるとの誤認。
　二　物品、権利、役務その他の当該消費者契約の目的と
　　なるものに関し、将来におけるその価額、将来におい
　　て当該消費者が受け取るべき金額その他の将来におけ
　　る変動が不確実な事項につき断定的判断を提供するこ
　　と。
　　　当該提供された断定的判断の内容が確実であるとの
　　誤認。

　以上二つが消費者契約法で違法となるかどうかの条件。
http://www5.cao.go.jp/2000/c/0512c-keiyakuhou.html

　Readmeやインストール時に書くこと書いてあって、事実に反しなければ
違法にはならない。
　もちろん、パッケージや売り文句に書いてあることと明らかに違うソフ
トなら、それについての契約は無効になる。

まーあたりまえっちゃあたりまえの話だよな

どっちにしろ免責条項が法律によって無効化されたら、フリーソフトを配布する人はいなくなるだろ・・・

>>437
つーか、そうなったらフリーでない個人プログラマーとか小さいソフトウェ
アベンダーは全滅するんじゃねーの?開発者や配布者の免責事項を無効にする
ってことは、ソフトの開発、配付、販売についての権利と義務を一切国の法
律で管理するってことだもの。

しかし、IEとかMS製品の場合、そのセキュリティーホールのせいで損害を受けたと
本気で訴えたいと思ってるﾔｼが多数存在するという現実。

どっか違う国へ引越す必要があ（以下略

セキュリティホールならMSに限った話ではないが
むしろ「MSだから」という理由で訴えたいﾔｼが多数存在するという事実。

いや、MSの場合IEは安全で快適な…とか言ってるから
そこら辺を突っ込みたいのでは。。。

＞MSの場合IEは安全で快適な…
それは免責事項や使用許諾じゃないだろ（ｗ

あ、ほんとだ・・大ボケした。ごめん

懐かしいスレが上がってるね。
結局なぜレジストリはダメなんだか分からなかったが。

理想的なインストーラーの仕様を詰めて語るとか……ダメかな？

Program Files\作者名\ソフト名 っていうフォルダはやめてほしい。
アンインストーラーついてないソフトを消すのに苦労する。
別に作者名で分けたところで何のメリットも無いと思うのだけれどなぁ

>>448 あえて理由を探すなら、ソフト名より作者名の方が
カブリにくいからだろうね。
ファイルの場所自体も 作者名\ソフト名 と二重のくくりにした方が確実。
その場合、ソフト名フォルダ内に本体がある方が自然でしょ。
レジストリの登録と同じ理屈だと思う。

Microsfotが 会社名\ソフト名 を推奨していて
個人だから会社名の代わりに作者名という程度の
理由と思われ

どっちなのか今ひとつわからないけど
>>449さん
ソフト名がカブるってそんなにあるのかなぁって思った。

>>450さん
なるほどーと。 それくらいの理由だったら勘弁して欲しいけど＾＾；

>>451
かぶっても大丈夫なようにMSが推奨してるんだろ?

>>451
滅多には被らないだろうけど、被った時は何が起こるかわからないし。
読むソフトの想定外の設定になってる可能性があるんだから。
出来るだけ被らないようにしてくれた方がいいっしょ。

INIならまだ許せるがレジストリに2バイト文字を使うのは止めて欲しい。
海外製のレジストリ最適化ソフト使ったら漢字使ったレジストリキーの所で
無限ループ起こしたらしくログがとんでもない事になってた。

なら国産のを使え

>>454
それは困るね。
レジストリを掃除するソフトで国産ので良いのがあれば使うけど良いの無いしね。

ageageage

そりゃ言いがかりってもんだろ。
日本語キーに対応してない最適化ソフトのほうが悪い。

>>454
それってその海外製アプリの不具合じゃん。
作者に2バイトコードに対応してくれって要望出せばよい。

そのソフトについてはそれで良いかも知れんが
他のソフトでも不具合が出る可能性が出てくるわけでしょ。
だったらわざわざ不具合が出るかもしれない2バイト文字の使うこたねーと思うが。

追記。Regedit.exeも2バイト文字駄目みたいだね。
ttp://www.haltz.com/rgstry/chap3b/regedit.htm

そのページによると仕様違反の可能性もあるんだな。
なんのためにキーをUnicodeにしてるんだか(NT系の場合)。

。
　　　o　　　　　　　　　　　　　　O
　　　　　　　　　　　　　　　　　　o
　　　　　(（　　　／甲甲＼ 　　　　　ｽｲｽｲ
　　　　(（　　＜（　　　　( ´∀｀)　　　 そろそろageるか。
　　　　　　　　⊂亠⊂亠亠⊃
　　　　　o

ﾎｯｼｭｯ ﾎｯｼｭｯ

こんなスレ立ててもいいと思いますか？おけが出たら立てようと思うのですが…
------------------------------------
【ｲﾝｽｺ】再インストールの必要の無い市販のアプリを紹介したりするｽﾚ【省力化】

Windowsが死んだとき、再インストールはお約束ですが、そこには非常に
無駄な労力が使われてしまいます。

国民総生産量（GDP）を引き下げる原因である「再インストール」を極限まで
省力化するスレです。

※パーティションの切り方など、基本的な質問は出来るだけよそでやって下さいおながいします。


つーことで、漏れのバックアップコンボ

�@RealSynkで
C:\WINDOWS\ｽﾀｰﾄ ﾒﾆｭｰ\
C:\WINDOWS\Favorites\
C:\WINDOWS\Tasks\
C:\WINDOWS\Cookies\
バクアプ

�Aﾚｼﾞｽﾄﾘを特定ソフトを狙い打ちでバクアプ

�Bノートンゴースト様でOS用ドライブを、復元

�Cﾚｼﾞｽﾄﾘ・データを、逆手順で復元

�D「新たに導入したソフト・ドライバを再インスコ」←無駄

�E(ﾟдﾟ)復元完了ｳﾏｰ　（所要時間　約30分　手順�Dの長さで変わる）

�F+α　ノートンゴースト様で、最新の復元CDを作る


このバクアプ法の弱点
C:\Windows\　なんかに糞dllをブチ込むアプリを再導入しなおす手間が発生する。

-----------------------------------------------------------------

ﾚｼﾞｽﾄﾘとあまり関係の無いソフトは、殆どDドライブに入れるんだが
こんなスレ、どうよ

いいね。
さっさと立てて首つって氏ね

>466
駄目か…。　
スレ立てる前に、聞いておいて良かったよ。
恥かかずにすんだ。ｻﾝｸｽｺ

マジでいいと思うのに・・
立ててよ！

余計なことするなよ。
こちとら、再インストールで金稼いでるんだ（ﾜﾗ

>>469
なんとも虚しい商売だね

でも現実だよな。

アンスコするときはちゃんとレジストリに書き込んだ分も消してよね。

でもさ、自分の書いた分（プログラムがね）とは別に、OSが書き込む値もあるでしょ？
他にも、フレームワークを使って書くと、自分は使ってなくても、フレームワークが使ってるとか。

INI

>>420
そこで急遽作られた
http://www.geocities.co.jp/SiliconValley-Oakland/8192/
って思わずひざを打つような(打ってねーけど)指摘がいっぱいあるね｡
やっぱり作り手でも分かってる人は分かってるんだ｡

ini…文字列しか書けない・遅い
レジストリ…アンインストが面倒・バックアップしにくい

つーか、今時XML化してないのは糞だ。

XML…遅い、パーサの分実行ファイルサイズが増える

XMLはDTDを切ればiniよりは遙かに早いよ。
iniは呼び出し要求があるたびにファイルを開いて、
キーをサーチしてるから遅い。

フリーで内臓可能(DLL不要)の小さな(数KByte以内)のパーサが無いと使う気になれん。

漏れのパーサはDOM level1準拠で8kbほど。
速度はも遅い方かも知れないけど、
iniよりは早いと思うよ、うん。

下がりすぎ、上げ。
私はini派だなぁ・・・1ユーザーとして。

>>479
バッファ内で処理すれば良い。

>>483
そんなことをするんじゃ、コメントの取り扱いが面倒になるし、
手軽に扱えるのがウリのiniを利用する意味もほとんど無くなる。
DelphiとかみたいにはじめからTMemIniFileとか用意されているならいいけどね。

age

iniならへぼユーザでも簡単にいじれる

カスソフトに限って必ずレジストリ

へぼユーザはiniファイルを不可視にしてます。

soreha ieteru

正直、482みたいなのは何の参考にもならない

iniなら（自分をへぼユーザと気づいていない）へぼユーザでも簡単にいじれる

ざっとスレ眺めてきたヘボプログラマだけど、
漏れもini（レジストリも）はいじられたくないなぁ。
バックアップのためってもiniをコピーされたくねー。
てことで、設定を書き出せるようにするほうに一票。

で、ｽﾚ違いっぽいけど
ﾏﾙﾁﾕｰｻﾞｰ = EXE一個で複数のユーザーに対応
ﾏﾙﾁｲﾝｽｺ = それぞれのユーザーにEXE一個ずつ
てことを踏まえて
ｲﾝｽｺはiniをEXEと一緒にしてあとはご自由に
ﾏﾙﾁﾕはiniかregで、uninstallはゴミのこすなよってこと？
でもさぁ、ﾏﾙﾁﾕの場合ｲﾆでもﾚｼﾞでもｱﾄﾞﾐﾝしか完全に消せなくね？

となると、やっぱソフトがﾏﾙﾁﾕ云々じゃなくてｲﾝｽﾄｰﾗの
問題じゃねぇの？
完全にﾏﾙﾁﾕ対応にしようとするとｱﾄﾞﾐﾝしかinstallできなくね？
UsersでもＯＫとなるとｼﾝｸﾞﾙしか無理っぽいけど、結局
ｼﾝｸﾞﾙ = ｲﾝｽﾄｰﾗなし、
ﾏﾙﾁﾕ = ｲﾝｽﾄｰﾗあり
こゆこと？

Admin権限無いとProgram Files以下にインストールも出来ないと思うが。
Admin権限があると、適切にアンインストール処理すれば、
他のユーザーのレジストリも消せる。

Power Usersでもインスコできるんじゃない？

それと、シェア作家居たら聞きたいんだけど
使用期限どこに保存する？（ｗ

HKCR\CLSID以下

>>495
MBRに記録していたツワモノがあった。ウィルスかっつーの。
シェアウェアというか計測用ソフトだが。

>>493
そうだよなぁ、ﾏﾙﾁﾕの場合ｱﾄﾞﾐﾝじゃないとキツイよなぁ。
>>494
PowerUserでもProgram Filesｲﾝｽｺできるけど、
ここのとこよく知らないんだけど
例えば他のﾕｰｻﾞｰの設定消せるのかな？
消せなかったらゴミ残しそうな。。。。

てことは、ｲﾝｽﾄｰﾗでｱﾄﾞﾐﾝで動いていたらﾏﾙﾁﾕとしてｲﾝｽｺ
そうじゃなかったらｼﾝｸﾞﾙでｲﾝｽｺってことでＯＫ？

>>497
サイズがでかめのブートローダー破壊して、再起不能になりそうだ。

>>498
ていうか、Admin以外でインストールするなと言う気もする。

結構みんな見てるねぇ（ﾏﾀｰﾘ
>>496
なんか、みたことある。某ＯＣとか（ｗ
これってやっぱりｱﾝｲﾝｽﾄしても、ここは残すね。
でもそれってゴミだよなぁ
しかし、こればっかりは綺麗にすると元も子もない（ｗ
そこんとこ難しいよな・・・
>>495
強烈だなｵｲ（ｗ。それってチェックに引っかかるって。
そこまではしたくねぇ、人として。

BIOS領域の空きエリアを調査して
そこに記録するドライバなら作ったけど、
自分で破壊したことがあるから公開してない（ﾜﾗ

俺もミニアプリ何個か公開してるけどさ、マルチユーザに対応してください
って言われたら、iniの名前をユーザごとに変えてマルチユーザ化するのが
手っ取り早いような気がするので、そうすると思う。

EXEと同じところにini置いとけば、アクセス権も一元管理できるし。
何か不都合あるだろうか？

>>498
どうでもいいけど、何で「ﾏﾙﾁﾕ」というのに「ｼﾝｸﾞﾙﾕ」って言わないんです？

Program Files以下にインストールされた場合、
PowerUsers以上のグループじゃないとiniを作れない。

>>499
たしかにそういう気はする。
設定ファイルいじるなと同じで（ｗ
>>501
BIOSってｱﾝﾀ・・・ま、まさか神！？
>>502
503も言ってるけど、
それプラスみんながアクセスできるとこだと勝手に見られる。
まぁ、見られてもいいデータじゃないならいいんじゃないの。
あと作ったﾔｼしか読めない設定にする手も>NTFS
消す時はｱﾄﾞﾐﾝで。

というかそういう場合はiniを
C:\Documents and Settings\All Users\Application Data
C:\Documents and Settings\ﾕｰｻﾞｰ\Application Data
に置いた方がいいらしいと、上のほうで書いてあった（ｗ
しかし、こうやるとﾌｫﾙﾀﾞ探すのがうざいらしい。

ﾕってつけないとﾏﾙﾁｲﾝｽｺと間違えそうだから。
まぁ、どうでもいいけどな。

>>503
書き込みできないなら、そのプログラムのフォルダだけ必要なアクセス許可与
えてくれ、と、運用する側に頼るのは甘えすぎだろうか？
ミニアプリの場合は、だけど。
書き込みできないときはその旨のメッセージボックス出すか何かして。

>>504
データの機密性

　　レジストリ（HKCU）　　ファイル
9x　　　　×　　　　　　　　　　×
NT　　　　○　　　　　　　　　　△（FileSystem依存）

どっちでも動くようなアプリを作っている場合、データの機密性を保とうとし
たら一工夫いりますな。

ちょっと疑問に思ったことがあるんだけど、
レジストリって本当に早いの？
あの膨大なデータの中から目的のキーを選んで引っ張ってくるんだよね？
iniの方が早いと思うのは間違い？

間違い。

>>506
ハッシュって知ってる？

>>508
知ってるよ。
ただ本当に早いのかなぁって思っただけ。
>>507,508
ありがと

>>508
ハッシュってなんだ？
別にレジストリとハッシュは特別に結びつく物でもないが。
レジストリが速いのはファイルシステムと同じように、
Index+関連づけられたデータという構造だから。
iniファイルは、値取得、書き込み要求ごとに、
ファイルを開く＞リニアサーチ＞取得だったり書き込み＞ファイルを閉じる
というプロセスで処理されている。
でかくなってくると、当然、リニアサーチにかかる負荷も尋常じゃない物に。

べつにリニアサーチ云々じゃなくて、
システム的に優遇されてるから早いんだろ。

ハッシュでIndexを作りハッシュで関連づけられたデータをインデックスから探す。
(探すと言うよりハッシュなので計算すれば探さずに一発で辿り着くのだが)

>>510
ファイルシステムもリニアサーチだよ。FAT32のFindFirstFileとか。

結局どうなの？
レジストリへのアクセスはINIより早いの？
またINIの方が高速と感じたり、どちらも同じくらいって感じる
サイズはINIのサイズにしてどれくらいなの？

自分で作って調べろよ。

NTFSもレジストリもハッシュじゃないよ。
B+Treeを使っている。

>>514
iniの方が速いケースは存在しないよ

>>517
じゃぁ体感できるほどレジストリの方が早いケースって？

一回レジストリアクセス監視ソフトで監視しながらエクスプローラとか使ってみ。
これが全部INIアクセスだったら体感できるほど遅くなってるだろう。

>>518
そうだな、アプリケーション自体が違うから、
比べられないといえば比べられないけど、
レジストリを使用しているテキストエディタと、
iniファイルベースのテキストエディタの起動時間とか比べてみると良いんじゃない？

>>519,520
うん、それは分かるんだけど、
1k,2k程度のiniをレジストリに変更しても、
そんなに速度差を感じないんだよね。
だからその程度のファイルをわざわざレジストリに置いて
Win全体を不安定にさせなくても…って思うんだよね。
まぁNT系だとそんなに不安定にはならないんだけど、
チリも積もればってやつで。

IEとかは1MByteとかレジストリに置くんだから、
そこいらのソフトで数KByte使ったところで不安定になるとは思えんが。

数百k以上の設定ファイルじゃなきゃ
iniとレジストリの読み込みや書き込み速度なんてわからないだろ。

>>523
そうでもないよ。その1/10位でも速度差でるんじゃない？

>>521
おいおい、、、
レジストリに書き込むと不安定になるっていったいどんな環境だよ。
HKCU以下に書き込んでも、OSの基本部分への影響は皆無だよ。
dbファイルからして別物なんだし。

OSの基本部分もHKCU読むわけだが。

>>524
それじゃぁ体感できんじゃん…

レジストリの読み書き速度は
レジストリの項目数に対する対数オーダー＋メモリアクセスのオーバーヘッド分で
iniの読み書き速度は
iniの項目数に対する線形オーダー＋ファイルアクセスのオーバーヘッド分じゃないの？

結局レジストリの優位点って
「マルチユーザへの対応が簡単」ってだけ？
速度差も馬鹿でかいサイズを一気に読み書きしなきゃ体感できないんだろ？

ていうか、ここの話聞いてると
今あるレジストリ使用するオンラインソフトの99%はINIで問題なさそうな気が…

MSがレジストリ使えINIは過去の遺物だって言ってるから
それに従ってるんじゃないの？

>>526
あんた、キッチリ調査して言ってますか？
HKCU以下を読むのは各種サービスやShell等です。
カーネルやWin32サブシステムに必要な情報はHCLMにしか記録されていません。

>>531
OSの基本部分の定義が不明。

>>529
速度は2〜3kbでも体感できるよ。
たとえば、ファイラーのDFをiniを作らない状態と、
iniを作ってからで起動速度比べてごらん。

2〜3KB程度のINIファイルだと線形サーチよりも
ディスクアクセスのオーバーヘッドが問題なんじゃない？

つまりみんなSCSIでRAID0でNTFSならiniもレジストリもほとんど変わらんと。

>>534
やってみれば分かるって。
１度起動して全部キャッシュに入れてからでも体感出来るから。

iniには文字列しか記憶させられない。

2〜3KB程度で体感できる速度差って、
よっぽど実装方法が悪かったとか、
使ってるハードがよっぽどショボイってだけなんじゃぁ…

>>538
ディスクアクセスがある時点で例え何バイトであろうと
ファイルを探したりロックしたりする色々なオーバーヘッドがかかるから
それが問題なんじゃないかな？
レジストリは常にメモリに載っかってるから速いんじゃないの？

>>538
ショボくてごめんね。
DFの起動時間を計測した結果、
iniあり:430ms前後
iniなし:460ms前後
実際にワンテンポ遅れる感じがしてる。

ちなみに、計測環境は
PIII1GHz 512MB SDRAM Win2kSP2
LANのプロパティを見ると、起動してから24日と9時間だそうだ。

>>539
iniファイルはすべてレジストリに乗る。

ちなみに、この時点でのdf.iniの内容は

[OPT]
EDITOR=NOTEPAD.EXE
USEDEF=1
ACTIVE=1
EXTCMD=1
CLOSEQUERY=1
[FONT]
DIRBOLD=1
DIRBLACE=0

の102バイト。

>>540 iniファイルはすべてレジストリに乗る。
意味不明だ。
キャッシュに訂正。

これだと、iniが遅いという測定にしかなっていないけど、
レジストリが遅いという意見は出てないから構わないよね。
測定して比べろと言うのなら、適当にiniとレジストリで速度差計ってみるけど。

ちなみに、上の測定に使ったソースの要点部分だけ出す。

timeBeginPeriod(1);
t = timeGetTime();
ShellExecuteEx(&shei);
WaitForInputIdle(shei.hProcess, INFINITE);
printf("%dms\n", timeGetTime() - t);
timeEndPeriod(1);

DFが内部で何やってるか分からないんだから、
自分でレジストリアクセスとiniアクセスをして時間測った方がいいと思う。

俺も参加。
テスト用コード書いてやってみた。[Win98SE、Pen2 333MHz]
それぞれ 10000回データを読み出して timeGetTimeで時間計測。
数字は int型の数字、文字は 11バイトの文字列。
平均を取った大体の所要時間は...

□INI（win.ini[約11kB] の最後のほうのデータを読む）
　数字：約3600ms
文字列：約3150ms

□レジストリ(HKCU\software\testというキーの下に値を作成)
　数字：約60ms
文字列：約60ms

win.iniは
HKLM\Software\Microsoft\Windows NT\CurrentVersion\IniFileMapping
にキャッシュされてるから普通に同じサイズの
プライベートなiniから読む場合はもっと遅くなるんじゃない？

ini
　0=00000000000000000000
　(略)
　999=00000000000000000999
　上の形式で、GetPrivateProfileString()の1000回ループで計測。
　0〜999を順に取得 4200前後
　0のみ取得 3900ms前後
　999のみ取得 4500ms前後

レジストリ
　0〜999を順に取得 200ms前後

ちなみに、iniファイルのサイズは26kbでした。

実測が出てきた

書き込み
（11バイトの文字列を 10000回書き込む。INIは文字列でしか書き込めないので、
文字列のみのテスト）

□INI　　　　　　約3600ms
□レジストリ　約78ms

こんな感じ。INIはもっと遅いかと思ったが．．．
（実使用時はデータの局所性が下がるので、差は大きくなるかな？）

>>545
Win98なんで、それは大丈夫。
（INIファイルを他の場所にコピーして試したが同じような結果だったし）

>>545

>>544のOSはNT系じゃない(98SE)だからキャッシュされないんじゃない？

チョンマルサランヘヨ

レジストリを汚されてもいいソフトとそうでないソフトがあるってこった

>>549
WritePrivateProfileString(lpszSection, lpszKey, lpszString, lpszFile)
のlpszSectionとlpszKeyは1万回とも同じ？
それだったら書込するiniの項目数にもよるんじゃない？
書込時にもすでに同じ項目があるかサーチしなきゃいけないわけだし。

>>550
9x/NT関係なくキャッシュされる。
キャッシュされないiniはフルパスを指定したiniのみ。

>>544は下の方にあるとか曖昧な点が多い。
データは何でも良いから、>>546のように連番で試してみて。

>>553
おっしゃるとおり。
まっさらな iniファイルに同じように書き込んだら、350ms になりますた。

疑問なんだが、>>544の環境だと10000回
>>546の環境だと1000回と、桁が一つ違うのに546の方が遅いのは
いったいどういうマシン使ってるんだ？
今時486のPCなのか？

データの行数の違いじゃない？

>>546　と全く同じ方法で試してみた（20バイトの文字列を読み書き）

不思議なことに READ/WRITEの速度がほとんど同じ（INI、レジストリ共に）
□INI　　　　　 約 610ms
□レジストリ　約135ms

>>546と差が結構あるのは．．．コーディングとか環境のせい？ 当方VC6です。
（デバッグ/リリースビルド両方試したが速度に明確な差はないっぽい）

>>559
下のソースでたのんます。
ウチだと2500ms程度ですた。

#include <windows.h>
#include <stdio.h>
#include <mmsystem.h>

#pragma comment(lib, "winmm.lib")

int main()
{
  char key[256], buf[256];
  DWORD t = timeGetTime();
  for (int i = 0; i < 1000; i++) {
    sprintf(key, "%d", i);
    sprintf(buf, "%020d", i);
    WritePrivateProfileString("0", key, buf, "c:\\test.ini");
  }
  printf("%dms\n", timeGetTime() - t);
}

>>560
timeBeginPeriodで制度上げなくていいの？

>>561
数千msに達するのに、10ms程度気にしてもしゃーない。

仮説１
>>560の環境がよく分からないけど、>>544の環境と比較して
これほど数値の差が出るほど低いとはあまり考えられないから、
NT/2k/XP環境と考えると、
NT系ではiniのパフォーマンスが極端に落ちていると考えるのがいいのかな？

>>560
590ms 程度でした。

ちなみに、ウチの環境はWin2000SP2でPentium3 750MHz/256MBの環境です。
1 ウチの環境がおかしい
2 >>563のようにNT/9xで差がある
のどちらかでしょう。

ちなみに、VC6SP5、最適化オプションなしです。

>>565
W2KSP2, P!!!933MHz/512MB/440BX
でiniが無い状態で450ms、一度実行してiniに記録されてる状態で550ms程度だったよ。

上のはVC6SP5速度最適化。
最適化無しにしても20msくらい遅くなるだけ(timeBeginPeriod(1)使用)。

>>568
test.ini、キッチリデータが作成されてます？
だとすると激しく謎です。
自宅の別PCでやっても同様な結果でした

仮説2
560の環境がおかしい。

>>569
作成されてます。それと何度か実行してみると
最適化有りでも無しでも数msしか変わらないみたいです。

ドーン
使っていないNSWをアンインストールしたらパフォーマンスが600ms程度まで上がりました。
あとはアンチウイルス系２つ常駐させてるんで、これをはずせばまともなパフォーマンスでるでしょう。
Norton氏ねって感じです

で、やっぱりレジストリのほうが速いという結論

INIは１回目の READのときはディスクキャッシュに無いから、
相当遅くなることもあるし。

俺もテストしてみた。
テスト内容は、
IniFileのエントリ数の違いによる時間の変化。
面倒臭かったからそれぞれ一回ずつ。
左がエントリ数（1のときはエントリ数2個、50の時は51個ね^^;）
開発環境はDelphi
あらかじめ乱数を発生させ、WriteIntegerにて書き込み。
こんな感じ

TC := TimeGetTime;

IniFile := TIniFile.Create(ChangeFileExt('.\'+intToStr(b), '.ini'));
for i:=0 to b do
IniFile.WriteInteger('TEST', IntToStr(i), iwork[i]);
IniFile.Free;

1: 10 ms
50: 90 ms
100: 230 ms
150: 371 ms
200: 531 ms
250: 671 ms
300: 891 ms
350: 1041 ms
400: 1262 ms
450: 1512 ms
500: 1773 ms
550: 2023 ms
600: 2333 ms
650: 2594 ms
700: 2874 ms
750: 3255 ms
800: 3875 ms
850: 4056 ms
900: 4446 ms
950: 4877 ms
1000: 5168 ms

以下は574で作成したINIを読み込んだとき

1: 0
50: 50
100: 161
150: 210
200: 280
250: 371
300: 461
350: 560
400: 661
450: 982
500: 861
550: 951
600: 1082
650: 1162
700: 1241
750: 1412
800: 1563
850: 1692
900: 1793
950: 1932
1000: 2023

そうそう、乱数は0〜100000の間ね。
1000で10.5ｋbyte
あと俺の環境は
Cele535 Mem256 2kSP2。

エントリ数が300くらいまで(約3k)ならiniで十分なんじゃないの？

正直、50ms以上取られたくない

操作→視覚へのフィードバック　において人間が認識できる遅延ってどのくらい
だったかな？ 最低でも 33ms、本当は 20msくらいでないとダメ．．．だっけかな？

>>577
使うソフトにもよるが、
500ms程度じゃぁソフト本体の起動時間を考えると大した影響はないだろ。

>>505
> 書き込みできないなら、そのプログラムのフォルダだけ必要なアクセス許可与
> えてくれ、と、運用する側に頼るのは甘えすぎだろうか？

甘えすぎだと思う。やるならそれぐらいインストーラーがやってほしい。
でも複数ユーザーが共有するプログラムのフォルダに下手に書き込み権限を
与えるとトロイを仕掛けることが可能になってしまうのであまりやりたくない。
それにその方式だと移動プロファイルやドメインユーザーにも対応できない。

個人的には、運用によるカバーが許されるのなら素直にプログラム自体を
%USERPROFILE%配下にインストールするよう促したほうがいいと思う。それなら
プログラムはマルチユーザー対応のために何もする必要はないし、ユーザーに
とってもわけのわからない設定をいじる必要がなく直感的でわかりやすい。
XP Homeではセキュリティ設定を変更するにはcacls.exeを使うしかないし。

559のソースを http://www.nakka.com/lib/ にあるiniファイル関数に置き換えて計測してみた。

#include <windows.h>
#include <stdio.h>
#include <mmsystem.h>
#include "Profile.h"

#pragma comment(lib, "winmm.lib")

int main()
{
char key[256], buf[256];
DWORD t = timeGetTime();
Profile_Initialize("c:\\test.ini", TRUE);
for (int i = 0; i < 1000; i++) {
sprintf(key, "%d", i);
sprintf(buf, "%020d", i);
Profile_WriteString("0", key, buf, "c:\\test.ini");
}
Profile_Flush("c:\\test.ini");
Profile_Free();
printf("%dms\n", timeGetTime() - t);
}

WritePrivateProfileString
5818ms
5487ms
5517ms

Profile_WriteString
180ms
190ms
180ms

他にiniファイルをアクセスする代替ライブラリあれば計測きぼん

>>581
環境教えて。
VirusBusterやNortonが常駐しているかとかも。ｌ

WritePrivateProfileString1000回だけど、
400ms前後で終わる環境と数秒かかる環境があるようだ。
>>567によるとW2KSP2の環境でも速いこともあるようだし。

>>28
今更ながら。

「フールセール」って何？
（「フェイルセーフ」「フールプルーフ」なら聞いたことあるんだけど。）

マルチブート環境でプログラム共用してるからINIじゃねぇと設定面倒。

>>582
Windows2000SP2
VC6
Norton AntiVirus Corporate Edition

レジストリに書き込むなら
レジストリをバックアップする
バッチが欲しい

探すのが面倒

あんまりいらない。

可能な限りレジストリは弄って欲しくない。
とくに、
レジストリに登録する情報が
アプリの追加と削除だけとか、
アプリのポジション情報だけとか、
邪魔なだけ。

それと、どうしてもレジストリに登録する必要があるんなら、
分かりやすい名前で登録して欲しい。
今日たまたまレジストリ開いてみたんだが、
「\TurboPower\APRO\」ってなんじゃ？
これじゃぁ検索のかけようもないじゃないか！
どうせ弄くるんだったらついでに
ソフトのフルネームを入れたキーとか作っておいて欲しい。

コマンドラインオプションで起動時に読み込むINIを指定できるタイプが1番好き。

レジストリ使う場合でも HKCU\Software\ 以下ならあんま気にならないけど、
その場合でもそのことを readome.txt 等に明記して欲しい。

レアなドーム

つーわけで、iniマンセー！！

レジ弄るソフトは作者の嫌がらせだよな

レジストリを使う場合は書き込む場所なりをきちんと記しておいて欲しいね。
ViXの設定保存をINIからレジストリに変えたら起動が早くなったので、起動に
時間のかかるようなソフトは選択出来るようにしてﾎｽｨ

>>593
禿同。
でも、INIばかでかくても最近はそこまで気にならんよ。
ここにいてるヤツも結構タブブラウザ使ってるだろうけど、
起動に物凄いストレス感じるヤツいてるか？
最近のタブブラウザの大半はINIだろ。
みんな大した文句言わずに使ってるじゃん。
Donutにいたっては「軽い」っていわれてんだぜ？
俺は現在のメインはSleipnirだけど、
アレほど設定をバカスカ書くヤツもそうそうないだろ。
それでもそれなりの起動スピードを実現してる。
ようは「早いから」ってだけでレジストリ使用するやつは
面倒くさいからだけなんだろうね…

EmFreeのような起動爆速ソフトがiniにしたら
それだけで体感できるパフォーマンスの低下が起きると思うが

>ようは「早いから」ってだけでレジストリ使用するやつは
>面倒くさいからだけなんだろうね…

なんでｺｲﾂはこんなに偉そうなんだろう…？
使わなきゃいいじゃん。

>>596
スレタイに「VS」って書いてるじゃん。
目暗か？
そんなことを言ってずにスレの流れも悪くなってきてんだから
もう少し建設的な意見を述べたらどうだ？

お題
「INIでスピードを殺さない方法とDonutが何故早いのか」
まずはDonutがレジストリ派に代わった場合どうなるか。
見違えるほど早くなるんだろうか。
それともそんなに変わらないだろうか。

実際問題として興味があるのは逆で、
レジストリ使うソフトがINI使うようになったらどれくらい遅くなるのかどうかということだけどな。
多機能なエディタとか。

どれほど遅くなるかっていうより、
それが実用的なスピードだったらそれでいいわけで…。
それに、エディタとかブラウザみたいに一回立ち上げたらそうそう消すことないんだから、
それ程起動スピードなんて気にする必要はないと思う。

>>597
vs はレジストリとiniの利便性や速度、開発側の手間も含めた比較などだろ？
レジストリを使ったソフトを作ってる作者をめんどくさがりだって言うのはどうかと。

レジストリは利用手順が煩雑なんで、どっちかというとレジストリの方がめんどくさい。
マルチユーザーなどを考えると過去にも出てきたように、iniが面倒になる（唯一絶対の解が無い）
…まぁ、一度ラッパーを作ってしまえば良いことなんだが。

>「INIでスピードを殺さない方法とDonutが何故早いのか」

iniでスピードを殺さない方法
＞iniにコメントを含め極力何も記述しない事。
＞速度に問題が出るほどたくさんのプロパティを一度に読むようにしないこと。

Donutが速い理由
＞実際問題として、通常サイズでのiniのオーバーヘッドはたいしたこと無いし、
＞頻繁に起動終了を繰り返すアプリでもないから、気になることがない。

>>599
SDIだったら頻繁に立ち上げることになると思うが？

SDIだからといってマルチプロセスとは限らない

>>600
> Donutが速い理由
比較対照がIEだからじゃないのか？

>>603
相対速度じゃあんまり参考にならないよな

別にIEと比較しなくても、
スタートページ表示しないようにしたときの
起動速度は実用には耐えがたい速度なのか？
俺は十分に実用的な速度だと思うぞ。

正直Donutなんてどうでもいいずら。

>>605
それはソフトによるだろ。
ブラウザなんかは別に0.5秒かかろうが1秒かかろうが大して気にならないが、

たとえば付箋紙とかメモソフトでメモを記入できるようになるまでに0.5秒かかったらイライラする。
起動した瞬間、ホットキーを押した瞬間に即座に入力可能になっていないと、使えないだろ。

ユーザーのことを考えるとやっぱりiniでいいかなと思っちゃったりするわけで・・・。

ユーザーって何？
マルチユーザーはどうすんの？

世に出回っている大半のオンラインソフトは
マルチユーザは「必 要 な い」
マルチユーザを考える必要のないソフトに
マルチユーザのためだけにレジストリを弄られるのは
「迷 惑」

適材適所ということで。

迷惑は良いんだけど、普通の作り方じゃadmin以外で動かなくなる可能性があるじゃないか。
何も知らない/Power権限もらえないユーザーにも設定を強要するの？

インストールとはそういうもの。

かくしてreadmeを読まないタコ論争に発展するのであった。

インストーラをつつくしか能のないユーザーに設定とやらを強要するほうが
よ　っ　ぽ　ど　迷　惑

しかも強要される理由が開発者の偏った美意識のせいなのだからたまらない。
たいていのユーザーは設定がどこに保存されるかなど気にもとめない。

偏った美意識ねぇ。
基地外は大抵自分が標準的な考えだと思うものだ。

たとえばレジストリに保存することは何が何でも悪だとかいうini信者な。
Microsoftも基地外だといわれたら反論できんが(w

小さなソフトはINI。
大規模なソフトはレジストリ。

マルチユーザ必要のないソフトにレジストリ使うのやめれ。
そのソフトに本当にマルチユーザ必要かちゃんと検証しれ。
INIでどうしてもアホみたいに重くなるなら、
読み込みのタイミングを分散させるとかして実用に耐え得るようにしれ。
検証に検証を重ねた上どうしてもレジストリが必要ならば
ユーザでINIかレジストリかを選べるようにしれ。

あと、インストーラやめれ。
インストーラ使うなら使わない版も同時に用意しれ。

初心者あがりのころが一番ｷｬﾝｷｬﾝ五月蝿いのな

レジストリ使うんだったらいっそのことインストーラ付きのほうがわかりやすいな。
インストーラ無しでしれーっとレジストリ使うソフトは
再セットアップの時についレジストリのバックアップしそこねてしまう。

>マルチユーザ必要のないソフトに
おまえ馬鹿だ、このスレ読んでないのか？

マルチユーザー環境で使われる可能性のないソフトならそれでも良いが、
NT系で使われるならProgram Files以下はデフォルトじゃ通常のユーザーで読み書き出来ないんだから、
iniファイルを作れないんだよ、ボケ。

>>623
初心者とかファイル整理によっぽど物臭なヤツじゃない限り
インストーラ使わないようなソフトを
わざわざProgram Files以下に置くか、ボケ。
しかもちゃんと「INIかレジストリか選べるように」って書いてるだろ。
お前が馬鹿だよ。

つか、作者でもないあんたが偉そうに何様のつもりだ

>>624
その初心者が一番のネックだと言うことが分からんのか
初心者じゃなければ自分でフォルダの権限設定できる

>>626
初心者が一番楽。
よく分からんソフトには手を出さない。
手を出したソフトは初期設定から弄らない。
何よりレジストリとかINIとかで文句言わない。

>>625
あんたが偉そうなのはナゼ？（　´,_ゝ`）

初心者の本当の怖さを知らないのか、話すだけ無駄だな。

あれ、マ板だかどこだかの「readme.txtにアンインストール情報を」っていう
スレ、DAT落ちしちゃった？

落ちた

ﾏﾀｰﾘとレジストリをｺｿｰﾘ使おう。
もちろんreadmeには「フォルダを削除するだけで結構です」と書いておく（ｗ

> 何よりレジストリとかINIとかで文句言わない。
文句言わないんならレジストリでいいじゃん。
設定が保存できないとか変なエラーが出るのには文句を言うと思うぞ。

このスレまだあったんだ。自分で立てたのに忘れてた。
レジストリが嫌って理由はなんだかんだ言っても
「アンインストール時に全ユーザの設定が消されない」
これに尽きる。もうこのスレのだいぶ前の段階で尽きてる。
これが解消されない限り話はループだね。
逆にこれが解消されれば即解決。

ファイルに関してはアンインストーラが自分がコピーしてないものを
消すと叩かれまくりなのに
レジストリだと逆に全部消せとかいう人が多いのが不思議

レジストリだって自分が書いてないもの消すと叩かれるだろう。

たとえばbashをアンインストールしたときに
バリバリカスタムしていた.bashrcを問答無用で全部消されたら
ふつー怒ると思うんだが
全ユーザーのレジストリを消すってそういうことじゃないの?

>>636
それをアンインストーラで「全ユーザの設定を消しますか？」とかなんとか
選択できればいいってのがだいぶ前のレスで既出

もうたいがいのメリット/デメリットとその解決法は出尽くしたんだよ・・・
あとはそれを実行するかどうかなんだが、悲しいかな、ここはム/マ板ではなくソフト板・・・

次スレはム板に立てるか
あと300以上も話すだけのネタがあればの話だが

300も続いたらム板に立てることを忘れて、またこの板に立っちゃいそうだな

>>637
削除していいかどうかは管理者ではなく各ユーザーに
確認を取るべきだと思うがどうか
これはがいしゅつじゃなかったような…

>>641
じゃあ管理者が各ユーザーに「消してもいいですかぁ？」とアンケートでも取って
管理者の責任においてやれ。
判断に迷うなら設定を残せばいい。
残したって今までのレジストリの使い方と同じになるだけだから問題ない。

第一、ソフト使用の責任は使用者にあるんだから、管理者がどう使うか
（そしてどうアンインストールするか）までめんどう見きれんよ。

こんな感じの選択式アンインストーラ。
http://www.geocities.co.jp/Beautycare/4965/public/ex_uninstaller.html

>>642
ログオンのタイミングでレジストリへの追加や削除が走るようにはできないの
なんかIEはそういう動作をしてる気がするんだけど

>>644
　１．通常のアンインストール
　２．各ユーザーの設定もすべて削除する
　３．各ユーザーに選択させる
の三択オプションてことかぁ・・・。誰か作れないかなぁ。

でココまで読むと作る側は、
　　メンドイのでマルチインストールでいいやんって気分になる。

ってのが何時ものループだっけ？

>>26
ありがとう。Gmaskの設定が消せたよ。
インストールしたフォルダにini吐かないからレジストリだと
ばかり思って探していた。
一向に見つからないので検索したらこのスレが見つかった。
WIN.INIとは・・・

レジストリでもINIでもいいからアンインストールの情報入れ
やヴォケ！昔そんなスレがあった気がしたがDAT落ちしち
ゃったかな？

しょっちゅうOSを入れ替えたりHDD交換したりしてるので
iniファイルの方がいいんだけど
設定をエクスポートできるならレジストリでも何でも構わないな
秀丸とかレジストリの該当部分をバックアップできるし

(nt)user.datのバックアップでどうよ
システム不調の原因まで一緒にバックアップしてしまう諸刃の剣だが

一つ言いたい事は
ヒストリとかフォルダのパスをINIに書くんじゃねええ
って事だ。

保存先がレジストリでも
保存先が記述してあるか
最低でもわかりやすい名前ならいいんだけどな

IRIAが一番いいよな
レジストリ使ってるけどレジストリがサラの状態でも
初回起動時に勝手に修復してくれるし

>>650
どこに書けと？

readmeにレジストリを使用しているかどうか書いてないとどうしても使う気にならない

>>653
フリーソフト作ったときは書いてる。
シェアウェアの時は書かないYo（ｗ

>>652
デフォルトで解凍先のパスをINIとかに書き込むカスツールが
多いんだが、そういうのは駄目だと思う。まずはexeのカレント
からサブディレクトリ、プロファイル、外部パスっていうやり方
がいいと思う。大体これで解決だろ。たま〜にショートカットの
作業ディレクトリが空だと%windir%にINIとかログとかばらまくの
もあるね。BlackJumboD○gとか。

>>655
(;´Д`)あれには参った・・・はじめ何が起こったのかと思ったよ・・・
作業ディレクトリが未指定だと起動しないソフトも有る。プログラマがｳﾝｺ

655がどんなソフトの話をしてるのかわからん・・・
自己解凍型ソフト？

>>655
>ヒストリとかフォルダのパスをINIに書くんじゃねええ
一瞬これ読んでエディタとか使ったファイルのヒストリなんぞ何処に残すつもりじゃ？と思ったが、わかった。
ヒストリ＝初期設定と関係ないやたら長いデータ（ログとか）
フォルダ＝インストールしたフォルダ
こう？エディタとかの10個ぐらいのファイル履歴はOKなわけね。安心した。
たしかにデータの検索しないソフトはｳﾝｺだな。
まぁ、インストール後移動しないというのが前提のソフトなんだろうけど。
検索の労力なんてたかだか数行なのに。

>>658
＞エディタとか使ったファイルのヒストリ
こういうのは設定のiniファイルに残さないでほしい
違うiniファイルを用意してそっちに書いてほしい

ようするに、バックアップに値するものとそうでないものとを
明確に区分してあればなんでもいいよ

ちょっと冷静になってみる

>658
＞ヒストリ
そのままの意味で、ファイルのヒストリ
中規模なアプリだったらHISTORYファイルとか
作って欲しいな。拡張子はDATがベツト。
他の環境に移すとき俺のPCの
パス丸見えじゃ！っていのは神経質過ぎ？
さっき小規模から中規模までのツールでINI使ってる
奴消去するの疲れた・・・。只単にブチまけたいだけだったりする。
せめてヒストリーのメニューに履歴のクリアとか
付けてホスィ。レジストリはその辺再インストール
すればなくなるから楽っちゃあ楽だね。

＞フォルダ
例えばアイコンとかサウンドとか共有する
フォルダも・・・・以下略

カスなツールで2行ぐらいしか項目無いのに
ワザワザINI作ったりすんじゃね〜。バーカバーカ！！

>>660
ふつーレジストリ使わないアプリケーションのアンインストロールっつったら
フォルダごと削除 だろ
あとにはなにも残んねーって

あぁそういう意味か。
>>660でやっとわかった。
別にヒストリの拡張子なんて何でもいいと思うが・・・
パス見えても問題ないと思うんだけど、この点はマルチユーザインストールと
話題が被ってくるなぁ。

あとフォルダのパス、要は絶対パスで記録するなってことね。
それはごもっとも。

ってかこれってこのスレの話題？
レジストリだろうとiniだろうと関係ない話題だと思うんだが。

関係ないことはないというか
そういう情報をレジストリに記録したりするソフトも多いから
やだね って感じ

>>659
なるほど。バックアップするときにゴミが付いてくるのが嫌なのか。
作る側にとっちゃiniでもdatでもたいして変わんないんだけどね。
ヒストリだけ分けるのは盲点だったわ。
>レジストリはその辺再インストール
これはiniでも再インストールすれば同じと思う。
レジストリでも消さなきゃ消えないし。
>>661
たぶんデータ置く場所が本体以下のフォルダじゃないのかも。
いや、いまいち漏れもわからんが・・・

必要な設定をバックアップできるような仕組みを提供するアプリは
まだ少ないからなぁ。簡単に復帰できるようにするのがベストだろうけど。

で、結局はプログラマの入れ込み次第か（ｗ

かぶった（ｽﾏｿ

そもそもMSの推奨が
　レジストリ＋でかいデータはApplication Dataフォルダ
だからなぁ。推奨に従うと逆に環境移行のときの最大のネックになる罠。


と話はこうして無限ループに陥るわけだが・・・

>>666
推奨に従うわけではないがINI及びでかいデータでマルチユーザ対応にすなら
どうしてもユーザーフォルダ以下にデータを作らないといけないし。

マルチインスコなら本体以下に作れ移動も移行も簡単だけど
ユーザー別にインストするのがメンドクサイという罠。

一番いいのはデータを作らないソフトということに気がついた（ｗ

>>667
不便なソフトはレジ弄ったりINIを無闇に作るソフトより使う気にならない・・・・

>>668
確かにそうな（ｗ
半分冗談だが、常駐するだけで全くデータ作らないのがある。
パソ起動しなおすと消えるけど（ｗ

ここらで作る側の姿勢ってのを最終的に纏めると
結局アンインストロール時にきれいｻﾊﾟｰﾘ消せれば
iniでもレジストリでもいいが設定を保存＆復帰できるようにしる。
ってことでいいの？

全然関係ないけど、DOSにあった%PATH%のような物って
Winできたっけ？ワザワザパスを絶対指定しなきゃならない
のは不便なんだな〜。SUBSTでもしてまとめるしかないのかな・・・

出来るだろ。
95/98/MeはAutoexec.batに
2000/XPはｼｽﾃﾑのﾌﾟﾛﾊﾟﾃｨ->詳細->環境変数
から

パス通さないと正常に動作しないアプリは多いだろ。

スレ違いもいいとこだな

ﾎｯｼｭﾎｯｼｭ

>>671
>>672
超カメレスだが、ちげーよ。
「ファイルから指定して実行」で

%Desktop%\エロ.mpg

とかやりたいのさ。PATHはあくまで
DOSだべ

>>675
本気で言ってる？

>>675
じゃあNT、2000、XPにある%PATH%はいったい何なの？
NTにはDOSもへったくれもないんだけど？

>>677
ｺﾏﾝﾄﾞﾌﾟﾛﾝﾌﾟﾄ

>>678
あれはDOSではない。

> とかやりたいのさ。
やれば? 余裕でできますけど

だからスレ違いだっつーの。
カメレスでぶり返すな。

結論としては、!kubotarを見習えってことか