[Wine] linux <-> wine program?

[Martin Gregorie]

On Wed, 2011-03-30 at 05:08 -0500, bcw wrote:
> I have a Windows routine that runs under WINE.  Currently it's a
> console app which receives input, processes, and returns an answer.
> 
> I would like it to keep a connection open and read from it when my
> linux program sends new input, and return the result, and wait for
> more.
> 
> I have the idea of the Windows program opening a 'file' to read from,
> perhaps a accumulating a character at a time (and sleeping
> periodically to avoid taking up all the cpu cycles), and when a
> specific character arrives as a flag processing what has been read,
> writing results to another 'file', and returning to reading from the
> input.
> 
You'd be better off using a network socket since both Windows and *NIX
systems can handle them.

> How can I do this?  On the linux side, it's a pipe.  Can I read a
> linux pipe from a WINE program?
> 
It would have to be a named pipe and AFAIK that's a *NIX-only concept -
hence my suggestion of using a network socket. The overheads are minimal
since you'd use the local loopback network, 127.0.0.1 to handle the
traffic.

> Without a Windows server (under WINE), can I read and write to network
> connections from my Windows program?  What mechanism can do that?
> 
Since your Windows program is currently acting as a textual server for
the user via the console, why not saw it in half, using its main logic
as the server and, if you still need console input, convert the console
interface into a really simple client that would use the socket
interface to do its processing.

The server would have to:
- listen for and accept incoming connections.
- listen for disconnections and action them as clients disconnect
- accept incoming request messages, process their content as though
  it had come from the console, and send a response message containing
  the results rather than writing them to the console

That's how I'd do it (and have done it many times), and I'd base the
server round the poll() function - that's bog-standard POSIX and doesn't
require any use of threads, POSIX or otherwise. Doing things this way is
pretty straight forward and adds a great deal of flexibility, since the
client processes no longer have to be on the same box as the server.
 
> I don't need a GUI at all, and I don't need to do anything more than
> what the above suggests, and I have no other reason to learn about
> Windows programming (or time).
>
In that case, why not implement the server as a native Linux process?
Or translate it to Java, Python or Perl (if you can write any of those)
so the same code can run virtually anywhere. 

Martin