Unix FD to Windows File Handles mapping.

Zebediah Figura z.figura12 at gmail.com
Sun Dec 22 10:04:20 CST 2019



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



More information about the wine-devel mailing list