`VkKeyScanW`/`VkKeyScanExW` are missing `CharSet = CharSet.Unicode`

[elachlan]

These functions and probably a lot more we don't know of should have CharSet = CharSet.Unicode.

• https://learn.microsoft.com/en-au/windows/win32/api/winuser/nf-winuser-vkkeyscanw
• https://learn.microsoft.com/en-au/windows/win32/api/winuser/nf-winuser-vkkeyscanexw

We should probably see if we can extract the information somehow, or if that isn't possible manually tag them.

WinUser.h:
https://github.com/microsoft/win32metadata/blob/f86785bec72eef8aa9c9cf5a84fc6d446abe2db5/generation/WinSDK/RecompiledIdlHeaders/um/WinUser.h#L5989-L6003

Related: dotnet/winforms#7945
Winforms Tracking: dotnet/winforms#7468

[elachlan]

@kennykerr Does the Rust projection also have this issue? I imagine it probably defaults to unicode instead of ansi. You might have the opposite problem with VkKeyScanA?

[elachlan]

I guess if WCHAR is used we should add CharSet = CharSet.Unicode?
https://learn.microsoft.com/en-us/windows/win32/learnwin32/working-with-strings

[kennykerr]

I don't think the CharSet attribute is needed. ECMA 335 has a "char" primitive that represents a 16 bit value. This is used by VkKeyScanW. The Win32 metadata then provides Windows.Win32.Foundation.CHAR to represent the 8 bit version used by VkKeyScanA. This is analogous to the difference between CreateFileA and CreateFileW that use PSTR and PWSTR respectively. It might be a bit more harmonious if the Win32 metadata provided an explicit WCHAR type def.

[AArnott]

I agree with @kennykerr. This isn't a bug in the metadata. It's a bug in CsWin32. IIRC, CsWin32 specifies CharSet when string parameters appear in p/invoke methods, but it may not do so when char is used. I'll move this to CsWin32 to investigate.