switch to using 'W' versions of windows functions instead of 'A'

[andrewrk]

Here's the situation:

The 'A' versions of windows functions depend on a global code-page setting. We don't want to depend on global state in this way.

The 'W' versions use UTF-16LE with no global state, which at least supports all of unicode.

There are also some microsoft decisions such as: 'A' versions of file paths are limited to 260 bytes while 'W' versions are limited to 32,727. For some new API functions, there is no 'A' version, only 'W'. In general, 'A' seems legacy and deprecated, and 'W' is the correct way to use the Windows API.

Sadly, since Zig uses UTF-8 in the standard library (and this remains the correct decision), this essentially means decoding UTF-8, encoding UTF-16LE, making a Windows API call, decoding UTF-16LE, encoding UTF-8 for many of our syscalls on windows. But that's how it goes in the windows world.

[PavelVozenilek]

'A' functions convert narrow string parameter to UTF16 and call the 'W' variant.

Manual conversion can be done by Win32 functions MultiByteToWideChar/WideCharToMultiByte. Their use is a bit tricky (CP_THREAD_ACP does not work in some situations, CP_OEMCP does) but they allow to find out how much memory will be needed for the conversion and then use good old alloca, not touching the heap.

It is also possible to set codepage to UTF8 per application (or per thread) and let Windows do the conversions.

[andrewrk]

Manual conversion can be done by Win32 functions MultiByteToWideChar/WideCharToMultiByte

Zig will use its own functions for this. Less room for error.

use good old alloca, not touching the heap.

This is not acceptable since the strings have a non-upper-bounded length.

It is also possible to set codepage to UTF8 per application (or per thread) and let Windows do the conversions.

How?

[PavelVozenilek]

Zig will use its own functions for this. Less room for error.

The above functions handle (or claim to handle) invalid input sentences and surrogates.

[alloca] is not acceptable since the strings have a non-upper-bounded length.

I have yet to see string longer than a page. Applications dealing with big texts (editors) split them into parts, long blob is a no-no.
Allocations larger than N can be trivially rerouted to the heap.

It is also possible to set codepage to UTF8 per application (or per thread) and let Windows do the conversions.

How?

Oops, not possible (to switch Win32 app to "UTF8 mode"). I was thinking something else.

[andrewrk]

The above functions handle (or claim to handle) invalid input sentences and surrogates.

Better to not make syscalls when no syscalls are fundamentally required.

Allocations larger than N can be trivially rerouted to the heap.

Not true since we accept an allocator argument when we want to use the heap.

[pluto439]

File paths is probably the only time this really matters. But yeah, to be safe.