*nix では、引数としてファイル名を受け入れる多くのコマンド ライン アプリケーションがパイプも受け入れます。例：
anApplication file.txt
また、
anApplication | anotherApplication arguments
そして、「anotherApplication」の結果は、ファイルだったので「anApplication」にリダイレクトされます
これに相当する Windows が「名前付きパイプ」であることを知りました。コマンド ライン アプリケーションは、それを理解するために名前付きパイプを認識している必要があるのか、それとも、ファイルを引数として受け入れるコマンド ライン アプリケーションが代わりに名前付きパイプで動作するのか疑問に思います。
あなたはこれをかなり後ろ向きに持っています。正確には：
anApplication file.txt
これはanApplication、ファイル名file.txtを最初のコマンド ライン引数として実行します。
anApplication | anotherApplication arguments
これはanApplication、コマンド ライン引数なしで実行されます。標準出力は、コマンド ライン引数としてanotherApplication実行される標準入力に接続されます。argumentsこれは、Windows でも Unix バージョンとまったく同じです。名前付きパイプは、まったく異なる OS 機能です。
名前付きパイプは、ファイルのように見えるディレクトリ エントリですが、出力と入力をアタッチできるデータ ストリームのように機能します。
Windowsの名前付きパイプは、あなたが話しているものとは非常に異なります。名前付きパイプは、実際にはWindowsでサーバーアプリケーションを構築するのに役立つツールであり、「Unixドメインソケット」とほぼ同等です。
あなたの状況でanApplicationは、この状況で機能するかどうかは、コマンドラインにファイル名なしで実行されたときにアプリケーションがどのように反応するかによって異なります。（私はあなたの説明で配置について話している;別の答えによって指摘されるようにコマンドラインは後方にある。）アプリケーションstdinがコマンドラインなしで起動されたときにから読み取る場合、この種のシェルパイプ配置は機能する。代わりに、アプリケーションがヘルプメッセージを出力し、ファイル名なしで起動したときに終了する場合、このシェルパイプは機能しません。
これはcmd.exeの構文であることに注意してください。
この種のパイプリダイレクトはどのプログラムでも機能するはずなので、特定の質問に答えるために、標準のコンソールアプリケーションであれば、プログラムに特別なコードは必要ありません。
注意点が1つあります。プログラムがランタイムAPIの特別なキーボード監視フォームを介して入力を取得している場合、リダイレクトは機能しません。
私の知る限り、WindowsでもUNIXでも同じように機能します。より高度な Win32 コンソール API 関数がこれをバイパスする可能性があると思いますが、それについてはドキュメントを読む必要があります。