14

.Netプログラムを作成するときに、アーキテクチャタイプ（x86とx64）が抽象化されていると思いますが、問題を引き起こす可能性のある他の考慮事項はありますか？

4

7 に答える 7

19

win32呼び出しを密かに行うサードパーティのCOMライブラリまたはサードパーティの.NETライブラリに注意してください。それが私たちの最大の頭痛の種でした。

于 2008-09-28T02:35:41.790 に答える
11

MSDN docoから、他の考慮事項の中で：

多くの場合、アセンブリは 32​​ ビットまたは 64 ビットの CLR で同じように実行されます。64 ビット CLR で実行したときにプログラムの動作が異なる理由には、次のようなものがあります。

  • ポインター型など、プラットフォームに応じてサイズが変わるメンバーを含む構造体。

  • 定数サイズを含むポインター演算。

  • IntPtr の代わりに Int32 をハンドルに使用する不適切なプラットフォーム呼び出しまたは COM 宣言。

  • IntPtr を Int32 にキャストする

また、デフォルトのファイルの場所。

于 2008-09-28T02:42:02.600 に答える
9

この記事には、知っておくべき多くの良い問題があります: http://osnews.com/story/20330/Windows_x64_Watch_List

個人的には、私の上司は 64 ビットの Vista コンピューターを使用しており、私は 32 ビット モードでプログラミングしています。次の問題が発生しました。

  • 32 ビット アプリのレジストリは、Wow6432Node フォルダーに (一種の) 非表示になります。レジストリでパスを見つけることに慣れているすべてのアプリがそのノードにあるわけではありません (たとえば、SQL Server はそうではありません)。

  • C:\Windows フォルダーの SysWow64 は、DLL が必要な場所にないという問題を引き起こす可能性があります (この問題は、サード パーティのライセンス コンポーネントで発生しました)。

  • 必要なファイルが「C:\Program Files」ではなく「C:\Program Files (x86)」にある場合があります。あまりにも吸う。

于 2008-09-28T03:16:06.123 に答える
2

  • 32 ビット プラットフォームでは、64 ビット値の読み取りと書き込みはスレッド セーフではありません。64 ビット値の読み取りには、コンテキスト スイッチによって中断される可能性のある 2 つの操作が必要です。詳細については、 Threading.Interlocked.Readに関する MSDN の記事を参照してください。

  • また、torialの回答に完全に同意します。:-)

于 2008-09-28T13:28:34.683 に答える
2

MSDN は、32 ビット アプリケーションを 64 ビット実行環境に移植する際の問題に関する小さな論文を掲載していました。

http://msdn.microsoft.com/en-us/library/ms973190.aspx

他の 2 人のブロガーは、以前 CLR チームで働いていたときに 64 ビット開発について書いていました。

于 2008-11-25T15:54:40.407 に答える
1

x64を使用すると、より多くのメモリをアドレス指定できますが、同じコードを指定すると、x86よりも多くのメモリを使用します。

于 2008-09-28T02:36:00.667 に答える
0

私の経験では、Asp.NET アプリケーションの移植は基本的に完璧でした。32 ビット マシンと 64 ビット マシンで実行しても問題は発生せず、さらに多くのメモリを使用できます。これは、前述の多くの問題 (レジストリ、スレッドなど) が Asp.NET によって管理されており、Asp.NET 環境で実行するには適切に修正する必要があるために発生します。

クライアント側 (Windows フォーム) でも同じことが起こりましたが、「安全でない」API を使用して特別なフォルダーやレジストリへのアクセスを取得した場合、既に指摘したように問題が発生する可能性があります。

よろしくマッシモ

于 2008-12-29T16:05:50.910 に答える