こんにちは。

「アプリケーション互換性」と書きすぎると、新しい OS は互換性が維持されていないのかと不安をあおってしまうかもしれませんが、そうした意味はありません。新しい OS が登場し、実際にアプリケーションをそこで動かすわけですから、まず、皆さんのアプリケーションすべてに関わる課題として、「互換性は大丈夫ですか ?」、「もっとも重要です !」 ということを本音で皆さんに情報発信していきたいと思います。

アプリケーション互換性について、まずは、開発者万人にとって間違いなく重要な 「ユーザーアカウント制御」 (UAC) に対する考え方を改めて知っていただこうと思い、ポイントを記載しました。あの UAC、そして昇格ダイアログ、「うざい !」、「うっとうしい !」 と思われる方もおられるかもしれませんが、そんな方はまずはお読みください。(UAC を回避したプログラムを書きたいですよね ? しかし、これを読み終えたあとで、その 「回避 ?!」 という考え方自体を変えて頂けるように整理したつもりです。)

なお、UAC のメカニズムの徹底解説 (昇格メカニズムなど、よりディープな話) については、日経ソフトウェアの 9 月号で完全網羅で解説したいと思っています。（通常、毎月 24 日頃の発売ですので、きっと 7 月 24 日あたりの発売ですね . . . あくまでも「予定」ですので、「未定」ですが . . .)

Windows 7 互換性 Overview

Windows 7 は互換性に配慮されたオペレーティングシステムです。Windows 7 では、新たに変更・削除された機能なども存在しますが、以前のバージョンである Windows Vista との高い互換性を目標に設計されており、Windows Vista によって検証済みのアプリケーションは「概ね Windows 7 でも動作する」ことになるでしょう。従って、「Windows 7 の互換性」について考える場合には、むしろ、「Windows XP 以前の OS から Windows Vista への互換性」を理解しておくことが重要です。こうした観点から、この投稿でも、まず Windows Vista における互換性のポイントを再び整理し、そのあとで、Windows 7 における若干の変更点を述べていくことにします。

互換性に関わる重要な概念のいくつかはこのあと説明していきますが、「Windows 7 の互換性」と表現した場合、それらは、以下の側面に分類できるでしょう。

• UAC (ユーザーアカウント制御) に関する互換性
• その他のセキュリティに関する互換性
• Internet Explorer に関する互換性
• 上記以外の互換性

また、互換性に対処する具体的手段は、大きく以下のように分類できます。

• 互換用のシム / モード (例: 互換性タブ、Windows XP Mode、など) を使用した対応や、関連するツール / ユーティリティ (例: Application Compatibility Toolkit 5.5、Microsoft Enterprise Desktop Virtualization、など) を使用したこれらの統一的管理
• Windows OS 自体が持っている動作許容性 (例: ディレクトリ接合、ファイルの仮想化、プログラム互換アシスタントによるガイド表示、など)
• アプリケーション自体の修正

アプリケーション自体の修正をおこなわない (1)、(2) の方法は、管理者 / IT Pro が扱う多数の企業内アプリケーションの対応や、サードパーティーが提供する製品の対応などといったケースでは有効な手段です。しかし、この連載で対象としている「開発者」にとっては、そもそもアプリケーション自体を Windows 7 で動作できるようにしておきたいと思われることでしょう。従って、ここでは、一貫して上記 (3) の観点に立って説明をおこないます。

補足 : ここでは省略していますが、Application Compatibility Toolkit (ACT) は、実は、管理者だけでなく開発者にとっても有用なツールです。例えば、ACT の中に含まれる Standard User Analyzer (SUA) は、構築したアプリケーションを標準ユーザーで動作させた場合の問題を検証するツールとして活用することができます。
こうした各ユーティリティの活用方法については、「Windows 7 互換性評価ポイント ハンズオンラボ」が参考になります。

ユーザーアカウント制御 (UAC) の考え方

ご存じの通り、Windows Vista 以降ではユーザーアカウント制御 (UAC) という新しいセキュリティ機構が搭載されました。1 人が 1 つの OS を所有するという「パーソナル」な利用環境では、管理者の権限による作業が頻繁に必要とされます。UAC は、パソコンにおけるこうした現実の利用状況に対応した新しいセキュリティの仕組みです。

UAC を理解する上で重要なのが、整合性レベル (Integrity Level, IL) と トークンのフィルター です。
ファイルなどのセキュリティ対象のオブジェクトに対して、ACL (アクセス制御リスト) が存在しているのは皆さんご存じでしょう。(下図)

Windows Vista には、整合性レベルと呼ばれるもう 1 つのアクセス制御のメカニズムが存在し、上図の ACL より先にこのメカニズムによるチェックがおこなわれています。整合性レベルは、プロセス、ファイル、レジストリーキーなどすべてのセキュリティ対象のオブジェクトに対して適用され、High (高) / Medium (中) / Low (低) の 3 つの レベル (Level) と、No-Write-Up / No-Read-Up / No-Execute-Up の 3 つの ポリシー (Policy) の組み合わせで構成されます。例えば、あるファイルに High のレベルで No-Write-Up のポリシーが適用されている場合、その下のレベルである Medium / Low のプロセスからこのファイルへの書き込み (Write-Up) はできません (※2)。High のレベルで No-Read-Up のポリシーが適用されているファイルには、その下のレベルである Medium / Low のプロセスからこのファイルの読み込み (Read-Up) はできません。つまり、上図の ACL の設定に関係なく、この整合性レベルのメカニズムによって権限を得られないことがあるのです。そして、こうした場合に、UAC のダイアログを使った管理者権限 (整合性レベル High) への昇格が必要となります。

補足 : icacls.exe コマンドを使用すると、こうした設定と動作確認を簡単におこなうことができます。また、icacls.exe <ファイル名> で、そのファイルの整合性レベルを確認することができます。例えば下記では、test.txt はレベル High (High Mandatory Level) でポリシー No-Read-Up (NR) であることを示しています。

また、Sysinternals のプロセスエクスプローラやプロセスモニターを使用すると、プロセスの整合性レベルを容易に確認することができます。

実は、管理者権限 (Administrators グループ) のユーザーでログインをしている場合でも、整合性レベルが常に High (高) になっているわけではありません。Windows Vista では、すべてのユーザーはいったんフィルターされたセキュリティトークンに変換され、その結果、ビルトインの Administrator を除き、管理者 (Administrators) 権限のユーザーもすべて標準ユーザーとして動作します。(ビルトインの Administrator だけは、フィルター後も整合性レベルが High となるような特別なフィルターが使用されます。) この結果、管理者権限が必要な HKEY_LOCAL_MACHINE のレジストリーキーへの書き込みや、%ProgramFiles% ディレクトリに対する書き込みなど、すべて既定では無効となり、昇格を使用した管理者権限の獲得が必要となります。

この考え方はプロセス間においても同様です。低いレベルのプロセスから高いレベルのプロセスに対して、いくつかの動作は許可されていません。例えば、標準ユーザー (すなわち整合性レベルが Medium) のプロセスから、整合性レベルが High のプロセスに対してウィンドウメッセージを送信しようとしても、この処理は受け付けられません。(これは、ユーザーインタフェース特権の分離 (UIPI) と呼ばれています。) 管理者権限で実行した notepad (メモ帳) や Visual Studio に対して、外のエクスプローラのウィンドウからファイルをドラッグアンドドロップしようとしても操作が無効になってしまうのもこのためです。
これは一見、非常に不便に思うかもしれませんが、昇格ダイアログ自体に外のプログラムから自由にメッセージやキーボード入力を送信できてしまうような状況を想像して頂くと、非常に堅く守られていることがご理解頂けるでしょう。

UAC を考慮したアプリケーション開発

こうしたUACの仕組みに対してアプリケーションに必要になる作業が アプリケーション マニフェスト の記述です。アプリケーション マニフェストは、下記のようにアプリケーションの動作を記述したXMLファイルであり、アプリケーションと同一のフォルダに配置する方法と、mt.exeコマンドによりアプリケーション(.exeなど)に埋め込む方法があります。(可搬性を考慮するとアプリケーションに埋め込む方法をお薦めします。)

<?xml version="1.0" encoding="UTF-8" standalone="yes"?><assemblyxmlns="urn:schemas-microsoft-com:asm.v1"manifestVersion="1.0">  <trustInfoxmlns="urn:schemas-microsoft-com:asm.v3"><security>  <requestedPrivileges><requestedExecutionLevel            level="requireAdministrator" uiAccess="false"/>  </requestedPrivileges></security>  </trustInfo></assembly>

上記で、requestedExecutionLevel と記載されている箇所 (太字) は UAC を制御する上で重要で、この例では、アプリケーションの実行時に管理者権限 (requireAdministrator) で昇格して実行するように指定しています。このアプリケーションを起動すると、起動時に昇格用の UAC のダイアログが表示されます。(なお、上記で uiAccess 属性は、他のアプリケーションへの UI アクセスが必要なユーザー補助アプリケーションなどで使用する属性です。証明書の添付と所定のフォルダへの配置が必要となります。)

補足 : ClickOnce アプリケーションではマニフェストによる権限の昇格はできませんので注意してください。

このアプリケーションマニフェストの作成は容易におこなえます。例えば、Visual Studio 2008 の Visual Basic では、プロジェクトのプロパティで [UAC 設定の表示] ボタンを押すことでマニフェストファイルの新規作成をおこなうことが可能です。(C# では、新しい項目の追加によってアプリケーションマニフェストファイルを追加します。また、マニフェストをアプリケーションに埋め込むか否かをプロジェクトのプロパティで設定できます。) マニフェストで上記の通り管理者権限を要求すると、アプリケーションへのシールドアイコン (昇格が必要であることを示すアイコン) も自動で設定されます。

アプリケーション開発者にとって、上記で述べた UAC に関する動作の基本概念を理解しておくことは重要です。
例えば、インストール後にプログラムの起動をおこなうインストーラーはよく見かけますが、インストール時に管理者への昇格がおこなわれ、インストール後にプログラム (子プロセス) の起動をおこなった場合、この起動したプログラムは整合性レベルが High のプロセスの子プロセスであるため、やはり高い整合性レベル (High) で動作します。利用者はこれに気づかずにアプリケーションを使用することになるでしょう。
ここでは詳述しませんが、動作設計・実装方法については、こうしたいくつかのポイントがあります。

さらに、もっと重要な点は、ここで述べた整合性レベルの「概念」をアプリケーション開発者が正しく理解することです。
この整合性レベルによるメカニズムでは、前述の通り、レベルの高いプロセス (High) は、High / Medium / Low のすべてのプロセスに権限を持つ (例：キーボード入力の送信、フック、など) ことになります。あるマナーの悪いアプリケーションが常に管理者権限で実行され、さらに入力チェックなども甘い状態であった場合、たとえ他のアプリケーションが強固でも、この整合性レベルの高い (Highの) アプリケーションを踏み台として他のプロセスに侵入する危険性があります。さらに、これが企業内で共通に使用されている社内アプリケーションであった場合には、企業内のすべてのコンピューター環境が同じ危険にさらされていることになるでしょう。このため、レベルが高いタスクや Windows サービスを実行する場合にも、入念な検証をしておく必要があります。
ここでは詳述しませんが、UAC に配慮したアプリケーション構築では、昇格が必要な処理とそれ以外の処理を明確にわけるなど、セキュリティを考慮したアプリケーションの設計・モジュール化やテスト方法が必要不可欠です。

つまり、アプリケーション開発者は、この UAC を「管理者権限の処理で回避しなければならない手続き」と捉えるのではなく、Windows Vista / 7 の時代における「新しいセキュリティモデル」と捉え、この機構とうまく付き合いながらアプリケーションを設計・構築していく能力 (Trustworthy な強いアプリケーションを作る能力) が求められます。
昨今、個人の些細なデータ流出や、個人がたまたま使っていたアプリケーションなどの理由で、企業の信頼性を大きく失墜させる時代です。利用者のマナーだけではなく、開発者のマナー (= この仕組みの正しい理解と、正しい利用) も必要な対策であり、マルウェア感染率 6 割減を実現できるこの道具 (UAC) とうまく共存していく能力が求められます。

セキュリティを中心とした その他の互換性のポイント

つぎに、Windows Vista 以降における互換性のその他のポイントと、さらに Windows 7 における変更点を説明していきます。以下に、重要なテーマに絞ってそのいくつかをご紹介しましょう。
(下記では、あえて問題になりそうなところをクローズ アップしてますが、Windows というのは、実は、かなり互換性に配慮して設計されています。。。)

その 1 つとして、セッション 0 の分離 があります。Windows XP 以前では、Windows にログインしたユーザーのセッションは、バックエンドで稼働している Windows サービスと同一のセッション (Session 0) で動作していたため、サービスが表示するポップアップウィンドウなどはログインしているユーザーの画面上にそのまま表示されていました。これは、セキュリティ上のリスクとなることは勿論、例えば、別のユーザーなどでログインしなおした場合には別のセッションが割り当てられ (その結果、サービスからのポップアップ画面は、今度はユーザーのデスクトップに表示されません)、その結果、動作の不一致も生じます。
Windows Vista 以降では、この考え方も整理されました。ログインをおこなうユーザーは、そもそも初回のログインであろうとサービスとは別のセッションとして稼働します。そのため、従来、ポップアップウィンドウなどを表示してユーザーと対話することを前提に構築されていたサービスはすべてブロックされ、こうしたアプリケーションでは修正が必要になります。

また、Windows リソース保護 (WRP) は、Windows が標準で提供するファイルやレジストリーなどを保護する新しい ACL (アクセス制御リスト) を提供します。例えば、System32 フォルダーの中の OS が提供するファイルのアクセス権限を見ていただくと、下図のように、「TrustedInstaller」という名前の Windows モジュールインストーラーサービスのアカウントのみがフルコントロール権限を持っており、Administrator を含むすべての一般アカウントに対して書き込み権限はありません。

このため、OS のライブラリを書き換えていたフリーウェアなどのアプリケーションは動作しなくなります。こうしたアプリケーションでは、そのアプリケーションのみで変更されたライブラリ (.dll) を使用するようにアプリケーションのカレントフォルダに変更したモジュールを配置するなどの対応が必要となるでしょう。これは、レジストリーに対しても同様です。

さらに、Windows Vista / Windows 7 上の Internet Explorer (IE7 / IE8) については OS 上で動作するプログラムであるため、前回説明した整合性レベルの管理下に置かれているという点に注意してください。これらの OS 上の Internet Explorer では、基本的には (管理者実行などをしなければ) 整合性レベルが Low で動作し、これは、「保護モード」と呼ばれています。(ただし、IE 6 以前のブラウザーや、Windows XP 上の IE7 は保護モードで動作しません。) このためブラウザーは、インターネット一時ファイルのキャッシュや、Cookie フォルダーなど、基本的には、整合性レベルが Low のリソースしか扱うことはできません。しかし、ブラウザーの利用者がページのソースや画像を (不特定なフォルダーに) 保存したり、ActiveX コントロールなどのプラグインをインストールする場合があります。こうした場合には、Internet Explorer のブローカーと呼ばれる代理のプロセス (整合性レベル Medium、High のプロセス) を使って処理がおこなわれます。(これらのプロセスを整合性レベル Low の ActiveX コントロールなどから直接操作することは不可能です。)

ここではすべてを述べることはしませんが、この他にも、セキュリティ関連として、デジタル署名に関するものや、さらにセキュリティ以外では、OS のバージョン変更、サロゲート文字、メイリオフォントなど、いくつか注意すべきポイントが存在します。
これらの全体については、Windows Vista 時代のものも含め、「アプリケーション開発者向け Microsoft Windows 7 対応アプリケーションの互換性」に記載されていますので、チェックリスト化し、静的検証 (実際に動作させて確認をするのではなく、事前にポイントを確認して修正) などに活用すると良いでしょう。

Windows 7 における変更点 (および、Internet Explorer での注意点)

では、Windows 7 における変更点をみていきましょう。前回の冒頭でも述べたように、Windows 7 の互換性の観点では、ここまで述べてきた Windows Vista から、ほんの少しの変更が加えられているだけです。(勿論、OS 自体は、カーネル自体も含め劇的な進化を遂げています。)

Windows Vista では、サービスパックなどの適用と共に、UAC の昇格プロンプトが「静かに」なってきていることにお気づきでしょうか。Windows 7 のユーザーアカウント制御 (UAC) では、利用者のフィードバックをもとに、「さらに静かになった」という点がポイントです。
Windows 7 では、管理者ユーザーでログインした場合、コントロールパネルから起動するさまざまな設定画面で、シールドアイコンのあるボタン (下図) をクリックしても UAC のダイアログ (昇格のダイアログ) は表示されません。(ただし、整合性レベルは High で起動されます。)

これは、ユーザーアカウント制御のレベル設定によって実施されており、デフォルトでは、Windows があらかじめ提供しているこれらの設定については昇格の確認をおこなわないように設定されています。(開発者が作成したプログラムなど、その他のプログラムでのみ UAC のダイアログが表示されるように設定されています。) この設定は、実は、Windows Vista でも可能でしたが、Windows 7 では、下図のような設定画面を使って簡単に設定をおこなうことができます。

上図でスライダーを一番上に設定すると、Windows Vista 同様、常に UAC のダイアログが表示されるようになります。

また、Windows 7 に含まれる Windows Installer 5.0 では、複数のパッケージを同時にインストール (Windows Installer 4.5 の新機能です) する際、特権ブローカーと呼ばれるものを使用して UAC のダイアログが何度も表示されないようになっています。さらに、DPI の設定もマシンごとではなくユーザーごとの設定となっており、昇格は不要です。

これらは、それぞれは細かな改善ですが、Windows 7 全体を通して UAC のダイアログが表示されるケースが低減されていることがおわかりいただけるでしょう。

また、Internet Explorer に対する互換性も Web アプリケーション開発者にとっては重要でしょう。ブラウザーの互換性対応も、他の互換性の考え方と同様、設定・モードで対処する方法 (例 : 互換表示、互換表示リスト、ACT の使用、など) と開発者が構築する成果物 (例 : Web ページの設定、サーバー側の設定、など) で対処する方法の双方があり、ここでも後者の観点でみていきたいと思います。
まず、Windows 7 に搭載されている IE 8 (Internet Explorer 8.0) は、W3C への完全標準を目標に設計されています。これは、他のブラウザーとの相互運用の観点で喜ばしいことかもしれませんが、逆に、IE 7 との互換性がなくなる場合があります。このため、IE 8 では、互換モードの設定をページやサイトごとに細かく設定して対処することが可能になっています。

例えば、下記は、ページ内に互換モードを設定した HTML ソースの例です。このページでは、IE 7 と同じモードでページを表示するよう、IE 8 (ブラウザー) に指示しています。

<!DOCTYPE html PUBLIC . . .<html><head>  <meta http-equiv="X-UA-Compatible" content="IE=IE7"><title>Test Page</title><style type="text/ccs">. . .</style></head>. . . . .

モードは IE 7 以外に、IE 5 以降で使用されている Quirks Mode (クアークス モード) も指定できます。また、IE 7 の頃の IE 7 モード / Quirks モードの動き (ドキュメントの DTD 定義による Quirks モード判定) に忠実に準拠して動作する「EmulateIE7」というモードも使用できます。(指定可能なモードの詳細は、「アプリケーション開発者向け Microsoft Windows 7 対応アプリケーションの互換性」のドキュメントに記載されています。)

現在使用されているモードは、Internet Explorer の「F12 開発者ツール」を使用すると簡単に確認できますので、「おかしいな ?」と思ったら、まずモードを確認してみてください。

IE のモード (互換性表示) は、上記以外の方法で指定することもできます。
例えば、上記はページ単位での設定ですが、Web サーバー側の HTTP ヘッダーや Web.config を使用すると、サイト単位に設定することも可能です。
あるいは、Internet Explorer 側の設定で、特定のサイトを互換表示 (別のモードで表示) させることもできます。例えば、イントラネット サイトは、既定で互換モードで表示されるようになっており、開発などでこの設定が邪魔な場合は、Internet Explorer のメニュー バーを表示し、メニュー [ツール] – [互換表示設定] で、[イントラネット サイトを互換表示で表示する] のチェックを外します。
さらに、Microsoft が指定する互換表示設定のサイトは、強制的に互換表示されています。以下のアドレスをブラウザーのアドレス バーに入力すると、こうしたサイトの一覧を確認できます。(もし、一時的に、これらのサイトについても互換表示を解除したければ、上述の [ツール] – [互換表示設定] で、[マイクロソフトからの更新された Web サイト一覧を含める] のチェックを外してください。)

File:\\%LOCALAPPDATA%\Microsoft\Internet Explorer\IECompatData\iecompatdata.xml

ここでは説明しませんが、上記の UAC、Internet Explorer 以外にも、少数ですが、Windows 7 で変更・削除された機能があります。これらについても「アプリケーション開発者向け Microsoft Windows 7 対応アプリケーションの互換性」にまとめられていますので是非参考にしてください。

ここでは互換性について大きなポイントを中心に説明しましたが、これら互換性に関する項目をすみずみまですべて暗記する必要はなく、全体としてどのような点に留意すべきかという全体像と、ここで説明したポイントのいくつかを抑えておくだけでも、実際のアプリケーション移行に際して円滑な判断が可能となるでしょう。