https://bugs.winehq.org/show_bug.cgi?id=46734 Andrew Nguyen <arethusa26(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Ever confirmed|0 |1 CC| |jacek(a)codeweavers.com URL| |https://web.archive.org/web | |/20190928104526if_/http://d | |ownload.jgsoft.com/editpad/ | |SetupEditPadProDemo.exe Regression SHA1| |7eb785416193f7ca154872222b9 | |cfcd3db7a7418 --- Comment #6 from Andrew Nguyen <arethusa26(a)gmail.com> --- 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 <jacek(a)codeweavers.com> Date: Wed Oct 4 15:18:29 2017 +0200 server: Use server side named pipe implementation in byte mode. Signed-off-by: Jacek Caban <jacek(a)codeweavers.com> Signed-off-by: Alexandre Julliard <julliard(a)winehq.org> 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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.