本題の前に、フンワリ考えてみる。

re: Vista UAC の未来をモワモワ考えるより：

「○○してもいいですか？」とセキュリティソフトが聞いてくる。俺もKasperskyを使ってますが、ぶっちゃけ、それをするとどんなリスクがあって、それをしないとなにができないのか、人並み以上にPC知識があるだろうと思う俺でも判断できません。

一応、詳細を読んだりしていますが、わかりません。つまり、情報の提示量に問題があると思います。

また、Kaspersky については、もうちっと調査をしておいてくれてもいいんじゃないの？とも思います。Symantec も同じような機能を実装していますが、標準で Windows に入っている機能については、聞いてきません。すでにルールが組み込まれています。また、どういう基準で選んでいるかわかりませんが、オンラインソフトを含む多くのソフトで、やはりルールが組み込まれています。

# re: Vista UAC の未来をモワモワ考えるより：

User へ選択を委譲しても責任の回避にしかなりません。
そんなんだったら、専門家が定めた policy で厳しく制限を課し利用させる方がよいかと。

ええ、そうですね。Vista の UAC は、その方向へ向かうのではないかと思います。あるいは、「向かって欲しい」と思います。

re: だいめいなし。より：

だったら、インストール可不可チェックの代行業者がいてもいーんじゃないかと。
＃ウィルスチェッカーと同じノリで。
で、業者ごとにブラックリストとホワイトリストを持ってて、それに基づいてインストールの可否を判断する。
個々のソフトについてのインストールの可否はユーザが判断できないけど、その代行業者に対して信頼できるかどうかで判断する。

で、本題。本題の元ネタが、これ↑。

「Windows ロゴ プログラム」という、プログラムがあります。「Windows ロゴ プログラム : 概要」とか、「Windows Vista ロゴ プログラム」とか。Windows Application のロゴ プログラム要件に、「最小特権の原則」があります。日本語の資料を探せなかったのですが、英語の資料はこちら→Developer Best Practices and Guidelines for Applications in a Least Privileged Environment

テスト要件も、ダウンロードできますね。いきなりダウンロードしちゃうので、リンクにはしません。→ http://download.microsoft.com/download/a/4/c/a4c003f7-76be-444b-a3b7-4e74b7d5767f/Certifiedfor_ProgramTestCases_1.3J.doc

この中に、「TEST CASE 2. 最小特権ユーザーが他のユーザの文書やファイルを変更できないことを検証する」、「TEST CASE 3. 最小特権ユーザーが Windows System ディレクトリにファイルを保存できないことを検証する」というのがあります。「最小特権ユーザが」という制約がありますが、Windows ロゴ プログラムをパスしているアプリケーションは、勝手にシステム ファイルを書き換えないことが、第三者機関によって保証されているわけです。かつ、署名されていることも検査されますので、ウィルスなどによる改ざんを検出することもできます。

つまり、Windows ロゴのついているソフトウェアは、比較的安心してインストールできると言っていいでしょう。言い切りませんよ。レジストリに関して、テストケースが見あたりませんから。

100％の安心を保証するものではないにしろ、危険な要素が少ないことは保証してくれるものであります。しかし、大企業を含め、日本企業のソフトウェアの多くは、ロゴ プログラムに参加していません。なぜでしょう？

「費用の問題」であったり、「他社の動向を見て」であったりします。

自社製品を使って下さるお客様に「安心・安全」を付加することより、コスト（そりゃ、コストがかかるとそもそも選んでもらえない可能性も出てくるけどね）や周りの目の方が気になる様です。セキュアな環境を阻んでいる要因は、案外、こういう事だったりするのかもしれない。

セキュリティに関しては、リスクです。リスクは、顕在化するか、しないか、わかりません。問題として顕在化しないのであれば、つっこむ金は少なくしておこう、という考え方なのでしょうか。でも、顕在化したときにかかる費用は、顕在化回避のために費やすお金の比じゃないと思うのです。でも顕在化しなければ、無駄金になる・・・これだぁ！！「無駄金」という考え方だ！！

どうにかなりませんかね？

とか書きながら、養護するつもりはない。しかし、歴史を知っておく必要はあると思います。

Win32 API のリファレンスを見ていてよく見かける（無理矢理組み合わせた、かも）、「lpctstr」という表記。これを、分解してみようかと思います。

まず、「p」から。これは、Pointer の p です。C 言語において、「文字配列」と「文字列へのポインタ」は、同じように扱えてしまえますが、実は違うものです。そのため、「ポインタであること」を明示するのは、読むとき、保守するときに有用です。

次、「l」。これ、よくわかりません。いろいろ読んでいるうちに「これかな？」と思ったのは、「local」か、「long」の「l」です。大昔、扱えるメモリ量が少なかったり、少ない故に小さいバイト数でいろいろ扱うために、DLL や EXE の境界を越えてポインタを渡せなかったようです。「ポインタ」に、「起点からの距離」を表すものと、「絶対距離」を表すものがあった様です。このうち、「起点からの距離」は、起点が違えば指す場所が変わってしまいます。あるいは、「GlobalHeap」という関数がありましたが、特定のプロセスのみで使えるアドレスと、Windows 全体で使えるアドレスか。そのため、これらを分けるために付けられたようです。はい、そこの人！！鵜呑みにしない。自分で確認すること。なんにしても、Windows 2000 の頃には、分ける必要がなくなっています。

次、「c」。これは、Const の c です。関数の引数に対して、「この引数の値は、関数内で変化させない」事を示すために付けられます。関数の入力、出力を明示するために使うわけです。これも、C++ になって const で修飾した場合、コンパイラがエラーを出します。このため、変数の修飾に使用して明示する必要はなくなっています。

次、「t」。これは、Multi-byte charactor set と、wide charactor set の、どちらにでも変化するよ、を表しています。そのため、文字(列)にしかつきません。Win32 API 関数の最後につく、A とか W と同じカテゴリです。

そして、「str」。これは String です。C では、char は「文字」だけでなく、「1バイトの数値」の意味も持っています。このため、「char a[10];」だと、「10バイトのデータ」なのか、「最大9文字の文字列」なのか、わかりません。そこで、str を付け、「文字列」であることを明示したわけです。

他に、整数値につく「i」があります。これは、整数といえど、割り算をすると浮動小数点型に変換されることがあります。こういった、暗黙の変換を防ぐ（注意を向ける）意図を持ちます。

また、short の場合、演算結果がオーバーフローする可能性が高くなりますから、これをレビューで検出できるようにすることもあります。

あとは、符号のあるなしについても、ありますかね？signed char の 0x80 と、unsigned char の 0x81 を比べると、どちらが大きいか。これは、最近だとコンパイラが警告を出してくれます。また、符号の有無と同じように、縮小変換についても警告、あるいはエラーとなるようにコンパイラが修正されています。したがって、変数名に明示する必要はなくなっています。

このように、単に型を示していたのではなく、目視レビューで間違いを検出しやすくするための工夫だったわけです。で、コンパイラが検出するようになったからか、Visual Studio 2008 に付属する SDK のドキュメント（英語）では、これらのシステム ハンガリアンな記述がなくなっています（作業中かもしれない）。

このように、C/C++ では、意味がある事でした。しかし、すべての言語で意味があることではない、あるいは、同じ記号であっていいわけではありません。

VB や C# のコードで、型名を明示する必要はありません。特に、「クラスだから」と、「cls」を頭に付けているようなものは、全く意味がありません。

そんな無駄なことをするより、なぜそのような符号を付ける必要があるのかを知り、その上で、使用している言語にそれが必要なのか、同じようにしていいのか、他に追加することがあるか、といったことを考える事の方が重要ではないでしょうか。「システム ハンガリアン使うな」とは言いません。しかし、使う前に、それにどんな意味があるか、知って欲しいと思います。