vcpp-ml

30

[vcpp 00061015] RE: #import を使用して Access2002 を利用する方法について

 渋木です。

> Access 2002 のタイプライブラリは「MSACC.OLB」とのことでしたので、
> 「MSACC.OLB」が依存するタイプライブラリを #import してみました。

 ACCESS をオートメーションスルだけなら、MSACC.OLB だけを #import するだ
けで事足ります。

 どうして ADO やら DAO まで #import してるのでしょう?
 本当にそんなに必要なんでしょうか?

> しかし、途中で、ADO 2.1 と ADO 2.5 のオブジェクト名がバッティングする
> ようで、エラーが出てしまいました。

 これも謎です。
 ADO 2.5 と ADO 2.1 を同時に #import する理由が分かりません。

 通常、新しい方だけ #import すれば十分だと思うのですが。。。

> 一応、rename("ADODB", "ADODB25") として、回避させましたが、
> 本当にこのような対応方法でよいのでしょうか?

 名前が衝突するなら仕方ないですね。
 でも、それ以前の問題のような気がします。


--
// 渋木宏明 (Hiroaki SHIBUKI)
// mailto:h...@mbi.nifty.com
// http://www.hidori.jp/
// Microsoft MVP 2002-2003 of Windows
30

[vcpp 00061014] Re: メモリマップトファイルでマッピング済みの領域の拡張

おはようございます。
ゆーち@ちょっとだけです。

質問1についてですが、
> ・共通部分である先頭100バイトA-B間でのデータ共有
> は保証されるのでしょうか?
これは、自責で同期を取らなければならないはずです。
名前付きのミューテクスを用意するとか。

それだけ守れば、第一引数の区別に違いはないとおもうのですが・・・。

#最近Win32から離れてます。間違っていたらすみません。m(_._)m
30

[vcpp 00061013] メモリマップトファイルでマッピング済みの領域の拡張

Suzukiといいます。

メモリマップトファイルで質問があるのですが、
ご存知の方、ご教授ください。


【質問1】
あるプロセス(A)がマッピング中のファイルに対して
他のプロセス(B)が、同じファイルにマッピングを行う時に、
マッピングサイズのパラメータを、
Aがマッピングを行う際に指定したサイズ以上のサイズ
(それがたとえ、ファイルの現サイズを超えていたとしても)
を指定したとき、その後の動作は保証されているのでしょうか?

【詳細】
例として、、、
100バイトのファイル"HogeFile"があったとします。
ProcessAがCreateFile()でそのファイルを開き、HANDLE hFileAを得ます。
次に
CreateFileMapping( hFileA, NULL, PAGE_READWRITE, 0, 100, "MYMAP");
で100バイトのマッピングを指定します。

その後ProcessBが、同じファイルを開き、HANDLE hFileBを得ます。そして
CreateFileMapping( hFileB, NULL, PAGE_READWRITE, 0, 200, "MYMAP");
と、200バイトのマッピングを指定します。

(私のテストプログラムでは、この時点で"HogeFile"は200バイトになるのですが)
この時、
・Aが最初からマッピングしてる100バイトへのAによるアクセス(読み書き)
・Bが後からマッピングした200バイトへのBによるアクセス(読み書き)
・共通部分である先頭100バイトA-B間でのデータ共有
は保証されるのでしょうか?

VisualStudioのマニュアルには
「ディスク上に存在する実際のファイルのサイズより大きいサイズを指定して
ファイルマッピングオブジェクトを作成すると、ディスク上のファイルのサイズは、
ファイルマッピングオブジェクトのサイズに一致するよう増やされます」
とは記述されていますが、すでに他プロセスにマッピングされていた場合の
記述は明記されていません。

【質問2】
上記がもし保証される場合、CreateFileMappingの第一引数に
INVALID_HANDLE_VALUEを渡して、ページファイルで共有した場合
も上記の内容は保証されるのでしょうか?

【背景、動機】
複数プロセス間でメモリ共有をするようことを考えています。
前提として、共有すべきメモリのサイズは動的に増えていき、
上限は予測できません。また、どのプロセスが増やすかも決まっていません。
このようなケースでは固定サイズに区切ったメモリブロックを
必要に応じて、必要な数だけ作成/共有するのが正しいやり方のような
気はするのですが、上記のような仕組みが実現できれば、ひとつの共有領域を
オンデマンドで拡張できるので、シンプルにできるかなと思っています。

また、拡張後のファイルサイズを(たとえば)共有領域の先頭に記述しておけば、
ProcessBが勝手に拡張しても、ProcessAが次回アクセスする際に先頭のサイズ
を参照すれば、誰かが増やしたことがわかるので、再度CreateFileMappingを
しなおせばAも200バイトにマッピングしなおすことができるので
結果的に全プロセスで拡張部分も含め共有できると思っています。


ただ、自分で実験した結果としては質問1はOK、質問2はNGっぽい
(CreateFileMappingは成功するが、拡張部分のメモリアクセスで落ちる)
のですが、もし詳細をご存知の方がいらっしゃれば教えてください。
よろしくお願いします。

ps.
夜しかメールがかけないので、返事が遅れてしまいます。ごめんなさい。

######################
 d...@ca2.so-net.ne.jp
記事検索
Amazon.co.jp
  • ライブドアブログ