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.
Last edited by Sat; 10/05/05 11:50 PM.
