ユーザーも開発者も，Windows XPのリリースを待ちわびていた。Windows XPは，Windowsオペレーティングシステムの進化における，いくつかの画期的な出来事を象徴している。Windows XPは，Win32ベースのオペレーティングシステムとしては初の，一般家庭とビジネスの両方で使用することを目的としたオペレーティングシステムである。

　Windows XPには，ベースのオペレーティングシステムに数々の改良を加えているほか，ユーザーの使用感を改善する新しいアクセサリを含んでいる。最も目に付くのは，装いを新たにした新しいシェル，ニューモデルの［スタート］メニュー，更新されたタスクバーである。新しい外観は，ユーザーインターフェイスを根本的に変更する配布可能なテーマファイルを使って，Windows XPに「テーマを被せる」ことによって実現される。

　Windows XPのもう1つの新機能は，同じマシン上で複数のユーザーをそれぞれの専用セッションに同時にログインさせる，高速ユーザー切り替えである。また，LCD画面用のMicrosoftのフォント表示技術であるClearType，そしてGDI（Graphical Device Interface）の後継技術であるGDI＋が新たに加わった。コントロールパネルにも，ユーザーがコントロールパネルの目当てのアプレットを見つけやすくするための，新しいカテゴリ方式が採用されている。

　こうした新しい機能は，ユーザーのメリットであると同時に，アプリケーションの設計方法に影響を与えるものである。Windows XPは，レガシーアプリケーションとの互換性の維持に努めているが，何らかの対応策が要求される新しい機能もいくつか存在する。また，アプリケーションの設計に利用したい新しい機能もいくつか存在する。

　Windows XPの新機能を利用するためには，Windows XPのアプリケーションを構築する方法と，Windows XPアプリケーションが実行されていることを検出する方法を理解しなければならない。Windows XPの新しい機能を使用するアプリケーションを構築するためには，正しいビルド式を設定しなければならない。_WIN32_WINNTとWINVERの両方を0x0501と定義する必要がある。

　また，Windows XP用にコンパイルしたからといって，アプリケーションがWindowsシステムの古いバージョンで実行できないわけではない。Windowsの以前のバージョンとの下位互換性を維持したい場合は，いつもと同じ点に注意すればよい。たとえば，Windows XPにしか存在しない関数はリンクしない。Windowsの古いバージョンで実行する場合は，構造体に正しいサイズの値を使用する，といった具合である。ポイントは，アプリケーションを実行しているWindowsのバージョンを把握することだ。

　Windows 2000以降，Microsoftはアプリケーションに新しいバージョンチェックAPIを使用するように呼びかけている。アプリケーションには，古い標準のGetVersionExの代わりに，同様の機能を少し異なる方法で実行するVerifyVersionInfoを使用する。もちろん，アプリケーションをWindows 2000以前のバージョンで実行する場合は，GetVersionExを使用しなければならない。なぜなら，VerifyVersionInfoは，Windows 2000とWindows XPでのみサポートされているからだ。

　幸い，GetVersionExはWindows NT 4.0のService Pack 6で拡張され，Windowsのバージョンのみならず，Windows XPのどのエディション（Home，Professional，64-Bit）で実行されているのかなど，知るべきすべての情報を提供するようになった。Windows XPのHome Editionは，一般家庭を対象とした新しい製品であり，Windows Meの後継者にあたる。Home EditionにはProfessional Editionのいろいろな機能（大半はセキュリティ関連）が含まれていないため，アプリケーションがWindows XPのHome Editionで実行されるていかどうかを把握することは重要である。

　実行中のWindows XPのバージョンを照会するには，VerifyVersionInfoまたはGetVersionExを使用することができる。GetVersionExの改良バージョンは，実行中のオペレーティングシステムのエディションを特定するためのフィールドを持つ，OSVERSIONINFOEXW構造体を受け取る。Figure 1に，この構造体を示す。

　新しいフィールドは，サービスパックバージョンのフィールドである，SuiteMaskとProductTypeである。興味深いのは，Windows XPのProfessional Editionと64-Bit Editionの違いがwProductTypeに示されるのに対し，Professional EditionとHome Editionの違いがwSuiteMaskフィールドに示されることだ。Figure 2のコードは，OSVERSIONINFOEXW構造体を使って，Windows XPが実行されているかどうか，実行されているとすれば，Home Editionなのか，Professional Editionなのか，それとも64-Bit Editionの1つなのかをつきとめようとする。

　Windows XPのさまざまなバージョンの判別方法を身に付けることは，作業のほんの手始めにすぎない。次は，Windows XPの新機能をいくつか試してみよう。

　高速なユーザーの切り替えは，ハードウェアにアクセスするアプリケーションや，コンピュータで一度に1つしか実行できないアプリケーションに影響する。Windows XPは，システムにログインしているユーザーごとにユーザーの状態を別々に管理するために，ターミナルサービスを使って高速ユーザー切り替えを実装している。ユーザーにとってはうれしい機能だが，あるユーザーが起動したアプリケーションが，別のセッションの別のユーザーによって新たに起動される可能性がある。この2つのインスタンスは同じ物理マシンで実行されるため，衝突する恐れがある。

　最善策は，複数のユーザーがアプリケーションを同時に実行できるように，アプリケーションを修正することだろう。これを実現するには，アプリケーションの2つのインスタンスが使用するファイルに，アプリケーションの状態を保存しないようにしなければならない。たとえば，アプリケーションの作業ディレクトリに一時データを保存してはならない。別のユーザーが同じアプリケーションを実行する際，2番目のインスタンスは一時データを保存するために，同じディレクトリの同じ名前のファイルを使おうとする。これを解決するには，GetTempPathを使って，ユーザーの一時ディレクトリを取得すればよい。Windows XPは，複数のユーザーがログオンしてもデータが衝突しないように，ユーザーごとに異なる一時ディレクトリを維持する。

　もちろん，正しいディレクトリを照会するためには，必ずシステム関数を使用しなければならない。スタートアップ，デスクトップ，マイドキュメントなどのディレクトリの照会には，SHGetFolderLocationを使用する。これは数年前からWindowsベースアプリケーションの認定条件になっているが，レガシーアプリケーションの中にはこのルールに違反しているものがある。Windows XPの高速ユーザー切り替え機能は，こうした互換性のないアプリケーションをさらにいくつか暴露するだろう。

　アプリケーションのなかには，システムが新しいユーザーに切り替えたことを把握しなければならないものがある。たとえば，Windows Mediaプレーヤーは，システムがユーザーを切り替えるとミュージックファイルの再生を中止する。所詮，音楽の好みは人それぞれなのだ。

　アプリケーションは，システムが新しいユーザーに切り替えたという通知を受けるために，WTSRegisterSessionNotification関数を使用することができる。Windows XPは，ユーザーの切り替えが行なわれると，登録されているウィンドウに通知メッセージを送信する。WTSRegisterSessionNotificationは，通知メッセージを受信するウィンドウのハンドルと通知してほしいタイミングを示すフラグという，2つのパラメータを取る。通知フラグは，ユーザーが現在のセッションにログオンする，または現在のセッションからログオフしたときに通知するNOTIFY_FOR_THIS_SESSIONか，またはシステムがセッションを切り替えたときに通知するNOTIFY_FOR_ALL_SESSIONSに設定することができる。システムが新しいユーザーへの切り替えを行なうと，アプリケーションのウィンドウはWM_WTSSESSION_CHANGEメッセージを受信する。wParamパラメータには，セッションが開始または終了したのか，それともユーザーを切り替えただけなのかという，メッセージの理由を示す通知コードが含まれる。

　ほとんどのアプリケーションは，複数のセッションでの実行に対応するか，または別のセッションが開始または終了されたことを把握することできちんと回復するかのどちらかになる。ただし，1台のマシンでは一度に1つしか実行できないアプリケーションも存在する。高速ユーザー切り替えでは，アプリケーションの別のインスタンスを検索する標準の手法が通用するとは限らない。たとえば，システムはユーザーセッションごとに異なるウィンドウクラスリストを管理するため，メインウィンドウのインスタンスの検索にFindWindowは使用できない。

　その代わりとして，アプリケーションはイベントやミューテックスなど，グローバルに名前付けされたカーネルオブジェクトを生成しなければならない。システムはセッションごとに異なるカーネルネームスペースを管理するが，すべてのセッションから参照可能なグローバルネームスペースも管理する。Windows XPで実行されるアプリケーションは，オブジェクト名に"Global\"というプレフィックスを付けることで，カーネルオブジェクトをグローバルネームスペースで名前付けすることができる。

g_hEvent = CreateEvent (NULL, FALSE, FALSE, TEXT ("Global\\MyEventName"));

　Figure 3のコードは，グローバルに名前付けされたイベントを使って，アプリケーションの別のインスタンスが現在のセッションまたは別のセッションで実行されていることを示す。

　"Global\"プレフィックスの使用は，Windows XPおよびターミナルサービスがインストールされたWindows 2000でサポートされている。"Global\"が大文字と小文字を区別することに注意してほしい。Windows 2000以前のバージョンでは，カーネルオブジェクトの名前に円記号を使用することができなかったため，下位互換性を維持したい場合はランタイムチェックを実行し，古いシステムで実行される場合はプレフィックスを削除しなければならない。ターミナルサービスがインストールされていないWindows 2000は，単に"Global\"プレフィックスを無視する。

　多くのユーザーは，新しいアプリケーションをインストールしたところ，それまで動いていたアプリケーションが動かなくなったというありがたい経験を持っていることだろう。通常は，インストーラが新しいアプリケーションと古いアプリケーションが共有するDLLを上書きすることが原因である。このDLL地獄から逃れるため，Windows 2000は切り分けなければならないアプリケーション（すなわち，そのアプリケーションに特化したDLLのローカルコピーを使用するアプリケーション）を特定する機能を持つ。Windows XPはさらに一歩踏み込み，アプリケーションが必要に応じてDLLの複数のバージョンを利用できるようにしている。

　システムが一度に複数のバージョンのDLLをサポートするという考え方を，サイドバイサイドのアセンブリ共有という。マシン上では新しいアセンブリと古いアセンブリが共存するようになるため，共有アセンブリの開発者は下位互換性を保証しなくてもアセンブリを更新できるようになる。また，こうした共有アセンブリのコンシューマは，新しいアプリケーションをサポートするためにマシンに新しいアセンブリが不可欠になった場合を含め，自分の都合に合わせて新しいアセンブリにアップグレードできるようになる。

　サイドバイサイドのアセンブリ共有の鍵を握っているのは，マニフェストファイルである。マニフェストファイルには，複数のアプリケーションによって共有されるアセンブリを定義するものと，サイドバイサイドのアセンブリを消費するアプリケーションを定義するものの2種類が存在する。アセンブリのマニフェストファイルは，バージョン管理の対象となる，アセンブリのさまざまなオブジェクトを定義する。オブジェクトはDLLとは限らず，ウィンドウクラス，COMサーバ，インターフェイス，タイプライブラリの場合もある。アプリケーションがバージョン管理の対象となるオブジェクトの1つを生成すると，Windows XPは要求しているアプリケーションのバージョンコンテキストを割り出し，正しいバージョンが指定されたオブジェクトにアプリケーションをリダイレクトする。

　アプリケーションはマニフェストファイルを使って，必要とするアセンブリのバージョンを指定する。Windows XPには，次の3つのアセンブリが組み込まれている。

　バージョン指定されたこれらのアセンブリは，Windows XPに付随するアセンブリマニフェストを備えている。サードパーティも，自分たちの再配布可能なモジュール用に，バージョン指定されたアセンブリを提供することができる。

　特に重要なのは，Windows XPの新しいコモンコントロールライブラリである。Windows XPで実行されるレガシーアプリケーションは，デフォルトではコモンコントロールライブラリのバージョン5.0にリダイレクトされる。この古いライブラリは，何年間かWindows UIの外観の主流となっていた，四角い3Dコントロールを使用する。

　新しいバージョン6.0のコモンコントロールを使用するためには，アプリケーションはアプリケーションマニフェストを提供して，新しいバージョンを明示的に要求しなければならない。アプリケーションマニフェストは，1つの独立したファイルとして，または実行可能ファイルに付随するリソースとして，Windows XPに提供される。1つのファイルとして提供されるマニフェストファイルは，実行可能ファイルと同じディレクトリに存在し，実行可能ファイルの名前に".manifest"が追加された名前を持っていなければならない。一例を上げると，foobar.exeのマニフェストファイルはfoobar.exe.manifestとなる。

　マニフェストファイルはXMLの構文を使用する。マニフェストファイルの完全なスキーマは，最新のWindows Platform SDKに定義されている。Figure 4に，新しいコモンコントロールライブラリを要求するMyAppアプリケーションのマニフェストファイルを示す。

　最初の数行は，マニフェストのXMLスキーマを定義する。最初のassemblyIdentity要素は，サイドバイサイドのアセンブリを消費するアプリケーションを定義する。name属性はアプリケーションの名前を指定し，version属性はアプリケーションのバージョンを4つの部分からなるバージョン番号で指定する。残りの属性はきわめて標準的なもので，アプリケーションの種類（Win32），プロセッサアーキテクチャ（x86），説明タグを指定する。

　dependency要素は，このアプリケーションが使用する従属要素とそれらのバージョンを列挙する。Figure 4では，MyAppがコモンコントロールライブラリのバージョン6.0を要求している。コモンコントロールライブラリは，dependency要素の下に列挙されたdependentAssemblyの1つの要素によって指定されている。コモンコントロールライブラリの定義において新しい属性は，publicKeyTokenだけである。このフィールドは，アセンブリを具体的に定義する。このアセンブリやほかのサイドバイサイドアセンブリの正しい値をつきとめるには，WindowsシステムディレクトリのWinSxSサブディレクトリに保存されているアセンブリマニフェストファイルを調べればよい。

　レガシーアプリケーションは，新しいコモンコントロールライブラリを使用して，Windows XPの新しい外観や新しいコモンコントロールが提供する追加機能を手に入れることができる。これを実現するには，アプリケーションと同じディレクトリにマニフェストファイルを配置すればよい。実際，システムのレガシーアプリケーション用にマニフェストファイルを作成することは，申し分のない実践練習になるだろう。もちろん，サードパーディのアプリケーションに新しいコモンコントロールライブラリを使用すれば，アプリケーションにバグを埋め込む可能性がある。その危険を覚悟のうえで練習に励んでほしい。

　新しいアプリケーションを開発する場合は，アプリケーション内のリソースとしてマニフェスト情報を提供することができる。この場合は，RT_MANIFESTというリソース型で，リソースファイルにエントリを作成する。この新しいリソース型は，最新のPlatform SDKに定義されている。このリソースは，最終的なEXEファイルに添付されたリソースデータに含まれるマニフェストファイルのファイル名を指定する。アプリケーションに組み込まれるマニフェストリソースを定義するコードは，次のとおり。

1       RT_MANIFEST        "test.manifest"

　test.manifestファイルのXMLフォーマットは，1つの独立した.manifestファイルと同じである。Visual Studio 6.0を使用する場合は，アプリケーションに組み込むマニフェストファイルとそのマニフェストに追加するリソースステートメントを自分で作成しなければならない。

　Figure 5とFigure 6に，私が数年前に書いたアプリケーションの2つのビューを示す。Figure 5は，アプリケーションのディレクトリにマニフェストファイルがないアプリケーションを示している。Figure 6は，新しいコモンコントロールライブラリを有効にするためにディレクトリにマニフェストファイルを持つ，実行時のアプリケーションを示している。ウィンドウのコントロールが，Windows XPのユーザーが普段目にする新しいテーマを使う様子に注目すること。

　Figure 6では，新しいコモンコントロールライブラリを使用しているにも関わらず，ウィンドウの右上のボタンがWindows XPの新しい外観と違っていることが分かる。これは，問題のボタンが所有者によって描画されるボタンであり，デフォルトでは新しい外観を反映しないためである。開発者はこれまで，Windowsの新しいバージョンがシステムコントロールのデフォルトの外観を変更した場合に，所有者が描画するコントロールの外観を更新することだけを気にすればよかった。ところが，Windows XPのリリースによって，ユーザーはコントロールパネルのテーマを変更するだけで，コントロールの外観を変更できるようになった。ユーザーが選ぶテーマを予測することは不可能であるため，これはアプリケーションが描画するコントロールにとって問題となる。

　カスタムコントロールや所有者が描画するコントロールを作成するプログラマにとって幸いだったのは，プログラマのコントロールが現在選択されているテーマに合うように，Windows XPがテーマのレンダリングを行なう関数を用意していることである。

　テーマエンジンを使ったカスタムコントロールの描画は，驚くほど簡単である。まず，IsThemeActive関数を使って，アプリケーションで何らかのテーマが有効になっているかどうか確認する。この関数がtrueを返した場合は，OpenThemeData関数を使って，コントロールの種類に最も近いコントロールのテーマデータのHTHEMEハンドルを開く。たとえば，コントロールの外観がボタンに近い場合は，次のように呼び出す。

HTHEME hTheme;
if (IsThemeActive())
  hTheme = OpenThemeData (hWnd, L"button"));
else
  hTheme = 0; // 古い方法で描画しなければならない

　ウィンドウクラスの名前は，実際にはセミコロンで区切られた複数のウィンドウクラス名のリストになる場合がある。OpenThemeData関数は，クラス名のリストを検索し，テーマデータを持つ最初のクラスを割り出す。また，テーマハンドルが実際に返されたかどうかを忘れずに確認する。ウィンドウクラスに要求されるテーマを持っていないテーマもある。0が返された場合は，標準のGDIまたはGDI＋の呼び出しを使って，コントロールを描画しなければならない。OpenThemeData関数に渡される文字列は，Unicode文字列としてハードコーディングされる点に注意すること。テーマAPIにおいて文字列のパラメータを持つ関数は限られており，それらはUnicode文字列しかサポートしない。

　テーマハンドルを取得したら，次に示すテーマ描画関数を組み合わせて，コントロールを描画する。描画関数を呼び出すたびに，描画するコントロールの一部と，標準，ホット，選択済みといったコントロールの状態を渡す。残りの作業は，テーマAPIが肩代わりする。

DrawThemeBackground	コントロールの背景画像を描画する
DrawThemeEdge		矩形の角を描画する
DrawThemeIcon		コントロールの中で使われるアイコンを描画する
DrawThemeLine		指定された矩形の内側に直線を描画する
DrawThemeText		正しいテーマフォントとサイズを使ってテキストを描画する

　簡単なコントロールの場合，コントロールのレンダリングを完了するために必要な作業は，DrawThemeBackground関数とDrawThemeText関数の呼び出しだけである。Figure 7のコードは，標準のプッシュボタンを模倣したコントロールを描画する。

　このコードのポイントは，その短さと単純さにある。このルーチンはWM_PAINTと呼ばれ，WM_LBUTTONDOWN，WM_MOUSEHOVER，WM_MOUSELEAVEなどのマウスメッセージに使われる。DrawControlのコードは，テーマエンジンが処理してくれるので，コントロールの色やテキストのフォントをいっさい考慮していない。

　コントロールを破棄する際には，OpenThemeData関数から返されたテーマデータハンドルを閉じるために，CloseThemeData関数を呼び出す必要がある。また，ユーザーがテーマを変えたときにブロードキャストされる，WM_THEMECHANGEDメッセージも監視しなければならない。このメッセージが受信されたら，現在のテーマハンドルを閉じ，新しいテーマがアプリケーションでサポートされているかどうか照会し，サポートされている場合は，テーマハンドルを新しく開いて，テーマ付きのコントロールを再描画する。

　このほかにも，さまざまなテーマコンポーネントのサイズや機能を照会するための関数がいくつか用意されている。また，アプリケーションはSetThemeAppProperties関数を呼び出すことで，アプリケーションのコントロール，アプリケーションのなかに表示されるWebページのコントロール，および非クライアント領域の描画にテーマを使用するかどうかを指定することができる。この関数は，論理和（OR）を取ることで新しいテーマの外観を有効にする，STAP_ALLOW_CONTROLS，STAP_ALLOW_WEBCONTENT，STAP_ALLOW_NONCLIENTという3つのフラグを取る。これらのフラグについては，説明するまでもないだろう。テーマはデフォルトで有効になるため，これらのフラグを渡さずに関数を呼び出せば，テーマの特定の部分を無効にすることができる。

　Windows XPベースのアプリケーションにとって，テーマは両刃の剣である。ユーザーがテーマを変更できるという事実は，開発者の作業が少し増えることを意味するが，テーマAPIの便利な機能は，選択されたテーマのスタイルに則ったコントロールの描画をかなり楽にする。

　Windows XPの革新的な機能の1つは，ClearTypeのサポートではないだろうか。ClearTypeは，カラーLCD画面のサブピクセルレベルでアドレス指定する機能を利用して，画面を描画するメカニズムである。ClearTypeで表示されたテキストは，標準のアンチエイリアス方式（ちなみに，Windows XPでもサポートされている）で描画されたものよりもシャープに見える。

　コントロールパネルの［画面］アプレットには，TrueTypeフォントを使用するすべてのアプリケーションにおいてClearTypeを有効にする全体的なスイッチがある。アプリケーションは，SystemParametersInfo関数にSPI_GETFONTSMOOTHINGフラグを使用することで，このグローバルビットの状態を検出することができる。フォントのスムージング機能が有効になっている場合は，SystemParametersInfo関数にSPI_GETFONTSMOOTHINGTYPEパラメータを指定することで，どのスムージングが使用されているのか照会することができる。この呼び出しは，標準のアンチエイリアス機能が使用されている場合はFE_FONTSMOOTHINGSTANDARDを返し，ClearTypeのスムージングが有効になっている場合はFE_FONTSMOOTHINGCLEARTYPEを返す。すでに想像したと思うが，これらのパラメータはSystemParametersInfo関数の補足コマンド，SPI_SETFONTSMOOTHINGおよびSPI_SETFONTSMOOTHINGTYPEを使って，プログラムから変更することができる。

　また，アプリケーションで明示的にClearTypeを使用したい場合や，ClearTypeを使用したくない場合もある。アプリケーションでのClearTypeの使用を制御したい場合は，アプリケーションに使用するフォントを作成する際に，正しいクオリティフラグを設定すればよい。グローバルのClearTypeフラグの状態とは無関係にテキストをClearTypeで描画するには，フォントを作成して，CreateFont関数のIfQualityパラメータか，またはCreateFontIndirect関数のLOGFONTのIfQualityフィールドに，CLEARTYPE_QUALITYフラグを設定する。指定するフォントはTrueTypeフォントでなければならない。標準のアンチエイリアスを指定したい場合は，IfQualityにANTIALIASED_QUALITYフラグを設定する。また，何らかの理由でスムージングを完全に無効にしたい場合は，NONANTIALIASED_QUALITYフラグを使用する。

　Figure 8のコードは，3行のテキストを表示する。フォントを作成するルーチンはプログラムから，テキストを描画するコードはWM_PAINTから引用した。1行目はシステムのデフォルトのスムージング方式で描画され，2行目は標準のアンチエイリアス方式で描画され，3行目はClearTypeで描画される。唯一の違いは，行を描画するために使用するフォントの作り方である。

　テストプログラムの結果を，Figure 9に示す。テキストを描画する3通りの方法の違いがはっきり分かるように，ズームインウィンドウとともにプログラムを表示している。

　1行目のテキストは，デフォルトのスムージング方式を使って描画されている。私が普段そうしているように，コントロールパネルの［画面］アプレットでClearTypeが有効になっている場合，1行目は3行目のように表示される。なぜなら，ClearTypeが全体的に有効になっている場合，TrueTypeフォントで描画されるすべてのテキストは，デフォルトでスムージングされるからだ。

　その名前が示すように，GDI＋は標準のGDI機能をベースに構築された，新しいグラフィックスライブラリである。画面に描画するための標準のWindows APIのセットであるGDIと違い，GDI＋はC++プログラムに統合しやすいクラスライブラリのセットである。こうした言語との相性に加え，GDI＋はグラデーションブラシや，永続的なパスオブジェクト，拡大縮小可能な領域，変換を容易にするマトリックスオブジェクトなど，機能面でも改良されている。

　GDI＋を完全に説明するいは別の記事が必要だが，ここで食欲をそそる一部を披露することにしよう。GDIの中心はデバイスコンテキストとその必須ハンドルだが，GDI＋はグラフィックスクラスを中心に据えている。画面に描画する際には，グラフィックスクラスを作成し，そのクラスのメソッドを呼び出す。ただし，デバイスコンテキストがなくなったわけではない。グラフィックスクラスによってカプセル化されただけである。

　GDI＋の特徴は，そのオブジェクト指向のプログラミングモデルだけではない。GDI＋が公開する機能は，従来のGDIをはるかに凌いでいる。Figure 10のコードに，GDI＋の威力を垣間見ることができる。このコードは，テキスト行をオーバーレイしたグラデーション付きで塗りつぶされた楕円を描画する。テキスト行の文字は，アルファブレンドのグラデーションブラシを使って塗りつぶされている。Figure 11に，コードが生成したウィンドウを示す。

　GDI＋ライブラリを使用するには，次に示すように，gdiplus.hインクルードファイルをインクルードし，gdiplusネームスペースを使用する必要がある。

#include <Gdiplus.h>
using namespace Gdiplus;

さらに，プログラムの起動時にGDI＋ライブラリを初期化し，プログラムの終了時に閉じなければならない。Figure 12に，その方法を示す。

　GDI＋の可能性を示したとはお世辞にも言えないが，これがGDI＋の利点を探るきっかけになればと願っている。これはWindows APIの待望の追加機能である。

　最後に，コントロールパネルのアプレットを開発するユーザーのために，Windows XPはアプレットを分類する新しいコントロールパネルアプリケーションを用意している。アプレットを正しいカテゴリに分類するためには，次のレジストリキーを変更する必要がある。

[HKEY_LOCAL_MACHINE]\Software\Microsoft\Windows\CurrentVersion\
ControlPanel\ExtendedProperties\{305CA226-D286-468E-B848-2B2E8E697B74} 2

このキーの下に，コントロールパネルのアプレットをDWORD値の名前として列挙する。値そのものは，カテゴリを指定する。Figure 13に，有効なカテゴリの一覧を示す。

　Figure 14に，コントロールパネルのカテゴリキーの値が表示されたRegEditを示す。コントロールパネルのアプレットへのパスのほとんどが，環境変数を使って指定されている点に注目してほしい。

　ここでは，Windows XPの新機能の一部に触れたにすぎない。ほとんどの部分では，アプリケーションの実行方法に影響すると思われるWindows XPの機能に焦点を当てた。幸い，アプリケーションに手を加える必要はほとんどないが，Windows XPはアプリケーションを改善できる新機能を随所に盛り込んでいる。

　Windows XPの新機能については，本号に掲載されているDino Espositeの記事，「新しいグラフィカルインターフェイス：Windows XPの新しいシェル機能でプログラムを強化する」をお見逃しなく。