• OS の互換モードの使用

  アプリケーションのバージョン チェック問題が原因で、インストールや起動ができないなら、ファイルのプロパティで「Windows XP ( Service Pack 3)」互換モードなどのオプション有効にします。これにより、以前の OS に近い環境でアプリケーションを実行することができます。

  

  図 3-2: [互換性] タブ

• VersionLie 互換フィックスの使用

  「VersionLie」は、アプリケーションに対して OS のバージョン番号を偽ることができる互換フィックスです。これにより、アプリケーションからバージョン番号が要求されたときに、以前の Windows のバージョン番号を回答することができます。この互換フィックスはさまざまな OS 用のものが提供されており、たとえば、WinXPSP3VersionLie 互換フィックスでは、アプリケーションに対して Windows XP SP3 のバージョン番号を返します。これにより、バージョン番号が一致していないだけの理由で、実行が失敗するといった問題に対処することができます。

  ただし、VersionLie は、アプリケーションのバージョン番号のチェックをすり抜けているにすぎません。Windows 7 では許可されない処理が呼び出されると、そのタイミングで失敗します。

• 目的のバージョン以上かどうかをチェックする

  将来の Windows でもアプリケーションの使用を許可するなら、バージョンをチェックする際に、「目的のバージョンと一致するかどうか」ではなく、「目的のバージョン以上かどうか」をチェックします。

• レジストリの CurrentVersion をチェックしない

  レジストリに直接アクセスして、OS のバージョンを取得しないようにします。

• 他のバージョンへのインストールを制限する

  低レベルのユーティリティで、特定の OS に密接に関連している場合や、EULA (使用許諾契約書) で将来の OS での使用が禁止されている場合は、故意に他の OS へのインストールを拒否することもできます。この場合には、以下のようなメッセージを出すなどして、システムに悪影響を及ぼさないように失敗させる必要があります。

  

  図 3-3: インストール制限

OS に特定の機能があるかどうかを検証したい場合、バージョン番号だけをチェックするのは最善の方法ではありません。新しい OS がリリースされたり、サービスパックなどの提供により、新しい機能が追加されたりすることもあるからです。

特定の機能の有無を確認するには、バージョン番号に依存するのではなく、その機能をサポートしているかどうかをチェックすることが重要です。これは、Windows 開発チームが推奨する方法です。

• GetVersionEx()

  GetVersionEx は、現在の OS のバージョン番号を返す API です。たとえば、以下のコードは、OS のメジャーバージョンが「6」以上かどうかを確認しているので、Windows Vista 以降かどうかを確認することができます。

  OSVERSIONINFO osvi;
  osvi.dwOSVersionInfoSize = sizeof(OSVERSIONINFO);
  GetVersionEx(&osvi);
  BOOL bIsWindowsVistaOrLater =
  (osvi.dwPlatformId == VER_PLATFORM_WIN32_NT) &&
  (osvi.dwMajorVersion >= 6);

• VerifyVersionInfo()

  VerifyVersionInfo() API は、単にバージョンを返すのではなく、現在の OS がアプリケーションの要件に沿っているかどうかを true もしくは false で答えます。要件には、OS のメジャー バージョン、マイナー バージョンおよびサービスパックを指定することができ、現在のシステムがそのバージョンかそれ以上であれば、true を返します。つまり、「SP3 を適用した Windows XP かどうか」といった条件を与えると、Windows 7 がインストールされている場合にも true を返します。ただし、この API はWindows 2000 以降でのみサポートされます。

• Environment.OSVersion プロパティ

  .NET Framework では、System.Environment.OSVersion プロパティを使用して、OS のバージョン チェックをすることができます。

• パスのハードコード

  マイ ドキュメントのフォルダー パスは Windows のバージョンによって変更されているため、特定の場所へのパスがハードコードされているアプリケーションは、ほかのバージョンの Windows では動作しない可能性があります。実際、この問題が多くのアプリケーション非互換の原因になっています。

  また、ドメインのようなエンタープライズ環境で運用している場合、ユーザーのマイ ドキュメント フォルダーは、ローカルディスクではなく、ネットワーク フォルダーに移動されることもあります。これにより、ユーザーはドメイン内のどのコンピューターからでも、移動ユーザー プロファイルを使用してアクセスすることができますが、パスをハードコードしていると、ローカル システム上でフォルダーを検索するアプリケーションの場合は、場所が変更されたときに マイ ドキュメント フォルダーを見つけることができません。

• 適切な API によるフォルダー パスの取得

  API を使用して、特定のフォルダーのパスを取得します。これにより、たとえ OS が変更されても、アプリケーションには新しいパスが返されるため、パスの変更による互換性の問題が発生しません。以下に API の例を示します。

  API	説明
  GetWindowsDirectory()	Windows フォルダーのパスを取得
  GetSystemDirectory()	Windows システムフォルダーのパスを取得
  GetTempPath()	システムの一時フォルダーのパスを取得
  SHGetFolderPath()	CSIDL 値によって識別された Windows 特殊フォルダーへのパスを取得

  たとえば、マイ ドキュメントなどのフォルダーを見つけるには、SHGetFolderPath() を使用してパスを取得します。以下にこの API を使ったコード例を示します。

HMODULE hModSHFolder = LoadLibrary("shfolder.dll"); 
if ( hModSHFolder != NULL )
{
(*(FARPROC*)&g_pfnSHGetFolderPath = 

    GetProcAddress(hModSHFolder, "SHGetFolderPathA")); 

}
Else
{
g_pfnSHGetFolderPath = NULL; 

}
if (g_pfnSHGetFolderPath != NULL )
g_pfnSHGetFolderPath(NULL, CSIDL_SYSTEM, NULL, NULL, szSystem32); 

else
szSystem32[0] = '\0'; 

OpenFileName.lpstrInitialDir = szSystem32;

• 適切なレジストリの使用

  レジストリからパスを取得する際は、データ型を確認しなければなりません。データ型が「REG_EXPAND_SZ」の場合には、ExpandEnvironmentStrings 関数を使用することができます。「REG_EXPAND_SZ」型は、展開可能な文字列型のことで、環境変数を含むことができます。環境変数を含むレジストリ値を読み込むときは、ExpandEnvironmentStrings 関数を使用することで、「%WinDir%」のような環境変数を現在の値に置き換えることができます。

Windows Vista や Windows 7 では、すべての実行可能ファイルに Authenticode 証明書を使用して署名すべきです。拡張子 .exe、.dll、.ocx、.sys、.cpl、.drv および .scr のついたファイルが対象です。Authenticode 証明書による署名のための手順を以下に示します。  

1. Authenticode 証明書をサードパーティの証明機関から入手します。信頼されるサードパーティの商用証明機関一覧は、Microsoft の Web サイト「Microsoft Root Certificate Program Members」(英語) で確認できます。
2. このような証明機関は、申請者の資格を確認し、その結果によって申請者に Authenticode 証明書を発行しています。

3. ソフトウェアの発行元は証明書を入手後、Windows SDK (ソフトウェア開発キット) に付属する署名ツール (Signtool.exeなど) を使用して署名します。Signtool.exe コマンドラインツールの使用例は、以下の通りです。

   signtool sign /a MyFile.exe

   各オプションの意味は、以下の通りです。

   オプション	説明
   sign	ファイルにデジタル署名する際に指定します。
   /a	最適な証明書を自動的に選択する際に指定します。
   MyFile.exe	署名するファイルへのパスを指定します。

   Signtool.exe の詳細は、Microsoft の Web サイト「署名ツール (SignTool.exe)」を参照してください。

通常、Authenticode 証明書は企業内で管理されています。そのため、開発やテストの段階では使用できないことがあります。MakeCert コマンドを使用すると、テスト用の証明書を作成することができます。使用例は、次の通りです。

MakeCert -r -pe -ss TestCertStoreName -n "CN=CertName" CertFileName.cer

各オプションの意味は、次の通りです。

MakeCert の詳細については、Microsoft の Web サイト「証明書作成ツール (Makecert.exe)」を参照してください。

厳密名付きのアセンブリを作成するときには、秘密キーと公開キーが必要です。秘密キーはデジタル署名のために使われます。また、公開キーは厳密名の一部となるため、他のアセンブリがそのアセンブリを参照するときなどには必須となります。

しかし、企業においては、公開キーや証明書は容易に取得できても、秘密キーは厳重に管理されているため、開発者が日常的にアクセスすることは難しいといえます。このような場面では、遅延署名を使用します。遅延署名を利用すると、ビルド時は、デジタル署名用のスペースを予約するだけで、署名しないため、秘密キーがなくてもビルドすることができます。

Visual Studio を使用して、遅延署名を設定する手順は、以下の通りです。

1. プロジェクトのプロパティで、[署名] タブを選択します。
2. [アセンブリの署名] チェックボックスをオンにします。
3. 公開キーが保存されたキーファイルを指定します。
4. [遅延署名のみ] チェックボックスをオンにします。
5. アプリケーションをビルドします。

図 3-10: [署名] タブ

遅延署名を設定したプロジェクトは、ビルドはできますが実行はできません。また、グローバルアセンブリキャッシュにも登録できません。これは現段階では署名がないからです。しかし、以下のコマンドを実行すると、一時的にそのアセンブリの署名を確認しないようにすることができるため、アセンブリが実行できるようになります。

sn.exe -Vr Application.dll

出荷直前に企業の秘密キーでデジタル署名するために、以下のコマンドを実行します。

sn.exe –R Application.dll

前の手順で「sn.exe -Vr」を実行しているため、このままでは署名の検証がおこなわれません。署名の検証を有効にするため、必ず以下のコマンドを実行します。

sn.exe -Vu Application.dll