Forums Feature Suggestions More reliable communication than mapped files

Hi,

I see using mapped files as being flawed because this can interfere with other applications that want to communicate with mIRC at the same time.

Using indexed file mappings is somehow better but that's still not unique.

Some possible slutions fore a more reliable communication:

1. Pass the handle returned by CreateFileMapping in lParam
This would ensure that the memory mapping is specific to the call. In case on interprocess communtication the handle should be duplicated to the remote process. GetWindowThreadProcessId can be used to obtain the process id from a HWND and OpenProcess can be used to obtain a process handle. If the caller created the remote process it has a process handle returned by CreateProcess. DuplicateHandle can then be used to duplicate the handle to the remote process.

2. Use WM_COPYDATA
This would be a much easier way because the data is marshaled to remote processes by Windows. The only problem is that the buffer cannot be modified. This could be solved by calling back with another WM_COPYDATA.

3. Pass callback function addresses to LoadDll
This is usable for in-process communication only but is very fast and easy to use. A LOADINFOEX structure could be created that is compatible with LOADINFO and a DLL could cast LOADINFO* to LOADINFOEX* when mVersion if greather than or equal to a specific value.

4. Export the callback functions by mirc.exe
This is the same as exporting functions from DLLs. All modules in the process can use GetProcAddress to obtain the address of these functions. Other than this this is the same as the previous solution.

I hope you like these ideas.
Comments are welcome.

Kornel

CreateFileMapping can act as an inter-process synchronization primitive, it's just that noone bothers to check its return values. The problem here is with the current DLL coders, not with mIRC. However, that's why the lParam index value was added..


It is good enough. If the return+error values from CreateFileMapping indicate that the mapping already existed, the trying process can close it, pick a different index and try again. This will eventually succeed as it's rather unlikely that all four billion possible file mapping indices are in use.


No matter how good the solution, it will never really work if the majority of mIRC DLL coders are people who can't read documentation. That is not directed at you by the way - 38 out of 40 DLLs I checked a few months ago, got their file mapping stuff wrong. The two others only got it half right.

I should say that using mapped files if flawed I should rather say that the way mIRC uses mapped files is flawed.

I just wanted to say that if you pass a duplicated handle to a file mapping then it is guaranted to be unique and not checks for existing mappings are necessary at all.



Of course we can't deal with stupid/lame people but we could make callbacks much easier.

Adding callback function pointers to LoadDll is a very reliable solution because there is no need for interprocess communication in DLLs loaded to the process of mIRC so developers don't have to deal with advanced things like interprocess communications and there is way less chance to write deffective code.

By using callback functions in the process of mIRC adding a new callback that can be used to register event handlers (similar to event handlers in scripts) would be possible as well.