Custom and Synthetic (Windows ELK) RegionInfos in .Net 2.0
When we ship the Microsoft .Net Framework, the culture data associated with that version is fixed. In Windows XP we have shipped additional locales (ELKs) that are not native to the Framework. Windows Vista also includes a superset of the locales in the Framework.
In v2.0 of the framework we added the ability for the framework to access these additional Windows-Only "Synthetic" locales from the operating system. The framework gets a list of new locales from Windows and queries those locales for data when a new CultureInfo or RegionInfo is constructed. The list consists of only Culture names, so RegionInfo objects cannot be constructed from the Region names. Instead they must be constructed from the full Culture name. (ie: en-US instead of US).
A similar problem happens with Custom Cultures. Since a custom "my-CULTURE" could have very different region data than a "your-CULTURE" a full culture name is required to construct a custom RegionInfo object.
For what its worth the Windows-Only cultures have to query the OS for all of their data during construction, which has a one-time per process performance impact. Some operations such as CompareInfo.IndexOf and CompareInfo.LastIndexOf can also be slower on Windows XP using those cultures. Performance can be improved by avoiding those methods. Additionally if the one-time cost is too high, performance can be improved by making replacement cultures identical to the Windows-Only cultures being used.
