Just FYI, this does not only change the string mapping but also the entry point chosen. As you might know most Win32 functions have an A and W suffix version. By forcing Charset to Ansi (instead of Auto or Unicode) you bind against the A suffix. I believe Windows 98 or ME were the last ones with an Ansi kernel so what happens is basically that you redirect all these calls through a compatibility layer.

Be careful with functions accepting struct-pointers as parameters as their binary layout may differ betwen Ansi and Unicode (in particular if they contain embedded strings, e.g. a lot of the Win32 font API is affected by this). If you come across a case where a struct is affected by the chosen charset you probably should go for Charset=Unicode instead of Charset=Auto, unless you still have a Win98 machine (or VM) around to test that it works properly in Auto mode.

Basically Ansi/Auto mode is legacy for the Win32 API these days (but Ansi mode does have some use to bind to 3rd party DLLs). Personally I always go for Unicode mode in the Win32 API.

Agree, using unicode/xxxW methods should be probably preferred.

@xoofx, please review the commits above - if everything is ok, I can close this issue.

It should be ok

Actually it is not ok, TextMetricA is defined "wrong" now, that was what I wanted to warn you about ;-)

Changing TextMetricA to unicode doesn't do any direct harm because there are no char fields, so TextMetricA still represents the Ansi version of the struct and the StructLayout annotation is just misleading. However if you are now passing it to a function which has been switched to unicode then you got yourself a bug (because that function will expect the unicode struct). You really should inspect the call sites where TextMetricA is used.

If you have already completely switched to unicode DllImports you can probably get rid of TextMetricA since you already got the unicode TextMetric struct in the same file.

Good point, however TextMetricA will not be used at all - even if it is defined wrong, its just a dead code.
Currently, the only place where it is used - it is the mapping of the ID3DXFont::GetTextMetricsW method, while the ID3DXFont::GetTextMetricsA is removed explicitly from mapping (line 2491 from the mapping above).