Vista 64 で書かれたコードは 32 ビット OS 上でも互換性がありますか?

StackOverflow https://stackoverflow.com/questions/30543

質問

新しい開発マシンを入手し、8GB RAM を活用するために Vista 64 Ultimate に移行しています。私たちのマネージャーは、コードを本番環境に移行するときに問題が発生しないことを確認するために、すべての開発を 32 ビット仮想マシンで行うことを望んでいます。

作成されたプログラムが 32 ビット OS で動作することを保証する方法はありますか?仮想マシンを使用するのは嫌いではありませんが、強制的に「シングル」モニター タイプのビューに戻されるのは好きではありません。私は VS ツールバーを他のモニターに移動するのが好きです。

編集：Visual Studio 2005 および 2008、VB.NET、および/または C# を使用しています。

編集：Harpreet の使用 答え, 、これらは、Visual Studio IDE を x86 / 32 ビットをコンパイルするように設定するために使用した手順です。

  1. 「ビルド」をクリックして構成マネージャーを開きます
  2. 「アクティブ ソリューション プラットフォーム」ドロップダウン リストを選択します
  3. x86 がリストにある場合は選択し、リストにない場合はステップ 5 に進みます。 <New...>
  4. [新しいソリューション プラットフォーム] ダイアログで、[x86] を選択し、[OK] を押します。
  5. すべてのプロジェクトで選択したプラットフォームが x86 であることを確認します。
  6. 「閉じる」をクリックします。

楽しむ。

ありがとうございます キース

役に立ちましたか？

解決

私は 32 ビット Windows 用の 64 ビット マシンで開発を行っています。問題じゃない。慎重に行うために、プロジェクトが x86 モードでコンパイルされるように設定されていることを確認する必要があります。ソリューション内の各プロジェクトを調べて、これを再確認してください。AnyCPU 設定を使用することもできますが、開発マシンでは 32 ビット マシンとは異なる動作をするため、少し危険です。もちろん、64 ビット モードは避けたいです。

私が遭遇した問題は、アプリが 64 ビット用にコンパイルされている場合 (明示的に 64 ビット、または AnyCPU が 64 ビット Windows 上でコンパイルされ実行されている場合) にドライバーが機能しないことです。これらの問題は、x86 コンパイルに固執することで完全に回避できます。これにより、開発マシン上のすべての欠陥が明らかになります。

理想的には、32 ビット マシン上で頻繁に実行できるビルドおよびテスト環境をセットアップできます。これにより、管理者は安心し、VM をデスクトップとして使用することを回避できるようになります。

他のヒント

実行可能ファイルを 32 ビットとしてコンパイルしている限り、32 ビットと 64 の Windows マシンの両方で実行可能です (保証されています)。64 の開発マシンを使用すると、64 ビットのコンパイルでコードのテストを開始できる (32 ビット整数にキャストされたポインターなどをチェックするため) という利点があり、これにより、将来の 64 ビットへの移行が容易になります (会社が選択した場合)。 64 ビット版を実行するには)。

64 ビット OS 用のコンパイルはコンパイラのオプションです。Vista 64 ビット内から 32 ビット exe にコンパイルすることは完全に可能です。アプリを実行すると、タスクマネージャーでプロセスの横に「*32」があることがわかります...これは 32 ビットであることを意味します ;)

あなたのマネージャーには、64 ビット OS が実際に何を意味するのかについてもう少し教育する必要があると思います :)

質問に対する答えではありませんが、問題の解決策になる可能性があります。VirtualBox (およびおそらく他のもの) は、2 番目のスタート バーを提供し、ウィンドウを自由にドラッグできる「シームレス統合」モードをサポートしています。

また、これはあなたの質問に対する答えですが、コンパイル設定によって異なります。Visual Studio を使用すると、さまざまな環境に合わせてコンパイルでき、64 ビット システム上で 32 ビット プログラムを完全にコンパイルできます。方法は説明できませんが、Visual Studio の専門家がきっと助けてくれるはずです。

私たちは VS 2005 (もうすぐ 2008) を使用して 32 ビット アプリケーションを開発しており、XP Pro x64 または Vista Business 64 ビットを搭載した新しいマシンをいくつか購入したところです。これにより、商業的に必要になった場合には、64 ビットへの移植も可能です。開発環境などでいくつかのスクリプトを調整する以外に、これを行うことに問題はありませんでした。

このアップグレード サイクルに含まれていない開発者は依然として 32 ビット マシンを使用しているため、チェックイン前に当然のことながら単体テストとアプリケーション テスト スイートを実行すると問題が見つかるはずです。

また、チェックインのセットをビルドおよびテストする「典型的な」構成 (XP/Vista、2/4/8 コアなど) で構成される「テスト ビルド」マシンのセットがあることを確認します。 - 安定性、パフォーマンスなどに関するさまざまなテストスイートを用意しています。- 適切な統合領域に追加される前。繰り返しますが、これらでは、64 ビット OS 上で構築された 32 ビット アプリケーションの実行に関する問題は検出されていません。

とにかく、他の人がすでに述べているように、コンパイラが実際に実行されているOSに関係なく、ターゲットOSに適切なコードを生成するのはコンパイラであるため、それが問題になるとは思いません。

そう、アダムが言っていたように。3 つのオプションがあります:MSIL (デフォルト)、x64、および x86。x64 をターゲットにして、64 ビット システム専用の DLL を生成することもできます。また、32 ビットと 64 ビットで実行できる x86 を実行することもできますが、64 ビット システムでも 32 ビットと同じ制限があります。

MSIL は基本的に、JITer にプラットフォーム固有の命令を発行させます (ネイティブ イメージと比較してパフォーマンスがわずかに低下します)。

編集:言語がないので、vb.net や C# などの .net フレームワーク言語について話しています。C++ はまったく別の動物です。

今日はこんなものを見つけました。

http://www.brianpeek.com/blog/archive/2007/11/13/x64-development-with-net.aspx

.NET を使用した x64 開発

今年の初めに、私は 64 ビット オペレーティング システム (正確には Vista Ultimate x64) に切り替えました。ほとんどの場合、このプロセスは比較的問題なく完了しましたが、途中でいくつか問題が発生しました (主に x64 互換ドライバーですが、それはこの議論の要点ではありません)。

x64 開発の世界では、いくつかの困難な点がありましたので、ここで概説したいと思います。このリストは今後さらに増える可能性があるため、この問題に関する今後の投稿に期待してください。

.NET 開発の素晴らしい世界では、アプリケーションとアセンブリをコンパイルしてさまざまなプラットフォームをターゲットにすることができます。デフォルトでは、アプリケーションとアセンブリは Visual Studio の Any CPU としてコンパイルされます。このシナリオでは、CLR は、実行されているマシンの既定のターゲットとしてアセンブリを読み込みます。たとえば、x64 マシンで実行可能ファイルを実行すると、64 ビット プロセスとして実行されます。

Visual Studio は、次の 3 つの特定のプラットフォーム ターゲットも提供します。x86、x64、Itanium (IA-64)。実行可能ファイルを特定のターゲットとしてビルドすると、そのタイプのプロセスとしてロードされます。たとえば、x64 マシン上で実行される x86 ターゲットの実行可能ファイルは、32 ビット CLR および WOW64 レイヤーを使用して 32 ビット プロセスとして実行されます。アセンブリが実行時に読み込まれる場合、アセンブリのターゲットがホスト プロセスのターゲットと一致する場合、またはアセンブリが Any CPU としてコンパイルされている場合にのみ、プロセスによって読み込むことができます。たとえば、アセンブリのターゲットとして x64 が設定されている場合、アセンブリは x64 プロセスによってのみ読み込むことができます。

これは私にとっていくつかのシナリオで影響を及ぼしました。

  • XNA - XNA は 32 ビット アセンブリのセットとしてのみ使用できます。したがって、XNA アセンブリを参照する場合、それらを使用する実行可能ファイル/アセンブリは x86 プラットフォームを対象とする必要があります。x64 としてターゲットされている場合 (または、任意の CPU として 64 ビット マシン上で実行されている場合)、XNA アセンブリをロードしようとするとエラーがスローされます。

  • Microsoft Robotics Studio - XInputGamepadService は内部で XNA を使用して Xbox 360 コントローラーと通信します。上記を参照。

  • マネージド DirectX - これはすでに非推奨であり、XNA に置き換えられていますが、まだ使用できます。アセンブリは特定のターゲット用にマークされていませんが、特に Microsoft.DirectX.AudioVideoPlayback アセンブリでのメモリ例外に問題がありました。

  • Phidg​​ets - どのライブラリをいつダウンロードするかによって、32 ビットのみとしてマークされる場合とマークされない場合があります。現在のバージョン (11/8/07) はそのようにマークされているため、それをホストするには 32 ビット プロセスが必要です。実行可能ファイルまたはアセンブリが特定のプラットフォームを対象としているかどうかを確認する最も簡単な方法は、corflags アプリケーションを使用することです。これを使用するには、[スタート] メニューから Visual Studio コマンド プロンプトを開き、確認するアセンブリに対して実行します。

実行可能ファイルまたはアセンブリが特定のプラットフォームを対象としているかどうかを確認する最も簡単な方法は、corflags アプリケーションを使用することです。これを使用するには、[スタート] メニューから Visual Studio コマンド プロンプトを開き、確認するアセンブリに対して実行します。

ライセンス： CC-BY-SA と 帰属
所属していません StackOverflow
scroll top