[Bug 46734] EditPad Pro 7: Cannot read/capture host (Linux) application's stdout/stderr to display in its message panel

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=46734

Andrew Nguyen  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1
                 CC|                            |[e-mail]
                URL|                            |https://web.archive.org/web
                   |                            |/20190928104526if_/http://d
                   |                            |ownload.jgsoft.com/editpad/
                   |                            |SetupEditPadProDemo.exe
    Regression SHA1|                            |7eb785416193f7ca154872222b9
                   |                            |cfcd3db7a7418

--- Comment #6 from Andrew Nguyen  ---
After reproducing in a VM the exact environment described, I performed a
regression test, which identified the following commit:

7eb785416193f7ca154872222b9cfcd3db7a7418 is the first bad commit
commit 7eb785416193f7ca154872222b9cfcd3db7a7418
Author: Jacek Caban 
Date:   Wed Oct 4 15:18:29 2017 +0200

server: Use server side named pipe implementation in byte mode.

Signed-off-by: Jacek Caban 
    Signed-off-by: Alexandre Julliard

However, I think the fundamental issue is that the current implementation of
named pipes in the server no longer relies on allocating a Unix socket pair.
Thus, if a named pipe is allocated to capture the output of a process spawned
from Win32, there's no longer an fd that can be mapped to a Unix process's
stdout/stderr.

This issue may very well be a WONTFIX if there's not an easy way in the current
implementation to emulate one end of a named pipe for use by a Unix process.