レジストリ vs プライベートINI
■ このスレッドは過去ログ倉庫に格納されています
0001名無しさん＠お腹いっぱい。
01/11/22 18:00ID:kWO77Burプログラマの視点から、逆にユーザの視点から、
それぞれの利点や欠点について意見を聞かせてください。
0116名無しさん＠お腹いっぱい。
01/12/06 16:50ID:???>保存先情報をexeと同じ位置にしたらマルチユーザーに対応できないし
なんでよ？マルチユーザ対応にするために使うんだけど。
>Users権限では保存先を変更できない状況
それは管理者が保存先を変更するなというルールを用いてるか、
でなければUsersでも変更できる場所にインストールすれ。
だいたい、
>全部exeと同じ位置に書けばいいじゃん。
って言うのだってUsersが変更できる場所にインストールすることが前提の発言だろ？
0117名無しさん＠お腹いっぱい。
01/12/06 16:55ID:???FFFTPの場合は簡単じゃん？
どっちかを調べて設定がなければ他方を読み込む。
今話してるのはマルチユーザの場合はどうするかってことで、
それを同フォルダに置くかディレクトリに置くか、と。
つーかみんな過去ログ読んでる？
0118117
01/12/06 16:59ID:???>それを同フォルダに置くかディレクトリに置くか
それを同フォルダに置くかレジストリに置くか
0119名無しさん＠お腹いっぱい。
01/12/06 17:50ID:???補足というかなんというかFFFTPはINIがあればINI優先になる。
どこに設定を保存しているかってのは、ちょっと発想が貧困だな。
ただ、ヘルプにもあるようにマルチユーザー用ではない。
>設定をINIファイルに保存するようにします。マルチユーザ環境でない時に使用してください。INIファイルは、ffftp.exe のあるフォルダに作成します。
>ＩＮＩファイルの方がレジストリよりもバックアップが簡単に出来るので便利です。
マルチユーザーで、個々に別々の設定を使いたいのならレジストリ使え
ば良いんじゃない？
共通の設定で構わないのなら、マルチユーザーでもEXEのあるフォル
ダにiniでも良いだろ。読み込みはできるんだから。
User権限で設定が変えられないのは仕方が無い。黙って管理者の設
定したままで使え。
0120名無しさん＠お腹いっぱい。
01/12/06 18:22ID:???ウィンドウの起動位置や起動状態（最小化／最大化など）みたいな
ちょっとしたことだけ保存されたら嫌？
0121名無しさん＠お腹いっぱい。
01/12/06 18:28ID:cnbIjEyD＞>保存先情報をexeと同じ位置にしたらマルチユーザーに対応できないし
＞なんでよ？マルチユーザ対応にするために使うんだけど。
漏れは114じゃないが、
マルチユーザ環境 = exeのあるフォルダはユーザ権限では書き込み不可
を想定と思われ。
保存先情報をexeのあるフォルダに保存というのは矛盾してる。
0122名無しさん＠お腹いっぱい。
01/12/06 19:02ID:???それは嫌すぎる。
だいたいﾚｼﾞｽﾄﾘ使うﾂｰﾙとかって、
どーでもいい情報に限ってﾚｼﾞｽﾄﾘに保存する傾向がある気がする…
まぁActiveXの登録とかｼｪﾙ拡張みたいな、
「OSの機能の恩恵をそのｱﾌﾟﾘｹｰｼｮﾝで享受する為にﾚｼﾞｽﾄﾘを用いる」
とかそういうのならむしろ歓迎。
けど、下らん情報しか保存しないくせにレジストリに保存するのは逝ってよし。
ところで逆に、レジストリじゃないといけない事って何？
たいていはINIで事足りると思われ。
てかマルチユーザ考えなきゃいけない場面ってそんなにある？
漏れ的にはPCは１人一台orそれ以上が基本だと思うから、
INIﾏﾝｾｰ派。
0123名無しさん＠お腹いっぱい。
01/12/06 19:18ID:cnbIjEyD＞ところで逆に、レジストリじゃないといけない事って何？
OSや他のアプリケーションとの連携に関する物はしかたないよね。
代表的なとこでは拡張子の関連づけとか。
それ以外だと、例えば各スクリーンセーバの設定情報とかがあるかな。
スクリーンセーバの実行ファイルってSystemフォルダに置かれるから、
そこにINI作られるとイヤーン。
Win3.1の頃はWIN.INIに勝手にセクション作って保存してたんだっけかな?
そういうのも嫌だよね。
まだレジストリの方がマシ。
＞てかマルチユーザ考えなきゃいけない場面ってそんなにある？
＞漏れ的にはPCは１人一台orそれ以上が基本だと思うから、
＞INIﾏﾝｾｰ派。
大学とか会社とか、そういう組織で使う場合かな。
あとはまあ家族で使う場合とかもあり得るかも知れないけど
家族でそんなきっちり管理者とユーザと権限分けて…
…とかってあんまやらないかな?
俺は個人でしか使わないからINIマンセーなんだけど。
0124123
01/12/06 19:26ID:cnbIjEyDそのアプリがインストールされてる場所を示す情報。
バージョンアップの際インストーラが
前のバージョンを上書きするために必要。
レジストリに場所を保存しておかないと
いちいち全フォルダスキャンして探すことになってうざいからね。
例えばRocketMouseはインストーラがデフォルトで
Program Files\MajoSoft\Rockm にインストールしようとするんだけど、
俺は嫌なので Program Files\RocketMouse にインストールしてる。
ところが新バージョンで上書きインストールしようとしても
また Program Files\MajoSoft\Rockm にインストールしようとしやがる。
いちいち修正するの面倒。
設定なんかはレジストリに保存してるくせに、
そういう情報は保存しないのって気が利いてないなーと思う。
0125名無しさん＠お腹いっぱい。
01/12/06 20:04ID:???だーかーらー、デフォルトで\Application Dataを読むようにするんだって。
0126名無しさん＠お腹いっぱい。
01/12/06 20:06ID:f6PGwbxH0127名無しさん＠お腹いっぱい。
01/12/06 20:11ID:???0128名無しさん
01/12/06 20:21ID:???あー、やっと意味がわかった気がする。
保存先をexeと同じフォルダのINIに記録するんじゃなくて、
Application Dataか、それともexeと同じフォルダか、
どちらのパターンを使うかって情報をexeと同じフォルダのINIに記録するわけね。
権限の関係でexeと同じフォルダを使えない場合は
デフォルトでApplication Dataに逝くから問題ないと。
要するにFFFTPと同様のパターンか。
>>126
それだと全ユーザがPower Users以上の権限を持ってないと破綻する
中途半端なマルチユーザ対応になってしまうような。
0129名無しさん＠お腹いっぱい。
01/12/06 20:38ID:???えっと、どちらかのパターンかじゃなくて、
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を
読みに行くようにするとか。
0130名無しさん＠お腹いっぱい。
01/12/07 03:03ID:???system wide settingはexeと同じフォルダに置くiniファイルに記録
%APPDATA%以下にiniがあれば、その情報で上書き
みたいにすればいいんじゃない?
iniを保存する時はデフォルトでは%APPDATA%に保存しようとするけど
exeと同じフォルダを指定もできるようにする。
%APPDATA%に入れる時はexeと同じフォルダにあるiniファイルとの差分
のみ保存してくれた方がメンテナンスしやすいかも。
0131名無しさん＠お腹いっぱい。
01/12/07 03:12ID:???>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のようなセットアップパターンが提供できる。
0132名無しさん＠お腹いっぱい。
01/12/07 04:02ID:???設定の保存先を記録するiniもsystem wide settingだしね。
ソフトによるだろうけどsystem wide settingなものは同フォルダでいいと思う。
なるほど、設定のオーバーライドはいいかもしんない。
0133名無しさん＠お腹いっぱい。
01/12/07 04:06ID:???持たせられるともっとよさげ。
0134名無しさん＠お腹いっぱい。
01/12/07 08:21ID:???なんだかややこしいので、
結局作る人的にはレジストリが一番楽なのであった…
0135作者兼使用者
01/12/07 08:35ID:???俺もややこしく思うから、マルチユーザとか考えずに、
EXEと同じ場所にINIファイル作って使うようにしよ…
どうせ多重インストールしても問題ない作りにしてるんだし。
マルチユーザしたければ多重インストールしてください、と。
0136名無しさん＠お腹いっぱい。
01/12/07 08:40ID:???そもそもWindows95で %userprofile%\Application Data を取得できるのか？
0137名無しさん＠お腹いっぱい。
01/12/07 10:13ID:???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ファイルに読み書き、みたいな感じじゃダメ？
0138他力本ガナー
01/12/07 11:16ID:???俺はもう少しここでの案が固まったら自作ソフトに実装しようと思う。
無名ソフトだがな！
関係ないけどTeraPadがバージョンアップしてマルチユーザ対応になってた。
exeのサブフォルダにユーザのフォルダ作ってるけど。
0139名無しさん＠お腹いっぱい。
01/12/07 11:46ID:???UNIXのrcファイルがそうだな
>>138
>exeのサブフォルダにユーザのフォルダ
インストーラが各サブフォルダのセキュリティ設定まで
してくれるならそれもアリだと思うけどね
0140もなか
01/12/07 12:13ID:???マルチユーザーにしたければレジストリ使って下さいじゃ、ダメかな？
……と、ずっと言いたかったんだけど、まあここの議論から新しい
可能性が生まれるってことも否定できないし。
0141名無しさん＠お腹いっぱい。
01/12/07 12:27ID:???設定の保存方法をユーザーに選ばせるというのはどうもなあ…
はっきりいって大多数のユーザーにとって設定がどこに保存
されるかなんてどうでもいいことだし。
ちなみにXPのガイドラインでは、システム全体にインストール
する権限がないユーザーがインストールしようとした場合、
個人用にインストールするかどうか選択権を与えることが
推奨されている。
0142名無しさん＠お腹いっぱい。
01/12/07 13:02ID:hRTbf65W0143名無しさん＠お腹いっぱい。
01/12/07 13:42ID:???たしかにレジストリの方が推奨されてるし手っ取り早いからいいんだけど
それでもやっぱりiniがいいっていう作者・ユーザがたくさんいるわけで・・・
マルチユーザでレジストリを使うよりApplication Dataのような場所を使う
理由の一つは、かなり前に書いたんだけどアンインストールが楽だってこと。
レジストリでは各ユーザの設定は基本的に消さないけど、iniだとAdminから
アンインストーラ使えば全ユーザのApplication Dataを走査して設定を消せる。
もちろんこう言うと「各ユーザのレジストリくらいそのままにしてても問題ない」
となるわけだけど、消したい人もいるわけで、だからこそドキュメントに
設定ファイルやレジストリの場所を書くわけで。
まぁ別にどっちがいいという話ではなくて、言われるとおり可能性の一つを探って
みようじゃないか、と。
>>141
>>140が言ってるのは作る側がソフトを作るときにレジストリを使用するような
ものを作って下さい、ってことだと思われ。
0144名無しさん＠お腹いっぱい。
01/12/07 16:21ID:???個人的には覗けるからといって勝手にファイル消されたら
思わず暗号化したくなるくらいムカつく。
ちなみに他ユーザーのレジストリはregedt32を使えれば
余裕で覗けるし、プログラムがユーザプロファイルをロード
するためのAPIも提供されてる。
0145名無しさん＠お腹いっぱい。
01/12/07 16:58ID:???>個人的には覗けるからといって勝手にファイル消されたら
ん？どこに対するレス？管理者が勝手に設定を消したらムカつくってこと？
管理者がアンインストールするなら問題ないんじゃ？
仮に管理者がソフトをアンインストールして、各ユーザの設定だけ残すと
どんなメリットが？
>ちなみに他ユーザーのレジストリはregedt32を使えれば
regedt32を使ってハイブをロードするのは簡単だけど、アンインストーラに
実装するのはファイルを削除することより面倒だと思った、が、
言われてみれば変わらないかも。LoadUserProfileだよね？
0146名無しさん＠お腹いっぱい。
01/12/07 17:22ID:???UNIXではrootが一般ユーザーのrcファイルを消して回ったりする
のが普通なんですか?
むしろ管理者権限でユーザーのプライバシーを侵してまで
わざわざ削除することにどんなメリットがあるのか聞きたい
んですが。
0147名無しさん＠お腹いっぱい。
01/12/07 18:42ID:???にはこう書かれています。
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ファイルを保存するなら、このガイドラインには違反しません。
0148もなか
01/12/08 02:00ID:???>仮に管理者がソフトをアンインストールして、各ユーザの設定だけ残すと
>どんなメリットが？
については、管理者じゃない人間が
「え〜！ あのソフト消しちゃったのォ！ また入れてよ」
ということで入れ直したとき、以前の設定で使えるというメリットが（笑）。
……しかし、まあ、この場合「消すけどいい？」って最初に訊くべきで、
「うん、いいよ」と答えたら、答えた以上、自分の設定も消されても文句はない
という関係があるべきで。その場合も >>144 はムカつくのかな？
言いたいのは、使う側（管理者とそれ以外の人間）の問題であって、
そーゆー仕様ならソフト側は >>143 の言うようにバッサリ消すような
アンインストール方法を用意した方がスッキリはするわな。
0149名無しさん＠お腹いっぱい。
01/12/08 08:46ID:???0150名無しさん＠お腹いっぱい。
01/12/08 11:34ID:???アンインストーラに付けろってことか
0151もなか
01/12/08 20:40ID:???いや、繰り返しになるけど、アンインストーラの仕様としては、
消す場合はバッサリ消した方がいいんじゃないの？
おれが言いたいのは「消すけどいい？」と他のユーザーに訊くのは管理者の責任で
ソフト側はそこまで用意する必要ないんじゃないかってこと。
0152名無しさん＠お腹いっぱい。
01/12/08 23:02ID:???いや、上の英文のこと。
0154名無しさん＠お腹いっぱい。
01/12/09 10:19ID:???話が及んでいくねぇ。
汎用のインストーラ／アンインストーラでこういうオプションは提供
できるのかな？？
情報求ム。
0155名無しさん＠お腹いっぱい。
01/12/10 06:55ID:???オプションで設定の保存先を変更できるようにすること。
保存先情報などのシステムワイドな情報はexeと同ディレクトリに保存。
こうすることで>>88のような各環境に対して様々なセットアップパターンを提供できる。
各ユーザーの設定を削除できるアンインストーラが含まれているのが望ましい。
各ユーザーの設定を残すのならば、アンインストーラを使わずにインストールした
フォルダを削除するだけでよい。アンインストーラを使ってもよいがその場合、
アンインストーラには各ユーザーの設定を残すか削除するかの選択オプションが
含まれているのが望ましい。
そうすればユーザーから「なんて柔軟性のあるソフトなのかしら……好き（ぽっ」
となること間違い無しだ。
0156名無しさん＠お腹いっぱい。
01/12/10 18:43ID:hqvM6/6wどうやって、Application Dataのフォルダを取得するの?
0157名無しさん＠お腹いっぱい。
01/12/10 20:13ID:HA0PHITT今MSDN見たんだけど、Windows95だとIE4.0以上がインストール
されてないとダメってこと？
0158みのもんた
01/12/11 11:09ID:???Ａ．Windows95をサポート外にする
Ｂ．ユーザーにIE4.0以上をインストールすることを促す
Ｃ．SHGetSpecialFolderLocationを使わず自力でApplication Dataを探す
Ｄ．Windows95は例外としてexeと同じフォルダに置く
0159名無しさん＠お腹いっぱい。
01/12/11 13:55ID:???そこまでコーディングに手間かけてられない
(んなヒマあったらもっと別のトコロに力注ぎたい&注いで欲しい)
ので、素直に多重インストールOKなコーディング、
EXEと同じフォルダ決めうちで構わないと思うが…
0160名無しさん＠お腹いっぱい。
01/12/11 19:23ID:???作っていただきたい。
0161名無しさん＠お腹いっぱい。
01/12/11 21:24ID:???IE4.0以上をインストールしてなくても、Windows95に
\ユーザ名\Application Dataフォルダ自体はあるんだよね？
（できれば正確なパスを教えて欲しい）
0162名無しさん＠お腹いっぱい。
01/12/11 21:26ID:???確かIE4.0以前のWindows95には存在しなかったはず。
0163名無しさん＠お腹いっぱい。
01/12/11 21:30ID:???0164名無しさん＠お腹いっぱい。
01/12/12 00:52ID:???NT系ならデフォルトで
ユーザ名\Application Data\アプリケーション名\
のパスを、9x系ならデフォルトで
exeがあるフォルダ\ユーザ名\
のパスを取得し、システムワイドiniファイルがあれば
それに従ったパスを取得する関数を作ってみた。
とりあえず動く用でエラーチェックなど細かいことはしていない。MFC。Win2kで確認。
>>156-158よりWin95だとDLLのバージョンの問題があるらしく、
DLLバージョンチェックがめんどうなので乱暴にNT系と9x系で
デフォルトフォルダの場所を分けたけど、バージョンチェックとか
細かいこともやってくれる人がいたら幸せ。
0166名無しさん＠お腹いっぱい。
01/12/12 03:47ID:???CSIDL_APPDATAをサポートしない環境ではSHGetSpecialFolderLocationが
E_INVALIDARGを返すから、戻り値を見て自力で計算するかどうか決めるほう
がOSのバージョンチェックよりもいいと思われ
どうしてもバージョンチェックでやるとしても、シェル関数の場合はDLLバージョン
を見るべき。
http://msdn.microsoft.com/library/en-us/shellcc/platform/Shell/versions.asp
0167名無しさん＠お腹いっぱい。
01/12/12 03:51ID:???0168名無しさん＠お腹いっぱい。
01/12/12 03:56ID:???書き込めない場所だったら困るなあとか。
せめて書き込めるかどうかチェックしてほしい。
0169名無しさん＠お腹いっぱい。
01/12/12 10:30ID:???0170名無しさん＠お腹いっぱい。
01/12/12 10:36ID:???それは設定する人間（たぶん管理者）がDQNぽいけど、
確かにプログラムでチェックしたほうが親切には違いない。
0171名無しさん＠お腹いっぱい。
01/12/12 12:31ID:???http://www.microsoft.com/downloads/release.asp?ReleaseID=30340&area=search&ordinal=1
0172名無しさん＠お腹いっぱい。
01/12/12 13:04ID:???あれ？「shfolder.dllを入れる」ってのはshfolder.dllを
ユーザーにインストールしてもらうって意味じゃないよね？
0173名無しさん＠お腹いっぱい。
01/12/12 13:29ID:???やっぱShFolder.dllか。
0174名無しさん＠お腹いっぱい。
01/12/12 13:48ID:P/hABMeLパーミッションもホスィ。
0175名無しさん＠お腹いっぱい。
01/12/12 16:45ID:???0176名無しさん＠お腹いっぱい。
01/12/12 17:21ID:???0177名無しさん＠お腹いっぱい。
01/12/13 01:26ID:???ライセンス的に再配布可能であることがはっきりしてたほうが
安心かと思って
0178名無しさん＠お腹いっぱい。
01/12/13 11:27ID:???おまえ気が利くな
0179名無しさん＠お腹いっぱい。
01/12/13 16:48ID:???手に入らなくて鬱
0180名無しさん＠お腹いっぱい。
01/12/14 00:19ID:???shfolder.dll＋SHGetFolderPath版てことで。
0181ini の保管場所
01/12/14 01:37ID:???(1)コマンド指定フォルダ
(2)プライベートフォルダ(c:\document and settings\... 等)
(3)本体と同じフォルダ
設定変更時／終了時の書き込み先優先順
(1)コマンド指定フォルダ（指定されている場合）
(2)起動時と同じフォルダ（←ミソ）
(3)プライベートフォルダ（user名が取得できた時のみ）
(4)本体と同じフォルダ（書き込み可能な場合）
としとけばいいんじゃねーノ？
んで、
・ユーザー毎に設定を分けたい場合は、プライベートフォルダに
iniを個別に作っておく。(win2kならdefault userを使うとラク)
あるいはショートカットのコマンド指定で振り分け。
（これも環境変数%user%を使えばラク）
・シングルユーザで使うorマルチユーザ環境で設定を共有したい場合は
コマンド指定or本体と同じフォルダにiniを置く。
とすりゃいい。
あと以下は必須じゃないが
・レジストリや環境設定によるフォルダ指定機能
・ツールやプロパティでiniを移動する機能
・本体フォルダに書き込めない場合の次候補（temp等）
なんかも用意しとくと完璧だと思われ。
0182スマソ
01/12/14 01:40ID:???↓
○ 環境変数%username%
0183名無しさん＠お腹いっぱい。
01/12/14 04:28ID:???作者としても、ユーザとしても。
0184名無しさん＠お腹いっぱい。
01/12/14 04:40ID:???同意。
実際にこのシステムのソフトが作られたとしても
「分かりにくい」とかいってまたここで叩かれそう。
0185名無しさん＠お腹いっぱい。
01/12/14 10:02ID:???iniの保管先をシステムワイドiniじゃなくて優先順位で区別するみたいだけど
>・ユーザー毎に設定を分けたい場合は、プライベートフォルダに
> iniを個別に作っておく
や
>・シングルユーザで使うorマルチユーザ環境で設定を共有したい場合は
> コマンド指定or本体と同じフォルダにiniを置く。
みたいにアプリケーションを使う前に、ユーザに前処理が必要になるってのは
どうもなぁ……
0186名無しさん＠お腹いっぱい。
01/12/14 23:29ID:???スマソ。説明が悪かった。（特に後半は蛇足）
一応ソフトがデフォルトでiniを保管する場所は
・マルチユーザ環境ならプライベートフォルダ。
・プライベートフォルダに書き込めない（≒シングルユーザ）なら、
本体と同じフォルダ。
で、保存する場所を変えたい場合にのみ
・手動でiniを移動させる。
・コマンド（や環境変数、レジストリ）で強制的に指定する。
のだと考えてオクレ。
コレで
・マルチユーザーのことを考えろやｺﾞﾙｧ。
・マルチユーザ環境で設定を共有できなきゃｲﾔﾝ。
・iniは本体と同じ位置がｲｲ!（持ち歩きたい）
・面倒なのは逝ｯﾃﾖｼ。
といった要求をすべて満たせると思うのだが。
0187名無しさん＠お腹いっぱい。
01/12/15 15:29ID:???0188もなか
01/12/15 17:50ID:???デフォルトでレジストリにしちゃってさ、インストール時に
標準／レジストリに設定を保存します。
特に問題を感じない場合は、こちらをセレクトして下さい。
カスタム／設定の保存場所をカスタマイズします。
マルチユーザーでの ini ファイル使用なども考慮することができます。
で、いいんじゃないの？ どうでしょ？
0189名無しさん＠お腹いっぱい。
01/12/15 18:18ID:VWy4rHM8そこまでする必要ないよ。こんなソフトあったらむしろヤだよ、俺。
どうせ半年もすればOSごと再インストールするんだし、細かいこと
気にしないで、もっと気楽に使おうよ。みんな几帳面すぎ！
レジストリの掃除にはうるさくても、部屋の掃除はしてなかったりして…
0190もなか
01/12/15 21:07ID:???気楽に行きたいのなら、黙って「標準」を選べばいいと思うんだが……。
インストール時に選択肢のあるソフトなんていくらでもあるじゃない？
ちなみにおれは、「レジストリ使ってもＯＫ派」なんだけど、
ここでの議論は面白いし、何かの形で実を結ぶ可能性があると思うよ。
それより……
＞どうせ半年もすればOSごと再インストールするんだし、
この手の話が出るたび、いつも不思議に思う。
まともに使ってて、そんなに再インストールってある？
おれ、結構いろんなソフト使ってるけど、二台持ってるうち、
一台は Win95 で、３年以上普通に動いてるし、もう一台は Win2000 に変えるまで
Win98 のまま、１年半、問題なかったけどなあ……。
スレ違い気味でスマソ。
0191名無しさん＠お腹いっぱい。
01/12/15 21:43ID:???だいたい同意です。
俺も「レジストリ使ってもＯＫ派」。
9x使ってた時は、年に2,3回はOSから再インストールしてたかも。
2kにしてからは再インストールしようと思わない。
0192名無しさん＠お腹いっぱい。
01/12/15 23:04ID:???ソフト側で対応するならマルチユーザ用iniもありだと思うんだけど、
デフォルトはexeと同じフォルダに保存するようにした方がいいと思う。
PCを一人で使ってる人が圧倒的に多いだろうから。
オプションでマルチユーザ用を選択するというのはどうか。
0193名無しさん＠お腹いっぱい。
01/12/16 00:41ID:???ユーザの設定ファイルはデフォルトで \ユーザ名\Application Data\sample0\ に
setting.iniという名前で保存し、保存場所は変更可能なサンプルプログラムを
作ってみた。
逆に>>192のようなデフォルトがexeと同フォルダバージョンも作ってみようかと思う。
0194名無しさん＠お腹いっぱい。
01/12/16 01:36ID:wl5Wiiy9家ではそうかも知れないけど、職場や学校でもPC使ってる人も相当いると思うYO!
もっともシングルユーザ環境で使いまわししてる場合が多いだろうから、
「マルチユーザはオプションで」というのには同意。
ただ>>193のサンプルみたいに、一般ユーザーが各々指定しないとダメ(?)なのは
あまり意味が無いと思う。
普通マルチユーザ設定は管理者がやる事だし。
>181,186
・デフォルトでは本体と同じフォルダ
・↑が（管理者により）書き込み禁止にされてるなら、
本体と同じフォルダ/setting/個人用フォルダ
・↑も書き込み禁止なら、Win標準の個人用フォルダ
・もしくはコマンド/レジストリ/環境変数/ini 等で指定のフォルダ（最優先）
に保存の方が良くない？
0195名無しさん＠お腹いっぱい。
01/12/16 01:58ID:???>ただ>>193のサンプルみたいに、一般ユーザーが各々指定しないとダメ(?)なのは
管理者が設定してUsersが書き込み権限のないフォルダに入れておけば
いいんだよ。
0196194
01/12/16 02:09ID:wl5Wiiy9>いいんだよ。
ユーザー数×ソフト数だけ設定しないとイカンのですよ？
0197名無しさん＠お腹いっぱい。
01/12/16 02:15ID:???え？なんで？
>>193はデフォルトでマルチユーザ対応なんだよ？
全ユーザ共通にしたかったら一回チェック入れるだけでいいんだよ？
0198194
01/12/16 02:31ID:wl5Wiiy9特に>>193氏のサンプルはWin標準の個人用フォルダ以下ですし。
0199名無しさん＠お腹いっぱい。
01/12/16 02:33ID:???でもWin9xの時は2ヶ月持てば(ﾟдﾟ)ｳﾏｰだった(；´д｀)
てなわけで使うなとヒステリックには叫ばないけど、
「なるべくならレジストリ使わないでINI使ってくれ」派。
（ ・∀・）あと目くじら立てずにもう少しﾏﾀｰﾘ逝こうよ
0200名無しさん＠お腹いっぱい。
01/12/16 02:45ID:???あぁそうか、設定を共通ではなく、かつフォルダの位置を変更したい
場合か。確かに。
0201194
01/12/16 03:17ID:???でもiniはテキストファイル=>一括変換も可能だから、さほど設定に苦労はしないカモ
…と今更気付く。
少し言い過ぎでした。ゴメンナサイ。（特に>>193氏）
ところで2ch-modeの設定ファイルがいつのまにか消えてて、気付かずage進行してた…
切腹。
0202名無しさん＠お腹いっぱい。
01/12/16 18:52ID:???デフォルトがexeと同フォルダに保存するバージョンを作った。
>>194案も考慮してみた。
たいていの人（従来通りexeと同フォルダに保存すればii!!と言う人）には
設定することすら必要ない。今まで通り起動して閉じるだけ。
アンインストールも展開したフォルダごと削除。
マルチユーザに対応すれ！と言う人にも、たぶんチェックボタンやラジオボタンを
押すだけで十分だと思う。
なお、UIはもっと改善したほうが良さそう。あまりうまい言葉が思いつかなかった(;´Д`)
0203名無しさん＠お腹いっぱい。
01/12/17 14:28ID:hjuO4DeLWin98で使っていたINIに設定を保存するアプリをWin2000で使ったら
動作がおかしくなる事ってありますか？
（もちろん2000にも対応しているアプリで）
0204名無しさん＠お腹いっぱい。
01/12/17 15:41ID:???2000に対応してておかしな動作をするならバグなんじゃないすか
0205名無しさん＠お腹いっぱい。
01/12/17 16:26ID:???レスありがとうございます。
設定情報以外にOSに関する情報とかもあったりするのかと思って、
今まで積極的に使えないでいました。これからWin2000で使ってみ
ようと思います。
0206名無しさん＠お腹いっぱい。
01/12/17 20:04ID:???アプリによるだろうに。
0207202
01/12/17 22:59ID:???・EXEファイルのあるフォルダ以下にユーザ別フォルダを置く
という項目を追加した。
0208名無しさん＠お腹いっぱい。
01/12/18 03:33ID:S7Ds6rRkこんな泥臭いことにはならなかったのに。
Unixの、一般ユーザーでもホームディレクトリの下に
勝手にソフト入れられる世界とは雲泥の差だ。
まあUnixはUnixで、ソフト毎に書式が違ったりして
結構アレなんだが。
もう少しだけUnixを忠実にパクって欲しかった。
MSがTerminal Server Editionの悲劇を繰り返さない
ことを祈る。
0209名無しさん＠お腹いっぱい。
01/12/18 03:40ID:???設定を書くというのはどうか。
インストーラなら書けないということはないはずだしわざわざインストール
しようとする人はマルチユーザで使えたほうが望ましいだろうし
0210名無しさん＠お腹いっぱい。
01/12/18 03:58ID:???0212名無しさん＠お腹いっぱい。
01/12/18 22:27ID:yKqNRrjg>インストーラなら書けないということはないはずだし
どういう意味？
0213名無しさん＠お腹いっぱい。
01/12/18 22:58ID:???インストーラはAdminで起動するはずだしそうじゃなければ
個人用インストールになるはずなのでどっちにしても
問題ない
0214名無しさん＠お腹いっぱい。
01/12/19 00:31ID:???でも~/直下に環境設定ファイル・フォルダを置きまくるという慣習はとっても嫌ずら。>Unix
~/etc 以下とかにまとめてほすィー。
自前でスクリプトを直せば良いんだろうけど、面倒。
0215名無しさん＠お腹いっぱい。
01/12/19 04:53ID:Ysyu3Q6+あと、Windows＆Systemフォルダに大量にある謎のファイル。
■ このスレッドは過去ログ倉庫に格納されています