For example, if I want to write a daemon program in C# that uses anonymous pipes to communicate with programs written in another language, is this both possible and feasible?

I ask because I intend to write the code in a language that can cross-compile to several targets (Haxe). I intend to write an application which compiles code on the fly, runs it, and communicates with it over a period of time, and other targets compile faster than C# (any scripted language for example), I can easily write common platform agnostic client code in Haxe, but is this possible and feasible in C# using the AnonymousPipeServerStream?

I see that the client handle is simply a strIng, what is this string for? How is it used to initialize the AnonymousPipeClientStream and can I create a cross-platform abstraction in client programs that similarly initializes and consumes the client handle from the .NET server application?

Most languages support subprocessing by running a shell command and returning an object with handles for the stdin, stdout and stderr streams for a program. This is, for example, a prerequisite to initializing an AnonymousPipeServerStream, the underlying program simply does something with a pipe handle, presumably this is more performant than using System.Diagnostics.Process.Stdin/Stdout?

How is this different than an anonymous pipe?

  • @RobertHarvey I've already read this. And I read the MSDN docs on the Anon Pipe win32 API. What I want to know is how it differs from just taking Process.Stdin/Stdout for IO, from reference source I can tell for most higher level language, without some FFI it's not possible to do exactly what Pipes do, as they use kernel level APIs. Commented Feb 9, 2020 at 20:24
  • @RobertHarvey do you agree that looking at the ref source it looks like Anonymous pipes just use some low level bindings (NativeTools or some other API that's looks like it's a very low level C# API) for redirection of STDIN/STDOUT? I'm wondering how this is different than just directly using those Streams. Commented Feb 9, 2020 at 20:26
  • 1
    Pipes are a different concept than the stdin/stdout stream. There is an OS object that is created. If another app binds to that pipe (easier with named pipes), then you should be able to communicate with it using the pipe API. Pipes go through the file system API. Commented Feb 28, 2020 at 17:15

2 Answers 2


Based on further research, the short answer (to the primary question) is yes.

The answer to the second question depends on the language, for example, HashLink does indeed use Anonymous Pipes for subprocesses.


If the goal is to communicate between a c# program and some other program, I would suggest using some kind of messaging library rather than pipes.

The problem is that pipes do not handle messages, just bytes. So you would probably need to implement your own protocol on top of the pipe, and implement this again for each language you want to target.

Take ZeroMq as an example of a message queue. It has quite a few language bindings already available, and I suspect that at least some messaging frameworks support pipes for transport. But there are many other libraries/protocols to chose from.

You probably also want to consider serialization, this is much easier to manage with a good serialization library, and I suspect most languages has support for the most common formats, like json.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.