連続していないファイルのブロックを連続したメモリにマッピングすることに関する質問への回答では、ここで、最後の (lpBaseAddress) パラメーターの「安全な」値を確立するために、MEM_RESERVE でVirtualAllocEx () を使用する必要があることを、ある回答者から提案されました。 MapViewOfFileEx ()の場合。
さらに調査した結果、このアプローチにより MapViewofFileEx() がエラー 487:「無効なアドレスにアクセスしようとしています」で失敗することが判明しました。 MSDNページには次のように書かれています:
「VirtualAllocまたはVirtualAllocEx関数を使用してメモリを予約するなど、マッピングに使用される領域で他のメモリ割り当てを行うことはできません。」
ドキュメントは有効な一連の呼び出しに関してあいまいであると考えられるかもしれませんが、実験では、VirtualAllocEx() を使用して MapViewOfFileEx() 用にメモリを予約することは有効ではないことが示唆されています。
ウェブ上で、値がハードコードされた例を見つけました - example :
#define BASE_MEM (VOID*)0x01000000
...
hMap = MapViewOfFileEx( hFile, FILE_MAP_WRITE, 0, 0, 0, BASE_MEM );
私には、これは不十分で信頼性がないように思えます...なぜこのアドレスが安全なのか、またはそこに安全にマップできるブロックの数ははっきりしていません。他の割り当てのコンテキストで機能するソリューションが必要であり、ソースをコンパイルして 32 ビットと 64 ビットの両方のコンテキストで動作させる必要があることを考えると、さらに不安定に思えます。
私が知りたいのは、アドレス空間のプールを確実に予約して、後で MapViewOfFileEx が確実に使用してブロックを明示的なメモリ アドレスにマップできるようにする方法があるかどうかです。