This is the current model of the SendMessage API:
1. Process checks if the MapFile to "mIRC" is available, and creates it if it is.
2. Process writes data to file
3. Process calls SendMessage to get mIRC to read the file and evaluate/execute statements, reading back data in the case of evaluation
4. Process closes the MapFile so other processes can access it.
Problems with this model:
Every thread/process is sharing control over mirc, and at the same time, every thread/process has complete control over that share. What I mean is, any process can open the map whenever it wishes, whether it's already in use or not. It can also choose not to close the MapFile at all, essentially causing any other processes that check permission to write to the mapfile to stop functioning. This means that all SendMessage code that properly follows the model above (does not write to the file if it is in use) will fail if another procress does not follow the model above. This also means that any other process that does not follow the model can overwrite [important] data being passed to or from mIRC whenever it wishes. In essence, it means that the validity of the data being passed through the SendMessage API can really not be guaranteed.
Solution:
mIRC should have some sort of API to request access to the map file so that it can control and synchronize which processes are accessing the file, thereby guaranteeing the validity of the data. mIRC should also control for how long a process can keep the file open for, possibly even handle the time-sharing aspect itself, rather than letting the processes do it individually.
Summary:
Basically, the SendMessage API that mIRC currently has implemented does not guarantee the validity of data passing to or from mIRC to the process that uses it. mIRC should have more control over who is allowed to access the MapFile and for how long- the time sharing of the MapFile should be under mIRC's jurisdiction, not per-process jurisdiction.
Hopefully this issue will be looked at- it causes major issues under processes that rely heavily on SendMessage.
