2 ms·

To me, it's stylistically very weird to include the W in source code that humans will read and write, because the fact that it's the unicode version is immateri

To me, it's stylistically very weird to include the W in source code that humans will read and write, because the fact that it's the unicode version is immaterial, and should appear on literally every API call. If macros are a problem, I feel like the ideal situation would be to declare without the W, and use some compiler or linker hint to append the 'W' to the symbol. (Kind of reminds me of how this topic is approached when doing interop from .NET)

int_19h 5y ago
Not every call - only those that take TCHAR arguments, or structs with TCHAR fields. Why do you think it's immaterial, though? It was back when A-funcs were considered legacy, and W-funcs were the way to go. But now the official stance is that A-funcs are for use with UTF-8. Being explicit about whether you're handling UTF-8 or UTF-16 strikes me like a good idea.
- asveikau 5y ago
  As you say, at various points the A funcs were talked about as legacy or deprecated. WinCE did not have them. During the win7 era refactor of things like kernel32 and advapi, they were also kind of deprioritized, left in the compatibility wrapper and not the first class interfaces. I haven't followed in recent years but when WinRT was coming on the scene they were talking about not including them? But I think of the canonical name as not having either A or W. Rather what you get for TCHAR is a per compilation unit setting, and the A or W in the linker name is sort of an implementation detail. That is to say I'd internalized the world the macros presented, and labelled that as "what makes sense". In particular it is distracting from the semantics of the APIs to have the string type show up in the name. If they could do c++ style name mangling in plain C I feel like they might've and it'd be somewhat more "pure". The macro thing feels like sort of a hack to achieve this.
  - int_19h 5y ago
    You're absolutely correct, this is all how it used to work. The flip to UTF-8 support and the use of A-funcs for that is very recent; the ability of the app to force itself into this mode first showed up in 2019. The naming doesn't really make much sense anymore, but then that wouldn't be the first for a 35-year old API set...

int_19h 5y ago

Not every call - only those that take TCHAR arguments, or structs with TCHAR fields. Why do you think it's immaterial, though? It was back when A-funcs were considered legacy, and W-funcs were the way to go. But now the official stance is that A-funcs are for use with UTF-8. Being explicit about whether you're handling UTF-8 or UTF-16 strikes me like a good idea.

asveikau 5y ago
As you say, at various points the A funcs were talked about as legacy or deprecated. WinCE did not have them. During the win7 era refactor of things like kernel32 and advapi, they were also kind of deprioritized, left in the compatibility wrapper and not the first class interfaces. I haven't followed in recent years but when WinRT was coming on the scene they were talking about not including them? But I think of the canonical name as not having either A or W. Rather what you get for TCHAR is a per compilation unit setting, and the A or W in the linker name is sort of an implementation detail. That is to say I'd internalized the world the macros presented, and labelled that as "what makes sense". In particular it is distracting from the semantics of the APIs to have the string type show up in the name. If they could do c++ style name mangling in plain C I feel like they might've and it'd be somewhat more "pure". The macro thing feels like sort of a hack to achieve this.
- int_19h 5y ago
  You're absolutely correct, this is all how it used to work. The flip to UTF-8 support and the use of A-funcs for that is very recent; the ability of the app to force itself into this mode first showed up in 2019. The naming doesn't really make much sense anymore, but then that wouldn't be the first for a 35-year old API set...