Converting Paths from within Windows processes on top of Wine

[Sebastian M. Ernst]

Hi all,

I have been converting Windows to Unix paths and vice versa from within
Windows processes on top of Wine by calling `wine_unix_to_nt_file_name`
and `wine_nt_to_unix_file_name` in `nddll.dll`.

The signatures of those functions changed from 5.12 to 5.13, which broke
a couple of things. As I need to support multiple versions of Wine, at
least down to 4.0, I need to find a generic (and preferably quick) way
of converting paths.

I am considering to simply call `wine_get_version` for deciding what
signatures to use. Would this approach be advisable or is there a
better, more stable, long-term way of achieving what I want? All of the
mentioned functions are sort of "undocumented" API, as far as I understand.

Best regards & thanks,
Sebastian

[Fabian Maurer]

On Sonntag, 17. Januar 2021 20:35:26 CET Sebastian M. Ernst wrote:
> Hi all,
>
> I have been converting Windows to Unix paths and vice versa from within
> Windows processes on top of Wine by calling `wine_unix_to_nt_file_name`
> and `wine_nt_to_unix_file_name` in `nddll.dll`.
>
> The signatures of those functions changed from 5.12 to 5.13, which broke
> a couple of things. As I need to support multiple versions of Wine, at
> least down to 4.0, I need to find a generic (and preferably quick) way
> of converting paths.
>
> I am considering to simply call `wine_get_version` for deciding what
> signatures to use. Would this approach be advisable or is there a
> better, more stable, long-term way of achieving what I want? All of the
> mentioned functions are sort of "undocumented" API, as far as I understand.
>
> Best regards & thanks,
> Sebastian

Can't you use "winepath" for the conversion?

Regards,
Fabian Maurer

[Alexandre Julliard]

"Sebastian M. Ernst" <ernst(a)pleiszenburg.de> writes:
> Hi all,
>
> I have been converting Windows to Unix paths and vice versa from within
> Windows processes on top of Wine by calling `wine_unix_to_nt_file_name`
> and `wine_nt_to_unix_file_name` in `nddll.dll`.
>
> The signatures of those functions changed from 5.12 to 5.13, which broke
> a couple of things. As I need to support multiple versions of Wine, at
> least down to 4.0, I need to find a generic (and preferably quick) way
> of converting paths.
>
> I am considering to simply call `wine_get_version` for deciding what
> signatures to use. Would this approach be advisable or is there a
> better, more stable, long-term way of achieving what I want? All of the
> mentioned functions are sort of "undocumented" API, as far as I understand.

If possible, I'd recommend using wine_get_unix_file_name() and
wine_get_dos_file_name() from kernel32, the NT ones are considered more
internal. The kernel32 ones should be more stable across versions.

-- 
Alexandre Julliard
julliard(a)winehq.org

[Sebastian M. Ernst]

@Alexandre
> If possible, I'd recommend using wine_get_unix_file_name() and
> wine_get_dos_file_name() from kernel32, the NT ones are considered more
> internal. The kernel32 ones should be more stable across versions.

Thanks a lot, good to know. The signatures of those functions have not
been changed for at least 12 years.

Potentially stupid question: Why are Wine's "Windows" paths using
unicode (wchar) while the unix counterparts are not (char)? It's the
same both in the kernel32 and NT APIs.

@Fabian
> Can't you use "winepath" for the conversion?

I can, but this can be agonizingly slow - compared to a direct call to
the above mentioned APIs. Starting a complete new (sub-) process seems a
bit of an overkill for this kind of task.

Sebastian

[Gabriel Ivăncescu]

On 18/01/2021 15:57, Sebastian M. Ernst wrote:
> Potentially stupid question: Why are Wine's "Windows" paths using
> unicode (wchar) while the unix counterparts are not (char)? It's the
> same both in the kernel32 and NT APIs.

Because the Windows APIs work with wide character strings (UTF-16), 
that's how Microsoft designed them. Unix uses UTF-8 which are char 
(potentially multi-byte) strings.

Both of them can encode Unicode, they just do it in different ways. IMO, 
UTF-8 is much saner, but we're stuck with UTF-16 when working with 
Windows APIs because of Microsoft's decision.