FMO関連の資料 †

FMOエントリのヘッダ仕様修正 †

1プロセスで複数ゴーストを立たせるため、FMOエントリの識別子部分はプロセスIDのMD5値ではなくなっています。
SSPでの識別子の仕様の例は以下のとおりです。

ssp_fmo_header_000002a5_002b3132.name[1]Emily\r\n
ssp_fmo_header_[プロセスID-16進]_[Sakura側hwnd-16進] 

以上のような32バイトの文字列を生成することにより、ゴースト毎にユニークな識別子を割り当て、かつ現状のFMOを利用するアプリケーションとの互換性を取ることができます。

FMOエントリ追加 †

[ID].kerohwnd †

kero側のhwndがunsigned int値として格納されています。
主に某ソフトでkero側のHWND値が欲しいという需要から追加されたものですが、何かしらkero側のウィンドウをいじりたい場合等に使えるでしょう。

FMOの排他制御 †

説明 †

FMOの排他制御には、"SakuraFMO"という名前付Mutexを利用します。
書き込み、読み込み時にきちんとMutexを所有することでロックをかけ、同時書き込みによるデータ破壊や、読み書きの衝突による不完全なデータの読み込みを効果的に阻止することができますので、できるだけ実装してください。

サンプルコード †

#pre{{
HANDLE hMutex = CreateMutex?(NULL,FALSE,"SakuraFMO");
if ( hMutex == NULL ) { エラー処理; }
 
if ( WaitForSingleObject?(hMutex, 1000) != WAIT_TIMEOUT ) {
 FMO読み書き;
 ReleaseMutex?(Mutex);
}

CloseHandle?(Mutex);
}}

素直に書けばこうなりますが、CreateMutex?するコストを気にする場合、起動時に取得してとっておく方法が良いでしょう。
なお、その場合、最後にCloseHandle?する必要はなく、プロセスが終了した時点で自動開放されるようです。

また、処理中のプロセスがMutexをつかんだまま異常終了すると、WaitForSingleObject?はWAIT_ABANDONEDを返します。
これを忘れてWAIT_OBJECT_0と比較しないよう注意してください。

こちらも参考にするとよいでしょう。

FMOが変更されたことの他プロセスへの通知 †

NOTIFY otherghostnameを実装したり、その他FMOを使うツールを作ったりする際に、いちいち定期的にFMOを読んで更新をチェックするのはあまりに高コストです。

ですので……

#pre{{
#define SAKURA_API_BROADCAST_GHOSTCHANGE 1024

spSakuraAPIMsg = RegisterWindowMessage?("Sakura");

SendNotifyMessage?(HWND_BROADCAST,spSakuraAPIMsg,SAKURA_API_BROADCAST_GHOSTCHANGE,m_ProcID);
}}

上記のように、FMOを更新する側が

  • message = Sakura APIと同じ
  • wParam = 1024
  • lParam = 自分のプロセスID

という通知を全アプリにブロードキャストすることで、FMOの更新を通知します。

#pre{{
#define SAKURA_API_BROADCAST_GHOSTCHANGE 1024

spSakuraAPIMsg = RegisterWindowMessage?("Sakura");

int CALLBACK WindowProc?( HWND hWnd, UINT message, WPARAM wParam, LPARAM lParam ) {
switch( message ){
case spSakuraAPIMsg:
if ( wParam == SAKURA_API_BROADCAST_GHOSTCHANGE ) {
if ( lParam != GetCurrentProcessId?() ) {
なんかやる;
}
}
}
}}

受ける側はこのようにして、更新の通知をチェックすることができるでしょう。


トップ   編集 凍結 差分 バックアップ 添付 複製 名前変更 リロード   新規 一覧 単語検索 最終更新   ヘルプ   最終更新のRSS
Last-modified: 2006-12-09 (土) 22:51:24 (4484d)