Unix FD to Windows File Handles mapping.

[Alexandre Julliard]

Zebediah Figura <z.figura12 at 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:
>> 
>> 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].

Or use wine_server_fd_to_handle() and call Win32 APIs instead of direct
syscalls, that's even easier...

-- 
Alexandre Julliard
julliard at winehq.org