Skip to main content
スキップしてメイン コンテンツへ

アプリケーション開発者向け Microsoft® Windows 7 対応アプリケーションの互換性

更新日: 2010 年 7 月 27 日

Word 文書 Windows7_Compatibility.docx (Word 形式、5.62 MB)

免責

このドキュメントに記載されている情報は、このドキュメントの発行時点におけるマイクロソフトの見解を反映したものです。マイクロソフトは市場の変化に対応する必要があるため、このドキュメントの内容に関する責任をマイクロソフトは問われないものとします。

このホワイト ペーパーに記載された内容は情報提供のみを目的としており、明示、黙示、または法令に基づく規定に関わらず、これらの情報についてマイクロソフトはいかなる責任も負わないものとします。

この文書およびソフトウェアを使用する場合は、適用されるすべての著作権関連の法律に従っていただくものとします。著作権法による制限に関係なく、マイクロソフトの書面による許可なしに、この文書の一部または全部を複製したり、検索システムに保存または登録したり、別の形式に変換したりすることは、手段、目的を問わず禁じられています。ここでいう手段とは、複写や記録など、電子的、または物理的なすべての手段を含みます。

マイクロソフトは、このドキュメントに記載されている内容に関し、特許、特許申請、商標、著作権、またはその他の知的所有権を有する場合があります。マイクロソフトから提供される使用許諾書に明記されていない限り、この文書の配布によりこれらの特許、商標、著作権、またはその他の知的財産権がお客様に譲渡されることはありません。

2009 Microsoft Corporation.All rights reserved.

Microsoft、Windows 7™は、米国 Microsoft Corporation の米国およびその他の国における登録商標または商標です。

この文書およびソフトウェアで使用されている実在の会社名および製品名は、該当各社の商標です。

このドキュメントは、Windows 7 RTM 版における情報をもとに構成しています。仕様および機能は変更される可能性があります。

3. 一般的な互換性問題

この章では、以下のような一般的な互換性問題について紹介します。

3.1 非公開情報に依存しない

Microsoft が推奨・公開している方法を使用して、アプリケーションを開発します。SDK では公開されていない関数・データ構造体・レジストリなどは、次のバージョンアップの際に変更されたり、なくなったりする可能性があります。そのため、その時の OS では動作しても、次のバージョンの OS で問題が発生する可能性があります。

ページのトップへ


3.2 OS のバージョン チェック

Windows の内部バージョン番号

Windows 7 の内部バージョン番号は、「6.1」です。内部バージョン番号は、OS のバージョン アップに伴い更新されます。(メジャー バージョンは「6」、マイナー バージョンは「1」となります。) これまでの Windows の内部バージョンは以下のとおりです。

Windows の種類内部バージョン
Windows 20005.0
32ビット版 Windows XP 各エディション5.1
Windows Server 2003
Windows XP x64 Edition
5.2
Windows Vista
Windows Server 2008
6.0
Windows 7
Windows Server 2008 R2
6.1

アプリケーションが「OS の特定のバージョンかどうか」をチェックしている場合、正しく動作しない可能性があります。たとえば、バージョンが「5.1 かどうか」をチェックしている場合には、Windows 7 は「6.1」を返すため、正しく動作しません。

特に Windows Vista と Windows 7 では、Windows 2000 以来のメジャーバージョンアップがおこなわれています。そのため、「メジャーバージョンが一致すること」のみをチェックしているアプリケーションは、Windows XP や Windows Server 2003 までは正しく動作しても、Windows Vista や Windows 7 では正しく動作しない可能性があります。たとえば、この場合はバージョンが「5 以上かどうか」をチェックすることで正しく動作させることができます。

OS のバージョン チェックの検証

バージョン チェック問題による実行の失敗は、アプリケーションによって発生するタイミングが異なります。一般的にはインストール時やアンインストール時、起動時にバージョン チェックをすることが多いため、これらのタイミングで失敗することが多いといえます。

図 3-1: バージョンエラー

図 3-1: バージョンエラー

互換性テクノロジを使用した問題の回避
  • OS の互換モードの使用

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

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

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

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

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

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

適切なバージョン チェック

既存のアプリケーションを、新しい OS にインストールできない最大の理由は、アプリケーションがバージョン番号を正しく扱わないことです。このようなアプリケーションでは、バージョン チェックの部分さえ取り除いてしまえば、新しい Windows でも問題なく動作することがよくあります。ここでは、正しいバージョン チェックの方法を紹介します。

将来のバージョンでのアプリケーションの使用を許可する
  • 目的のバージョン以上かどうかをチェックする

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

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

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

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

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

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

    図 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 のバージョン チェックをすることができます。

ページのトップへ


3.3 ファイルやフォルダー パスの取得

ファイルやフォルダー パスの変更

Windows では、各リリースでいくつかのフォルダーの位置が変更されています。たとえばマイ ドキュメント フォルダーは、Windows 95 からWindows 7 までの間に以下のようにパスが変わっています。

OS の種類マイ ドキュメントのパス
Windows 9xC:\My Documents
Windows NT 4.0C:\Windows\Profiles\<username>\Personal
Windows 2000
Windows XP
Windows Server 2003
C:\Documents and Settings\<username>\My Documets
Windows Vista
Windows 7
Windows Server 2008
C:\Users\<username>\Documents
Note: Windows Vista と Windows 7 のマイ ドキュメント

Windows Vista では、マイ ドキュメント フォルダーの表示名 (エクスプローラーで開いたときに表示される名前) は、「ドキュメント」でした。しかし、Windows 7 では、「マイ ドキュメント」に戻っています。これは、Windows 7 では、図 3-4 のように、「ライブラリ」内に「ドキュメント」ライブラリが作成され、その中に、「マイ ドキュメント」と「パブリックのドキュメント」が含まれるようになったからです。この「マイ ドキュメント」が「Documents」フォルダーです。

図 3-4: キュメントとマイドキュメント

図 3-4: ドキュメントとマイ ドキュメント

ただ、Windows 7 でも、「Documents」というフォルダー名自体は変更されていないので、Windows Vista への対応が完了しているアプリケーションはそのまま使うことができます。

※他にも変更されているフォルダーがあります。詳細は、 「4.1 リソースの管理」を参照してください。

フォルダーやファイル パスの取得方法

やってはいけないこと
  • パスのハードコード

    マイ ドキュメントのフォルダー パスは 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;
Note:

このコードでは、「CSIDL_SYSTEM」CSLID 値を使用して、Windows のシステム フォルダーへのパスを取得しています。以下に、よく使用される CSIDL 値を示します。

CSIDL 値説明
CSIDL_SYSTEMSystem フォルダーへのパスを取得
CSIDL_PROGRAM_FILESProgram Files フォルダーへのパスを取得
CSIDL_PERSONALマイ ドキュメント フォルダーへのパスを取得
CSIDL_COMMON_APPDATAアプリケーション データへのパスを取得
  • 適切なレジストリの使用

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

ページのトップへ


3.4 ファイルへの署名

デジタル署名の必要性

インターネットからソフトウェアをダウンロードする場合、そのソフトウェアが適切な発行元で、適切に作成されたことが保証されないと、信用できないソフトウェアや悪意のあるソフトウェアをインストールしてしまう可能性があります。これらをインストールしてしまうと、システムの安定性やセキュリティに悪影響を及ぼします。

そこで、ソフトウェアが正規の発行元から提供されていて、しかも改ざんされていないことを証明するために、デジタル署名を使用することができます。デジタル署名により、管理者やユーザーはソフトウェアをインストールする前に、信頼できるソフトウェアかどうかを確認することができます。

デジタル署名による改ざんの防止

デジタル署名は、公開鍵暗号基盤 (PKI) を使用しており、改ざんを防ぐことができます。たとえば、ソフトウェアの発行元がデジタル署名すると、以下のような手順で安全にソフトウェアを送信できます。

  1. ソフトウェアの発行元は、コードの作成後、ハッシュアルゴリズムを使用して、メッセージダイジェスト (MD) を生成します。
  2. メッセージ ダイジェストを、ソフトウェアの発行元の秘密キーを使用して暗号化します。これがデジタル署名です。
  3. ユーザーは、コードとともに、デジタル署名もダウンロードします。
  4. ユーザーは、発行元から送信されたコードをハッシュし、メッセージ ダイジェストを生成します。
  5. ユーザーは、発行元の公開キーでデジタル署名を復号し、メッセージ ダイジェストを取り出します。
  6. ユーザーは、4 でハッシュした結果と、5 で復号したメッセージダイジェストを比較し、同じであれば、送信時に改ざんされていないことが保証されます。

図 3-5: デジタル署名を利用したソフトウェアの送信

図 3-5: デジタル署名を利用したソフトウェアの送信

デジタル署名では、ユーザーが取得した、「発行元の公開キーが正当なものである」ということが前提になっています。公開キーが改ざんされた場合には、デジタル署名は意味を持ちません。そこで、公開キーの正当性を確保するために「デジタル証明書」を使用します。デジタル証明書はインターネットにおける電子的な身分証明書で、証明機関 (CA: Certification Authority) により発行されます。デジタル証明書には発行元の「公開キー」が含まれているため、送信先のユーザーに提示すれば、自分の公開キーを安全に送信することができます。

Authenticode 証明書とは

Windows では、デジタル証明書を利用したコードへの署名の手法として、「Authenticode」といわれる技術を提供しています。Authenticode で使用される証明書のことを「Authenticode 証明書」といいます。以下に、Authenticode 証明書がどのように使用されているのかを示します。

  1. ソフトウェアの発行元は、証明機関 (CA) に「Authenticode証明書」を要求します。証明機関の審査を通過すると、証明書を取得することができます。Authenticode 証明書は、複数のベンダーから入手可能です。取得するためには、一定の条件が必要となります。
  2. ユーザーがソフトウェアのダウンロードを要求した際に、コードとともに発行元の「Authenticode 証明書」も一緒に送信します。
  3. ユーザーは証明書の中から、公開キーを取り出します。

これにより、図 3-5 の手順 5 で使用する公開キーを取得したことになるため、受け取ったデジタル署名を復号することができます。

図 3-6: 証明書を利用した公開キーの送信

図 3-6: 証明書を利用した公開キーの送信

Note: 証明機関 (CA: Certification Authority)

証明書を発行する証明機関は、ユーザーのコンピューター上に「信頼する証明機関」として登録されている必要があります。ユーザーが信頼する証明機関は、Internet Explorer で [ツール] メニューから [インターネットオプション] を選択し、「コンテンツ」タブから「証明書」ボタンをクリックして確認することができます。この画面で、信頼する証明機関を追加することもできます。

図 3-7: 信頼された証明機関

図 3-7: 信頼された証明機関

Authenticode の利用場面

Windows XP までは、インターネット サイトから取得した Active X コントロールや Java アプレットなどのダウンロード パッケージや実行可能ファイル、およびドライバーをインストールする際に、デジタル署名をチェックし、ユーザーが信頼していない発行元のソフトウェアには、警告を表示することでインストールを阻止することができました。

Windows Vista や Windows 7 ではこれに加えて、いくつかの新機能がデジタル署名と連動しているため、デジタル署名の使用が義務付けられているコードが増えています。対象となるソフトウェアは以下の通りです。

  • Internet Explorer を使用してダウンロード、インストールされるパッケージや自己解凍形式の実行可能ファイルは、実行・インストールするためにデジタル署名が必要です。
  • 未署名のカーネル モード コンポーネントをインストールするには、管理者特権が必要です。これには、デバイス ドライバー、フィルタ ドライバー、サービスなどが含まれます。
  • ハードウェア関連のドライバーは、Windows ロゴ プログラムを取得するためにデジタル署名が必要です。
  • Windows Vista や Windows 7 の 64 ビットバージョンでは、署名済みのドライバーが必要です。
  • 起動時に読み込まれるドライバーのバイナリには、埋め込み署名を含める必要があります。
  • カーネルモードのドライバーには、WHQL や DRS プログラムを通じて入手する Microsoft による署名が必要です。
Note: WHQL (Windows Hardware Quality Labs) とは

コンピューターや周辺機器などのハードウェアやドライバーが、Windows 対応製品としてふさわしいかどうかをテストする組織です。WHQL で認定されると、Windows 対応ロゴを取得することができます。

Note: DRS (Driver Reliability Signature) とは

Windows Vista から導入されているプログラムで、デバイスのロゴを取得するためのベースとなるテストを提供します。DRS に合格すると、Microsoft からデジタル署名ファイルを入手することができます。

Authenticode 証明書は、バージョンに依存しないので、Windows XP で利用していたものが使えます。また、証明書には有効期限がありますが、有効期限内であれば何度でも利用することができます。つまり、1 つの証明書で複数のソフトウェアを署名することができます。

他の機能との連動

Windows Vista や Windows 7 では、以下の新機能がデジタル署名と連動しています。

  • 添付ファイル実行サービス (AES)

    AES (Attachment Execution Service) は Windows XP SP 2 以降でサポートされている機能です。メールに添付された圧縮ファイル (.zip や .lzh) に含まれる .exe や .com の実行をブロックすることができます。

  • ユーザーアカウント制御 (UAC)

    権限昇格ダイアログが表示される際に、発行元の情報を表示することができます。UAC に関しては、 「4.3 ユーザーアカウント制御 (UAC: User Account Control)」を参照してください。

  • Internet Explorer 8

    既定では未署名の Active X コントロールのインストールは制限されています。

ソフトウェアへのデジタル署名

デジタル署名の方法

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

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

オプション説明
-r証明書が自己署名されていることを指定します。つまり、これによりルート証明書が作成されます。
-pe証明書に関連する秘密キーのエクスポートを可能とみなします。
-ss TestCertStoreNameテスト証明書を保持する証明書ストアの名前を指定します。
-n "CN=CertName"証明書を特定する際に、コマンド ライン署名ツールで使用できる証明書の名前を指定します。テスト証明書として明確に特定できる証明書名を使用することをお勧めします。
CertFilename.cerテスト証明書のコピーを含むファイル名を指定します。証明書ファイルは、信頼されたルート証明機関および信頼された発行元の証明書ストアに証明書を追加する際に使用します。

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

Note:

ソフトウェアをテストするコンピューターでは、対応する MakeCert テスト証明書をそのコンピューターの信頼されたルート証明機関の証明書ストアと、信頼された発行元の証明書ストアにインストールする必要があります。発行元が信頼されていないと、インストールの際に、信頼されていないことを通知する、図 3-8 のようなダイアログが表示されます。

図 3-8: 不明な発行元を告げるダイアログボックス

図 3-8: 不明な発行元を告げるダイアログ ボックス

あらかじめ、MakeCert テスト証明書をそのコンピューターの信頼されたルート証明機関の証明書ストアなどにインストールしておくと、ソフトウェアパッケージは、署名付きとして扱われるため、図 3-9 のようなダイアログボックスが表示されます。

図 3-9: 発行者の確認

図 3-9: 発行者の確認

証明書をインストールするためには、Internet Explorer で [ツール] メニューから、[インターネットオプション] を選択し、「コンテンツ」タブから「証明書」ボタンを選択します。

遅延署名

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

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

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

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

図 3-10: [署名] タブ

図 3-10: [署名] タブ

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

sn.exe -Vr Application.dll

オプション説明
-Vr アセンブリ名署名の検査をスキップするアセンブリ名を指定します。
Note:

このオプションは、開発時にのみ設定します。署名の検証を省略したままにしておくと、悪意のあるアセンブリによって、偽装される可能性があります。解除方法は、後述します。

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

sn.exe –R Application.dll

オプション説明
-R アセンブリ名遅延署名を有効にしたアセンブリに、デジタル署名を追加します。

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

sn.exe -Vu Application.dll

オプション説明
-Vr アセンブリ名署名検査のスキップを解除します。

ページのトップへ


3.5 x64 バージョンのサポート

Windows Vista や Windows 7 では、AMD や Intel の 64 ビットアーキテクチャプロセッサを完全にサポートしています。64 ビット版 Windows 7 では、64 ビットのネイティブコードのほか、WoW64 (Windows on Windows 64) サブシステムにより 32 ビットアプリケーションの動作環境が提供されます。

サポートされないソフトウェア

以下のソフトウェアは WoW64 上で実行することはできません。

  • 16 ビットの実行可能プログラムやインストーラ
  • 32 ビットのカーネルモード ドライバー
  • 64 ビットのデジタル署名のないドライバー

これらの問題点に対する回避策はないため、以下の方法で対処します。

  • 16 ビットの実行可能プログラムはすべて削除し、32 または 64 ビットの同等のプログラムに置き換える。
  • 16 ビットのインストーラを 32 または 64 ビットのインストーラに変換する。
  • アプリケーションでカーネルモードのドライバーを使用する場合、64 ビットのドライバーを用意する。
  • すべての 64 ビット ドライバーにデジタル署名する。

ファイル リダイレクションとレジストリ リダイレクション

WoW64 は、32 ビットアプリケーションと、64 ビット カーネルを仲介します。そして、Windows Vista や Windows 7 では互換性のために 32 ビット用と 64 ビット用の 2 つのシステムファイルが用意されていますが、32 ビットのアプリケーションからのアクセスの場合には、32 ビット用のシステムディレクトリに自動的に切り替えられるようになっています。このファイルリダイレクション機能は、WoW64 により提供されます。

同様に、ソフトウェア用のレジストリも 32 ビット用と 64 ビット用が用意されていて、WoW64 のレジストリリダイレクション機能により自動的にリダイレクトされます。

64 ビットバージョンのアプリケーションの作成

.NET Framework 1.0 や 1.1 で作成されたアプリケーションは、すべて 32 ビットアプリケーションとして作成されます。一方、.NET Framework 2.0 以降では、32 ビットに加え、64 ビットのアプリケーションも作成できるようになっています。どのタイプのアプリケーションを作成するかは、コンパイラのオプションにより設定できます。以下に主要な言語での設定方法を紹介します。

言語設定方法
Visual Basic

Visual Studio 2008 でプロジェクトのプロパティを開き、[コンパイル] タブから「詳細コンパイルオプション」ボタンをクリックし、「ビルドの詳細設定」ダイアログボックスから「ターゲットCPU」を指定します。各オプションは以下の通りです。

  • AnyCPU

    任意のプラットフォームで実行するアセンブリをコンパイルします。

  • x86

    32ビットの CLR 上で実行するアセンブリをコンパイルします。

  • x64

    64ビットの CLR 上で実行するアセンブリをコンパイルします。

  • Itanium

    Itanium プロセッサ搭載コンピューター上の 64 ビットCLR 上で実行するアセンブリをコンパイルします。(このオプションは、Visual Studio Team System でのみサポートされます)

C#Visual Studio 2008 でプロジェクトのプロパティを開き、[ビルド] タブから「プラットフォーム ターゲット」を選択します。設定できるオプションは Visual Basic と同じです。
C++Visual Studio 2008 でプロジェクトのプロパティを開き、[構成]-[全般] を選択し、「共通言語ランタイムサポート」で「安全な MSIL 共通言語ランタイム サポート (/clr:safe)」を選択します。これにより、任意のプラットフォームで実行するアセンブリをコンパイルします。
ネイティブ 64 ビットアプリケーションを作成する方法は、Microsoft の Web サイト 「Visual C++ による 64 ビット プログラミング」を参照してください。


ページのトップへ

評価してください: