3 ms·

Can we finally go back to using *A functions, but with UTF-8?

• NavinF 3y ago
  Yes, see sibling comment. > Until recently, Windows has emphasized "Unicode" -W variants over -A APIs. However, recent releases have used the ANSI code page and -A APIs as a means to introduce UTF-8 support to apps. If the ANSI code page is configured for UTF-8, then -A APIs typically operate in UTF-8. This model has the benefit of supporting existing code built with -A APIs without any code changes.
• skissane 3y ago
  Unfortunately there are still cases where the A API has bugs that the W API lacks, see e.g: https://stackoverflow.com/q/67427569 https://stackoverflow.com/q/67427569 Also, some APIs use buffers with a fixed maximum size, and the A API's buffer isn't big enough to handle the maximum possible data size for the W API. And some APIs are Unicode-only, and don't have A versions. For maximum reliability, better to use W APIs only and do the UTF-8<->UTF-16 conversion yourself. However, in practice, if you just use A APIs only and let Windows do the UTF-8 conversion for you, it is going to work 95% of the time. But maybe at some point you'll hit that 5% where it doesn't. It is more likely if you are using more obscure APIs (like my example at the start of manipulating Windows Terminal Server sessions). More likely for system-level stuff than application-level.
  • account42 3y ago
    > For maximum reliability, better to use W APIs only and do the UTF-8<->UTF-16 conversion yourself. You mean the WTF-8<->WTF-16 conversion. https://simonsapin.github.io/wtf-8/ https://simonsapin.github.io/wtf-8/
• Dwedit 3y ago
  You can if you manage to call the secret API function that initializes the code page data for UTF-8 rather than your system default codepage. Or if you make it Windows 10+ only and add a particular manifest.