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

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

Bug ID: 46734
           Summary: EditPad Pro 7: Cannot read/capture host (Linux)
                    application's stdout/stderr to display in its message
                    panel
           Product: Wine
           Version: 2.19
          Hardware: x86
                OS: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: -unknown
          Assignee: [e-mail]
          Reporter: [e-mail]
      Distribution: ---

Created attachment 63726
  --> https://bugs.winehq.org/attachment.cgi?id=63726
Python script to write "Hello World" to stdout.

Distribution: Linux Mint 17.3 ; 32-bit ; Trusty ; MATE Desktop
AppDB App: EditPad Pro 7
AppDB Entry: #8392
Wine Ver w/o Bug: 2.18 (devel) & 2.04 (stable)
Wine Ver w/ Bug: 2.19 (devel) & 3.04 (stable) & 4.0 (stable)

Steps to reproduce:
  * Download EditPad Pro free trial version 7.6.5 and install
    - URL: http://download.jgsoft.com/editpad/SetupEditPadProDemo.exe

* Install Wine 2.18 (devel)
  * Run EditPad Pro (EPP) from Wine
    - Executable: EditPadPro7.exe
  * From the EPP menu, go to Tools -> Configure Tools
  * Import the EPP Tool configuration file
    - Attachment: RunWithPython.ini
  * Open the Python source file
    - Attachment: hello.py
  * From the EPP menu, go to Tools -> Run w/ Python
  * Will see the Python script's output in EPP's message panel as expected
    - See attachment: EPP_Wine2.18_WithoutBug.png
  * See Wine 2.18's terminal output file to see that the output did not go to
the terminal as expected
    - Attachment: Con_Wine2.18_WithoutBug.out

* Install Wine 2.19 (devel)
  * Run EditPad Pro (EPP) from Wine
    - Executable: EditPadPro7.exe
  * Open the Python source file
    - Attachment: hello.py
  * From the EPP menu, go to Tools -> Run w/ Python
  * Will not see the Python script's output in EPP's message panel
    - See attachment: EPP_Wine2.19_WithBug.png
  * See Wine 2.19's terminal output file to see that the output went to the
terminal instead of EPP's message panel
    - Attachment: Con_Wine2.19_WithBug.out

Note: This bug *may* be related to bug 23596. However, bug 23596 is reported
against Wine version: 1.2-rc7.

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

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

[e-mail] changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #63726|Python script to write      |EditPad Pro Tools
        description|"Hello World" to stdout.    |configuration file.

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

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

--- Comment #1 from [e-mail] ---
Created attachment 63727
  --> https://bugs.winehq.org/attachment.cgi?id=63727
Python script to write "Hello World" to stdout.

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

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

--- Comment #2 from [e-mail] ---
Created attachment 63728
  --> https://bugs.winehq.org/attachment.cgi?id=63728
EditPad Pro screenshot under Wine 2.18

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

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

--- Comment #3 from [e-mail] ---
Created attachment 63729
  --> https://bugs.winehq.org/attachment.cgi?id=63729
Wine 2.18 terminal output.

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

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

--- Comment #4 from [e-mail] ---
Created attachment 63730
  --> https://bugs.winehq.org/attachment.cgi?id=63730
EditPad Pro screenshot under Wine 2.19

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

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

--- Comment #5 from [e-mail] ---
Created attachment 63731
  --> https://bugs.winehq.org/attachment.cgi?id=63731
Wine 2.19 terminal output.

[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.