Suzukiです。
こんばんわ!
お返事ありがとうございます!

> おはよございます。
> またはずしましたか・・・(^^;

いえいえ。
貴重なご意見、大変参考になります。m(__)m

> たとえば、普通にオープンするファイルだった場合に他のプロセスがファ
> イルのサイズを変えると、別のオープン済みのプロセスは変化したサイズ
> までファイルポインタをシークできるはずですよね。
> これと同じようなメカニズムではないでしょうか?
> ファイルマッピングオブジェクトとはいえ、プログラムから直接ファイル
> にアクセスするのではなく、OS内部のキャッシュが実施されているはずで
> す。なので、一方のプロセスではたぶん範囲外だろうあたりのオフセット
> を指定されてもキャッシュ更新時に同期を取るだろうから、ご要望のこと
> はOSとして「できなければならない」ことではないかと。

なるほど。。。
確かに普通のファイルならそうですよね。
そうは思うのですが、、、


> 増殖させる大きさをOSのキャッシュサイズより大きくしたりして実験すると
> 可・不可の判断ができるような気がしますが・・・σ(^_^)はできると思いま
> すね。
> #時間がないのでテストできませんが・・・

(OSのキャッシュサイズの限界を超えてのテストはしていないのですが、、、)
じつは、テストプログラムをシンプルにして再度腰をすえて実験をしたのですが、
結果としては
最初のメールの質問1、2ともにNGでした。。。。
つまり、ノーマルファイル・ページファイルを問わず、2度目に最初の
マッピングサイズよりも大きい値を指定しても、最初のサイズを越えた
アクセスはできませんでした。。。

最初のプロセス100バイト。後から別のプロセスが5000バイトをマッピング
すると、後のプロセスが、4097バイト目をアクセスした時点で
不正なアクセスで落ちてしまいます(ノーマルファイルでもページファイルでも)。
最初の100バイトは確かに超えていますが、おそらくページサイズ単位で
マッピングされているので、2回目の5000バイト(2ページ分)は
正しくマッピングされていないということだと思います。
#ちなみにノーマルファイルの場合、フォルダー上のファイルサイズ自体は
  ちゃんと5000バイトになっているのですが。。。

<勝手な予想>
CreateFileMappingのサイズの指定は、一番最初に
行ったときだけ有効で、後から同じマッピングの名前を指定した場合は
最初の値が適用されるだけで、サイズの指定に意味はないのではないか?
(最初より小さい場合は有効かもしれませんが)
と考えています。
</勝手な予想>

> 是非結果を教えてくださいませ。

別の方からもレスをいただいていますが、やはり後から大きな
マッピングサイズを指定することによる共有メモリの拡張はNG
ということかな?と今思っています。

結局メモリマップトファイルによる動的なメモリ共有は
・決めうちの固定サイズのマッピングを、必要の応じ、増やしていく
・ノーマルファイルで共有し、サイズを拡張する場合は
  一旦全員のマッピングをCloseして、誰か一人がまず拡張してたあと
  また、再度全員マッピングをする。
・(DMでご指摘いただいただけで、未確認ですが)
  NTFSであるなら、Sparse file(FSCTL_SET_SPARSE)を利用してみる。

くらいかな、と思っています。
どなたかいい方法があれば教えてくださいませ。

ではでは。