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.
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..
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.
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.
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.
