String constants need attribute indicating original encoding

[kennykerr]

Constants like BCRYPT_3DES_ALGORITHM need to indicate whether they were originally ANSI strings like "3DES" or wide strings like L"3DES" because statically compiled languages need to bind them as compile time constants.

[riverar]

We have NativeTypeName, NativeTypedef, NativeArrayInfo, NativeInheritance, and other similar attributes, so perhaps something like this is in order?

// ─── wincrypt.h

// #define CERT_PIN_RULES_CTL_FILENAME_A               "pinrules.stl"
[NativeEncoding("ansi")]
public const string CERT_PIN_RULES_CTL_FILENAME_A = "pinrules.stl";

// #define CERT_PIN_RULES_CTL_FILENAME                 L"pinrules.stl"
[NativeEncoding("utf16")]
public const string CERT_PIN_RULES_CTL_FILENAME = "pinrules.stl";

// ─── bcrypt.h

// #define BCRYPT_DH_PARAMETERS   L"DHParameters"
[NativeEncoding("utf16")]
public const string BCRYPT_DH_PARAMETERS = "DHParameters";

Or would folks prefer a Windows.Win32.Interop.Encoding enumeration over the string?

[mikebattista]

Would need to update the ConstantsScraper to differentiate the various string types and add the attribute.

[monax3]

This would be very helpful, as otherwise these strings are left in a frustrating to deal with state instead of being directly usable as is their intent

[kennykerr]

Yep, we'd really appreciate a fix for this issue.

[mikebattista]

Couple questions from looking into this:

• How do we handle TEXT macros?
• Do we attribute every string or assume lack of an attribute indicates a default like utf-16 and we only attribute strings we know are always ansi?

[kennykerr]

How do we handle TEXT macros?

That's a conditional macro used for APIs that have both an A and a W version where the W version is preferred so I suggest those are always compiled with UNICODE and thus land up as UTF16 strings.

Do we attribute every string or assume lack of an attribute indicates a default like utf-16 and we only attribute strings we know are always ansi?

The headers don't have attributes. They're either ansi or wide string literals so I wouldn't imagine there would be any ambiguity.

[mikebattista]

That's a conditional macro used for APIs that have both an A and a W version where the W version is preferred so I suggest those are always compiled with UNICODE and thus land up as UTF16 strings.

Sounds good.

The headers don't have attributes. They're either ansi or wide string literals so I wouldn't imagine there would be any ambiguity.

I meant in the metadata. Do we want to put an explicit attribute on every string in the metadata? Or assume utf-16 for example and only add an attribute for ansi?

[kennykerr]

Sure, that sounds good.

[kennykerr]

Thanks Mike, this is now plumbed through to Rust: microsoft/windows-rs#2101