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

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

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