UNICODE not defined when creating `.rdl` files

[arnetheduck]

Summary

According to the documentation:

New applications should always call the Unicode versions.

Yet, in the RDL files it seems that during generation, UNICODE was not defined and consequently we end up with the ANSI functions taking first stage in the naming, like with STARTUPINFO = STARTUPINFOA.

It seems preferable that the suffix-free names should prefer the W versions so that these become easier to use and don't require an explicit choice.

In fact, one could argue that the A functions and types should be stowed away into separate, harder-to-find modules since no modern application should be using them.

[riverar]

According to the documentation

The documentation is outdated.

It seems preferable that the suffix-free names should prefer the W versions [...]

Not sure about that, but definitely something we can chat about.

In fact, one could argue that the A functions and types should be stowed away into separate, harder-to-find modules since no modern application should be using them.

Recall, however, that Windows back in 2019 introduced the ability to set UTF-8 as the process' code page, letting the existing -A APIs pass around UTF-8 encoded strings. Arguably modern applications should be using that, not UTF-16 😜. (But like with everything in life, it depends. There are good reasons to use any of the three.)

[arnetheduck]

Lol ok - found a few of these references to A being dead in the docs so TIL.

Not sure about that, but definitely something we can chat about.

Since the A/W-free function aliases / macros are not exposed, perhaps the better choice then is to remove the type aliases too (until the dust settles)?

Until recently, Windows has emphasized "Unicode"

Right - let's see how long "recently" stays in that doc :)

[riverar]

I agree, removal seems ideal. But I haven't had time to sample the impact yet. Maybe Kenny Kerr (@kennykerr) has some initial thoughts.

[kennykerr]

I think the cleanest outcome would be to omit the suffix-free charset aliases and expose only the explicit A and W types. Detection is possible without maintaining a large list: there are currently about 571 aliases shaped exactly like X = XA, and every one has a corresponding XW type. We could identify those pairs, rewrite any references to the concrete type selected by the scrape, and suppress the generic alias.

The complication is that we cannot just stop emitting the aliases, since other declarations may refer to them and leave dangling metadata references. A fully accurate solution would probably scrape both ANSI and Unicode configurations and identify aliases that change from XA to XW, then merge the concrete declarations while dropping the selector aliases. That is a fairly large change to the generation pipeline with a lot of generated-output and compatibility impact. Since callers can already choose the explicit A or W APIs and types, this feels more like worthwhile cleanup than a correctness issue, and probably not a high priority.

Alternatively, the headers just provide some annotation that tells the scraper that these are just charset aliases and we can then conditionally omit them. If that seems like a better idea you might want to propose that over at https://github.com/microsoft/win32metadata as they are actively looking at ways to improve the header semantics.