nindoja

Hello. Basically, my main program needs to open multiple programs and pass data back and forth between them. Just for your information, the programs were written by myself, so if I need to place the source in the main program that is no concern. Upon googling for a way to pass data between two programs, I decided that the easiest way to do this would be threads. The only problems with threads is that I need a console window for each thread, and I could not, by way of MSDN and google, find a way to open a new console window for each thread. If there is a better way to accomplish this than threads, I would appreciate that as well, as I am not required to use threads.

Dameon

Threads are components of single programs (processes). Some more information on why you need multiple programs running would be helpful...communicating between processes is more difficult than communicating between threads, but whether or not you truly need separate processes is a mystery.

__________________
MD5(sig) = bcef75433db02e9ad9bf81d6f7c5c270

nindoja

What I am building is a networking application that receives data from the server, then based on the first part of the data, sends the information to the console window of the specified program. That program then processes the information and gets user input back from the user. The user input is then sent back to the original program, which then sends the data back to the server to be used. The reason I am doing it this way is because I cannot bind one program to many ports, so I thought this would be the best way to do so. If it isn't, I would appreciate ideas.

grumpy

Threads are unrelated to inter-process communications.

There are many different means of achieving interprocess communications ranging from the simple (eg program A writes data to a file, while program B polls until the file exists and then reads it), through to slightly more advanced (eg sockets), somewhat more advanced (eg mailboxes), and the reasonably advanced (eg using a complete distributed framework based on something like CORBA or DCOM).

The scheme you use depends on a lot of things, and (depending on requirements) you might use more than one scheme. Examples of the sorts of questions you need to ask include;

1) What operating system(s) are your clients and servers running on? This can limit your choices because, for example, windows supports a number of means of IPC that unix does not, and vice versa. There are also some IPC mechanisms that are specific to only one operating system, so you can't use them if you need communication between two applications running under different operating systems.

2) Are you aiming to send a small amount of data a large amount of data, and how often are you looking to do it? Some methods are better suited to sending small amounts of data often, but fail miserably if you use them to send large amounts of data.

3) Are you trying to send data to only one recipient, or multiple recipients? This can mean the difference between direct peer-to-peer communications vs broadcasting.

4) Does the sender need confirmation that the data has been received?

etc etc.

nindoja

The programs don't actually have to be compiled executables, I could just place the code in a function, I just need a way to open a console window for each one. That aside, the client and the server will be running windows. The data is rather small, just a string, and there will only be on receipient for each message, and there will be no need for confirmation. I'll look into what you suggested, although based on previous knowledge, I'll probably end up using sockets.

P.S. This is just a personal project, so I don't have to do it really fancy, although I might upgrade it later once I have the foundation down.

The Dark

Does it have to be console windows? You could make your program a normal Windows application, create two windows and output the text into multiline edit controls.

para

Interprocess communication can be achieved with pipes ( http://www.cs.cf.ac.uk/Dave/C/node23.html ). Basically a pipe is a buffer managed by the operating system, you can read from it and write to it. Each operation (read/write) has an associated file descriptor.

http://en.wikipedia.org/wiki/Pipes_and_filters
http://www.tin.org/bin/man.cgi?section=2&topic=pipe

nindoja

The_Dark: It doesn't have to be, but I don't have enough knowledge of the Win32 API to use windows applications.

Para: Pipes would work, except I need to write to the other processes' output, not to their input.