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() ) {
なんかやる;
}
}
}
}}
受ける側はこのようにして、更新の通知をチェックすることができるでしょう。
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
