問題タブ [64-bit]

ある時点でコールスタックをウォークするC++ツールがあります。コードでは、最初にライブCPUレジスタのコピーを（RtlCaptureContext（）を介して）取得し、次にいくつかの " #ifdef ..."ブロックを使用してCPU固有のレジスタ名をstackframe.AddrPC.Offset、... AddrStack...、および...に保存しますAddrFrame。 ..; また、Addr上記の3つの...メンバーのそれぞれに対して、...を設定しstackframe.Addrます.Mode = AddrModeFlat。（これは、しばらく前に出くわしたサンプルコードから借用したものです。）

x86バイナリでは、これはうまく機能します。ただし、x64バイナリでは、StackWalk64（）は偽のアドレスを返します。 （APIが最初に呼び出されたとき、明らかに偽のアドレス値のみがAddrReturn（== 0xFFFFFFFF'FFFFFFFE-別名StackWalk64（）の3番目の引数、GetCurrentThread（）によって返される疑似ハンドル）に表示されます。APIが2回呼び出された場合ただし、すべてのAddr...変数は偽のアドレスを受け取ります。） これAddrFrameは、設定方法に関係なく発生します。

• 推奨されるx64「ベース/フレームポインタ」CPUレジスタのいずれかを使用：rbp（= 0xf）、またはrdi（= 0x0）
• 使用rsp 中（動作することを期待していませんでしたが、とにかく試してみました）
• 設定AddrPCし、通常はゼロのAddrStackままにします（他のサンプルコードで見られます）AddrFrame
• すべてのAddr...値をゼロにして、StackWalk64（）が渡されたCPUレジスタコンテキストからそれらを入力できるようにします（他のサンプルコードで見られます）

FWIWでは、物理スタックバッファーの内容もx64とx86で異なります（もちろん、ポインター幅とスタックバッファーの場所の違いを考慮した後）。理由に関係なく、StackWalk64（）は引き続きコールスタックを正しくウォークできるはずです。つまり、デバッガーは引き続きコールスタックをウォークでき、StackWalk64（）自体をバックグラウンドで使用しているように見えます。奇妙なことに、デバッガーによって報告された（正しい）呼び出しスタックには、ベースアドレスとリターンアドレスのポインター値が含まれ、その構成バイトは実際にはスタックバッファー（現在のスタックポインターの下または上）に存在しません。

（FWIW＃2：上記のスタックバッファの奇妙さを考慮して、ASLR（/dynamicbase:no）を無効にして違いが生じるかどうかを確認しましたが、バイナリは同じ動作を示しました。）

それで。これがx86で正常に機能するのに、x64で問題が発生する理由はありますか？それを修正する方法について何か提案はありますか？

CSIDL_PROGRAM_FILES ID の代わりに CSIDL_PROGRAM_FILESx86 フォルダー ID を使用して 32 ビット システムでSHGetFolderPath API 呼び出しを使用するとどうなりますか?

理論的には、CSIDL_PROGRAM_FILESx86 はC:\program files (x86)64 ビット システムにマップする必要がありますが、このパスが存在しない 32 ビット システムでは何にマップされますか?

大きなファイルを順次処理していますが、その大きなチャンクをメモリに保持したいと考えています。64 ビット システムでは 16 GB RAM を使用できます。

これを行う手っ取り早い方法は、単純に入力ストリームをバッファリングされた入力ストリームにラップすることです。残念ながら、これでは 2 GB のバッファしか得られません。もっと記憶に残しておきたいのですが、他にどのような方法がありますか?

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

マルチターゲティング用にVisualStudioビルドをセットアップする方法について少しジレンマがあります。

背景：サードパーティの32ビットDLLへのp /invokingを備えたc＃.NET v2.0、セットアッププロジェクトを備えたSQL Compactv3.5SP1。現在、プラットフォームターゲットはx86に設定されているため、Windowsx64で実行できます。

サードパーティの会社がDLLの64ビットバージョンをリリースしたばかりで、専用の64ビットプログラムを作成したいと思います。

これは私がまだ答えを得ていないいくつかの質問を提起します。まったく同じコードベースが欲しい。32ビットのDLLセットまたは64ビットのDLLのいずれかを参照してビルドする必要があります。（サードパーティとSQL Server Compactの両方）

これは、2つの新しい構成セット（Debug64とRelease64）で解決できますか？

2つの別々のセットアッププロジェクト（標準のビジュアルスタジオプロジェクト、Wixやその他のユーティリティなし）を作成する必要がありますか、それとも同じ.msi内で解決できますか？

任意のアイデアや推奨事項を歓迎します。

1つのlonglongintがあり、そのビットを取得して、それから4つのunsignedshortintを作成するとします。

ここでは、特定の順序はそれほど重要ではありません。

私は一般的に、ビットをシフトしてunsignedshortintのサイズに切り捨てる必要があることを知っています。でもどこかで変な間違いをするかもしれないと思うのでお願いします。

既存のコードを 64 ビット マシンに適合させようとしています。主な問題は、ある関数で、前のコーダーが void* 引数を使用し、関数自体で適切な型に変換されることです。簡単な例:

もちろん、64 ビット マシンでは次のエラーが表示されます。

これを修正して、32 ビット マシンでもできるだけきれいに動作するようにしたいと思います。何か案が ？

新しい開発用PCを購入したいと思っています。私の予算は$1,000USD（モニターを含む）以下です。私はラップトップ（デスクトップ交換タイプ）を利用できます。そうでない場合は、従来のデスクトップPCで問題ありません。

私の主な開発環境は、Microsoft、Visual Studio 2008（および古いVisual Studio 6コードのサポート）です。SQL Server 2005、2008、およびSQL Server2000のレガシーサポート。MicrosoftOffice2003、2007をインストールする可能性がありますが、Office 2000までサポートします。私が作成してサポートするソフトウェアは、ほとんどがWindows XPですが、一部のVistaです。インストール先の64ビット実装があると想定する必要があります。

私の最初の混乱は、AMDまたはIntelを選択することから始まります。私の懸念は、AMD環境でVisualStudioを使用してソフトウェアを構築する際の互換性の問題があることです。私には証拠がありません。誰かが私のために片付けてくれることを願っています。

最後に、32ビットと64ビットのインストールについて混乱しています。64ビットが着実に普及しているにもかかわらず、最小公分母（32ビット）を使用する必要がありますか？64ビットオペレーティングシステムは4Gを超えるRAMに対応し、テスト環境用にできるだけ多くの仮想マシンをセットアップしたいので、一度に多くの仮想マシンをアクティブにすることができるので、気に入っています。

私は夢のマシンを探しているのではなく、モニターと、そこにあるほとんどのマシン用のソフトウェアを作成できる約$1000の最高のプロセッサーを備えたマシンだけを探しています。

INSTALL.W64 の指示に従った後、2 つの問題が発生しました。

• コードは引き続き「out32」フォルダーに書き込まれます。ワークステーションでライブラリの 32 ビット バージョンと 64 ビット バージョンの両方にリンクできるようにする必要があるため、64 ビット バージョンが 32 ビット ライブラリを破壊することは望ましくありません。
• 出力は 32 ビットのままです。これは、x64 アプリからライブラリにリンクしようとすると、「未解決の外部シンボル」エラーが発生することを意味します。

pthread-win32をx64で動作させるためにいくつかの作業が行われたようですが、ビルド手順はありません。Visual Studio x64 Cross Toolsコマンドプロンプトを使用して単純にビルドしようとしましたが、x64アプリケーションからlibにリンクしようとすると、関数のエクスポートが表示されません。まだライブラリをx86か何かとしてコンパイルしているようです。

/ MACHINEをmakefileの適切な場所に追加しようとしましたが、役に立ちません。誰かがこれを機能させましたか？