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
On Sonntag, 17. Januar 2021 20:35:26 CET Sebastian M. Ernst wrote:
Can't you use "winepath" for the conversion?
Regards, Fabian Maurer
"Sebastian M. Ernst" ernst@pleiszenburg.de writes:
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
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
On 18/01/2021 15:57, Sebastian M. Ernst wrote:
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.