*FMO関連の資料 [#ra3ec8a9]
**FMOエントリのヘッダ仕様修正 [#f36e9d1a]
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エントリ追加 [#be3dad20]
***[ID].kerohwnd [#cc2cb176]
kero側のhwndがunsigned int値として格納されています。~
主に某ソフトでkero側のHWND値が欲しいという需要から追加されたものですが、何かしらkero側のウィンドウをいじりたい場合等に使えるでしょう。
**FMOの排他制御 [#c3908ec5]
***説明 [#y2336bab]
FMOの排他制御には、"SakuraFMO"という名前付Mutexを利用します。~
書き込み、読み込み時にきちんとMutexを所有することでロックをかけ、同時書き込みによるデータ破壊や、読み書きの衝突による不完全なデータの読み込みを効果的に阻止することができますので、できるだけ実装してください。
***サンプルコード [#gb43bc83]
#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と比較しないよう注意してください。
[[こちらも参考にするとよいでしょう。>http://bottle.mikage.to/inside/fmo.html]]
**FMOが変更されたことの他プロセスへの通知 [#oe08d56f]
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() ) {
なんかやる;
}
}
}
}}
受ける側はこのようにして、更新の通知をチェックすることができるでしょう。