プログラムを64ビットシステムに移植する7つの手順

注釈

この記事では、32ビットWindowsアプリケーションを64ビットWindowsシステムに正しく移植するための主な手順について説明します。 この記事はVisual Studio 2005/2008環境でC / C ++を使用する開発者を対象としていますが、アプリケーションを64ビットシステムに移行することを計画している他の開発者にも役立ちます。

はじめに

この記事では、32ビットプログラムを64ビットシステムに移行することを計画している開発者が直面する主なポイントについて説明します。 もちろん、対処された問題のリストは完全ではありませんが、時間が経つにつれて、この記事の拡張版が提供されることを願っています。 著者は、この記事の情報内容を改善するレビュー、コメント、質問に感謝します。

1.ステップ1。 64ビットは異なります。

それを把握しましょう

コンピュータアーキテクチャのフレームワーク内で、「 64ビット 」という用語は、64ビットの整数と、サイズが64ビットのその他の種類のデータを指します。 「64ビット」システムは、64ビットマイクロプロセッサアーキテクチャ（EM64T、IA-64など）または64ビットオペレーティングシステム（Windows XP Professional x64 Editionなど）として理解できます[ 1 ]。

AMD64（別名x86-64、Intel 64、EM64T、x64）は64ビットマイクロプロセッサアーキテクチャであり、AMDが開発した対応する命令セットです[ 2 ]。 この命令セットは、EM64T（Intel64）という名前でIntelによってライセンスされています。 AMD64アーキテクチャは、完全な下位互換性を備えたx86アーキテクチャの拡張です。 アーキテクチャは、パーソナルコンピュータおよびワークステーションのベースとして広く普及しています。

IA-64は、IntelとHewlett Packardが共同開発した64ビットマイクロプロセッサアーキテクチャです[ 3 ]。 ItaniumおよびItanium 2マイクロプロセッサに実装されています[ 4 ]。 このアーキテクチャは、主にマルチプロセッササーバーとクラスターシステムで使用されます。

AMD64とIA-64は、互いに互換性のない2つの異なる64ビットアーキテクチャです。 したがって、開発者は、これらのアーキテクチャの両方をサポートするか、1つだけをサポートするかを直ちに決定する必要があります。 ほとんどの場合、クラスターシステム用の高度に専門化されたソフトウェアを開発しない場合、または高性能DBMSを実装しない場合、高い確率で、IA-64よりはるかに普及しているAMD64アーキテクチャのみのサポートを実装する必要があります。 これは、AMD64アーキテクチャでほぼ100％占有されているパソコン市場のソフトウェアに特に当てはまります。

この記事の残りの部分では、AMD64アーキテクチャー（EM64T、x64）についてのみ説明します。AMD64の使用は、アプリケーションソフトウェア開発者に最も関連性があるためです。

異なるアーキテクチャについて言えば、「 データモデル 」の概念に言及する必要があります。 データモデルは、開発環境内で採用されている型のディメンションの比率として理解される必要があります。 1つのオペレーティングシステムに対して、異なるデータモデルに準拠したいくつかの開発ツールが存在する場合があります。 ただし、通常は、最も適切なハードウェアおよびソフトウェア環境という1つのモデルのみが優先されます。 例は、 LLP64がネイティブデータモデルである64ビットWindowsオペレーティングシステムです。 ただし、互換性のために、64ビットWindowsシステムは、 ILP32LLデータモデルモードで動作する32ビットプログラムの実行をサポートしています。 表N1は、主要なデータモデルに関する情報を提供します。



表N1。 データモデル



プログラムコードでは使用データのビット深度を考慮する必要があるため、使用データモデルは64ビットアプリケーションの開発プロセスにその足跡を残します[ 5 ]。

2.ステップ2。 製品の64ビットバージョンが必要かどうかを調べる

64ビットシステムの開発は、「64ビットシステム用にプロジェクトを再構築する必要がありますか？」という質問から始める必要があります。 この質問には答えなければなりませんが、急いで考えてはいけません。 一方では、タイムリーに64ビットソリューションを提供することなく、競合他社に遅れをとることができます。 一方、64ビットアプリケーションでは時間を浪費する可能性があり、競争上の優位性は得られません。

選択を支援する主な要因をリストします。

2.1。 アプリケーションのライフサイクル

短いライフサイクルでアプリケーションの64ビットバージョンを作成しないでください。 WOW64サブシステムのおかげで、古い32ビットアプリケーションは64ビットWindowsシステムで非常によく機能するため、64ビットプログラムを作成しても意味がありません。これは2年後にサポートされなくなります[ 6 ]。 さらに、実際には、Windowsの64ビットバージョンへの移行が遅れており、ほとんどのユーザーが短期的にはソフトウェアソリューションの32ビットバージョンのみを使用する可能性があります。

ソフトウェア製品の長期にわたる開発と長期的なサポートを計画している場合は、ソリューションの64ビットバージョンで作業を開始する必要があります。 これはゆっくりと行うことができますが、本格的な64ビットバージョンがない場合は、64ビットバージョンのWindowsにインストールされたこのようなアプリケーションのサポートでより多くの問題が発生する可能性があることに注意してください。

2.2。 アプリケーションリソースの強度

64ビットシステム用にプログラムを再コンパイルすると、膨大な量のRAMを使用できるようになり、作業が5〜15％速くなります。 64ビットプロセッサのアーキテクチャ機能、たとえばより多くのレジスタの使用により、5〜10％の高速化が行われます。 別の1％から5％の速度の向上は、32ビットアプリケーションと64ビットオペレーティングシステムの間でAPI呼び出しを変換するWOW64レイヤーがないためです。

プログラムが大量のデータ（2GBを超える）で動作せず、その速度が重要でない場合、近い将来の64ビットシステムへの移行はそれほど重要ではありません。

ところで、単純な32ビットアプリケーションでも、64ビット環境での起動を利用できます。 / LARGEADDRESSAWARE：YESスイッチでコンパイルされたプログラムは、32ビットWindowsオペレーティングシステムが/ 3gbスイッチで実行されている場合、最大3ギガバイトのメモリを割り当てることができることをご存知でしょう。 64ビットシステムで実行される同じ32ビットプログラムは、ほぼ4 GBのメモリ（実際には約3.5 GB）を割り当てることができます。

2.3。 ライブラリ開発

ライブラリ、コンポーネント、またはサードパーティの開発者がソフトウェアを作成するその他の要素を開発している場合、製品の64ビットバージョンをすばやく作成する必要があります。 そうしないと、64ビットバージョンのリリースに関心のある顧客は、代替ソリューションを探すことを余儀なくされます。 たとえば、ハードウェアおよびソフトウェア保護の開発者の中には、64ビットプログラムの出現に長い遅延で応答したため、多くのクライアントがプログラムを保護するために他のツールを探す必要がありました。

ライブラリの64ビットバージョンのリリースの追加の利点は、個別の製品として販売できることです。 したがって、32ビットアプリケーションと64ビットアプリケーションの両方を作成する顧客は、2つの異なるライセンスを購入する必要があります。 たとえば、Spatial Corporationはこのポリシーを使用して、Spatial ACISライブラリを販売しています。

2.4。 サードパーティライブラリへの製品の依存関係

製品の64ビットバージョンを作成する作業を計画する前に、使用するライブラリとコンポーネントの64ビットバージョンがあるかどうかを確認してください。 また、64ビットバージョンのライブラリの価格設定ポリシーを確認してください。 これらはすべて、ライブラリの開発者向けサイトにアクセスして確認できます。 サポートが利用できない場合は、64ビットシステムをサポートする代替ソリューションを事前に探してください。

2.5。 16ビットアプリケーションの存在

ソリューションに16ビットモジュールがまだある場合は、それらを削除します。 64ビットバージョンのWindowsでの16ビットアプリケーションの操作はサポートされていません。

ここでは、16ビットインストーラーの使用に関する1つのポイントを明確にする必要があります。 一部の32ビットアプリケーションのインストールには引き続き使用されます。 最も人気のある多くの16ビットインストーラーを新しいバージョンに即座に置き換える特別なメカニズムが作成されました。 これは、16ビットプログラムが64ビット環境でも動作するという誤解を招く可能性があります。 覚えておいて、これはそうではありません。

2.6。 アセンブリコードの可用性

大量のアセンブラコードを使用すると、64ビットバージョンのアプリケーションを作成するコストが大幅に増加する可能性があることを忘れないでください。

上記のすべての事実、長所と短所を検討した後、プロジェクトを64ビットシステムに転送するかどうかを決定します。 もしそうなら、次に進みましょう。

3. 3番目のステップ。 ツールキット

製品の64ビットバージョンを開発することに決め、時間を費やす準備ができている場合、これは成功を保証するものではありません。 実際には、必要なすべてのツールを用意する必要があり、不快なインシデントが発生する可能性があります。

最も単純な、しかし最も乗り越えられない問題は、64ビットコンパイラの欠如かもしれません。 この記事は2009年に作成されましたが、64ビットCodegear C ++ Builderコンパイラーはまだありません[ 7 ]。 そのリリースは今年の終わりまでに予定されています。 もちろん、そうでない限り、同様の問題を回避することはできませんが、たとえばVisual Studioを使用してプロジェクト全体を書き直してください。 しかし、64ビットコンパイラーがないことですべてが明らかになると、他の同様の問題がより秘密になり、プロジェクトを新しいアーキテクチャに移行する作業の段階で既に抜け出す可能性があります。 したがって、製品の64ビットバージョンを実装するために必要なすべてのコンポーネントがあるかどうかを事前に調査することをお勧めします。 不快な驚きがあなたを待っています。

もちろん、ここでプロジェクトに必要な可能性のあるものすべてをリストすることはできませんが、それでもあなたがあなたの方位をつかむのに役立つリストを提供し、おそらくあなたの64ビットプロジェクトの実装に必要な他のポイントを覚えています：

3.1。 64ビットコンパイラの存在

64ビットコンパイラを持つことの重要性について他のことを言うのは困難です。 それだけである必要があります。

最新バージョン（執筆時点）のVisual Studio 2008を使用して64ビットアプリケーションを開発する場合、次の表N2が必要なVisual Studioのエディションを判断するのに役立ちます。



表N2。 Visual Studio 2008のさまざまなエディションの機能

3.2。 64ビットオペレーティングシステムを実行している64ビットコンピューターの存在

確かに仮想マシンを使用して32ビットテクノロジで64ビットアプリケーションを実行できますが、これは非常に不便であり、必要なレベルのテストテストを提供しません。 少なくとも4〜8ギガバイトのRAMがマシンにインストールされていることが望ましいです。

3.3。 使用されているすべてのライブラリの64ビットバリアントの可用性

ライブラリがソースコードで提示されている場合、64ビットプロジェクト構成が存在する必要があります。 ライブラリを個別にアップグレードして64ビットシステム用にビルドすることは、恩恵のない困難な作業である可能性があり、結果は信頼性が低く、エラーが含まれることがあります。 また、これらのライセンス契約に違反する可能性があります。 バイナリモジュールの形式でライブラリを使用する場合は、64ビットモジュールが存在するかどうかも確認する必要があります。 64ビットアプリケーション内で32ビットDLLを使用することはできません。 COMを介して特別なバインディングを作成できますが、これは別の大規模で複雑なタスク[ 8 ]になります。 また、ライブラリの64ビットバージョンを取得すると追加の費用がかかる可能性があることに注意してください。

3.4。 インラインアセンブラコードの欠如

Visual C ++は、64ビットのインラインアセンブラをサポートしていません。 外部の64ビットアセンブラー（MASMなど）を使用するか、C / C ++ [ 9 ]で同じ機能を実装する必要があります。

3.5。 テスト方法の近代化

テスト方法の大幅な改訂、単体テストの近代化、新しいツールの使用。 これについては以下で詳しく説明しますが、アプリケーションを新しいシステムに移行するのにかかる時間を評価する際には、これを考慮することを忘れないでください[ 10 ]。

3.6。 テスト用の新しいデータ

大量のRAMを消費するリソース集約型アプリケーションを開発している場合は、テスト入力データのデータベースを補充する必要があります。 64ビットアプリケーションの負荷テストでは、4ギガバイトのメモリ消費を超えることが望ましいです。 多くのエラーは、このような状況でのみ発生します。

3.7。 64ビットセキュリティシステムの存在

使用する保護システムは、必要な範囲で64ビットシステムをサポートする必要があります。 たとえば、アラジンはHaspハードウェアキーをサポートする64ビットドライバーを迅速にリリースしました。 しかし、非常に長い間、64ビットバイナリファイル（Hasp Envelopプログラム）を自動的に保護するシステムはありませんでした。 したがって、保護メカニズムはプログラムコード内で独立して実装する必要があり、これはスキルと時間を必要とする追加の困難なタスクでした。 セキュリティ、更新システムなどに関連するこのような瞬間を忘れないでください。

3.8。 インストーラー

64ビットアプリケーションを完全にインストールできる新しいインストーラーが必要です。 ここで、私はすぐに1つの伝統的な間違いについて警告したいと思います。 これは、32/64ビットソフトウェア製品をインストールするための64ビットインストーラーの作成です。 開発者は、アプリケーションの64ビットバージョンを準備する際に、「64ビット」を絶対的なものにしたいと考えることがよくあります。 また、64ビットインストーラーを作成しますが、32ビットオペレーティングシステムのユーザーにとっては、このようなインストールパッケージは単に起動しません。 ディストリビューションに含まれている非32ビットアプリケーションと64ビットアプリケーション、つまりインストーラー自体は起動しないことに注意してください。 実際、ディストリビューションが64ビットアプリケーションである場合、もちろん32ビットオペレーティングシステムでは起動しません。 これに関する最も厄介なことは、ユーザーが何が起こっているのか推測できないことです。 実行できないインストールパッケージのみが表示されます。

4. 4番目のステップ。 Visual Studio 2005/2008でプロジェクトをセットアップする

Visual Studio 2005/2008で64ビットプロジェクト構成を作成するのは非常に簡単です。 新しい構成を構築し、その構成のエラーを検索する段階で、問題が発生します。 64ビット構成を作成するには、次の4つの手順を実行するだけで十分です。

図N1に示すように、構成マネージャーを起動します。



図1.構成マネージャーの起動





構成マネージャーで、新しいプラットフォームのサポートを選択します（図N2）：



図2.新しい構成の作成





64ビットプラットフォーム（x64）を選択し、ベースとして32ビットバージョンから設定を選択します（図N3）。 ビルドモードに影響するこれらの設定は、Visual Studioによって自動的に調整されます。



図3. x64をプラットフォームとして選択し、Win32構成を基盤として





新しい構成の追加が完了し、64ビット構成オプションを選択して、64ビットアプリケーションのコンパイルに進むことができます。 アセンブリの64ビット構成の選択を図N4に示します。



図4. 32ビットおよび64ビット構成が利用可能になりました。





運がよければ、64ビットプロジェクトの追加構成を行う必要はありません。 ただし、これはプロジェクト、その複雑さ、および使用するライブラリの数に大きく依存します。 すぐに変更する価値があるのは、スタックのサイズだけです。 プロジェクトでデフォルトのサイズスタック、つまり1メガバイトを使用している場合、64ビットバージョンのサイズを2メガバイトに設定することは理にかなっています。 これは必須ではありませんが、事前に自分で保険をかける方が良いです。 デフォルトのサイズとは異なるスタックサイズを使用する場合は、64ビットバージョン用に2倍大きくするのが理にかなっています。 これを行うには、プロジェクト設定で、Stack Reserve SizeおよびStack Commit Sizeパラメーターを見つけて変更します。

5.ステップ5。 アプリケーションのコンパイル

64ビット構成のコンパイルフェーズで発生する一般的な問題についてお話しできたらうれしいです。 サードパーティライブラリでどのような問題が発生するかを考慮し、WINInAPI関数に関連付けられたコード内のコンパイラーではポインターをLONG型に配置できなくなり、コードをアップグレードしてLONG_PTG型を使用する必要があることを伝えます。 そして、はるかに。 残念ながら、非常に多くのエラーがあり、1つの記事またはおそらく本でこれを述べる方法はありません。 コンパイラーが出すすべてのエラーと、以前は存在しなかった新しい警告を調べ、それぞれの場合にコードをアップグレードする方法を見つけ出す必要があります。

64ビットアプリケーションの開発専用のリソースへのリンクのコレクションにより、部分的に作業が楽になります： http : //www.viva64.com/links/64-bit-development/ コレクションは絶えず更新されており、著者は、彼らの意見では注目に値するリソースへのリンクを送ってくれた読者に感謝します。

アプリケーションを移行するときに開発者が関心を持つ可能性のあるタイプのみを検討しましょう。 これらのタイプを表N3に示します。 ほとんどのコンパイルエラーは、これらのタイプの使用に関連付けられます。

種類	プラットフォームタイプx32 / x64	ご注意
int	32/32	基本タイプ。 64ビットシステムでは、32ビットのままでした。
長い	32/32	基本タイプ。 64ビットWindowsシステムでは、32ビットのままでした。 64ビットLinuxシステムでは、このタイプは64ビットに拡張されていることに注意してください。 WindowsおよびLinuxシステム用にコンパイルして動作するコードを開発している場合は、忘れないでください。
size_t	32/64	基本的な符号なしタイプ。 型のサイズは、理論的に可能な配列の最大サイズを書き込むことができるように選択されます。 ポインターは安全にsize_tに配置できます（クラス関数へのポインターは例外ですが、これは特別な場合です）。
ptrdiff_t	32/64	これは、size_t型に似ていますが、重要です。 1つのポインターが他のポインター（ptr1-ptr2）から減算される式の結果は、ptrdiff_t型になります。
ポインタ	32/64	ポインターのサイズは、プラットフォームのビット深度に直接依存します。 ガイドを他のタイプに変換するときは注意してください。
__int64	64/64	符号付き64ビット型。
DWORD	32/32	32ビット符号なし型。 WinDef.hで宣言：typedef unsigned long DWORD;
DWORDLONG	64/64	64ビットの符号なし型。 WinNT.hで宣言：typedef ULONGLONG DWORDLONG;
DWORD_PTR	32/64	ポインターを配置する符号なしタイプ。 BaseTsd.hで次のように宣言されています：typedef ULONG_PTR DWORD_PTR;
DWORD32	32/32	32ビット符号なし型。 BaseTsd.hで次のように宣言されています：typedef unsigned int DWORD32;
DWORD64	64/64	64ビットの符号なし型。 BaseTsd.hで次のように宣言されています：typedef unsigned __int64 DWORD64;
HALF_PTR	16/32	ハーフポインター。 Basetsd.hで次のように宣言：#ifdef _WIN64 typedef int HALF_PTR; #else typedef short HALF_PTR; #endif
INT_PTR	32/64	ポインターを配置できる文字タイプ。 BaseTsd.hで次のように宣言されています：#if defined（_WIN64）typedef __int64 INT_PTR; #else typedef int INT_PTR; #endif
長い	32/32	32ビットのままの符号付きタイプ。 したがって、多くの場合、LONG_PTRを使用する必要があります。 WinNT.hで宣言：typedef long LONG;
LONG_PTR	32/64	ポインターを配置できる文字タイプ。 BaseTsd.hで次のように宣言されています：#if defined（_WIN64）typedef __int64 LONG_PTR; #else typedef long LONG_PTR; #endif
LPARAM	32/64	メッセージを送信するためのパラメーター。 WinNT.hで宣言：typedef LONG_PTR LPARAM;
SIZE_T	32/64	size_t型の類似物。 BaseTsd.hで次のように宣言されています：typedef ULONG_PTR SIZE_T;
SSIZE_T	32/64	タイプptrdiff_tの類似物。 BaseTsd.hで次のように宣言されています：typedef LONG_PTR SSIZE_T;
ULONG_PTR	32/64	ポインターを配置する符号なしタイプ。 BaseTsd.hで次のように宣言：#if defined（_WIN64）typedef unsigned __int64 ULONG_PTR; #else typedef unsigned long ULONG_PTR; #endif
WORD	16/16	符号なし16ビット型。 WinDef.hで次のように宣言されています：typedef unsigned short WORD;
WPARAM	32/64	メッセージを送信するためのパラメーター。 WinDef.hで宣言：typedef UINT_PTR WPARAM;

表N3。 32ビットプログラムを64ビットWindowsシステムに移植する場合の対象のタイプ。

6.隠れたエラーの診断

すべてのコンパイルエラーを修正した後、待望の64ビットアプリケーションを受け取ると思う場合は、がっかりする必要があります。 一番難しいもの。 コンパイル段階で、コンパイラが検出できる最も明白なエラーを修正します。これは主に、暗黙的な型変換の不可能性に関連しています。 しかし、これは氷山の一角です。 ほとんどのエラーは隠されています。 抽象C ++言語の観点から見ると、これらのエラーは安全に見えるか、明示的な型変換によってマスクされています。 このようなエラーは、コンパイル段階で特定されたエラーの数の数倍あります。

/ Wp64スイッチは期待されるべきではありません。 このキーは、多くの場合、64ビットエラーを見つけるためのすばらしいツールとして提示されます。 実際、/ Wp64スイッチは、32ビットコードをコンパイルするときに、コードの特定の部分が64ビットモードで正しくないという警告をコンパイルする機会を与えるだけです。 64ビットコードをコンパイルする場合、これらの警告はどのような場合でもコンパイラーによって発行されます。 したがって、64ビットアプリケーションをコンパイルする場合、/ Wp64スイッチは無視されます。 さらに、このキーは隠れたエラーの検索には役立ちません[ 11 ]。

隠れたエラーの例をいくつか見てみましょう。

6.1。 明示的なキャスト

エラーのクラスは最も簡単ではありますが、検出が最も簡単ではありませんが、重要なビットが切り捨てられる明示的な型変換に関連付けられています。

一般的な例は、SendMessageなどの関数に渡すときに32ビット型へのポインターをキャストすることです。

MyObj * pObj = ... :: SendMessage（hwnd、msg、（WORD）x、（DWORD）pObj）;

ここでは、明示的な型変換を使用して、ポインターを数値型に変換しています。 32ビットアーキテクチャの場合、SendMessage関数の最後のパラメーターはLPARAMタイプであり、32ビットアーキテクチャではDWORDと同じであるため、この例は正しいです。 64ビットアーキテクチャでは、DWORDの使用に誤りがあり、LPARAMに置き換える必要があります。 LPARAMタイプは、アーキテクチャに応じて32ビットまたは64ビットです。

これは単純なケースですが、多くの場合、型キャストはよりエレガントに見え、コンパイラの警告を使用して、またはプログラムテキストを検索して検出することは不可能です。 明示的な型変換は、型キャストが正しいことをコンパイラーに伝えるように正確に設計されており、プログラマーがコードのセキュリティを担当したため、コンパイラーの診断を抑制します。 明示的な検索も役に立ちません。 型は標準名（typedefを介してプログラマーによって定義される）ではない場合があり、明示的な型変換を実装する多くの方法があります。 このようなエラーを確実に診断するには、 Viva64やPC-Lintアナライザーなどの特別なツールのみを使用する必要があります。

6.2。 暗黙的なキャスト

次の例はすでに暗黙的な型変換に関連付けられており、重要なビットも失われます。 fread関数のコードはファイルから読み取りますが、64ビットシステムで2ギガバイトを超えるデータを読み取ろうとすると正しくありません。

size_t __fread（void * __restrict buf、size_t size、 size_t count、FILE * __restrict fp）; size_t fread（void * __restrict buf、size_t size、size_t count、 ファイル* __restrict fp） { int ret; FLOCKFILE（fp）; ret = __fread（buf、size、count、fp）; FUNLOCKFILE（fp）; return（ret）; }

__fread関数はsize_t型を返しますが、int型は読み取られたバイト数を格納するために使用されます。 その結果、大量の読み取りデータでは、実際に読み取られるバイト数が誤って返される場合があります。

これは初心者向けの非識字コードであり、そのような型変換はコンパイラによって報告され、一般にそのようなコードは簡単に見つけて修正できると言うことができます。 これは理論的にはです。 しかし、実際の大規模プロジェクトでは、状況は異なる場合があります。 この例は、FreeBSDのソースコードから引用したものです。 エラーは2008年12月にのみ修正されました！ これは、FreeBSDの最初の（実験的）64ビットバージョンが2003年6月にリリースされたという事実にもかかわらずです。

修正前のソースコードは次のとおりです。

http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/libc/stdio/fread.c?rev=1.14

そして、ここに修正版があります（2008年12月）：

http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/libc/stdio/fread.c?rev=1.15

6.3。 ビット、シフトを操作する

個々のビットで動作するコードを間違えるのは簡単です。 次のタイプのエラーは、シフト操作に関連しています。 例を考えてみましょう：

ptrdiff_t SetBitN（ptrdiff_t値、符号なしbitNum）{ ptrdiff_t mask = 1 << bitNum; 戻り値| マスク; }

上記のコードは32ビットアーキテクチャで動作し、ユニットごとに0〜31の数字でビットを設定できます。 プログラムを64ビットプラットフォームに転送した後、0〜63のビットを設定する必要があります。しかし、このコードは32〜63のビットを設定しません。 「1」はint型であり、図5に示すように32桁シフトするとオーバーフローが発生することに注意してください。コンパイラの実装に応じて0（図5-B）または1（図5-C）の結果が得られます。



図5. A-32ビットコードの31番目のビットの正しい設定。 B、C-64ビットシステムでの32ビットの設定エラー（2つの動作）



コードを修正するには、マスク変数と同じ型の定数「1」を作成する必要があります。

ptrdiff_t mask = ptrdiff_t（1）<< bitNum;

また、修正されていないコードが別の興味深いエラーにつながることに注意してください。 64ビットシステムで31ビットを設定すると、関数の結果は値0xffffffff80000000になります（図6を参照）。 式1 << 31の結果は、負の数-2147483648です。 この数は、64ビット整数変数で0xffffffff80000000として表されます。



図6. 64ビットシステムで31ビット目を設定する際のエラー

6.4。 マジックナンバー

マジック定数、つまり、あるタイプまたは別のタイプのサイズを設定するために使用できる数値は、多くの問題を引き起こす可能性があります。 正しい解決策は、そのような目的でsizeof（）演算子を使用することですが、大きなプログラムでは古いコードが失われる可能性があり、ポインターのサイズは4バイトであり、size_t型は常に32ビットであると確信していました。 通常、このようなエラーは次のようになります。

size_t ArraySize = N * 4; size_t *配列=（size_t *）malloc（ArraySize）;

表N4に、64ビットプラットフォームに切り替える際に注意が必要な主要な数値を示します。



表N4。 アプリケーションを32ビットから64ビットプラットフォームに移植するときに危険な主な魔法の価値

6.5。 インデックスとして32ビット変数を使用する際のエラー

大量のデータを処理するプログラムでは、大きな配列のインデックス付けに関連するエラーが発生したり、永続的なサイクルが発生したりする場合があります。 次の例には、一度に2つのエラーが含まれています。

const size_t size = ...; char * array = ...; char * end = array + size; for（符号なしi = 0; i！=サイズ; ++ i） { const int one = 1; end [-i-one] = 0; }

最初のエラーは、処理されたデータのサイズが4ギガバイト（0xFFFFFFFF）を超えると、変数 'i'のタイプが 'unsigned'になり、値0xFFFFFFFFに到達しないため、永遠のサイクルが発生する可能性があることです。 発生は可能ですが、必ずしも発生するとは限りません。 コンパイラがどのコードをビルドするかによります。 たとえば、デバッグモードでは永遠のループが存在し、リリースコードではループが消えるので、コンパイラーはカウンターに64ビットレジスターを使用してコードを最適化することを決定し、ループは正しくなります。 これらはすべて混乱を招き、昨日機能していたコードは翌日突然機能しなくなる可能性があります。

2番目のエラーは、負のインデックス値が使用されている配列を最後から最初に渡すことに関連しています。 上記のコードは32ビットモードで動作しますが、ループの最初の反復で64ビットマシンで実行すると、アクセスが配列の境界を超えてしまい、プログラムがクラッシュします。 この動作の理由を考慮してください。



32ビットシステムでのC ++言語規則に従って、式「-i-one」は次のように計算されます（最初のステップi = 0）：

1. 式「-i」は符号なしタイプで、値は0x00000000uです。
2. 変数「one」は、タイプ「int」からタイプunsignedに展開され、0x00000001uになります。 注：int型は、2番目の引数が符号なしの型である操作に関係している場合、（C ++標準に従って）型 'unsigned'に展開されます。
3. 2つの符号なしの値が関与する減算演算が行われ、演算の結果は0x00000000u-0x00000001u = 0xFFFFFFFFuです。 結果は符号なしの型であることに注意してください。
4. 32ビットシステムでは、インデックス0xFFFFFFFFuの配列にアクセスすることは、インデックス-1を使用することと同等です。 つまり、終了[0xFFFFFFFFu]は終了[-1]に類似しています。 その結果、配列要素は正しく処理されます。

64ビットシステムでは、最後の段落で図が異なります。 署名されたptrdiff_tに署名されていないタイプの拡張が発生し、配列のインデックスは0x00000000FFFFFFFFFFi64になります。 その結果、配列のスコープを超えます。

コードを修正するには、ptrdiff_tやsize_tなどの型を使用する必要があります。

6.6。 使用する関数の種類の変更に関連するエラー

一般に、誰も責任を負わないという間違いがありますが、これは間違いではありません。 ずっと前に（Visual Studio 6.0の）遠方の銀河で、CWinAppからの継承であるCSampleAppクラスが存在するプロジェクトが開発されたことを想像してください。 基本クラスには、仮想WinHelp関数があります。 相続人はこの機能をオーバーラップし、必要なアクションを実行します。 視覚的には、これを図7に示します。



図7. Visual Studio 6.0で作成された実行可能な有効なコード





次に、プロジェクトはVisual Studio 2005に転送され、WinHelp関数のプロトタイプが変更されますが、32ビットモードではDWORD型とDWORD_PTR型が一致し、プログラムが引き続き正常に動作するため、誰も気づきません（図8）。



図8.正しくありませんが、実行可能な32ビットコード





このエラーは、DWORD型とDWORD_PTR型のサイズが異なる64ビットシステムでそれ自体を証明するのを待っています（図9）。 64ビットモードでは、クラスに2つの異なるWinHelp関数が含まれていますが、これは当然正しくありません。 このようなトラップは、一部の関数が引数のタイプを変更したMFCだけでなく、アプリケーションのコードとサードパーティライブラリでも非表示にできることに注意してください。



図9.エラーは64ビットコードで現れます

6.7。 隠れたエラー診断

このような64ビットエラーの例を引用して引用できます。 このようなエラーに興味があり、それらのエラーについて詳しく知りたい場合は、記事「C ++コードを64ビットプラットフォームに移植する20のtrap」[ 12 ]に興味があります。

ご覧のように、特に多くのエラーが不規則に、または大量の入力データにのみ表示されるため、隠れたエラーを検索する段階は簡単な作業ではありません。 静的コードアナライザーは、入力データや実際の状態でのセクションの実行頻度に関係なく、アプリケーションコード全体をチェックできるため、このようなエラーの診断に適しています。最初の段階でほとんどのエラーを見つけるために、アプリケーションを64ビットプラットフォームに移植する段階と、64ビットソリューションのさらなる開発の両方で、静的分析を使用することは理にかなっています。静的分析は、64ビットアーキテクチャに関連するエラーの特徴をよりよく理解し、より効率的なコードを記述するようにプログラマに警告し、教えます。この記事の著者は、Viva64 [ 13 ] と呼ばれるそのような特殊なコードアナライザーの開発者です。このツールをより詳しく理解し、会社のWebサイト「ソフトウェア検証システム」からデモバージョンをダウンロードできます。

公平に言うと、Gimpel PC-LintやParasoft C ++ Testなどのコードアナライザーでは、64ビットエラーを診断するための一連のルールがあります。ただし、第一に、これらは汎用アナライザーであり、それらの64ビットエラーを診断するためのルールはあまり表現されていません。第二に、オペレーティングシステムのLinuxファミリで使用されるLP64データモデルに重点を置いているため、LLP64データモデルが使用されているWindowsプログラムでの使用が削減されます[ 14 ]。

7.ステップ7。テストプロセスのアップグレード

前のセクションで説明したプログラムコードのエラーを検索する手順は、必要ですが不十分な手順です。静的コード分析を含む単一の方法では、すべてのエラーを完全に検出できるわけではなく、さまざまな手法を組み合わせて初めて最良の結果が得られます。

64ビットプログラムが32ビットバージョンよりも多くのデータを処理する場合、テストを拡張して、4ギガバイトを超える容量のデータ処理を含める必要があります。これは、多くの64ビットエラーが現れる境界線です。このようなテストには、1桁以上の時間がかかる可能性があるため、事前に準備する必要があります。通常、テストは、各テストで少数の要素を処理するように記述されているため、たとえば、すべての内部単体テストに合格できますか？数分で、自動化されたテスト（たとえば、AutomatedQA TestCompleteを使用して）数時間で。32ビットシステムの並べ替え関数は、100個の要素を並べ替える場合、100,000個の要素で正しく動作し、ほぼ完全に保証されます。ただし、50億要素を処理しようとすると、64ビットシステムで同じ機能が失敗する場合があります。単体テストの実行速度は数百万回低下する可能性があります。64ビットシステムをマスターする際に、テストを調整するコストを忘れずに決めてください。解決策の1つは、単体テストを高速テスト（少量のメモリで動作）とギガバイトを処理して夜間などに実行する低速テストに分割することです。リソースを集中的に使用する64ビットプログラムの自動テストは、分散コンピューティングに基づいて構築できます。