むりでしょう。
素直に x64 に乗り換えることをお勧めしますな。

そんな大量の連続メモリを必要としないように書き換えるほうが解決が早いとみた。

やはり。

ちなみに、707MBって何なのでしょう？
SIZE_T のMAX値よりも小さい気もしますが？

>ちなみに、707MBって何なのでしょう？

たまたま、連続領域で開いていたのが707Mだった…ということでは？
プロセス空間内のいろいろなところにDLLが読み込まれたりしますし。

> たまたま、連続領域で開いていたのが707Mだった…ということでは？
> プロセス空間内のいろいろなところにDLLが読み込まれたりしますし。

多分そうですね。
他のアプリ機動前、DLLの読み出し前に確保すると、もっと取れるかも知れません。
更にDLLのロードアドレスを再配置しておくのも手かも知れません。
但し、環境次第では普通に失敗すると思います。
メモリがあいてるかどうかよりも、メモリ空間(連続したアドレス)があいてるかの方が重
要で、
大抵1GB以下で確保失敗することになるわけです。
# 一般論で言えば100MB×10の方が取れる可能性は高いはず。

で、tetrapodさんの提案のいずれかを考えるのが正攻法。
> 素直に x64 に乗り換えることをお勧めしますな。
> そんな大量の連続メモリを必要としないように書き換えるほうが解決が早いとみた。

よくわかりました。
ありがとうございます。
参考になります。

ちなみに、x64 のほうが、メモリ空間自体が広いので、連続したアドレスが空いている
可能性が高いということでしょうか。

また、ちょっとコードに関する疑問なのですが、
メモリを２つ確保するとき
m_hHeap = HeapCreate(0,0,0);
m_mom[0] = (LPSTR)HeapAlloc(m_hHeap,HEAP_ZERO_MEMORY,10000L);
m_mom[1] = (LPSTR)HeapAlloc(m_hHeap,HEAP_ZERO_MEMORY,10000L);
と
m_hHeap[0] = HeapCreate(0,0,0);
m_hHeap[1] = HeapCreate(0,0,0);
m_mom[0] = (LPSTR)HeapAlloc(m_hHeap[0],HEAP_ZERO_MEMORY,10000L);
m_mom[1] = (LPSTR)HeapAlloc(m_hHeap[1],HEAP_ZERO_MEMORY,10000L);
は動作違いますか？

>は動作違いますか？
はい違います。

前者は１つのヒープ管理領域から２つのメモリを確保。
後者は２つのヒープ管理領域から１つのメモリをそれぞれ確保。

GUI を持つアプリだと MFC**.DLL とかいろんなものがロードされる関係で
「空き連続アドレス空間」は小さくなっているのが普通。
「空きメモリ」があっても「空き連続アドレス空間」が無いならば、
100MB サイズの連続メモリ領域を１０個取る（合計1GB)のは可能であっても、
1GB サイズの連続メモリ領域を１個取る、ことはできない、ってのはごく普通。

計算アルゴリズムの変更などで大量連続メモリを使わないようするのが
結果的に早い（メモリの少ないマシン等でもうごくようになるわけだし）
それがどうしても無理なら、大量連続メモリを確保する実験してるページ紹介
http://www.marbacka.net/asm64/arkiv/64bit_addressing.html
どのくらい「空き連続アドレス空間」があるかも調べられるよ

みなさん、ありがとうございます。
感謝です。

>前者は１つのヒープ管理領域から２つのメモリを確保。
>後者は２つのヒープ管理領域から１つのメモリをそれぞれ確保。

どのように使い分ければよいのでしょうか？

いままで、何も考えずに、
>後者は２つのヒープ管理領域から１つのメモリをそれぞれ確保。
を使用していましたが、最近、
>前者は１つのヒープ管理領域から２つのメモリを確保。
こうかかれている、ソースを見ました。