On 12/22/19 6:40 AM, Gabriel Ivăncescu wrote:
On 12/21/19 5:34 PM, Bruno Albuquerque wrote:
Thanks. That led me to the init_user_process_params() where it seems stdin/stdout/stderr are mapped to the running Windows program. I could not find any code that would do anything with other inherited opened fds and that led me to think that there is really no special handling and it somehow just happens to work with a winelib program (most likely because it has a bigger Linux surface to it).
Based on this, I guess what I really want to know is:
1 - Does a non-winelib Windows program have access to opened fds inherited during a fork/exec of Wine? 2 - If so, is there a way to actually use those fds in the Windows program?
Hi Bruno,
I'm not sure if this is feasible to you, but keep in mind that "Windows programs" ran under Wine are technically still running on Linux. So you still have access to Linux syscalls (but not libraries, unless you load them manually, which is not worth it).
One possible hack to do this in a "generic" way would be:
Use an exception handler in your app.
Call the 'uname' system call to make sure the returned sysname is
'Linux'. If the syscall results in an exception, then it's obviously not running on Linux (it could be running on Windows), so do the necessary thing there.
There's also wine_get_host_version(), exported from ntdll, which would probably be easier.
In order to get access to file descriptors in the first place, you can use the counterpart wine_server_handle_to_fd() [also exported from ntdll].
- If it's 'Linux' then mark it so and simply use Linux syscalls to use
the fd and read or write to it. You can use inline assembly for this purpose.
If your program is not intended to run on non-Linux environments then you can skip the first two steps. I realize it's a hack but without winelib I don't think there's much else you can do.