Unix FD to Windows File Handles mapping.

[Gabriel Ivăncescu]

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:

1) Use an exception handler in your app.

2) 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.

3) 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.