我有一个问题徘徊在 JVM 和 Windows 之间的某个地方，我担心我对任何一个问题都不够了解，无法很好地提出这个问题，但是这里有：
我有一些非 Java 代码（它是 SAS SCL 代码，但我希望不需要 SAS 知识来回答这个问题）启动 Java 进程并将其 STDOUT 和 STDERR 流重定向到 SAS 的命名管道概念. 该 Java 进程将一些文本写入 System.out。然后 SAS 代码尝试从管道中读取该文本。
这在许多系统上已经工作了很长时间，但最近在 Windows 上出现了问题。这些问题可能特定于 Java 7（尽管也可能是 Java 6），和/或可能特定于 Windows 7 及更高版本。
有两个上下文可以调用此代码。在一种情况下，它运行良好；另一方面，SAS 没有看到 Java 进程的任何输出（根据其他输出，它似乎正在成功运行）。当它不起作用时，“fread”调用似乎会阻塞，直到 Java 进程完成；但是，该调用仅返回“EOF”。
（特别是：如果从 SAS Workspace Server 进程运行，它可以工作。如果它从批处理模式 SAS 运行，它不会。我不清楚这两个环境之间到底有什么不同，尽管进程所有者不同。 )
在它不起作用的情况下，我会短暂地看到一个 Windows 控制台窗口，其中包含 SAS 应该是但没有看到的 STDOUT 输出。在它工作的情况下，我看不到这样的窗口，但这可能是由于该进程在与我登录的用户不同的操作系统用户下运行的结果。
鉴于这一切，我想我的问题是：JVM 如何确定 STDOUT 的结束位置？JVM 是否可以将输出写入控制台窗口，而不是连接到 SAS 管道的所需 STDOUT 流？JVM 在做出此决定时所关注的环境的突出方面是什么？
编辑 2013-02-20：
进一步调查表明，在启动 Java 进程时，SAS 会执行以下操作：
cmd /C <java command>
这是在运行代码的两种上下文中完成的。
我使用 Java 5 进行了测试，其行为与 Java 7 相同：这似乎不是特定于 Java 版本的。
Windows 7+ 是通用线程。我猜这与Windows 7/Windows Server 2008 R2 中添加的新 ConHost.exe 进程有关。