Registry for IPC

[Sam Hobbs]

How reliable is the registry for IPC?

I am using the registry in a developer's tool I wrote for myself to pass a parameter to and return a value from a program. I assume that the registry is not a reliable IPC mechanism for commercial software and such, but I am curious if anyone has had experience with this.

I am storing a filename in the registry then creating a process. I was undecided about how to pass the filename to the child process and then I realized that the program could get the filename from the registry. So the program also returns an error message in the registry if there is an error.

I would not use the registry for communication between two processes during the execution of both, but in this situation (where something is passed prior to execution of the child process and potentially returned by the child process for use after it's execution) it seems reasonable.

The obvious solution is to pass the filename in the command line, but in this situation, the program is actually a DLL that is injected into the other process, so the command line is not an option.

The potential problem is that the registry is cached, so I am not sure if either process is guaranteed to get the current value. The RegFlushKey function seems to provide that guarantee.

[poojapatel]

Hi,

The good methods for IPC is Named pipe, mapped memory. there are many other method but i had always used this two method only.

go through MSDN and you will get the example of mapped memory.

reply if you get your solution and feel free to ask furthur query.

Rate the article if you like it.

[MikeAThon]

If I understand your question correctly, then one of the concerns you are facing is that both of the two processes might not be actually executing at the time when you want to send information from one to the other (although they might be). Because of this, you are using a pre-agreed location for both processes (here, the registry) for exchanging information, almost like a rendezvous server or a relay server.

You might have toyed with the idea of changing this architecture so that both processes are executing. For example, you currently write the filename in the registry and then start the other process (which retrieves the filename from the registry). Instead, you could have started the the other process, WaitForIdleInput, and then used normal IPC mechanisms to exchange information. I assume that you toyed with ideas like this and others, and rejected them for good reasons not relevant here.

So, in direct answer to your question, the only issue that I know of in relation to use of the registry is the issue you have already addressed: caching.

Is there a reason why you do not use a more ordinary place to store the filename (and the returned value)? For example, why not simply write out a .txt file from one process that the other process reads? I/O flushing still might be an issue, but a pre-agreed upon location for the files should not be difficult, since the first process must necessarily know where the second one resides, if it's able to start it.

Mike

[Sam Hobbs]

If I understand your question correctly, then one of the concerns you are facing is that both of the two processes might not be actually executingNo. I am sorry that I was not clear.

One way to say what I am asking is that I am asking for anything relevant anyone can tell me that is not obvious and not in the documentation, or at least that is not easily found in the documentation.Instead, you could have started the the other process, WaitForIdleInput, and then used normal IPC mechanisms to exchange information.Actually, starting the process first is a bad idea for this, since I don't need to; I am writing to the registry first, and that is a safer way to do things.Is there a reason why you do not use a more ordinary place to store the filename (and the returned value)?The filename is stored in the registry regardlous of how the child process gets it. The parent process stores the filename in the registry for the convenience of the user. I am sorry I was not clear about that; I tried to explain that the descision to store the filename in the registry was made before any attempt was made to decide how to pass it to the child process.For example, why not simply write out a .txt file from one process that the other process reads?If I do that, then I would have the same exact problem with the filename of the txt file.

So let me explain again that I am asking for any information that is not easily determined by reading the documentation.

I will explain my current application a bit more, although I think the details are not important. I have written a UI version of the withdll sample provided with Microsoft Detours. The withdll sample uses Detours to create a process to be monitored and inject a dll into the process. My program is easier to use than the console-based withdll sample. The sample trace program traceapi (a dll that monitors uses of the Windows API) uses a complex utility syelogd to get messages from the process being monitored to the syelogd console window. My version of monitoring dll simply logs messages to a log file, which makes things much easier. It is the log filename that I am passing to the dll. My UI progranm uses a form for specifying the exe, dll and log filenames. I could use a hard-coded filename for the log filename, but using the registry in the manner I do is an easy way to allow the log filename to be specified in the UI. I am returning an error message only for catastrophic problems, such as the log file cannot be opened. If the log file is opened, then I write errors to it instead of the registry.

[kirants]

What you are doing is pretty standard way of doing such things i.e. placing configuration information in the registry. This is commonly followed practise, where in a software installed it's own registry key under HKLM(or HKCU)/SOFTWARE/{company name} and uses it to store application or per user configuration settings.

[Sam Hobbs]

What you are doing is pretty standard way of doing such things i.e. placing configuration information in the registry. This is commonly followed practise, where in a software installed it's own registry key under HKLM(or HKCU)/SOFTWARE/{company name} and uses it to store application or per user configuration settings.Yes, of course it is common for an application to store configuration data that it uses. You did not read what I wrote enough to get the difference. The difference is that the configuration settings are also used by another process, and that is not common. I am asking about use of the registry for IPC, which is not common.

Your comments provide very fundamental information that is easily obtained simply by reading the documentation. I am not asking for comments such as that. Such comments clutter the thread and make it more difficult for others that have something useful to say.

[kirants]

Yes, of course it is common for an application to store configuration data that it uses. You did not read what I wrote enough to get the difference. The difference is that the configuration settings are also used by another process, and that is not common. I am asking about use of the registry for IPC, which is not common.

Well.. I did read it enough to grasp what you are saying :) What I am saying is about software configuration settings. A software is not necessarily one single application. Several applications in a software suite can make use of common settings, which is fairly common practise.

My apologies if my comments polluted this thread, however, my intention was surely not to do so.