This is how I do IPC.

[WaitingForZion]

Although I could not successfully adapt my first complete implementation of an IPC mechanism in C++ to AutoIt through plugins, I would like to suggest a very simple model of IPC on which the implementation was based, so that others with the time available and the idea not yet conceived can implement it themselves according to their own needs. The model works perfectly when implemented correctly. In fact, my IPC plugin did not work as perfectly as intended, not because the implementation of its workings were flawed, but because its interface with AutoIt was flawed, seeing before testing it with AutoIt, it worked quite well as a small C++ class library. The model is very simple, so I do not expect praise upon praise for the concept, but I cannot deny that despite my lousy coding skills and poor creativity, I did indeed imagine it myself.

One need only implement a manager for invisible windows whose messages suffice to provide the IPC mechanism for transferring data of any kind and length. In order to send and receive this data from within the main thread, as is the case with AutoIt scripts since only one thread is permitted, the window manager must not only operate in a separate thread, but communicate with the main thread, and permit the creation and destruction of windows used to mediate the communication as directed by the main thread. Therefore, there should be a window that is responsible for creating and destroying the others upon receiving messages representing those directives. This is necessary because only the thread that creates a window can later destroy it or process its messages.

Beside that window there must be another kind of window, of which there can be many for a given process, responsible for sending and receiving data through the WM_COPY message. It must convey a reference to itself in all transmissions, and must respond to ordinary yet user-defined windows messages asking whether it is indeed such a window and to what protocol it belongs. Now all this functionality should be encapsulated for ease of use within classes, so that it is not brought to user's mind what is actually happening. I've called instances of these classes augerates, but you can call them whatever you like.

But upon this set of classes there should be built one last layer of abstraction, which utilizes the open system discussed so far to implement the appearance of a system of closed connections between applications. For each process, there ought be at least one augerate called a senator. Senators in different processes communicate with each other to provide the name of the process they represent, and to establish connections, creating a phone object in each of the two process whose senators have agreed on a connection. These phones must simply provide methods to send and receive data between each other, and methods to mutually disconnect.

Both the senator augerate and the phone augerate must have a protocol that is distinct from each other. Methods in the senators should be provided to test for all process ready to communicate by enumerating through each window, inquiring of its protocol and briefly expecting a response. Upon the appropriate response, the process can then inquire of the name of the senator, and make connections with the process it represents.

To take it one step beyond my own implementation, you could implement a service to keep track of all the existing senators, so that you can immediately connect to it by its window name, and rapidly retrieve information about all the senators, instead of briefly waiting through the silence of non-senator windows.

Without getting too specific or detailed, those are the basic of the augerate IPC model. It may not be impressive or sophisticated but it works perfectly. Just make sure to avoid memory leaks and deadlocks. If anyone wants my sloppy source code (it may not even be the same as when it worked; I don't know; I could have changed it) just PM me and I'll be glad to send it to you. I'm in college now so I'm learning how to code properly, but I wrote it before I took my first programming class. Let me know if my description is not clear enough so I can give better ones in the future.

[Zibit]

I think an IPC should be in the kernel.

i like to develop Operating System's and in my OS i ALWAYS add 200 bytes to memory for each process for inter-process relations. Each line inserted to that memory has a specific Address for another process, The address in fact is the other process NC&PID (Number of Communications, so they wont have conflicts with other communications) and the other reads the commands and the command gets deleted for memory freeing.

Its quite simple and effective, so my point is. You cant make an effective IPC without kernel support because kernel can call functions when a communication line has been inserted. the only other way you can make an effective ICP is TCP server which isn't effective at ALL.

[Valik]

Please don't resurrect 4 month old threads to inject useless and irrelevant opinions into them.