Zebediah Figura z.figura12@gmail.com writes:
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].
Or use wine_server_fd_to_handle() and call Win32 APIs instead of direct syscalls, that's even easier...