Visual Studio 2005 で、Windows Form のアプリケーションを作成します。このとき、フォームにスプリッター コントロールを置きます。フォームの大きさを変更して、デフォルトよりも大きくします。スプリッター コントロールの初期スプリット位置を、左右どちらかに極端に近づけます。このフォームを実行します。すると、実行時に例外が発生します。

この件、VS2005 のベータテストで、かなり初期に「バグ」として報告されていました。いったん「修正済み」としてクローズしたのですが、複数の「Build xxxx でも再現する」というコメントが寄せられていました。

そして、私がデュプリケートしたのですが、返答は「現象を確認したが、修正はもう間に合わない」というものでした。

Vista でも、同じような事が起こっています。32 bit 版で報告したバグが、RC-1 で修正されていました。しかし、64 bit 版の RC-1 では発生しました。これを、コメントとして、「x86 版で修正を確認しました。」「x64 版 RC-1 で現象が発生します。」と報告しました。「RC-1 以降に修正が反映されます。」という返事がありました。さて、この「修正が反映される」のは、64 bit 版を指しているのでしょうか。回答内容からは、判断がつきません。しかし、32 bit と 64 bit で、足並みが揃っていないことは予想されます。

Vista の、ベータ２以前は、ファイルの拡張子がデフォルトで表示されていたと思います。しかし、ベータ２以降では非表示になっています。

この件、提案した（FeedbackID=185533）のですが、「開発でレビューが行われ、XP SP2 と同じ仕様になります」という返答でした。

しかし、「拡張子を表示するようにしておこう」という話は、あちらこちらにあります。これは、利便性だけでなく、自己防衛のためでもあります。

どの様なレビューがされ、なぜ XP SP2 と同じ仕様になったのかは、明らかにはされません。これがわからなければ、「ご了承願います」といわれても、了承できないのです。

XP ですが、Windows Live Messanger をインストールしました。すると、各アカウントの My Documents フォルダに、共有フォルダが出来ました。

う～ん。。。どういうつもりなんだろう？

Vista に「共有」つながり。

vista では、システム ドライブ直下のフォルダ名が大幅に変更になりました。あれ？いつから「ディレクトリ」ではなく「フォルダ」になったんだろう？まぁ、いいや。

ユーザの情報は、C:/Users に入ります（バックスラッシュの代わりに、スラッシュを使っています）。

この、Users フォルダが、共有されています。しかも、管理共有を示す '$' なしに。いったい、何のために？

そして、ドキュメントを入れるフォルダは、当然この Users フォルダの下にあります。今、あるフォルダを共有して、そこにドメイン内に公開するファイルを入れようと思いました。仮にこのフォルダを "Shared" とします。

ところが、この "Shared" を共有できません。理由は、より上位にある Users が共有されているため、すでに共有状態になっているから。

「マイクロソフト・ヒューストン社長、「Windows Vistaは、最もセキュアなOSとして提供できる」」って、本当ですか？共有するつもりのないファイルが共有されているんですけど、それって「セキュア」って言っていいんですか？

当然、「バグ」として報告しています（FeedbackID=197840）が、「新しい Sharing Design による仕様」なのだそうです。

※ Shared フォルダを共有することが、Users フォルダが共有設定されるトリガかもしれません。

※ 実際にどの様な共有がされるのかは不明です。共有しようとすると、「すでに共有されています」というメッセージが表示されるのですが、アクセス権がどの様に設定されているかまでは調べていません。しかし、共有した憶えがないのに「すでに共有されています」って、不安を覚えませんか？

.NET Framework の時からあったのですが、Vista の RC1 より前では、日本語のメッセージがあちこちブチ切れています。おそらく、英語で「これくらいの幅があれば大丈夫だね～」って確保した幅が、日本語では足りなかったのだと思います。RC1 では、インストールの時のメッセージに、まだ残っています。

これって、他国言語対応のアプリケーションを開発している人にとっては、共感できる問題なのではないでしょうか。それとも、日本語で作ってから英語リソースを作るので、そんなに出くわさない？

「いらない機能」の有無を事前に確認しておく必要があるそうです。

関連エントリ：Windows Vista: UAC の抜け道を考える４

なんにしても、UAC が促すのは「このプログラムの実行を、あなたは意図していますか？」ということです。そのプログラムがどの様な動作をし、その結果どうなるのか、事前に調べておく必要がある、、、ということですかね？

シャレで書いたつもりだったのですが、マジでした。

Microsoft Connect に出した提案の回答：

Windows Vistaのインストーラ検出機能は管理者グループに所属するユーザでログインされている場合でもプロセスを自動的に昇格させることはなく、権限昇格のダイアログ上で、ユーザの承諾を得て昇格させております。一般のお客様におかれましては、権限昇格のダイアログ上で、権限昇格をされる際に、本当に意図したプロセスを実行されようとしているのか確認された上で実行していただく必要がございます。

これ、マジでいっているのか？

「こういう機能があります」と宣伝することと、「実際に機能する内容」が異なることがあることをわかっていないのか？

しかし、「意図したプロセスを、ユーザモードで動作させたいのだが、その選択肢がない」といっているのに、なぜこんな回答になるの？

「署名していない」アプリケーションのインストーラを、InstallShield 12 で作りました。

インストーラの起動ファイルは、"SETUP.EXE" という名称でした。

当然、互換性機能による昇格対象です。このファイルには Vista がシールド アイコンを付け、起動しようとすると昇格ダイアログが表示されます。この「昇格させる」挙動は Vista が行うものであり、SETUP.EXE に「昇格が必要」とマークされているわけではありません。つまり、インストーラ作成者が意図して行うものではありません。

そして、このインストーラには、インストーラ作成ツールの製造会社、Macrovision の署名がされていました。ルートの発行機関は VeriSign で、マイクロソフトがデフォルトで登録している「信頼されたルート証明機関」ですので、昇格ダイアログは灰色です。

SETUP.EXE は、開発者が作ったスクリプトにしたがって、様々な動作を行います。この中には、サービスをインストールして起動するという、危険な動作も含まれます。

さて、気がつかれましたか？ユーザが目にするのは、「インストーラ起動プログラムに対する署名」です。実際にインストール動作を行うプログラムに対する署名ではありません。

違った。この場合、「インストールプログラムに対する署名」で「インストール動作に対する署名」ではありません。かな。

"SETUP.EXE" には署名がされています。その署名を元に、"SETUP.EXE" の製造元に連絡をすることが出来ます（ただし、メールアドレスは記載されていないので、Web などで検索する必要がある）。しかし、本当の処理は "SETUP.EXE" に対して行われる指示で、その指示の製造元に対する連絡先を知ることはできません。いわば、Macrovision の署名を偽って使うことが出来る、というわけです。もちろん、“注意深い”ユーザなら、「配布者と署名者が違う」ことに気づくでしょうが。気づいたら気づいたで、それも問題ですね。

アプリケーションのインストール動作は、ディレクトリにファイルを置くことだけではありません。ウイルスやスパイウェアを配置しても、動作させなければ、大丈夫なのです。

また、動作するにしても、ユーザ権限で動作するなら、あるいは大丈夫かもしれません。プロセス０の分離や仮想化などで、危ない動作はカットされ、ユーザに「昇格への同意」を求めなければならないからです。

しかし、インストール動作の中で、他のプロセスを動作させることも可能です。昇格しているプロセスから起動されたプロセスは、すでに昇格済みです。これが、十分に検討された仕様です。

また、"SETUP.EXE" に対する「昇格」を求めるのは、インストールされるアプリケーションでも、"SETUP.EXE" でもありません。Vista 本人です。ユーザに与えられた選択肢は、「昇格して実行」と、「実行しない」です。MSI 形式のインストーラでは、「昇格しないで実行」が出来るのですが、"SETUP" や "INSTALL" という名称が含まれたファイル名の EXE 形式では、それを選ぶことは出来ません。そして、このときユーザが確認できるのは、インストールするアプリケーションの署名ではなく、インストーラである "SETUP.EXE" の署名です。あるいは、「Vista がだまされている」ともいえるでしょう。これも、十分に検討され、「互換性のために必要」とされた仕様なのです。

プログラムの署名によって、「誰が作ったのか」を確認することは出来ます。「改変されていない」ことを確認することは出来ます。しかしそれは、製造時点での「悪意の不在」を証明するものではありません。ご注意を。

「インストーラ検出機能」は、ファイル名だけを検出対象とはしていません。ファイルを右クリックして［プロパティ］を選び、［概要］タブを開くと、様々な付随情報があります。この付随情報も、検出対象です。

元々 InstallShield という会社がありましたから、この会社が開発したものは、今でも「InstallShield」という文字が、概要の中に残っています。

「Install」！！インストーラ検出機能が「インストーラである」と判断する対象です。「「InstallShield」というブランド名を捨てろ」ということなのでしょうか。

※ InstallShield 12 は、Vista の RTM 後、パッチによって挙動が修正される可能性があります。

XP を、家族で使っています。管理権限のあるアカウントと、管理権限のない私および妻のアカウントの３つを使っています。

私のアカウントで、妻のアカウントのホーム フォルダ（C:/Documents And Setting/妻）を見ることはできません。アクセスが拒否されます。

ところが、Vista では拒否された後に昇格ダイアログが表示され、昇格すれば見れてしまいます。ここまでは良いでしょう。問題はこの後です。

いったん Windows Explorer を終了します。そしてもう一度表示し、もう一度妻のホーム フォルダへ移動します。今度は拒否されず、昇格ダイアログも表示されません。

プロセスを分離しても、ログオフしても、同じ挙動でした。

これも「By Design」（FeedbackID=192122）です。

だったら、コントロール パネルの下も、同じように昇格情報を憶えておいてよ。。。