問題タブ [win64]

作成してx64用にコンパイルするすべてのプロジェクトに自動的に追加されるようですが、x64構成を選択すると、プロジェクトの構成プロパティ/(C/C++)/プリプロセッサにも表示されません。

Delphi 2009 をインストールせずに、64 ビット Windows Vista で、コマンド ライン dcc32.exe コンパイラを使用して Win32 GUI アプリをコンパイルすることに成功した人はいますか? 私たちのシステムでは失敗し、DFM ファイルに不明な 16 ビット リソースが含まれているというメッセージが表示されます。これは通常、DFM ファイルを読み取れないことを示しています。私たちが試したすべての 32 ビット Vista および Windows XP で完全に動作します。

お尋ねしたいのは、必要に応じて現在の exe ファイルを後で再構築できるようにしたいためです。将来、全員が 64 ビット OS に切り替えたとしても、古い 2009 バージョンを再構築できるようにしたいと考えています。

COMCTL32.OCX（ "Microsoft Windows Common Controls 5.0（SP2）"）のImageListコントロールを使用してTreeViewsとListViewsのアイコンを提供する古いVB6アプリケーションがあります。

アプリはWindows7.064ビットでも起動しません。ImageListが含まれているフォームを読み込もうとすると、クラッシュします（実際、アプリはウィンクアウトし、トレースなしで終了します）。

フォームからImageListを削除すると、問題が解決します。

何か案は？

必要なすべてのキーと値をレジストリに書き込むことにより、COM相互運用機能アセンブリをプログラムで登録するJavascriptコードがいくつかあります。このCOMオブジェクトの古いバージョンはVB6で記述されており、ユーザーがx86 sidebar.exeを手動で実行しない限り、x64バージョンのWindowsでは正しく機能しませんでした。そのため、一部のユーザーはx86sidebar.exeを使用するように切り替えました。動作するCOMオブジェクト。

つまり、現在実行中のオペレーティングシステムのアーキテクチャを正しく検出する必要があります。x86バージョンのsidebar.exeが実行されている場合、誤った値を返す次のすべてを試しました。

x86 sidebar.exeを実行している場合でも、Win64が実行されているかどうかを確実に検出するために使用できるものはありますか？

ユーザー空間プログラムは、64 ビット Windows (現在 XP-64) で "GS:" をどのように構成できますか?
(設定により、GS:0 を任意の 64 ビット リニア アドレスに設定します)。

「JIT」環境を、もともと Win32 用に開発された X86-64 に移植しようとしています。

残念な設計上の側面の 1 つは、同一のコードを複数のユーザー空間スレッド (「ファイバー」など) で実行する必要があることです。コードの Win32 バージョンは、これに GS セレクターを使用し、ローカル データにアクセスするための適切なプレフィックスを生成します。「mov eax,GS:[offset]」は、現在のタスクの正しいデータを指します。Win32 バージョンのコードは、機能する値を持っていれば、その値を GS にロードします。

これまでのところ、64 ビット Windows は LDT をサポートしていないことがわかっているため、Win32 で使用される方法は機能しません。ただし、X86-64 命令セットには「SWAPGS」と、従来のセグメンテーションを使用せずに GS をロードする方法が含まれていますが、これはカーネル空間でのみ機能します。

X64 のマニュアルによると、たとえ Win64 が記述子へのアクセスを許可していたとしても (そうではありません)、セグメント ベースの上位 32 ビットを設定する方法はありません。これらを設定する唯一の方法は、GS_BASE_MSR を使用することです (および対応する FS_BASE_MSR - 64 ビット モードでは他のセグメント ベースは無視されます)。WRMSR命令はRing0なので直接使えません。

ユーザー空間の "GS:" を変更できる Zw* 関数、または Windows API のその他のダーク コーナーを期待しています。Windows はまだ FS: を独自の TLS に使用していると思いますが、何らかのメカニズムが利用可能でなければなりませんか?

---

このサンプル コードは、問題を示しています。バイト コードを使用していることをあらかじめお詫び申し上げます。VS は 64 ビット コンパイルのインライン アセンブリを行いません。説明のために、これを 1 つのファイルとして保持しようとしていました。

XP-32 では「PASS」と表示されますが、XP-x64 では表示されません。

---

クラスの非静的メンバー関数があり、可変引数があります。64 ビット Windows で、64 ビット ランタイムを使用して Visual Studio 2005 でコンパイルしています。

float を期待しています。float を関数に渡します。しかし、デバッグすると、渡したフロートが得られません。実際、これは関数によって 64 ビット double として受信されています! 私はこれをしなければなりません：

これで、Win64 はレジスタでパラメータを渡すのが好きで、これを行うときにフロートをキャストすることがわかっています。

ほとんどの参照によると、渡されたパラメーターでいっぱいのクリーンなスタックが必要です。

私の質問は次のとおりです。これは正しい動作ですか、それともバグですか? また、それがバグである場合、それは私のバグですか、それとも Microsoft のバグですか?

WIN64 と _M_AMD64 を定義していますが、WIN32 は未定義です。

64ビットシステムで実行されている32ビットアプリケーションから64ビットアプリケーションのデフォルトフォルダーにアクセスする方法はありますか？

たとえば、32ビットアプリケーションからCSIDL_PROGRAM_FILESでSHGetSpecialFolderPathを使用すると、「C：\ Program Files（x86）」が返されます。64ビットアプリケーションから同じ呼び出しが使用された場合、「C：\ProgramFiles」が返されます。 32ビットアプリケーションからのその「C：\ ProgramFiles」？

ここでの関連する質問は、SHGetFolderPath（）32ビットと64ビットのどちらにも役立ちません。また、SHGetSpecialFolderPathを呼び出す前にwow64ファイルシステムのリダイレクトを抑制しません。

C# アプリケーションで form_load から例外をスローすると、プラットフォームが x64 の場合に機能しません。(x86 では期待どおりに動作します)

コードをステップ実行すると、例外がスローされた行に到達し、すぐに timer_Tick にジャンプします。

新しいプロジェクトを作成し、次の行を form_load に追加すると: throw new System.Exception("oops!");

x86 の場合、予想どおりにクラッシュします。x64 ではクラッシュしません。

64 ビットで form_load からアプリケーションを実際にスローする方法はありますか?

32 ビットの perl であっても、Perl スクリプトが 64 ビットの Windows マシンで実行されていることを検出するにはどうすればよいですか?