编写自己的IDE －－ 如何在图形界面中实时捕获控制台程序的标准输出

核心提示： 3. 连接其他人编写的，或者我们自己很久以前编写的控制台程序——我经常因为难以调用一个功能强大但又没有源码的控制台程序而苦恼万分，编写自己的IDE －－ 如何在图形界面中实时捕获控制台程序的标准输出(2)，这样好的功能是如何实现的呢？首先，如果我们想做的是用一个控制

3. 连接其他人编写的，或者我们自己很久以前编写的控制台程序——我经常因为难以调用一个功能强大但又没有源码的控制台程序而苦恼万分。

这样好的功能是如何实现的呢？

首先，如果我们想做的是用一个控制台程序调用另一个控制台程序，那就再简单不过了。我们只消把父进程的stdout重定向到某个匿名管道的WRITE端，然后启动子进程，这时，子进程的stdout因为继承的关系也连在了管道的WRITE端，子进程的所有标准输出都写入了管道，父进程则在管道的另一端随时“侦听”——这一技术叫做输入输出的重定向。

可现在的问题是，GUI方式的Windows程序根本没有控制台，没有stdin、stdout之类的东西，子进程又是别人写好的东西无法更改，这重定向该从何谈起呢？

还有另外一招：我们可以直接在调用子进程时用命令行中的管道指令“>”将子进程的标准输出重定向到一个文件，子进程运行完毕后再去读取文件内容。这种方法当然可行，但它的问题是，我们很难实时监控子进程的输出，如果子进程不是随时刷新stdout的话，那我们只能等一整块数据实际写入文件之后才能看到运行结果；况且，访问磁盘文件的开销也远比内存中的管道操作来得大。

我这里给出的方案其实很简单：既然控制台程序可以调用另一个控制台程序并完成输入输出的重定向，那我们完全可以编写一个中介程序，这个中介程序调用我们需要调用的工具程序并随时获取该程序的输出信息，然后直接将信息用约定的进程间通讯方式（比如匿名管道）传回GUI程序，就象下图中这样：

图中，工具程序和中介程序都是以隐藏的方式运行的。工具程序原本输出到stdout的信息被重定向到中介程序开辟的管道中，中介程序再利用GUI程序创建的管道将信息即时传递到GUI程序的一个后台线程里，后台线程负责刷新GUI程序的用户界面（使用后台线程的原因是，只有这样才可以保证信息在GUI界面中随时输出时不影响用户正在进行的其他操作，就象我们在Visual Studio中执行耗时较长的编译功能那样）。