表紙 / 自作ソフト / 日記 / 宝箱 / サイト情報 / 検索
一般 / 新C言語 / 駄文
一覧 / 本文

Windows アプリケーションの設定ファイル (ini ファイルや config ファイル) 格納場所について

Last update: 2007/11/18

(c)2007 seclan. All rights reserved.
Homepage: http://seclan.dll.jp/
E-mail: seclan[ここはアトマークに置き換えてください]dll.jp


はじめに

アプリケーションを便利に使っていくには、ソフトウエアメーカが最初に設定した状態ではなく、自分が設定した状態を標準で使っていくことがコツになります。その仕組みを実現するには、その設定をどこかに保存する必要があります。

マルチユーザをほとんど意識していなかった DOS や Win9x (Win95, Win98, Win98SE, WinMe) などは、あまりそれについて考える必要はなく、単にアプリケーションと同じ位置に置けばよかったのですが、マルチユーザを意識している WinNT (WinNT4, Win2K, WinXP, Vista) などは、そうはいきません。一応、システムではそのためにレジストリを提供していますが、ユーザからその設定が見えづらく、また再インストールなどで設定を復元する場合に扱いづらいなどの問題から、レジストリへの設定の格納はあまり歓迎されない傾向があります。そうすると、設定を記述したファイルをどこかに格納する必要がありますが、それをどこに格納すればよいのかと言うのが問題になります。

各種 OS での設定ファイル格納場所

各種 OS でどのように設定ファイルを格納していたのかおさらいをします。なお、下で使われる幾つかの記号について以下のように定義します。

myappアプリケーションの名前
maker製造元または作者名
%USER% ユーザ名
%APPDIR% アプリケーションの格納ディレクトリ
%APPDATA% マイクロソフト推奨のユーザデータ格納基準ディレクトリ

Unix (FreeBSD、Linux など)

Unix では、始めからマルチユーザが考慮されており、それぞれの「ホーム」ディレクトリと言う、各ユーザに専用に用意された作業ディレクトリが提供されていました。このホームディレクトリは、環境変数の %HOME% (${HOME}) に設定されています。

アプリケーションの設定ファイルは、慣習的にそのホームディレクトリ直下の .myapp というディレクトリの中に格納されてきました。myapp の前に . をつけるのは、標準のファイル一覧コマンド ls を実行した場合、. が先頭についているファイルは表示されないという特性を利用するためです。

DOS

DOS は単一ユーザが使用することが前提だったので、特にどこに格納すべきと言う場所は提供されていませんでした。たいていは、アプリケーションと同じ場所 %APPDIR% に設定ファイルなどが格納されていました。アプリケーションによっては、設定ファイルの格納場所をアプリケーション固有の環境変数で指定するものもありました。

Windows 3.1

GUI が提供されるようになりましたが、やはり基本的には単一ユーザの使用が前提でした。格納場所は DOS の時と同じく、アプリケーションと同じ場所 %APPDIR% に ini ファイル形式で格納されるか、WINDOWS のシステムディレクトリ内の win.ini や system.ini に格納されていました。しかしながら、system.ini はシステムの設定に使われることが主な目的であり、また win.ini も各アプリケーション個別の設定が一つのファイルに入ってしまうことで、名前が衝突する危険性があったほか、設定が WINDOWS ディレクトリに入ってしまうといった理由から、あまり歓迎されませんでした。しかし、手軽に使用することができたので、当時のアプリケーションでは、ここを使用したものが多数ありました。

Windows 95

この頃になると、多少はマルチユーザの使用が考慮されるようになりました。それの一つの回答としてマイクロソフトが用意したのが、レジストリへの格納です。レジストリとは、いってみれば単一ファイルでできたデータベースファイルで、それをユーザ毎に提供することで、ユーザ毎の設定を格納可能にしていました。また、異なったマシンで使用するときも、このレジストリファイルを当該マシンにコピーすることで同じ設定を使用できるようにする、という狙いもあったようです。ただし、このレジストリに巨大なデータを保存することは推奨されず、その場合はアプリケーションでその場所を個別に提供すべしということになっていました。

後期になると 「c:\WINDOWS\Profile\%USER%\Application Data\」を %APPDATA% として使用することが推奨されましたが、あまりアプリケーションからは利用されませんでした。実際 Windows ディレクトリの中に、ユーザ毎の設定を格納すると言うセンスはどうかと思います。マイクロソフトもそう思ったのか、Windows 2000 以降は格納場所が変えられています。

Windows NT4、Windows 2000、Windows XP

Windows NT 系列では、始めからマルチユーザの使用が考慮されていました。そのため、前述のレジストリに加え、NT4 では「c:\Windows\Profile\%USER%\Application Data\」を、以降では「c:\Documents and Settings\%USER%\Application Data\」のようなユーザ毎のデータ格納場所 %APPDATA% が提供されていました。この場所に、製造元(作者名) のディレクトリ maker を作り、その中にアプリケーション名のディレクトリ myapp を作り、そこにデータを置くという形式です。しかし、Win9x と同じに動作するアプリケーションを作るため、アプリケーションディレクトリに設定ファイルを格納するアプリケーションも少なくありませんでした。

Windows Vista

Windows では、アプリケーションは「c:\Program Files\」というディレクトリの下にそれぞれのディレクトリを作って、その中にアプリケーションを格納することが推奨されてきました。したがって、%APPDIR% に ini 形式のファイルで保存する場合、たいてい Program Files ディレクトリの下に格納されることになります。

ところで Windows Vista から UAC (User Account Control) という機能が有効になりました。この機能は、管理ユーザとしてログインしていても、その権限を通常ユーザと同等に制限するというものです。管理者権限で動作させたい機能がある場合には、明示的に権限を昇格させる必要があります。

これが問題を発生させる可能性があります。UAC が有効になっておりかつ権限が昇格されていない状態の Vista では、「c:\Program Files\」以下への書き込みは、「c:\Users\%USER%\AppData\Local\VirtualStore\」という場所に自動的に変換されて書きこまれるようになりました。つまり、設定ファイルを書き込もうとすると自動的に違う場所に書き込まれることになります。また UAC が無効か権限が昇格されている場合には、そのまま Program Files のところに書き込まれます。これは混乱を引き起こしかねません。

また Vista での標準の %APPDATA% は 「c:\Users\%USER%\AppData\Roaming\」となりました。

まとめ

以上をまとめ、表にすると次のようになります。

OS 名場所
Unix%HOME%/.myapp/
DOS%APPDIR%
Windows 3.1%APPDIR%
Windows ディレクトリにある win.ini や system.ini
Windows 95レジストリ
%APPDIR%
Windows NT 系列レジストリ
%APPDATA%/maker/myapp/
%APPDIR%

設定ファイルの格納ディレクトリの検討

レジストリへの格納

レジストリの格納については、以下のような問題があるので却下することにします。

  • ユーザからその設定が見えづらい
  • 再インストールなどで設定を復元する場合に扱いづらい
  • 大きなデータを格納できない

そうすると、どこかのディレクトリに格納することになります。

格納すべき基準ディレクトリ

基本的には、システム推奨の位置、つまり SHGetFolderPath 関数で CSIDL_APPDATA を問い合わせた結果でよいと思います。ただし、この関数 SHGetFolderPath を使用するには、システムディレクトリに SHFOLDER.DLL というファイルが必要ですが、Win98 以前、WinNT4SP3 以前には含まれていません。ただし、IE5 以降をインストールすると自動的に導入されるほか、マイクロソフトのサイトでも再配布可能として提供されているので、それをインストールすることで使用可能になります。

さて WinNT 系列の場合はそれでもよいですが、Win9x では SHGetFolderPath で返すディレクトリは WINDOWS ディレクトリの下なので、それには抵抗があります。そこで、%APPDIR% か、またはマルチユーザで使うのであれば、ユーザの指定したディレクトリを使用するのがよいかと思われます。

それを指定するには環境変数を参照するのが自然です。そこで、どの名前を使うのかが問題になります。慣習的には、Unix で使われる %HOME% が望ましいように思われるのですが、この %HOME% という環境変数は、Windows に移植された Unix 系の移植コマンド・環境で参照されていることが多く、Windows の設定ファイルを格納するのは、少し違うような気がします。そのようなことから、別の名前を使用することにします。

そこで、使用する名前として %APPDATA% を使うことにします。環境変数 %APPDATA% は以下の環境で自動的に設定されています。

OS 名%APPDATA%SHGetFolderPath
Win95×
Win98×
Win98SE×
WinMe×
WinNT4×△ (SP3-)
○ (SP4+)
Win2K
WinXP
Vista

%APPDATA% は Win9x 系列では自動では全く設定されていないので、もし設定してある場合、マルチユーザで使用するというよい宣言になります。また、WinNT 系列では WinNT4 を除いて自動的に設定されているので、そのまま使用することができます。

もし Win9x で %APPDATA% が設定されていないのなら、単に単一ユーザでの使用ということで %APPDIR% に格納すればよいでしょう。

まとめると、次のようになります。

OS 名基準ディレクトリ
Unix%HOME%
WinNTSHGetFolderPath(CSIDL_APPDATA) で返されるディレクトリ
Win9x環境変数 %APPDATA% が設定されていればそのディレクトリ。なければ %APPDIR%。

格納すべきサブディレクトリ

基準ディレクトリの下にアプリケーションの設定を格納するわけですが、マイクロソフトでは、その下に maker ディレクトリを作り、さらにその中に myapp のディレクトリ作って格納することを推奨しています。しかし、マイクロソフトのような名の知れた企業ならともかく、小さな会社やフリーソフトでは、maker 名でディレクトリを作っても、何のソフト用のものなのかがわかりません。ほとんどの人は、ソフトの名前は覚えていても maker名、作者名は覚えていません。そのようなことから、maker 名でディレクトリを作るのはやめることにします。

しかし一応、maker 名で作るということが建前なので、このディレクトリは maker 名ではないですよと言うことがはっきりわかるようにすべきです。そこで、はっきり示すため、myapp で直接ディレクトリを作るのではなく、. を前置して、.myapp でディレクトリを作るようにします。こうすれば、maker 名ではなく、ソフト名であることが一目瞭然になります。また、この方式は Unix と共通環境を作りやすいという特性を持ちます。

Win9x の単一ユーザでの使用の場合、今までのように %APPDIR% に直接設定ファイルが格納されなくなり、そこの .myapp ディレクトリの中に格納されることになりますが、それは必要経費として割り切ることにします。ユーザとしても、配布物と設定ファイが明確になるのでよしとします。

結論

以上をまとめると、以下のディレクトリに格納すべきということになります。

OS 名格納すべきディレクトリ
Unix%HOME%/.myapp/
WinNTSHGetFolderPath(CSIDL_APPDATA)/.myapp/
Win9x%APPDATA%/.myapp/ (%APPDATA% があれば)
%APPDIR%/.myapp/ (GetModuleFileName 関数で現在の実行ファイルのフルパスが取得可能)

表紙 - 著作権 - 注意事項 - リンクについて - 404 エラーについて
(c)2007 seclan. All rights reserved.