To indicate that the baseware is running, SSP holds a Mutex named "ssp", and Materia and CROW hold a Mutex named "sakura".
By checking for the presence of this named Mutex, you can determine whether it is running or not at a low cost.
The state of the Mutex itself is not determined, and there is no need to check whether or not it is in a signal state.
All baseware maintains a named file mapping object (FMO) while running.
By reading this inter-process shared memory, the running ghost can be obtained at relatively low cost.
To avoid incomplete information while writing, exclusive control is performed by Mutex for FMO. Please check these together.
Saura: OS dependent, Shift JIS on Japanese OS
SakuraUnicode: Fixed to UTF-8 [SSP 2.5.26 or later]
The first 4 bytes (bytes 0-3) indicate the size of the allocated FMO.
This is not the length of the information being written, but is a fixed value that indicates the allocated size of the FMO itself.
The value is currently fixed at 0x00010000 in little-endian, or 64kb.
To ensure compatibility with other programs, size changes are not currently considered.
The 4th and subsequent bytes are the main body of the FMO data. This will be in the following format.
(32-byte unique ID).(key name)[\1]value[\r\n]
[\1] is byte value 1, [\r\n] is CR_LF (line feed).
This format is repeated on multiple lines.
The end of the data is a byte value of 0, the same as for a C string.
Hence, the maximum size available for the data body is 65531 bytes (65536 - 4 - 1).
If you need to write to FOM and are about to exceed the size limit, be careful not to write incomplete information.
If the size is likely to be exceeded, it is preferable not to write a whole set of data. Even if this is not possible, do not end in the middle of a single line.
This is a unique unique ID that indicates one group of ghosts. You must choose a string that is unique, at least within the FMO.
In many cases, some unique information is combined to obtain an MD5 hash or a combination of HWND (window handle).
Although the length is not specified in the Materia standard, it should be a fixed length of 32 bytes for compatibility.
A key indicating the type of information and the information body. It is as follows.
Since FMO itself does not have an exclusive control mechanism, a separate Mutex is maintained to avoid write/read conflicts.
The name will be FMO name + "FMO". For example:
FMO = Sakura : Mutex = SakuraFMO
FMO = SakuraUnicode : Mutex = SakuraUnicodeFMO
The determination of signal and non-signal status is important here.
When reading or writing, be sure to use WaitForSingleObject or an equivalent wait function to acquire ownership, and ReleaseMutex to release ownership when finished.
Old baseware may not support Mutex for FMO, so please do not generate an error if you fail to obtain Mutex.
In this case, please keep in mind the possibility of obtaining an incomplete FMO during writing, and write code that can handle this as safely as possible.