Std - Handles
-
Hi All, I'm writing a service, that spawns several new processes. These new procs can either be gui apps or console apps. I redirect the std handles (stdout/stderr/stdin) via anonymous pipes as seen in well known msdn articles. After creating the new processes I wait for all my pipe-handles to become signaled. So far so good. Everything works fine with console apps, but if I start a gui app (e.g. notepad.exe), the pipe handle (stdout) gets signaled and a following ReadFile() blocks forever!. Okay, I tried to check for available data with PeekNamedPipe(). It's return value is always 0 (zero), so I skip the ReadFile(). But now the pipe handle becomes signaled ever and ever again and my cpu is at 100% with peeking the stdout pipe... I'm lost. What does Notepad.exe do with the std - handles? Any hints would be very appreciated!!! Frozen greetings from Germany, Jens :suss:
-
Hi All, I'm writing a service, that spawns several new processes. These new procs can either be gui apps or console apps. I redirect the std handles (stdout/stderr/stdin) via anonymous pipes as seen in well known msdn articles. After creating the new processes I wait for all my pipe-handles to become signaled. So far so good. Everything works fine with console apps, but if I start a gui app (e.g. notepad.exe), the pipe handle (stdout) gets signaled and a following ReadFile() blocks forever!. Okay, I tried to check for available data with PeekNamedPipe(). It's return value is always 0 (zero), so I skip the ReadFile(). But now the pipe handle becomes signaled ever and ever again and my cpu is at 100% with peeking the stdout pipe... I'm lost. What does Notepad.exe do with the std - handles? Any hints would be very appreciated!!! Frozen greetings from Germany, Jens :suss:
Maybe the problem is that you try to talk with GUI applications by the same way as with console applications. They should be handled by the other way. After creating the process use WaitForInputIdle() to wait for it's initialization. FindWindow, EnumWindows etc. allow to get window handle, after this talk with this window using PostMessage. Check out also windows hooks (SetWindowsHookEx). There is nothing to do with pipes here.
-
Maybe the problem is that you try to talk with GUI applications by the same way as with console applications. They should be handled by the other way. After creating the process use WaitForInputIdle() to wait for it's initialization. FindWindow, EnumWindows etc. allow to get window handle, after this talk with this window using PostMessage. Check out also windows hooks (SetWindowsHookEx). There is nothing to do with pipes here.
...sure, but my problem is the strange behavior. I don't know whether I start a gui- or console application, so I can't differentiate between them. If a gui applicaton doesn't touch the std-handles, why do they behave in such a strange fashion?
-
Hi All, I'm writing a service, that spawns several new processes. These new procs can either be gui apps or console apps. I redirect the std handles (stdout/stderr/stdin) via anonymous pipes as seen in well known msdn articles. After creating the new processes I wait for all my pipe-handles to become signaled. So far so good. Everything works fine with console apps, but if I start a gui app (e.g. notepad.exe), the pipe handle (stdout) gets signaled and a following ReadFile() blocks forever!. Okay, I tried to check for available data with PeekNamedPipe(). It's return value is always 0 (zero), so I skip the ReadFile(). But now the pipe handle becomes signaled ever and ever again and my cpu is at 100% with peeking the stdout pipe... I'm lost. What does Notepad.exe do with the std - handles? Any hints would be very appreciated!!! Frozen greetings from Germany, Jens :suss:
What about CreateProcess and waiting on the process handle? Actually, from your description I'm not entirely sure what you really want to do. /Mike
-
...sure, but my problem is the strange behavior. I don't know whether I start a gui- or console application, so I can't differentiate between them. If a gui applicaton doesn't touch the std-handles, why do they behave in such a strange fashion?