   [win32/C++] IPC using WM_COPYDATA
  Hello, I am trying to set up some communication between two win32 processes. The approach I am thinking of seems 'onorthodox' (or not?) so please criticise my approach if I am abusing the WinAPI here..I have two processes which are kind of in a master/slave role. Process 1 will send a message to process 2. Process 2 starts executing this (lengthy) request. Process 2 will send back progress messages while doing this. At the end it will return some kind of result. The original request should be synchronous, process 1 does not return from the request until it is done. I'm aiming for using a minimal amount of threads per process.The data being sent in the messages are just 'big strings'. I rather like the windows messaging API so I prefer to use that over other IPC alternatives like sockets/mailslots/named pipes/shared memory/etc. Since I have two separate processes I need a way to pass the strings. The WM_COPYDATA message seems to fit the bill perfectly. (I realise it uses shared memory in its implementation). It seems WM_COPYDATA has been around since win95, is it still a 'common technique'? Any application level information about the requests is serialised into the strings which are sent back and forth. So I'll basically only need the WM_COPYDATA message for IPC.Here's my idea. Assume everything has started up properly. Process 1 uses SendMessage (I'll probably use SendMessageTimeout, not relevant) to send a string to process 2. SendMessage blocks so it is a synchronous call. Process 2 has a message-only window and it is pumping the loop for that window. When it receives the WM_COPYDATA message it starts doing some work. During this time it will not accept any more messages. While doing this work process 2 reports progress by calling SendMessage. (It is not possible to use WM_COPYDATA with PostMessage, which makes sense.)The possibly onorthodox part is this: process 1 is still blocking on its SendMessage call. So how can it process the incoming progress message? According to the msdn docs, a thread blocked by SendMessage will still accept nonqueued messages. So the progress messages will be handled just fine by process 1. The same goes for the eventual 'result message'. The whole 'transacation' ends when process 2 finally returns from the work. Process 1 will now return from the SendMessage call and should have already received and stored the result.This almost makes it seems as though there is some multithreading going on but each process only needs one thread for this mechanism. I realise that if process 1 is a GUI app it will start to freeze and all that. Let's just think of both processes as console apps for discussional purposes (discussional is not a word I know :) ).Is this a good approach? I already implemented a prototype and 'it works'. But everyday the phrase 'it works' is getting less meaning for me :). I am talking about the stability/maintainability/elegance/etc aspects, this is supposed to be production-level code, not just an experiment. What are the potential pitfalls with this?Thanks for reading this wall of text, I thank you for- and am very curious about your replies.   
  Seems like you've got it well figured out. You might want to employ some security in the transaction. Using WM_COPYDATAAs for how a thread blocked by SendMessage will still accept nonqueued messages. Accepting a message is not the same as processing a message. The thread blocked on SendMessage will accept nonqueued messages but wont process them until it yields. Blocked is blocked."Nonqueued messages are sent immediately to the destination window procedure, bypassing the system message queue and thread message queue." Nonqueued Messages. The various ways of sending a messageQuote:When SendMessage() is used to send a message to a window in *this* thread, the window procedure is called immediately by SendMessage().When SendMessage() is used to send a message to a window is *another* thread, the message goes to a "separate place" that is not the message queue. But the message will only be sent (i.e., the window procedure will only be called) when the thread that owns the window calls a Win32 API function that directly or indirectly looks at this "separate place" for queued messages and automatically calls the window procedure.See also When can a thread receive window messages?You could use SendMessageTimeout and not worry about it.   ;  Thanks LessBread. Your reply made my day :) Especially that last link dispells any doubts I had left. I recently started following Raymond Chen's blog, I think I might dig through his archive some more now.Thanks again :)   