The SLAR (vol2) on System.Runtime.InteropServices.CharSet
Continuing in the series sharing some of the information in the .NET Framework Standard Library Annotated Reference Vol 1 and .NET Framework Standard Library Annotated Reference Vol 2 with some information on CharSet.
public enum CharSet
{
CF Ansi = 2,
Auto = 4,
MS CF None = 1,
Unicode = 3,
}
It’s somewhat unfortunate that CharSet.Ansi is the default behavior for PInvoke, since
managed strings and characters are internally Unicode. Win32 APIs often expose both an ANSI
and Unicode export, but by default you end up calling the ANSI one, requiring the Interop
marshaler to copy each Unicode string to a new ANSI string! In contrast, by calling the Unicode
export, the CLR can just pin the managed strings and expose them directly. You can override
the default behavior and explicitly mark each PInvoke signature with CharSet.Auto,
although in the future the CLR will provide a module-level DefaultCharSetAttribute that
allows you to select your own default for all signatures in your module.
BTW – if you like Adam’s take on the world, check out his exhaustive book on Interop…
.NET and COM: The Complete Interoperability Guide
Comments
- Anonymous
November 17, 2005
Another comment about this enum is that it doesn't have a member for zero, which breaks the enum design guidelines (see http://blogs.msdn.com/kcwalina/archive/2004/05/18/134208.aspx). Instead, the None member has a value of 1 and this means you can have a situtation where the default value assigned by the CLR is not a member of the enum. E.g. the following ctor will output "False":
internal class CharSetTest
{
private CharSet m_charSet;
public CharSetTest() : base()
{
Debug.WriteLine(Enum.IsDefined(typeof(CharSet), m_charSet).ToString());
}
}
Having said that, I doubt this enum is used much outside of the existing interop attributes, so it's unlikely to be a problem.