How to Write a program to communicate between two processes using the pipe.

I am learning operating system, this is a really big trouble for me, i do not how to write that kind of program above in C++, if anyone know the answer please post complete "code" that write in C++, this is urgent, thank you so much, this is question:
Write a program to communicate between two processes using the pipe as follows:
A process read from the file consists of multiple consecutive sequences, each sequence of the operations +, -, *, / and 2 mathematics
out. For example, the file will save the string like this:
2 + 3
1 to 2
4 * 6
15 / 3
Then the first process of the first sequence send(transmit) data for the second process . the second process
perform calculations and return the resulting string back to the first process to record the
file as follows:
2 + 3 = 5
1-2 = -1
4 * 6 = 24
15 / 3 = 5

Begin with:
http://msdn.microsoft.com/en-us/libr..._pipes_for_ipc
http://msdn.microsoft.com/en-us/libr...(v=vs.85).aspx

Quote:

---

if anyone know the answer please post complete "code" that write in C++, this is urgent, thank you so much

---

FYI. If this is really urgent, please follow the Victor's advice.

Thank you anyway.

However, please don't quit the thread. Try to start some real coding, identify your problems, post your code (snippets, or better compilable project), and people here will be glad to answer your specific questions.

Interesting links, Victor. Is there any advantage to using pipes as opposed to using WM_COPYDATA ?

Quote:

---

Originally Posted by Mike Pliam

Interesting links, Victor. Is there any advantage to using pipes as opposed to using WM_COPYDATA ?

---

You reread the links posted and extract information yourself.

I have compiled and run the examples given by M$. The coding is pretty advanced and, although I found it works OK, I am concerned about using this approach without soliciting the opinions of those more experienced than I am.

I have been having trouble processing errors from a DLL. I have considered using MessageBox(...), files, PostMessage(WM_COPYDATA, ...), sockete, and DLL callbacks, but I have never tried using pipes which I have come to think of as somewhat arcane.

My question is: Have any gurus had experience using pipes to send error messages from a DLL to an application? What is the best way to handle DLL errors? One thing is certain, throwing exceptions across DLL boundaries is a big NO NO!

This is an old topic that has come up many times before. The web is replete with comments regarding error processing in DLLs. But I have not come across any good code examples dealing with the problem.

FWIW, I had started an old thread that posed a similar question, but my question was somewhat misinterpreted as how to debug a DLL. I am NOT asking how to debug a DLL, rather, how to build an interface with an MFC App and DLL that can feed back messages to the App user during runtime.
http://www.codeguru.com/forum/showth...r+messages+dll

Your thoughts greatly appreciated. :)

Quote:

---

Originally Posted by Mike Pliam

Interesting links, Victor. Is there any advantage to using pipes as opposed to using WM_COPYDATA ?

---

WM_COPYDATA:

Pros:
1. Faster/very easy to implement for a developer.

Cons:
1. Slower to run (implemented on a user level, goes through a message pump).
2. Requires a window (HWND) to accept messages (i.e. won't work for a console process, or a service.)
3. Doesn't work across sessions or desktops.
4. Less reliable (SendMessage may fail for no apparent reason.)
5. Easy to run into a deadlock between threads (by using SendMessage) or a race condition (with PostMessage.)

Pipes:

Pros:
1. Works across sessions and/or various desktops.
2. Runs faster (implemented on a kernel level via memory mapping).
3. Can send larger amounts of data.

Cons:
1. Quite challenging to implement.
2. Difficult to debug.
3. Lack of reliable documentation. MSDN samples are often buggy.

Thanks ahmd. I have been trying implement named pipes to pass error messages from a DLL using modifications of the code provided by M$:

http://msdn.microsoft.com/en-us/libr...(v=vs.85).aspx

http://msdn.microsoft.com/en-us/libr...(v=vs.85).aspx

I opted to rewrite the pipe client and pipe server codes as two separate classes, and to convert both files from unicode to multibyte. When these classes are independently implemented in separate Win32 console apps, they work just fine. The only problem that I encountered was that of trying to use the DWORD WINAPI InstanceThread(LPVOID); callback function in my CNamedPipeServer class. I finally just took it out of the class and set it as a free-standing C-language function.

Encouraged by my initial success, I tried using these classes int a DLL and it's calling app. But using the pipe client in a DLL class and the pipe server in a Win32 app calling class, doesn't work and all I keep getting is the message:

Quote:

---

Could not open pipe. GLE=2

---

Now, if I try to run the pipe client without booting the pipe server app in the non-dll setting, I get the same message. As soon as I boot the pipe server app, the message disappears and everything is working. So it appears that my problem in the dll-app setting is my inability to properly initialize the server in the main app. Another problem is how to capture the messages received by the server, but that should not be too hard to do. :)

I have attached a Win32 demo of my named pipe classes which works. I have also attached a demo app to show my problem sendiing messages through a named pipe from a dll to a calling app.

Your thoughts greatly appreciated.

Listen, just curious, why would you want to rewrite it from using unicode to multibyte? That seems pretty masochistic. Every system since Windows 2000 uses Unicode internally.

As those MS examples go, I saw those too and I'd stay away from copying them one-to-one. As you can see by the number of comments below, they are far from perfect. What they fail to show is that one needs to properly configure the DACL for each pipe server (or lpSecurityAttributes parameter in CreateNamedPipe), since otherwise you may have a conflict of a less privileged user process (or a pipe client) trying to connect to a pipe server that is most certainly running with higher privileges (as a local service).

Quote:

---

Every system since Windows 2000 uses Unicode internally.

---

You had to say "since Windows NT 3.1" actually. :) Windows NT OS family made Unicode-based since the very first version released in 1993.

Quote:

---

otherwise you may have a conflict of a less privileged user process (or a pipe client) trying to connect to a pipe server that is most certainly running with higher privileges (as a local service).

---

A service may expose the pipe with NULL DACL but impersonate client to avoid this privilege elevation. It depends on design points.

Quote:

---

Originally Posted by Igor Vartanov

A service may expose the pipe with NULL DACL...

---

Maybe I'm mistaking, but isn't it actually "frowned upon" to set a NULL DACL? It sure is easy to program but it may become a security breach.

Let me quote myself:

Quote:

---

Originally Posted by Igor Vartanov

It depends on design points.

---

Quote:

---

...why would you want to rewrite it from using unicode to multibyte ?

---

For the obvious reason that just one line of code in the Pipe Client class needed to be changed, whereas the project I plan to use this methodology in has hundreds of lines of code that would need to be changed. To that point, I am slowly and painfully rewriting the target project to be Unicode compliant, but that is another topic.

As far as DACL being set to NULL, that is a very good point. But I don't think it would matter in this test project that is run on the same machine with administrative privileges (or am I wrong about that).

In support of that view:

Quote:

---

lpSecurityDescriptor
A pointer to a SECURITY_DESCRIPTOR structure that controls access to the object.
If the value of this member is NULL, the object is assigned the default security
descriptor associated with the access token of the calling process. This is not
the same as granting access to everyone by assigning a NULL discretionary access
control list (DACL). By default, the default DACL in the access token of a process
allows access only to the user represented by the access token.

---

see: http:msdn.microsoft.com/en-us/library/windows/desktop/aa379560(v=vs.85).aspx

In any case, it will be an easy task to rewrite this small test project in Unicode, but I strongly suspect the result will be the same because I don't think that is the problem. To verify that impression, I have attached UTF-16 versions of the Named Pipe demos with and without an associated dll.