Forums Feature Suggestions Improving the current SendMessage API

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.

I fully agree.

There is a combination two factors to blame here: the complexity of the Windows API, and sloppy (or simply ignorant) DLL coders. The Windows API is not exactly intuitive when it comes to mapped files, and many coders seem to not understand the basic concept underlying it.

For example, I've actually seen DLLs that create the mapped file at load time, and keep it open all the time while running. Such behavior causes a deadlock in a properly coded program, which would wait until the mapped file doesn't exist anymore. The irony here is that if the writer of that program chooses to ignore any errors, it will actually work most of the time (but in a completely messed up way).

In theory, merely raising awareness should be sufficient to solve this problem, but in practice I'm afraid that's not going to work. Some kind of solution imposed by mIRC would be by far the best option.

Edit: one very simple way of working around this problem in a backwards-compatible way, would be to use the lParam parameter to SendMessage() as an added text string to the mapped file name, eg. using sprintf(lpMapName, "mirc%08x", lParam); if lParam doesn't equal zero.

Yea I was thinking of a way Khaled could implement MULTIPLE mapped files instead of one that would be shared by all processes. Using the lParam of the SendMessage() call never came to mind, but that's a great idea.



That won't stop incompetent coders from deadlocking certain mIRC mapfiles i suppose, but it will allow people to work around it. Though, this is definitely not the best solution. The best solution was mentioned in my first post imho-- this is just an easier one (if Khaled is watching :P)

instead of a random number which could be duplicated in odd cases why not use unix time? or epoch time

Indeed, I consider it a workaround, nothing more

That would actually make the chance of two processes using the same mapped file at the same time more likely..

https://forums.mirc.com/s...true#Post120842

My post on an exported API is waht really needs to be done imo the mapped file is really not a good way to deal with passing information between mIRC and a dll; an exported api that dlls could gain access to is a much better alternative

The two issues are not exactly the same. There are also external programs and winamp plugins (etc) that want to send information to mIRC, and since they are not part of mIRC's address space, they wouldn't be able to make use of the API you are suggesting. While your suggestion would be a huge improvement for mIRC DLL coders, it would not (fully) solve the problem described here.

Khaled should implement both imho

But I think on Khaled's side of the table, it may not be a great idea to export such symbols (there's really no need to elaborate on this- if you get it, you get it, if you dont, you dont)

hrmm i duno i think in the long run i would like to see stuff like a window struct and such accessible to dll's just opens up a lot of options... in the short run however id die for some simple exports like the WM_MEVAULATE and such...

Just an addendum: using the GlobalAddAtom family of functions for this would be even neater.. if lParam isn't 0, assume it is an atom number of the global atom containing the name of the mapped file to use; otherwise, use "mIRC" as before.

In fact I believe that the whole mapped files mechanism could be replaced by global atoms, but that's another issue..