首页 文章

来自运行进程Win32Api的管道输出(stdout)

提问于
浏览
18

我需要使用windows api获取(或管道)已经运行的进程的输出 .

基本上我的应用程序应该允许用户选择一个窗口来管道输入,所有输入都将显示在控制台中 . 我也会看看如何在stderr上获得一个管道 .

重要提示:我没有使用CreateProcess()或其他方式启动该过程 . 该进程已在运行,我所拥有的只是进程的句柄(从GetWindowThreadProcessId()返回) .

3 回答

  • 0

    无论你想做什么,你都做错了 . 如果您正在与拥有源代码的程序交互,请为IPC创建一个已定义的接口:创建套接字,命名管道,Windows消息传递,共享内存段,COM服务器或任何您喜欢的IPC机制 . 不要试图将IPC移植到不打算进行IPC的程序上 .

    你无法控制该过程如何控制孩子 . You don't go in and change the carpets in somebody else's house .

    甚至不想考虑进入那个过程,尝试它的stdout,并且 CreateFile 指向你的管道的新标准 . 这是灾难的一个秘诀,将导致奇怪的行为和崩溃 .

    即使你能做你想做的事,what would happen if two programs did this

  • 4

    最简单的方法是在不造成任何不良影响的情况下执行此操作,如果您使用Adam暗示将现有stdout句柄与您自己交换的方法可能会发生,则可能会使用挂钩 .

    如果你将一个线程注入到现有的应用程序中,并用一个拦截的版本交换对WriteFile的调用,它将首先给你一个正在编写的内容的副本(通过句柄,源代码等等),然后将它传递给真正的:: WriteFile,而不是造成伤害 . 或者你可以通过只更换printf或软件正在使用的任何调用来拦截更高的调用(显然需要一些实验) .

    但是,当亚当说这不是你想要做的事情时,亚当是个好消息 . 这是最后的手段,所以在走下这条线之前要非常非常仔细地思考!

  • -7

    在搜索主题时遇到了来自MS的这篇文章 . http://support.microsoft.com/kb/190351

    在Unix上管道输入和输出的概念是微不足道的,似乎没有很好的理由使它在Windows上如此复杂 . - 卡尔

相关问题