基本的には POSIXに於けるSAORIの扱いについて に記載されている内容に準拠するものとする。
一応上記URLの内容をざっくり紹介する。
通常のSAORIからの変更点を載せる。
HGLOBAL->char *、BOOL->int
GlobalAlloc/GlobalFreeの代わりにmalloc/freeを使う。
- SAORIのロード方法
-
/path/to/saori.dllをロード出来るか試す(SAORI_FALLBACK_ALWAYS!=0なら無視) -
1が失敗(or無視)したら
saori.dllをSAORI_FALLBACK_PATHから検索してロード出来るか試す -
成功したらそのライブラリを使う
- SAORIのファイル名
saori.dllを呼びたい場合は、libsaori.soをビルドし、saori.dllのシンボリックリンクをはる。(UNIX的お作法)
つまり、こうする。
g++ -shared -o libsaori.so ...
ln -s libsaori.so saori.dll
cp -d libsaori.so saori.dll /path/to/saori_fallback_path/
exportする関数について変更がある。 以下の問題が存在するため、SAORI in POSIXだけでは対応できない。
- 一回の呼び出しで処理が完了しないSAORIの存在(
imgctl_saori.dllとか)
POSIX環境ではSAORIは共有されるため、 1ゴーストが複数回の呼び出しを行っている途中に 他ゴーストによる呼び出しが行われるとSAORI内部の情報がおかしくなる。 そのため、インスタンスはゴースト毎に分ける必要がある。
- POSIXのライブラリ呼び出し規約に起因する問題
POSIXでは同名の関数は最初にロードしたライブラリのものを 使う様になっているため、そのままではSAORIは1つしか使えない。 そのため、exportする関数名はSAORI毎に独立していなければならない。
(SAORI名)_saori_*という命名規則でライブラリを作成する。
saori_test.dllと同等の機能を持つsaoriをPOSIX環境用に作る場合を例に挙げる。
long saori_test_saori_load(char *path, long len);
char *saori_test_saori_request(long id, char *request, long *len);
int saori_test_saori_unload(long id);
引数、戻り値はYAYAのmulti_*を参考にした。
POSIXのYAYAはmulti_loadでインスタンスを生成して一意な識別子を返し、
その識別子を使ってmulti_request、multi_unloadを呼び出す。
それと同じように(SAORI名)_saori_*を呼び出す。
loadはインスタンス生成に成功したとき、 1以上1024以下の任意のlong型整数の識別子を返す。 失敗した場合は0を返す。 1024という数字に深い意味は無い。それくらいあれば充分だろうという考え。 理論上はlong型で対応できる範囲の整数を返してよい。
ninix-saoriを参照のこと。