Representing WCHAR and CHAR types on structs

[sotteson1]

We're using PWSTR and PSTR structs to wrap pointers to strings. They are defined as:

[NativeTypedef]
public struct PWSTR
{
    public unsafe char* Value;
}

[NativeTypedef]
public struct PSTR
{
    public unsafe byte* Value;
}

This lets a projection know that a field/parameter of this type is a string, and not just a pointer to a single char or byte. Now I need to do something about fixed-length strings that appear on structs. I can't use PWSTR and PSTR because these aren't pointers to strings--they are a fixed number of bytes which contain strings:

public struct WIN32_FIND_DATAW
{
...
    public char[260] cFileName;

    public char[14] cAlternateFileName;
}

public struct WIN32_FIND_DATAA
{
...
    public byte[260] cFileName;

    public byte[14] cAlternateFileName;
}

The W version isn't bad because "char" implies that it's a string, but ECMA-335 doesn't have an equivalent for single byte characters, so it's not obvious that WIN32_FIND_DATAA.cFileName is meant to contain single byte characters. The original definition for WIN32_FIND_DATAA uses CHAR which lets the developer know what the field is for:

public struct WIN32_FIND_DATAA
{
...
    public CHAR cFileName[260];

    public CHAR cAlternateFileName[14];
}

I could make a new struct called CHAR and use it in places like WIN32_FIND_DATAA:

[NativeTypedef]
public struct CHAR
{
    public byte Value;
}

public struct WIN32_FIND_DATAA
{
...
    public CHAR[260] cFileName;

    public CHAR[14] cAlternateFileName;
}

To the projection authors @kennykerr, @timsneath and @AArnott, what do you think?

[AArnott]

CHAR is fine, if ECMA lets you define fixed length inline arrays with a custom struct. C# doesn't, so CsWin32 will have to do magic to workaround that. But as you effectively convey the semantic this way, it seems adequate.

The only alternative I can think of is to use byte[260] and add an attribute identifying it as an 8-bit char string.

For 16-bit characters, UTF-16 is well understood when using char in ECMA-355.
How can we tell what the encoding is meant to be when CHAR is used? Is it ANSI or is it UTF-8? Should we make it more explicit in the typedef struct name and define potentially multiple of them? As the projections may want to translate a native string for a given runtime/platform to the CHAR used here, we need to know which encoding to use. If all of them are just one encoding, then let's just document it and go with what you propose. But if it may vary by API, we should consider multiple typedefs IMO.

[sotteson1]

There aren't different Win32 structs/APIs for UTF-8. How the OS interprets the -A APIs is determined by the process code page:

https://docs.microsoft.com/en-us/windows/uwp/design/globalizing/use-utf8-code-page
"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, -A APIs operate in UTF-8. This model has the benefit of supporting existing code built with -A APIs without any code changes."

[timsneath]

I'm a bit unclear right now as to the right path forward for the Dart projection, so this thread is interesting to me. So far I've chosen to only wrap the Unicode APIs, so I don't yet have an opinion on the ANSI/UTF-8 APIs.

Ideally I'd prefer not to expose both APIs -- in the same way that C allows you to set #define UNICODE and then call something like ChooseFont rather than ChooseFontW, I'd like to hide some of the complexity here.

One obstacle I have with structs is that there's no programmatic way to identify the 'unencumbered' name of the struct. I'd like to be able to interrogate an attribute to discover that WIN32_FIND_DATAA is the ANSI version of the WIN32_FIND_DATA struct. Of course, I can't just read the last letter, because the A might just be the last letter of the name itself, rather than a suffix. Today I have had to add a JSON file that provides a mapping between the ILSpy name and its "canonical" representation, but ideally I'd retrieve this from the metadata.

Hope this helps!

[timsneath]

Curious -- what do you do with something like Windows.Win32.Mib.MIB_BOUNDARYROW? How do you know whether this struct is called MIB_BOUNDARY_ROW or is a Unicode struct called MIB_BOUNDARY_RO?

[AArnott]

I don't check structs for the suffix. I only check methods, so such an ambiguity is less likely to exist (and doesn't, AFAIK).
I only generate structs that support methods that are actually generated (or that are explicitly requested in NativeMethods.txt), so you implicitly don't get A structs that aren't used by generated methods.
I also never rename structs as I may do for methods.

[timsneath]

Got it. So your ChooseFont method takes a CHOOSEFONTW as a parameter?

[AArnott]

Yes.

[timsneath]

Ugh. I was hoping you'd come up with some magic that I hadn't yet divined :) OK, @sotteson1, I think you have an opportunity for a customer delighter feature here :)